UART Wildcard User Guide
Configure the UART Wildcard for RS232, RS485 or RS422 communications.

The UART Wildcard implements two full-duplex serial ports that can be configured for RS232, RS422, and RS485 protocols to implement the communications links that are often needed in instrument control applications, including the MODBUS protocol. This tiny 2" by 2.5" board is a member of the Wildcard™ series that connects to Mosaic's line of microcontroller-based embedded computers. A UART (Universal Asynchronous Receiver/Transmitter) chip (sometimes called a USART) on the Wildcard implements the conversion between the parallel Wildcard bus and the RS232 and RS485/RS422 asynchronous serial links. The Wildcards make it easy to implement instrumentation and automation solutions.

This document describes the capabilities of the UART Wildcard, tells how to configure the hardware, and presents an overview of the driver software. A glossary of the software device driver functions, demonstration program source code, and complete hardware schematics are presented in the accompanying pages.

The UART Wildcard may be configured for RS232, full-duplex RS422, or multi-drop RS485 serial communiction protocols. To learn more about these communication hardware/software protocols, their baud rates and data formats, see Understanding Serial Communications.

The UART Wildcard comprises a Wildcard bus header, field header, digital logic circuitry, a dual UART chip, and driver/receiver circuitry for the RS232, RS422, and RS485 protocols. Jumpers enable module address selection, conversion from RS422 to RS485, and the installation of optional RS422/485 termination networks. The Wildcard bus header interfaces to the host processor (QCard, QScreen, Handheld, or PDQ series controller), and the field header brings out the serial I/O signals for the two serial channels.

The following photo shows the positions of the connectors on the board:

At the top of the board is the field header (H3) for serial communications connections. The Wildcard connector at the bottom, H1, plugs into the controller stack. Two jumpers, J1 and J2, configure the address of the board. Three jumpers for each serial communications port (J3, J4, and J5 for Serial Port 1, and J6, J7, and J8 for Serial Port 2) choose whether RS232/485 or RS422 are used and set a termination resistor on RS485 lines.

To connect the UART Wildcard to the Wildcard bus on the controller board:

With the power off, connect the female 24-pin side of the stacking go-through Wildcard bus header on the bottom of the UART Wildcard to Module Port 0 or Module Port 1 on the controller or its mating PowerDock. The corner mounting holes on the Wildcard should line up with the standoffs on the controller board. The module ports are labeled on the silkscreen of the controller board. Note that the UART Wildcard headers are configured to allow direct stacking onto the controller board, even if other Wildcards are also installed. Do not use ribbon cables to connect the UART Wildcard to the Wildcard bus. Use of ribbon cables on the UART Wildcard’s field header is fine.

Once you have connected the UART Wildcard to the Wildcard bus, you must set the address of the module using jumper shunts across J1 and J2.

The Wildcard Select Jumpers, labeled J1 and J2, select a 2-bit code that sets a unique address on the module port of the controller board. Each module port on the controller accommodates up to 4 Wildcards. Wildcard Port 0 provides access to Wildcards 0-3 while Wildcard Port 1 provides access to Wildcards 4-7. Two Wildcards on the same port cannot have the same address (jumper settings). The following table shows the possible jumper settings and the corresponding addresses.

The remaining jumpers on the UART Wildcard enable conversion from RS422 to RS485, and the installation of optional RS422/485 termination networks. There are three jumpers for each serial port. The silkscreen on the UART Wildcard designates Port1 and Port 2 as the two jumper regions. Within each region is a pair of jumpers labeled RS485, and an additional jumper labeled Term, which stands for termination.

Two jumpers on each port configure that port to be either RS422 or RS485 capable. In RS422 mode, two wires are used for receive and two for transmit. In RS485 mode only one pair is used for both transmit and receive; the RS422 transmit and receive pairs are shorted together with a pair of onboard jumpers. To use the half duplex RS485 protocol on a given serial port, install the two jumper caps on the two jumpers labeled RS485 in that port’s jumper area (jumpers J3 and J4 for Port1 or jumpers J6 and J7 for Port2). To use RS422, remove the jumper caps from the RS485 jumpers. If the port is software configured for RS232 the jumpers have no influence. The remaining protocol configuration is software programmable as described below.

