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.

The following table 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 page describes the serial ports and how to use them for instrument control and automation applications.

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.

These protocols are summarized on this page, but for more information regarding their data formats and their use for simplex or multi-drop serial lines, consult Understanding Serial Communications (but keep in mind that that page is directed to the use of the UART Wildcard, so it uses different driver functions).

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. The following table 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 the above table. All of the RS232 signals start with the / (slash, pronounced not) 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 the table, /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.

The PDQ Board's two serial ports support limited use of generating a parity bit. This is an extra single bit appended to the end of each byte or character transmitted, which is set or cleared as necessary to ensure that the total number of '1' bits in the byte is always odd or even. This allows for basic error detection, in that if noise on the transmission line causes one bit to be received incorrectly, either received as a '0' when transmitted as a '1' or vice-versa, the error would be detected due to the count of '1' bits in the byte being odd when it is expected to be even, or vice-versa depending on the parity checking settings.

For example, the ASCII character 'b' is represented in binary as 01100010. If a 'b' is to be transmitted from a serial port with even parity, a parity bit set to '1' will be prepended to the byte transmitted in order to make the total number of '1' bits even: 101100010. The receiving serial port will check that the total number of '1' bits is even and thus accept the byte as valid, discard the parity bit and pass the received character 'b' to the application. The ASCII character 'c', however, is represented in binary as 01100011, and thus a '0' parity bit would be prepended since there are already an even number of '1' bits in that byte: 001100011. Again, the receiving serial port would validate that the total number of '1' bits received is even, discard the parity bit and pass the eight-bit byte with the character 'c' to the application. In either of these cases, a source of noise that caused one bit to be received incorrectly would invalidate the received byte, since the total number of '1' bits would be odd rather than even.

Parity checking is not often used, because it is not a robust method of error detection. If two bits are received incorrectly, the error will go unnoticed by parity checking. For this reason, frame-level cyclic redundancy checks are much more widely used for validating data from serial links, network connections and storage media. For more information see http://en.wikipedia.org/wiki/Cyclic_redundancy_check

If your application requires communicating with a device that expects to receive a parity bit, the generation of a parity bit and selection of even or odd parity, and whether there are seven or eight data bits in each byte, is performed by setting or clearing bits in the configuration registers SCI0CR1 for Serial1 and SCI1CR1 for Serial2. The following bit masks are used for these settings:

// Data Mode: Clear for 8 bits, set for 9 (including possible parity)
#define SCICR1_M_MASK  0x10
 
// Parity Enable: Clear to disable parity check, set to enable highest bit as parity bit
#define SCICR1_PE_MASK 0x02
 
// Parity Type: Clear for even parity, set for odd parity
#define SCICR1_PT_MASK 0x01

The PE bit, with mask 0x02, determines whether the most-significant bit in each byte is used as a parity bit. When PE is cleared (equal to zero), the most-significant bit of each transmitted character will be a data bit. When PE is set (equal to one), the most-significant bit in each byte transmitted will be a parity bit that is either set or cleared by the serial port automatically in order to achieve even or odd parity.

The M bit, with mask 0x10, determines whether eight or nine bits total are transmitted with each byte, regardless of whether or not the most-significant bit is a parity bit. So, for eight data bits with a parity bit, M would be set (equal to one) in order to add an extra bit to each byte transmitted, and PE would be set in order to make that extra bit be used as a parity bit. For seven data bits with a parity bit, M would be cleared (equal to zero), and PE would be set in order to make the most-significant bit of a normal eight-bit byte be used by the serial port as a parity bit.

The PT bit, with mask 0x01, determines whether even parity or odd parity is used if parity bit generation is enabled. If PT is cleared, then all transmitted bytes with a parity bit will have an even number of total '1' bits. If PT is set, all transmitted bytes with a parity bit will have an odd number of total '1' bits.

