Serial Communications

The PDQ Board implements a number of asynchronous (unclocked) and synchronous (clocked) serial communications channels. Two asynchronous communications ports named Serial1 and Serial2 can each be configured for RS232 or RS485 protocols. A 2-wire synchronous IIC (Inter-IC) bus provides multi-drop signaling at rates up to 100 Kbaud. Of the processor’s three synchronous SPI (Serial Peripheral Interface) ports, two are available for inter-processor communications on multi-processor systems, and the third is brought out to the Wildcard expansion bus. Table 12-1 summarizes the available serial channels. All of the serial ports are supported by pre-coded C-language software drivers that make it easy to exchange data. This chapter describes the serial ports and how to use them for instrument control and automation applications.

Table 12-1 Serial Channels on the PDQ Board.
Serial Port	Signal Names	Header	Comments
Serial1	/TxD1, /RxD1, XCV1+, XCV1-	HCS12 Comm Header	Standard baud rates up to 115.2 Kbaud. Jumper selectable RS232 or RS485. Jumper selectable termination options. All signals are also available on the Docking Panel.
Serial2	/TxD2, /RxD2, XCV2+, XCV2-	HCS12 Comm Header	Standard baud rates up to 115.2 Kbaud. Jumper selectable RS232 or RS485. Jumper selectable termination options. The RS485 signals are not available on the Docking Panel.
IIC	SDA, SCL	Analog Field Header	2-wire multi-drop bus, up to 100 Kbaud. Each device must have unique numeric address.
SPI0	MOSI, MISO, SCK	Wildcard Bus Header	3-wire multi-drop bus, up to 10 MBaud if SPI bus master, up to 5 MBaud if SPI slave. Each device must have unique hardware chip select signal.
SPI1, SPI2	MOSI1, MISO1, SCK1, /SS1, MOSI2, MISO2, SCK1, /SS2	SPI Header	Used for inter-processor (IP) communications on multi-processor systems such as the PDQScreen. Can be used to communicate with other peripheral devices if multi-processing is not required.

The PDQ Single Board Computer (SBC) has two asynchronous serial communications ports named Serial1 and Serial2. Each serial port can be configured for the RS232 or RS485 protocol, and runs at standard baud rates up to 115,200 bits per second. The default baud rate after a factory cleanup is 115200 baud. The Serial ports are implemented by the dual on-chip hardware UARTs (Universal Asynchronous Receiver/Transmitters) on the Freescale 9S12 (HCS12) microcontroller.

Each UART (sometimes referred to as a "USART") controls the serial-to-parallel and parallel-to-serial conversion and performs all of the timing functions necessary for one asynchronous serial communications link. They translate the bit-by-bit data on the serial cable into bytes of data that can be interpreted by the operating system or by your application program. The communications is asynchronous because no synchronizing clock signal is transmitted along with the data. Rather, the UART deduces the correct time to sample the incoming signal based on the start and stop bits in the signal itself.

The Serial1 and Serial2 ports have identical communications capabilities, although more of the Serial1 signals (both RS232 and RS485) are made available on the Docking Panels headers and connectors. After a factory cleanup, Serial1 is the default serial port for program development and downloading. In a finished instrument, either or both channels can be used to communicate with other serial devices, or with other computers and/or terminals using RS232 or RS485. Having a second serial port is also handy for system debugging. Since both channels can operate simultaneously and independently, serial debugging can be performed while the application program is communicating via its primary channel.

There are several protocols that govern the format of exchanged data, with the RS232 protocol used primarily by personal computers, and the RS485 protocol used in industrial control systems. The Serial 1 and Serial2 ports can be configured for either RS-232 or RS-485 communications at standard baud rates up to 115200 bits per second.

RS232 is by far the most common serial protocol, and is the default protocol for both of the PDQ Board’s serial ports. Its simplest implementation requires only three wires: one to transmit serial data, a second to receive serial data, and a third to provide a common ground reference. RS232 allows both communicating parties to transmit and receive data at the same time; this is referred to as full duplex communications. RS232’s greatest benefit is its universality; most personal computers can use this protocol to send and receive serial data. If your computer does not have an RS232 serial port, low cost USB-to-RS232 serial cables are available; contact Mosaic Industries for details.