Each serial communications link can be thought of as a transmission line with a characteristic impedance. When the signals on the transmission line encounter a non-matching impedance, a portion of the signal energy is reflected, thereby degrading the signal-to-noise ratio of the communications link. One advantage of the differential signaling scheme used by the RS422 and RS485 protocols is that a straightforward termination network can be installed at the end of the transmission line to minimize unwanted reflections. The UART Wildcard provides a default termination network for each serial port.

To install the termination network, simply place a jumper cap on the jumper labeled Term (termination) in that port’s jumper area (jumper J5 for Port1 or jumper J8 for Port2). The jumper places a 100 Ω resistor in series with a 0.1 μF capacitor across the differential signal conductors. The capacitor blocks DC current that would greatly increase the power drain of the circuit. The 100 Ω resistor provides the effective termination resistance seen by the high frequency bit transitions.

Aside from the RS485 and termination network jumpers described above, all remaining protocol selections are performed under software control by writing to control registers implemented by logic on the Wildcard. It is not necessary to understand this implementation detail, as the pre-coded functions described in the Glossary transparently manage these registers for you. This information is presented for those who want to know how the low level hardware works.

The programmable logic chip on the UART Wildcard implements four registers named CONFIG1, CONFIG2, DIRECTION1, and DIRECTION2. They are addressed sequentially starting at offset 0x10 in the Wildcard’s address space. The CONFIG registers configure the associated serial channel’s protocol. The DIRECTION registers are used to control the direction of the RS422/485 driver chips by enabling and disabling the channel’s receiver and transmitter. The following table describes the contents of these registers. The D4 through D0 labels at the top of the table designate the data bits that access the information in the register.

CONFIG1 and CONFIG2 configure the protocols for serial Channel1 and Channel2, respectively. In both configuration registers, D1 is set true in RS232 mode and false otherwise, and D0 (labeled RS4xx) is set true in RS422 or RS485 mode, and false otherwise. Recall that RS422 and RS485 share a driver/receiver chip. These bits determine which input receiver drives the serial input pin on the UART chip for the specified channel.

When set, the RS232_En bit in CONFIG1 powers up the serial driver chip that handles the transmit and receive signals for Channels 1 and 2. When set, the Handshake_En bit powers up the serial driver chip that handles the modem handshaking signals for Channel1. The Modem bit is set to true if the optional modem handshaking signals are in use. When set, this bit causes the hardware to route the incoming signal from the /RxD2/DCD1 pin on the field header to the /DCD1 pin on the UART. Handling of the modem signals is described in more detail in the next section.

The DIRECTION1 and DIRECTION2 registers control the transmitter and receiver enable signals for the RS422/RS485 driver/receiver chips for Channels 1 and 2, respectively. The Ch1_Xmit and Ch2_Xmit turn the respective transmitters ON when the bit is set, and the active low Ch1_Rcv_Bar and Ch2_Rcv_Bar signals turn the respective receivers ON when the bit is clear. In RS422 mode, both the driver and the receiver are enabled, thereby enabling full duplex communications. In RS485 mode, the driver is OFFand the receiver is ON in receive mode, and the driver is ON and the receiver is OFF in transmit mode.

The configuration and direction registers are transparently managed by the functions described in the Glossary below.

Most users of the UART Wildcard implement direct computer-to-computer communications via a serial cable. In these cases, hardware handshaking signals are typically not required. Rather, frequent polling or software-controlled handshaking by means of the XON and XOFF characters serves to ensure that the receiving computer is not overwhelmed by the incoming data stream.

Some applications, however, require the use of hardware handshaking signals that enable the sender and receiver to signal their readiness to send and receive data. Communication over a telephone link via an RS232 modem is a prime example of such an application. The UART Wildcard implements five handshaking signals defined by the RS232 protocol to support a modem connection on serial Channel 1. If these modem handshaking signals are enabled, serial Channel 2 cannot be used for independent RS232 communications; however, it can still be used for RS422 or RS485.

DTR, DSR, RTS, and CTS are handshaking signals that can be set and checked by the application software to control the flow of data. These signals are buffered by a single chip that can be powered down by the Set_Protocols function if the handshaking signals are not in use.

DCD is an input from the modem that becomes active when an incoming data stream is detected on the phone line. DCD shares the RS232 receiver for serial channel 2; thus, Channel 2 cannot be configured for RS232 if the modem configuration is selected for Channel 1. The protocol initialization software function Set_Protocols is smart enough to detect an invalid protocol specification, returning an error parameter if it is attempted.

The supported modem signals are listed in the following table:

