With some integrated circuits from different manufacturers it is possible to realize a low cost network for slow data transfer. Uarts with 'Multidrop Mode' and an 8 pin driver 75176 or LTC485 etc are used for this purpose. Also different microcontrollers with built in Uart have this operational mode. Here is my list of devices witch support this.
Motorola: 68681, 68HC11, 68332 Exar: XR-82C684 Quad Uart (68681 compatible) Philips: SCC68C198 Octal Uart Intel: many 8051 derivates Zilog: IUSC Z16C32 Hitachi: SH1 microprocessors Toshiba: TLCS900 microprocessor Cypress: EZUSB
There is also an older article from c't (a german computer magazin) 1990/2 HTalk witch uses RS485 drivers and serial data transmission. But they don't use the multidrop mode, because the usual 15450/15550 are able to select the parity bit as '1' or '0' for transmitting, but cannot produce an interrupt only when receiving a byte with parity bit = 1.
This term is used in the data sheet of the Motorola 68681 Duart. Other manufacturers have other terms (Intel: Multiprocessor Mode). The parity bit is used to distinguish between an address byte and a data byte. The checking function of this bit (parity) is lost. If the parity bit is set to '1' this byte is an address, if set to '0' it is a data byte (see drawing at top of page). The essential advantage is the ability to generate an interrupt only if a byte with parity set to '1' e.g. an address byte, arrives. The processor then checks if this is the own adress. If so, interrupts are enabled for all bytes and the following data bytes (with parity bit = '0') are received. Intel has recently improved this option. Now you are also able to write the own adress to a register. The interrupt occurs only if an address byte with the own adress is received (see 8x930Ax User Manual, 27294901.pdf, Chapter 13.4). Starting with this concept, a protocol is developed to connect some microprocessors and to realize a low cost network with slow data transfer.
Byte Meaning 0 destination address (parity='1') 1 source address (for this and the following bytes of this packet: parity='0') 2 header type byte (=0x01) 3 count byte high 4 count byte low x data bytes ( n=(count high) * 256 + count low, 0<=n<=(2^16-1)) n+1 crc16 (high byte) n+2 crc16 (low byte)
The overhead of this packet is 7 bytes: 2 address, mode, 2 count, 2 crc.
Connect the Tx output from the Uart to the Tx input of the RS485 device. Connect Rx output from the RS485 device to the Rx input of the Uart. Set the Rx enable input of the RS485 device so that receiving is always enabled. Connect the RTS output of the Uart (or any other programmable output pin) to the Tx enable input of the RS485 device. In case of a PC: insert a inverter to the RTS line. This deactivates the transmitter of the RS485 device after startup. Connect two weak pull up/down (R=10k-100k) to the RS485+ and RS485- pins: RS485+ to +5V and RS485- to GND. If these connections are floating, they sometimes generate interrupts. These Pull up/down resistors are only needed once, but there is no negative influence if they are on each node.
With these connections all bytes sent were received simultaneously, and if they were not equal there was a collision or other general fault cause.
This protocol allows about 1500 internet addresses per square meter of terrestric surface. This seems to be satisfactory, with the exception of skyscraper buildings. They must get the addresses from the oceans. Also if micromechanics needs some addresses this may be tight.
I have one wish:
To hardware developers: Please include the RS485 driver into the Uart device. With an additional bit software selects after power up RS485 or RS232 mode.