Yeah, all that complicated analog signaling is bound to cause trouble.


Here is an idea I just had (based on the serial 'Token Ring' stuff that was
on the list in the last few days).

The hardware:

Each unit contains a PIC controller. The UARTs are wired in a ring with the
master controller:

TX of the master goes to RX of PIC1
TX of PIC1 goes to RX of PIC2
TX of PIC2 goes to RX of PIC3
......
TX of PICn goes to RX of the master

The master sends packets of the format:

<start marker>
0 <--- pointer value
data for PIC1 (0 or more bytes)
data for PIC2
data for PIC3
.
.
data for PICn
<end marker>
<crc>

The 'data for PICn' is an area reserved in the packet for a specific PIC. On
receipt, this area contains the incoming data to the PIC, on transmission it
contains information to be reported back to the host. The area needs to be
max(incomingsize,outgoingsize) bytes long.


Each PIC, as it receives the packet, does the following things to it:

1: Increments the pointer value by the number of bytes it needs
2: Extracts its data from the packet as it flies by.
3: Replaces its data received from the host with its response to the host
4: Checks the CRC. If it is valid then it accepts the input bytes, otherwise
it ignores them.
5: If the incoming CRC is valid then output a new valid CRC, otherwise
deliberately 'smudge' the CRC to force it to be bad.

Note that the PIC sends the packet out as quickly as it receives it. It does
not buffer the entire packet in RAM.

When the packet gets back to the host, all the responses are there and ready
to process.

Now, to check performance:

Assume 50 pics, with an average of 2 bytes of data each. This gives a packet
size of about 110 bytes, counting overhead. At 19,200 baud that packet can
be sent about 17 times per second.


Bob Ammerman
RAm Systems

--
http://www.piclist.com hint: To leave the PICList
mailto:piclist-unsubscribe-request@mitvma.mit.edu