All of the signals listed in the above table are active low. That is, when active they are at a logic low (0 volts) at the UART chip, which corresponds to a positive voltage on the RS232 cable.

The Glossary includes functions that control and monitor the signals listed in the above table.

The serial communications signals are brought out to a 24-pin dual row header on the UART Wildcard as shown in the following table:

/TxD1 and /RxD1 are the RS232 transmit and receive signals, respectively, for Channel 1. /TxD2 and /RxD2 are the RS232 transmit and receive signals for Channel 2.

RCV1+ and RCV1- are the Channel 1 differential RS422/485 receive signals. XMIT1+ and XMIT1- are the Channel 1 differential RS422/485 transmit signals. To implement an RS485 protocol on Channel 1, install the jumper caps on the jumpers labeled RS485 in the Port1 jumper area on the UART Wildcard. This connects RCV1+ to XMIT1+, and connects RCV1- to XMIT1- to implement the half-duplex serial link on Channel 1.

RCV2+ and RCV2- are the Channel 2 differential RS422/485 receive signals. XMIT2+ and XMIT2- are the Channel 2 differential RS422/485 transmit signals. To implement an RS485 protocol on Channel 2, install the jumper caps on the jumpers labeled RS485 in the Port2 jumper area on the UART Wildcard. This connects RCV2+ to XMIT2+, and connects RCV2- to XMIT2- to implement the half-duplex serial link on Channel 2.

DTR1, DSR1, RTS1, and CTS1 are the optional modem handshaking signals. The DCD1 (data carrier detect) modem signal is shared with /RxD2 on pin 18 of the header. The hardware automatically routes this signal to the DCD input on the Channel1 UART if Channel1 is configured for the RS232 modem protocol.

This section presents some suggested cable connections for common protocols. Each application will typically require a custom cable assembly to meet the needs of that project.

The following table illustrates the connections required to implement two RS232 ports, each using a standard 25-pin D-type connector.

 Signal  |  Pin# at UART  | Pin# on 25 pin |  Pin# on 25  | Signal  |
Name at  | Wildcard Field |    Channel1    | pin Channel2 | Name at |
 UART    |    Connector   |   Connector    |  Connector   | Remote  |
Wildcard |                |                |              |         |
_________|________________|________________|______________|_________|

 /TxD1            1  ____________  3                         /RxD
 /RxD1            2  ____________  2                         /TxD
  DGND            3  ____________  1                          FGND
  DGND            4  ____________  7                          SGND
 /TxD2           17  ____________________________  3         /RxD
 /RxD2           18  ____________________________  2         /TxD
  DGND           19  ____________________________  1          FGND
  DGND           20  ____________________________  7          SGND
                                   4 ___           4 ___      RTS
                                   5 ___|          5 ___|     CTS
                                   6 ___           6  ___     DSR
                                  20 ___|         20 ___|     DTR

Note that /TxD at the local UART Wildcard connects to /RxD at the remote, and the local /RxD connects to /TxD at the remote. Also note that the RS232 handshaking signals RTS and CTS are connected to each other with a shorting wire at the D connector. Similarly, the RS232 handshaking signals DSR and DTR are connected to each other at the D connector. This standard scheme makes the remote computer think that it is always OK to send and receive data.

The following table/diagram shows a cable that supports a modem on channel 1.

  Signal  |  Pin# at UART  | Pin# on 25 pin | Signal  |
  Name at | Wildcard Field |    Channel1    | Name at |
  UART    |   Connector    |   Connector    | Remote  |
 Wildcard |                |                |         |
__________|________________|________________|_________|


 /TxD1            1 _______________ 3        /RxD
 /RxD1            2 _______________ 2        /TxD
  DGND            3 _______________ 1         FGND
  DGND            4 _______________ 7         SGND
  CTS1           12 _______________ 4         RTS
  RTS1           11 _______________ 5         CTS
  DTR1            9 _______________ 6         DSR
  DSR1           10 ______________ 20         DTR
/RxD2/DCD1       18 _______________ 8         DCD

Note that the handshaking signals are brought out to the 25 pin D-connector. The CTS1 (clear to send) input to the UART Wildcard connects to the RTS (ready to send) output from the remote. The DSR1 (data set ready) input to the UART Wildcard connects to the DTR (data terminal ready) output from the remote. The DTR1 and RTS1 outputs from the UART Wildcard connect to the DSR and CTS inputs to the remote, respectively. The DCD (data carrier detect) modem output connects to the /RxD2/DCD1 input on the UART Wildcard. Because this pin is shared with /RxD2, Channel2 cannot be configured for RS232 when a modem is in use. In this case, the user is free to implement RS422 or RS485 on Channel 2.

