a8bd4794d1
* README.md - Add new readme indicating that this host program is only intended for the stream-based demo, and explaining how to use it * host.adb - Add much more comments in the header block explaining how to use this program and why it is needed - Parameterize the host port number instead of hard-coding it * demo_serial_port_blocking.adb - Use normalized (new) procedure names for Send and Receive, for consistency with other versions - Add comments re: baud rate and other settings required * demo_serial_port_nonblocking.adb - Better name for local procedure - Add many more comments re: settings * demo_serial_port_streaming.adb - Replace source code in comment header block with location of the actual code and project file. - Add comment re: serial port settings * peripherals_blocking.ads - Peripheral should be a constant - COM can now reference the designated USART, the component of Peripheral * peripherals_nonblocking.ads - Same as for peripherals_blocking.ads * peripherals_streaming.ads - Same as for peripherals_blocking.ads * serial_io-blocking.ads - Type Serial_Port now designates a USART rather than type Peripheral - No longer provide call through routines for the Serial_IO package's Initialize_Hardware and Configure since client can easily call them. Better separation of concerns as a result. - Change signatures of internal routines to be access-to-USART * serial_io-blocking.adb - Internal simplifications reflecting change to access discriminant now designating type USART - Remove code for Initialize_Hardware and Configure, per removal from package spec * serial_io-nonblocking.ads - Type Serial_Port now designates a USART rather than type Peripheral - No longer provide call through routines for Serial_IO packages Initialize_Hardware and Configure since client can easily do so, and simplifies this package - Change signatures of internal routines to be access-to-USART * serial_io-nonblocking.adb - Internal simplifications reflecting change to access discriminant now designating type USART - Remove code for Initialize_Hardware and Configure, per removal from package spec - Use short-circuit control forms in ISR since don't need to check both conditions, should be a little faster * serial_io-streaming.ads - Type Serial_Port now designates a USART rather than type Peripheral - No longer provide call through routines for Serial_IO packages Initialize_Hardware and Configure since client can easily do so, and simplifies this package - Change signatures of internal routines to be access-to-USART * serial_io-streaming.adb - Internal simplifications reflecting change to access discriminant now designating type USART - Remove code for Initialize_Hardware and Configure, per removal from package spec * serial_io.ads - Procedure Initialize_Hardware's formal parameter is no longer an access parameter - Procedure Configure's first formal parameter is now access to USART * serial_io.adb - Change to prcoedures' signatures as per spec - Procedure Configure now uses distinguished receiver syntax for USART routines, much cleaner
This project defines multiple forms of higher-level "serial port" abstractions, i.e., higher than direct use of USART/UART devices, along with demonstrations of their use.
Each demo illustrates a distinct serial port abstraction.
One such serial port uses polling to control the underlying USART interaction for sending and receiving. This is said to be a "blocking" serial port because calls to send and receive using these ports wait until the I/O completes before returning to the callers.
Another serial port uses interrupts to control the USART interactions and is said to be "non-blocking" because callers will return from the send and receive calls without waiting for sending or receiving to complete. (A means of waiting for eventual completion is provided.)
For those two abstractions' demonstrations, you must use an app on the host that communicates with host serial ports to show the characters sent to and received from the target. For example, we use one named HyperSerialPort on Windows.
Another serial port abstraction supports use of streams to send and receive binary values of arbitrary types, not just characters and arrays of characters. NOTE: THIS VERSION REQUIRES THE RAVENSCAR-FULL-* RUNTIME LIBRARIES. Set the scenario variable accordingly.
In all cases the program running on the target board communicates with a program running on the host computer. Characters are sent and received over a serial line presumably connected to a host computer (see below for connection hardware and software).
The first two kind of serial ports just send and receive characters directly (via message buffers), rather than using streams. As such, a program such as HyperSerialPort will suffice to send and receive characters on the host.
For the streams-oriented serial port demo, we provide the sources for a "host" app to run on the host computer. This "host" app interacts with the user to send and receive strings to the target board using streams rather than raw characters. Although streams allow arbitrary binary values to be sent over a common, shared stream, and thus provide great flexibility, for this demonstration we only work with Strings.
In all cases you need a way to connect the GPIO pins on the target board to a serial port on your host computer.
You can use a USB cable specifically designed to appear as a COM port. For example:
- Mouser Part No: 895-TTL-232R-5V
- Manufacturer Part No: TTL-232R-5V
- Manufacturer: FTDI
- Description: USB Cables / IEEE 1394 Cables USB Embedded Serial Conv 5V 0.1" Header
Note that that is a 5-volt cable, and that some pins cannot handle 5 volts. The pins we use in these demonstrations are 5-volt compatible so that is not a problem, but it could be a problem with other boards or pins. If so, 3-volt versions of these cables are also available.
The end of the cable is a female header, described in the datasheet
(DS_TTL-232R_CABLES-217672.pdf). See pages 10 and 11 in particular.
Using male-to-female connector wires, connect the following on the target board GPIO pins:
- header pin 1, the black wire's header slot, to a ground pin on the board
- header pin 4, the orange wire's header slot, to PB7
- header pin 5, the yellow wire's header slot, to PB6
Header pin 4 on the cable is TXD, the transmit data output. Header pin 5 on the cable is RXD, the receive data input. See table 4.1 on page 11 of the datasheet for all the pins.
On the host, just plug in the USB-to-serial cable.
The USART is set to: 115_200, N81, no flow control so change the app's connection accordingly.