> 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...

That is what the CRC is about.

Bob Ammerman
RAm Systems

>
> ----- 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

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