The following cable diagram illustrates the connections required to implement two RS232 ports, each using a 9-pin D-type connector as found on many laptops.

  Signal |  Pin# at UART  | Pin# on 9 pin | Pin# on 9 pin | Signal  |
 Name at | Wildcard Field |    Channel1   |    Channel2   | Name at |
  UART   |   Connector    |   Connector   |   Connector   | Remote  |
Wildcard |                |               |               |         |
_________|________________|_______________|_______________|_________|

 /TxD1          1 ______________ 2                            /RxD
 /RxD1          2 ______________ 3                            /TxD
  DGND          3 ______________ 5                             SGND
 /TxD2         17 _______________________________ 2           /RxD
 /RxD2         18 _______________________________ 3           /TxD
  DGND         19 _______________________________ 5            SGND
                                 7 ___            7 ___        RTS
                                 8 ___|           8 ___|       CTS
                                 6 ___            6 ___        DSR
                                 4 ___|           4 ___|       DTR

Note that /TxD at the local UART Wildcard connects to /RxD at the remote, and the local /RxD connects to /TxD at the remote. Also note that the RS232 handshaking signals RTS and CTS are connected to each other with a shorting wire at the D connector. Similarly, the RS232 handshaking signals DSR and DTR are connected to each other at the D connector. This standard scheme makes the remote computer think that it is always OK to send and receive data.

Connections for dual RS422 ports are shown in the following table. As shown, when you connect local RCV pins to remote XMIT pins, the polarities of the local and remote pins must match (+ to +, - to -).

The following table defines the connections for dual RS485 ports:

Local XCV (transceive) pins connect to remote XCV pins, and the polarities of the local and remote pins match (+ to +, - to -). Note that the two RS485 jumper caps must be installed for each port that is configured as RS485; these short RCV+ to XMIT+, and RCV- to XMIT- for the specified serial channel.

A package of pre-coded device driver functions is provided to make it easy to control the UART Wildcard. This code is available as a pre-compiled kernel extension library to C and Forth programmers. Both C and Forth source code versions of a demonstration program are provided. This demo program illustrates how to initialize and use the UART Wildcard in an RS232 multitasking application.

The UART Wildcard driver code makes it easy to configure the baud rate, data format, and protocol for each channel, send and receive characters, and control the direction of an RS485 channel. A demonstration program shows how to use the functions, and how to revector the serial primitives so that standard I/O print routines (such as . in Forth and printf in C) will automatically use a specified serial channel on the UART Wildcard.

The following functions are available; clicking on the function name should show a full definition:

Most of the functions accept as input parameters the channel number (1 or 2), and the UART Wildcard address number (0 through 7). The constants CHANNEL1 and CHANNEL2 are synonyms for 1 and 2, respectively; they are provided to allow for clean readable code. The Wildcard address number passed to the software functions must correspond to the hardware jumper settings as described in the address jumper table above.

The initialization functions are Set_UART_Number, Set_Baud, Set_Data_Format, and Set_Protocols. Set_UART_Number sets a variable that holds the Wildcard number used by the channel-specific serial I/O routines described below; this value can be read using the function Read_UART_Number. Set_Baud sets the bit frequency to a specified integer value that can span standard rates from 300 up to 56000 bits per second. Set_Data_Format accepts parameters that specify the number of data bits, number of stop bits, and parity for the specified channel. A set of pre-defined constants makes it easy to specify the desired parity; they are: NO_PARITY, EVEN_PARITY, ODD_PARITY, HIGH_PARITY, and LOW_PARITY. See the Serial Communications Basics: Data Format section above for a description of the parity modes. The standard QED serial ports operate with 8 data bits, 1 stop bit, no parity, and a baud rate of 9600 or 19200.

The fundamental serial I/O routines are called Emit_UART, Ask_Key_UART, and Key_UART. Each accepts a channel number and Wildcard number as input parameters. Emit_UART also accepts an input character, which it queues in the outgoing FIFO for transmission on the specified serial channel. Ask_Key_UART tests whether an input character is pending in the receiver FIFO; if so, it returns a true (-1) flag, and if not, it returns a false (0) flag. Key_UART returns the next pending character in the input FIFO; if the FIFO is empty, it waits for a character and returns it.