RS232 uses inverse logic; that is, a positive bit at the HCS12 UART is inverted by the onboard RS232 driver chip and appears as a negative signal on the serial cable. The terminal’s serial receiver chip re-inverts the signal to its positive sense. The data bits are also transmitted in reverse order, with the least significant bit transmitted first, after a start bit. The specified signal levels of approximately +/- 9 Volts are derived from the PDQ Board’s +5 Volt supply by a dual RS232 driver chip that has a built-in charge pump voltage multiplier.

RS485 is another protocol supported by the primary serial port on the PDQ Board. It is a half duplex protocol, meaning that only one party at a time may transmit data. Unlike the standard RS232 protocol, RS485 allows many communicating parties to share the same 3-wire communications cable. Thus RS485 is the standard protocol of choice when multi-drop communications are required.

Like RS232, the data bits are transmitted in reverse order, with the least significant bit transmitted first. The RS485 protocol uses differential data signals for improved noise immunity; thus RS485 can communicate over greater distances than RS232. Two RS485 transceivers are present on the PDQ Board, one for each channel. The RS485 data direction of Serial1 and Serial2 are controlled by the PJ0 and PJ1 processor pins, respectively. As described below, the RS485Transmit() function controls the RS485 data direction of each serial port.

The primary and secondary serial communications ports are accessible through the PDQ Board's 10 pin, dual row Communications Header (H2) and through the Docking Panel's 10 pin, right-angle, dual row Communications Header (H1) and individual DB-9 Serial 1 and Serial 2 connectors. These 9-pin standard DB-9 serial connectors are located on the back of the Docking Panel. The mating 10-pin connectors that join the H6 header of the PDQ Board to the H4 header of the Docking Panel are typically not accessed directly, and are not discussed in detail here.

The pinout of the PDQ Board’s Communications Header (H2), Docking Panel’s Communications Header (H1), and the Docking Panel’s Communications DB-9 Connectors are shown in the following tables.

There are surface-mount resistor pads on the Docking Panel to bring out the RS485 signals to the DB9 Serial 1 Connector. Please contact Mosaic Industries if you need this custom configuration.

Although the RS232 protocol specifies functions for as many as 25 pins, each communications channel requires only three for simple serial interfaces: /TxD1 (transmit data), /RxD1 (receive data), and DGND (digital ground). The RS232 protocol specifies the use of two separate grounds, a signal ground and a protective (or chassis) ground. The PDQ Board does not differentiate between these. To provide a convenient means of attaching two grounds to the serial cable, there are several pins (labeled DGND) on the communications connector that are connected to the controller’s ground plane.

Given the availability of ready-made communications cables, it is not necessary to study or understand the following descriptions of cable connections. These detailed signal descriptions and cable diagrams are presented to provide complete information for those who have special communications requirements and for those who wish to make their own application-specific communications cables. Most computers conform to IBM PC AT-compatible RS232 interfaces which use 9-pin D-Type connectors, consequently the PDQ Board brings out its serial ports to two female 9-pin D-Type connectors on the Docking Panel. Table 12-6 shows the connection diagram for a standard 9-pin serial cable.

We can gain insight into the operation of the RS232 protocol by examining the signal connections used for the primary serial port in Table 12-6. All of the RS232 signals start with the / (slash) character to indicate that the signals on the serial cable are logically inverted.

The transmit and receive data signals carry the messages being communicated between the PDQ Board and the PC or terminal. The PDQ Board’s transmit data signal /TxD1 (pin 2 on the 9-pin serial connector) is connected to the terminal’s receive data signal /RxD (pin 2 on its 9-pin connector). Likewise, the terminal’s transmit signal /TxD is connected to the PDQ Board’s receive signal /RxD1. Chassis and signal grounds are connected together to the digital ground (DGND) signal.

From the PDQ Board’s point of view, these three signals (/TxD, /RxD, and ground) are the only connections required to perform serial communications. While these signals provide a data path, they do not provide hardware handshaking that allows the two communicating parties to let each other know when they are ready to send or receive data.

The RS232 protocol provides for four handshaking signals called ready to send (RTS), clear to send (CTS), data set ready (DSR), and data terminal ready (DTR) to coordinate the transfer of information. The PDQ Board, however, does not implement hardware handshaking. Rather, it relies on software handshaking via transmission of XON/XOFF characters (ascii 0x11 and 0x13, respectively) to coordinate data transfer and ensure that information is not lost when one of the communicating parties is busy.