See the following example for switching among the various parity modes on Serial1. While running this program, the parity settings of Mosaic Terminal may be adjusted, and in each case the message that matches current settings will appear clearly while the other messages will appear garbled.

 1: #include <mosaic\allqed.h>
 2:
 3: // Data Mode: Clear for 8 bits, set for 9 (including possible parity)
 4: #define SCICR1_M_MASK  0x10
 5:
 6: // Parity Enable: Clear to disable parity check, set to enable highest bit as parity bit
 7: #define SCICR1_PE_MASK 0x02
 8:
 9: // Parity Type: Clear for even parity, set for odd parity
10: #define SCICR1_PT_MASK 0x01
11:
12: #define SERIAL1_8BITS() ( SCI0CR1 &= ~SCICR1_M_MASK )
13: #define SERIAL1_9BITS() ( SCI0CR1 |=  SCICR1_M_MASK )
14: #define SERIAL2_8BITS() ( SCI1CR1 &= ~SCICR1_M_MASK )
15: #define SERIAL2_9BITS() ( SCI1CR1 |=  SCICR1_M_MASK )
16:
17: #define SERIAL1_PARITY_DISABLE() ( SCI0CR1 &= ~SCICR1_PE_MASK )
18: #define SERIAL1_PARITY_ENABLE()  ( SCI0CR1 |=  SCICR1_PE_MASK )
19: #define SERIAL2_PARITY_DISABLE() ( SCI1CR1 &= ~SCICR1_PE_MASK )
20: #define SERIAL2_PARITY_ENABLE()  ( SCI1CR1 |=  SCICR1_PE_MASK )
21:
22: #define SERIAL1_PARITY_EVEN() ( SCI0CR1 &= ~SCICR1_PT_MASK )
23: #define SERIAL1_PARITY_ODD()  ( SCI0CR1 |=  SCICR1_PT_MASK )
24: #define SERIAL2_PARITY_EVEN() ( SCI1CR1 &= ~SCICR1_PT_MASK )
25: #define SERIAL2_PARITY_ODD()  ( SCI1CR1 |=  SCICR1_PT_MASK )
26:
27: #define SERIAL1_PARITY_RESET() ( SCI0CR1 &= ~( SCICR1_M_MASK | SCICR1_PE_MASK | SCICR1_PT_MASK ) )
28: #define SERIAL2_PARITY_RESET() ( SCI1CR1 &= ~( SCICR1_M_MASK | SCICR1_PE_MASK | SCICR1_PT_MASK ) )
29:
30: int main()
31: {
32:   int i;
33:
34:   while(1)
35:   {
36:     SERIAL1_PARITY_RESET();
37:     puts("\n\n8 data bits, no parity bit.\n\n");
38:
39:     for( i = 0; i < 10; ++i ) MicrosecDelay( 50000 );
40:
41:     SERIAL1_PARITY_ENABLE();
42:     puts("\n\n7 data bits, even parity.\n\n");
43:
44:     for( i = 0; i < 10; ++i ) MicrosecDelay( 50000 );
45:
46:     SERIAL1_PARITY_ODD();
47:     puts("\n\n7 data bits, odd parity.\n\n");
48:
49:     for( i = 0; i < 10; ++i ) MicrosecDelay( 50000 );
50:
51:     SERIAL1_9BITS();
52:     puts("\n\n8 data bits, odd parity.\n\n");
53:
54:     for( i = 0; i < 10; ++i ) MicrosecDelay( 50000 );
55:
56:     SERIAL1_PARITY_EVEN();
57:     puts("\n\n8 data bits, even parity.\n\n");
58:
59:     for( i = 0; i < 10; ++i ) MicrosecDelay( 50000 );
60:   }
61:
62:   return 0;
63: }

The above parity settings will also determine how incoming data is interpreted (whether the most significant bit is considered a parity bit or part of the data being transmitted, and how many bits total to expect in each byte). However, verifying correct parity of bytes received with a parity bit is currently not supported.

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 (A-H) 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 → Serial Peripheral Interface (SPI)