Sounds like a way better idea than mine... cheaper too.  And avoids the
analog circuitry.  Probably less subject to interference, too.  And its easy
to implement.  One thing though, is how to handle errors? Have you thought
about it any?  Maybe a checksum at the end could do some error checking...


----- Original Message -----
From: "Bob Ammerman" <rammerman@VERIZON.NET>
To: <PICLIST@MITVMA.MIT.EDU>
Sent: Thursday, June 24, 2004 3:48 PM
Subject: Re: [EE:] Analog signaling


> 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

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