The channel-specific serial I/O routines are called Ch1_Emit, Ch2_Emit, Ch1_Ask_Key, Ch2_Ask_Key, Ch1_Key, and Ch2_Key. These routines have the correct parameter list to enable revectoring of serial I/O functions as illustrated in the demonstration program. Each uses the Wildcard number that has been set using the Set_UART_Number function, and the channel number suggested by the function name. Ch1_Emit and Ch2_Emit queue a specified character in the outgoing FIFO for transmission. Ch1_Ask_Key and Ch2_Ask_Key test whether an input character is pending in the receiver FIFO; if so, a true (-1) flag is returned. Ch1_Key and Ch2_Key return the next pending character in the input FIFO.

Full duplex protocols (RS232 and RS422) operate with both transmitters and receivers active at all times. The half duplex RS485 protocol requires that the channel be either transmitting or receiving. The functions RS485_Xmit_UART and RS485_Rcv_When_Xmit_Done control the RS485 direction for the specified channel and Wildcard number. As expected, the former function establishes the transmit mode. The latter establishes the receive mode after all pending outgoing characters have been sent, thereby avoiding errors caused by shutting off the transmitter in the middle of a character transmission.

Additional functions allow the application to send break characters, and set and read the modem handshaking signals.

For detailed specifications on control of the communications port, refer to the UART data sheet (Texas Instruments Part# TL16C552A).

The demonstration program presents constants and functions that illustrate how to use the serial channels. The function named Default_UART_Init accepts a Wildcard number parameter, and initializes both serial channels to default values specified by the constants DEFAULT_BITS_PER_CHAR, DEFAULT_STOP_BITS, DEFAULT_PARITY, DEFAULT_BAUDRATE, DEFAULT_PROTOCOL, and DEFAULT_MODEM_SUPPORT. The values of these constants can be edited, and a more versatile initialization function can be crafted to meet the needs of your application.

The multitasking operating system on the Mosaic Controller allows each task to access its own distinct serial I/O channel by pointing the three primitives Emit, Ask_Key (called ?KEY in Forth), and Key to the desired serial I/O handler functions. The advantage of revectoring is that higher level serial management functions that accept and print characters and strings will then use the designated serial channel. The Ch1_Monitor and Ch2_Monitor functions in the demonstration perform the revectoring, and then call functions that perform interactive echoing via the specified serial channel on the UART Wildcard. The Run_Demo function (or the main function in C) starts and runs the multitasking demonstration using both channels of the UART Wildcard. The demonstration program source code is presented in a later section.

The UART Wildcard device driver software is provided as a pre-coded modular runtime library, known as a kernel extension because it enhances the on-board kernel's capabilities. The library functions are accessible from C and Forth.

Instructions for PDQ

Instructions for QED/Q-line

COLD

COLD

The C demo is located in your installation directory. It is also provided here for reference.

Instructions for PDQ

#include <mosaic/allqed.h>
//__GNUC__ is true for Mosaic PDQ IDE
 
#ifdef __GNUC__
#include <wuam.h>
#else
#include //library.h//
#include //library.c//
#endif

Instructions for QED/Q-line

#include //library.c//

#include //library.h//

The Forth demo is located in your installation directory. It is also provided here for reference.

Instructions for PDQ

MosaicPDQ\forth\demos\UART_Wildcard\uamdemo_loader.4TH

Run_Demo

Instructions for QED/Q-line

WHICH.MAP 0=
IFTRUE 4 PAGE.TO.RAM  \ if in standard.map...
       5 PAGE.TO.RAM
       6 PAGE.TO.RAM
      DOWNLOAD.MAP
ENDIFTRUE

4 PAGE.TO.FLASH
5 PAGE.TO.FLASH
6 PAGE.TO.FLASH
STANDARD.MAP
SAVE

RS485 multidrop communications are often used to establish communications with a remote instrument. Typically, a command and response protocol is used. The Mosaic Controller issues a command, usually terminated with a specified terminating character such as a carriage return, and the remote instrument then transmits a response back to the Mosaic Controller. It is the Mosaic Controller's responsibility to revert to the RS485 receive mode immediately after transmitting the terminating command character to the remote.

In multitasking RS485 applications, the time to go from transmit mode to receive mode on the RS485 link may be too long, causing characters to be dropped when the remote instrument responds to a command from the Mosaic Controller. This situation can arise because the task that controls RS485 communications is not running when the transmission of the terminating command character completes, and receive mode is not entered until the RS485 task regains control.

Of course, if a full duplex RS422 interface to the remote were available, this would solve the problem. Many instruments only support RS485, so we need a way to turn off the RS485 transmitter immediately after the last character in a command finishes transmitting.

To start the discussion, let's consider the simplest case of a one-task (non-multitasking) application. In this case, the simplest approach to RS485 communications yields good results.

With the RS485 channel in transmit mode (see the function RS485_Xmit_UART), we use CH1_Emit or CH2_Emit to send the entire command, including the terminating character. Each CH1_Emit or CH2_Emit places a character in the proper outgoing 16-byte FIFO (First-In/First-Out) buffer in the UART, and the UART automatically transmits them until the buffer is empty. All the serial driver routines are FIFO-aware, so the programmer doesn't have to worry about buffering; it's handled transparently. After emitting all the command characters, we revert to the receive mode using the command:

RS485_Rcv_When_Xmit_Done

which accepts the channel_num and Wildcard_num as input parameters. This command polls the XMIT_HAS_COMPLETED_MASK bit in the UART’s line status register, PAUSEs if there are characters remaining to be sent, and changes to receive mode when the transmission is complete. This works well for a single-task system, as the PAUSE will simply loop back to the single task, and the receive mode will be entered as soon as the last character is transmitted.

In a multitasking application we have to be more careful about time delays. For example, if there are 4 tasks running with the default 5 msec timeslice period, then each PAUSE invoked by RS485_Rcv_When_Xmit_Done will typically involve a 15 msec delay as the other 3 tasks use their timeslices. If the terminating command character is transmitted during one of these 15 msec delays, incoming characters from the remote instrument may be missed if the remote starts transmitting as soon as the terminating command character is received.

The solution is to ensure that the RS485 task maintains control while the very last character in the command string is being sent, so that the RS485 task can revert to receive mode with no time delay. To maintain multitasking efficiency, we should break the command string into two parts:

1. the command (not including terminator), and

2. the terminating character.

To facilitate this approach, an additional function has been added to the UART Wildcard kernel extension Version 1.1. It is:

Loop_Until_Xmit_Done

which accepts the channel_num and module_num as input parameters. This function is very similar to Wait_Until_Xmit_Done, but it does not PAUSE while waiting. Using this function as described below, we are able to avoid task switches as the terminating character is transmitted and the RS485 receive mode is entered.

Assume we're using channel 1 of the UART Wildcard. We transmit the command string by repeatedly calling CH1_Emit (but we don't emit the terminating character yet). We call