Many terminals and PCs, however, do rely on hardware handshaking to determine when the other party (in this case the PDQ Board) is ready to accept data. By connecting pairs of these handshaking signals together, the terminal or PC can be made to think that the PDQ Board is always ready to send and receive data. Thus in Table 12-6 , /RTS1 is connected to /CTS1, and /DSR1 is connected to /DTR1 and /DCD1 onboard the PDQ Board using zero ohm shorting resistors. These signals may alternatively be redirected to the second serial port if hardware handshaking is required.

The secondary serial port is connected similarly except that the onboard connection of /RTS to /CTS, and /DSR to /DTR are permanent.

The default serial routines used to download programs to the operating system assume that full duplex communications are available, so you cannot use the RS485 protocol to program the controller. If your application requires RS485, you can use the secondary serial port (serial2) to program and debug your application code using the RS232 protocol, and use the primary serial port (Serial1) for RS485 communications. The advantage of using Serial1 for RS485 is that the Serial1 RS485 signals are also available on the Docking Panel, while the Serial2 RS485 signals are available only on the PDQ Board’s Serial Communications Header. If this limitation is not a problem, you can reverse the roles of the Serial1 and Serial2 ports, because they have identical communications capabilities.

A jumper labeled "1 485En" (J4) enables RS485 operation on the Serial1 port if the jumper cap is installed, and configures Serial1 for RS232 operation if the jumper cap is not installed.

• For Serial1 RS232 operation: Remove the jumper shunt from "1 485En" (J4). In this case, cable connections may be made to Serial 1 on either the 10-pin PDQ Board Serial Communications Header, or the Docking Panel’s 10-pin right-angle Serial Header, or the Docking Panel’s Serial1 DB-9 Connector.
• For Serial1 RS485 operation: Install the jumper shunt onto "1 485En" (J4). In this case, cable connections may be made to Serial 1 at pins 5 and 6 of the PDQ Board’s 10-pin Serial Header , or pins 5 and 6 of the Docking Panel’s 10-pin right-angle Serial Header. By default, the RS485 connections are not brought out to the Docking Panel’s DB-9 Serial1 Connector, although custom placement of zero-ohm surface-mount resistors on the Docking Panel can route the RS485 signals to the DB-9.

Enabling RS485 on the Serial2 port is parallel to the process described above. A jumper labeled "2 485En" (J7) enables RS485 operation on the Serial2 port if the jumper cap is installed, and configures Serial2 for RS232 operation if the jumper cap is not installed.

• For Serial2 RS232 operation: Remove the jumper shunt from "2 485En" (J7). In this case, cable connections may be made to Serial 2 on either the 10-pin PDQ Board Serial Communications Header, or the Docking Panel’s 10-pin right-angle Serial Header, or the Docking Panel’s Serial2 DB-9 Connector.
• For Serial2 RS485 operation: Install the jumper shunt onto "2 485En" (J7). In this case, cable connections may be made to Serial 2 at pins 4 and 10 of the PDQ Board’s 10-pin Serial Header, or pins 5 and 6 of the Docking Panel’s 10-pin right-angle Serial Header. By default, the RS485 connections are not brought out to the Docking Panel’s DB-9 Serial1 Connector. Contact Mosaic if you require RS485 signals to be routed to the DB-9 Connector.

RS485 multi-drop networks are daisy-chained networks with a single cable connecting multiple devices. Two devices are at the ends of the cable, while others are connected somewhere in between. The end devices are responsible for terminating the cable so that there are no reflections from the cable ends. You have several options for terminating the RS485 line at the PDQ Board:

• No termination – If the PDQ Board is not an end device, you should not terminate that cable. In that case, do not install jumper caps at the jumpers labeled "Term" or "RTerm".
• Resistive termination – If the PDQ Board is at the end of the RS485 cable you can terminate the cable by installing jumper caps at both jumper locations, "Term" and "RTerm". That places a 120 Ω resistor across the RS485 differential line at the driver chip. The other end of the cable should be terminated similarly.
• RC termination – In some applications requiring low power you may not want to load the line with 120 Ω resistors at each end. In that case you may terminate the lines with a series RC network comprising a 0.1 μF capacitor in series with a 120 Ω resistor. To do that, install a jumper cap at "Term" only.
• Bias termination – Using resistive termination decreases noise immunity, particularly if the cable is loaded with many devices. In that case, when using very long cables you can improve noise immunity and assure a valid idle level when the transceiver is not active by installing bias resistors. To do that, install 1kΩ resistors on the board at locations R56 and R64 for Serial_2 and R55 and R57 for Serial_1. Use 0603 SMT sized resistor packages. They should generally not be needed, except if you use long cables, multiple RS485 devices, and resistive termination.

