Network RS232

With an ever increasing number of off the shelf electronic modules and boards available at low prices, designers are inclined to use these instead of making all their electronics from scratch. In many cases this makes sense as developing  say, a PID motor controller or a GPS receiver from scratch requires considerable skill, time and effort. A surprising number of modules still have an interface based on RS232. No wonder, as RS232 is easy implemented on a microcontroller with two I/O pins and a line driver such as the MAX232. In the case where the master is a PC, the serial port is relatively easy to access on both Windows and Linux. Usually modules implement a text terminal interface that decodes single line commands with arguments and generate a reply like this:

Tx: cmd arg0 arg1 ... argX/n
Rx: cmd arg0 arg1 ... argX/n
replyline0/n
replyline1/n … replylineY/n

A complication occurs when there are a number of RS232 modules in a project, as each requires a serial interface at the master. A hardware solution in the form of an RS232  multiplexer would be a solution but wouldn’t  it be nice to get this functionality for free! By deviating from the original aim of RS232 as a point-to-point link, we can have an RS232 network in which all the modules share both transmit and receive lines to one master inter-face. All modules operate at the same speed, start and stop bits with no flow control.

Circuit diagram :

Network RS232 Circuit Diagram

When idle, all the modules are listening for commands from the master and have their transmitters disabled. Each module is configured with an identifier consisting of a number that the master sends as a single line (e.g. ‘2/n’ selects module 2). If a module receives an identifier that matches its own, it is selected and can decode commands and drive its transmitter for the duration of the reply. Conversely, if the identifier does not match it must not decode commands and ensure its transmitter remains disabled.

In addition to some firmware sup-port, the RS232 driver electronics must be able to tri-state the transmitter while keeping the receiver operational. Sadly, the classic MAX232 driver is unsuitable but the ICL3321 and MAX242 are possible candidates for our purpose. These have low-power shutdown modes that power-down the charge pump and transmitters but keep the receivers enabled for monitoring RS232 activity.

The number of modules in your RS232 network is limited by the (nominal) 5 kΩ pull-down at the receiver input of the line driver device. Multiple modules increase the loading on this signal, reducing the maximum operating speed and cable length. Using the circuit shown here, running an application with five modules at 9,600 bps located within 1 meter  of each other did not present any problem.

Modules need a means of enabling the network mode and setting the unique identifier. This can be done via switches, jumpers or, if I/ O pins are scarce, by storing the configuration in the user EEPROM/Flash provided by many  microcontrollers. If the latter is done, it is reasonable to assume the module will only be configured with normal RS232. Special configuration commands can then be provided that are always decoded irrespective of the identifier match.

It is unlikely that commercially available modules can be tweaked to support ‘network’  RS232 unless the vendor has used a suitable RS232 line driver and is prepared to provide the firmware code. However, it is possible to implement on DYI modules and perhaps module designers can take note and enhance the functionality of their future designs.