Wait_Until_Xmit_Done

to wait and PAUSE until the transmission completes. Time delays due to task switches during this process should not matter, because the remote instrument is waiting for the terminating character to come in from the Mosaic Controller.

Next, call the following commands (of course, supply the proper parameters for each function):

DISABLE.INTERRUPTS \ prevent task switching while sending last character
 
CH1_Emit \ send the final terminating character of the command,
 
Loop_Until_Xmit_Done \ don't pause, wait for terminating char to be sent
 
RS485_Rcv_UART \ revert to receive mode
 
ENABLE.INTERRUPTS \ re-enable interrupts
 
PAUSE \ this is optional, may boost multitasking efficiency

This sequence of function calls retains control while the last (terminating) character of the command is transmitted, then immediately enters the RS485 receive mode. Disabling interrupts should always be done sparingly, but is warranted in this case to ensure that no incoming characters are lost. We disable interrupts for only the time it takes to transmit one character, which at 19200 baud is about half a millisecond. As soon as Loop_Until_Xmit_Done is finished (meaning the character has been transmitted), RS485_Rcv_UART is called to immediately enter receive mode, and interrupts are re-enabled. At this point, the UART input FIFO buffer is able to accept up to 16 incoming characters before being serviced, so in some applications it may be efficient to PAUSE at this point to give other tasks a chance to run.

In summary, this approach should lead to high reliability acquisition of response data from remote RS485 instruments.

Download the schematics for the UART Wildcard:

• UART Wildcard Rev. 3 Schematic CPLD page
• UART Wildcard Rev. 3 Schematic Serial Driver page

• TL16C552APN Dual UART With FIFO
• MAX242CAP Multichannel RS-232 Driver/Receiver
• MAX489CSD RS-485/RS-422 Transceiver

See also → UART C Demo
UART Forth Demo
UART Glossary