Using the primary Serial1 port is easy. In fact, you have been using it all along as you worked through the examples in this document. The terminal program communicates with the PDQ Board via this serial port. The standard C serial I/O routines such as printf(), scanf(), putchar(), and getchar() give you high level access to the serial ports. All high level routines call the following low level revectorable serial primitives (declared in the C:\MosaicPlus\c\libraries\include\mosaic\SERIAL.h file) to access the currently active serial port:

int   AskKey(void)   // returns a flag that is true if an input char is waiting
char  Key(void)      // waits for and returns the next input char
void  Emit(char)     // outputs the specified char to the serial port

Because all of the serial I/O routines on the PDQ Board are revectorable, it is very easy to change the serial port in use without modifying any high level code.

Let’s do a quick experiment to see how easy it is. We’ll use code from the GETSTART.c program which was introduced in the chapter titled Your First Program. If you have already downloaded the program, you are ready to go. If your board is presently running a multitasking application, type

WARM↓

to stop the program now.

If you have not yet compiled the "Get Started Demo" program and you want to do the exercises here, do so now:

Open a new "Get Started Demo".

Look for this icon under Project→ New Project:

Get Started Demo

Once the project is open, click Build→ Build, and after the compilation is done, enter the Mosaic Terminal by clicking Tools→ Mosaic Terminal and use the Send File menu item to send GETSTART.DLF to the PDQ Board.

Before running the program, let’s switch to the secondary serial port. We assume that you are now communicating with the PDQ Board via the default Serial1 port at the standard 115200 baud rate. To switch to the secondary serial port running at the same baud rate, simply type from the terminal the following interactive QED-Forth commands:

DECIMAL ↓
1152  2  BAUD↓
USE.SERIAL2↓

The DECIMAL command makes sure that numbers are interpreted in the decimal base. The BAUD operator expects two numbers on the stack: the desired baud rate divided by 100, and the serial channel_id (1 or 2). Typing the number 1152 specifies 115200 baud, and the 2 specifies Serial2. The USE.SERIAL2 command means that the operating system’s terminal interface now communicates via Serial2. Because we chose the default baud rate (which the terminal is presumably already set for), you can simply move the serial cable from the Serial Port 1 connector to the Serial Port 2 connector on the Docking Panel to complete the change to the new port. Typing a carriage return at the terminal should now produce the familiar ok response via the Serial2 port. If it doesn’t, confirm that the terminal’s baud rate is correct by selecting the Comm item in the Settings menu of the Mosaic Terminal program, and click on 115200 baud.

Assuming that the GETSTART.dlf file has been loaded into the board, you can now type:

main↓

and you’ll see the familiar starting message of the GETSTART.C program:

Starting condition:
The radius is      0; the circular area is 0.000000.
ok

In fact, the program works the same as it did before, but now it is using the secondary serial port instead of the primary port – and you didn’t even have to recompile the code!

For those of you interested in the details, here’s how it works: The low-level serial driver routines named Key(), AskKey() and Emit() are revectorable routines that can be redirected to use either of the serial ports. By interactively executing the QED-Forth function

USE.SERIAL2↓

before calling main, we revectored these serial primitives to use the Serial2 port.

You can invoke the C version of this routine by calling

UseSerial2()

anywhere within your C program’s source code file. Function prototypes for this function and other versatile serial I/O routines are declared in the C:\MosaicPlus\c\libraries\include\mosaic\SERIAL.h header file, and are described in detail in the C Glossary.

To return to using the primary serial port, simply type from the active terminal the QED-Forth command:

USE.SERIAL1↓

which transfers control back to serial port 1 running at the prior established baud rate (typically 115200 baud). A hardware reset (pressing down on the reset switch) has the same effect. If you do this now, remember to move the PDQ Board’s serial connector back to Serial Port 1.

If you always want the PDQ Board to start up using the secondary serial port as the default serial communications link, you can type at your terminal:

SERIAL2.AT.STARTUP↓

The complementary routine is:

SERIAL1.AT.STARTUP

which makes the Serial1 port the default startup serial link. The BAUD routine described at the start of this subsection configures the baud rate of each of the Serial1 and Serial2 channels. Its parameters are the baud rate divided by 100, and the serial channel_id (1 or 2). The specified baud rate is established immediately, and is also stored in the operating system’s EEPROM area so that subsequent restarts will re-establish the specified baud rate. The default baud rate for both Serial1 and Serial2 is 115200 baud after a factory cleanup.

All of these functions that we are calling interactively via the operating system can also be called from C in your program source code; their C function prototypes are as follows:

void UseSerial1( void );
void UseSerial2( void );
void Baud( int baud_over_100, int serial_port_id );
void Serial1AtStartup( void );
void Serial2AtStartup( void );

In summary, the code provided for implementing the second serial port is very flexible and can be used to support dual concurrent communications ports. Data translation between different machines can be performed with ease, and applications that communicate via the one serial port can be debugged using the other serial channel.

In multitasking systems using both serial ports Serial1 and Serial2, the application code should include one of the commands

SERIAL_ACCESS = RELEASE_ALWAYS;
SERIAL_ACCESS = RELEASE_NEVER;

before building the tasks. This prevents contention that can occur if the default RELEASE_AFTER_LINE option is installed in the SERIAL_ACCESS user variable.

The Serial1 and Serial2 ports are is supported by the HCS12's dual on-chip hardware UARTs, and do not require interrupts to work properly.

Connecting computers together in multi-drop networks is common in factories and laboratories. In these distributed processing networks, a variety of machines and instruments work locally, but communicate and share data or resources with one another globally using a single serial link. You can use one or both of the PDQ Board’s RS485 links to create such a multi-drop serial network.

In the most common multi-drop RS485 protocol, one computer is designated as a master and the rest of the computers or devices on the serial bus are designated as slaves. At any given time, only the master and a single active slave communicate. The remaining inactive slaves may actively receive, or listen to, data on the communications line, but only one slave at a time can transmit a message. If more than one slave tried to drive the transmit line simultaneously, their serial drivers would fight with each other for control of the bus. To ensure that no two devices drive the network at the same time, it is necessary that each slave device be able to disable its own RS485 data transmitter.

Because the requirements of every multi-drop application are so unique, it is difficult to specify or design a software protocol that meets everyone’s needs. This section describes the driver routines that control the RS485 transceiver, and presents some ideas that may prove useful in designing a multi-drop data exchange protocol.

The PDQ Board controls the Serial1 and Serial2 RS485 transceivers with bits PJ0 and PJ1, respectively, of PORTJ of the processor. When this bit is high, the transceiver is in transmit mode. When it is low, the transceiver is in receive mode. Three built-in routines facilitate control of the RS485 transceiver:

void RS485Init( void );
void RS485Receive( int serial_port_id );
void RS485Transmit( int serial_port_id);

RS485Init() configures PORTJ to ensure that bits 0 and 1 are outputs, and disables both RS485 transmitters, leaving the Serial1 and Serial2 RS485 channels in receive mode. RS485Receive() accepts a serial_port_id input parameter of 1 or 2 to specify Serial1 or Serial2, respectively, and clears the appropriate PORTJ bit to place the transceiver in receive mode. RS485Transmit() accepts a serial_port_id and places the specified transceiver in transmit mode.

To use a PDQ Board as a slave in a multi-drop network, simply define a word, (named Silence(int serial_port_id), for example) that when executed calls RS485Receive() to wait for any pending character transmission to complete, then disable the transmitter, and then execute a routine such as Key() to listen to the communications on the serial bus. The Silence() routine searches the incoming serial characters for a pre-determined keyword (for example, the ascii name of this particular slave). When the network master wants to talk to this particular slave, it outputs the slave’s ascii name onto the serial bus. When the keyword name is received by the Silence() routine running in the slave, the slave PDQ Board executes RS485Transmit() to send an acknowledgment to the master (which should now be listening to the serial bus to accept the acknowledgment). The master and slave can then exchange data.

The data exchange format may be a line of ascii text, a byte count followed by data and a checksum, or a line in the Intel or Motorola hex dump formats (see the glossary entries for DUMP.INTEL, DUMP.S1, and DUMP.S2 in the Interactive Debugger Glossary section of the C Function Glossary for descriptions of these formats). The master and slave could even exchange ascii QED-Forth operating system commands. When the exchange is complete, the slave can again execute the Silence() routine to disable its transmitter and begin listening for its name.

See also → Synchronous Serial Peripheral Interface (SPI)