>
> On Thu, 12 Aug 1999, Byron A Jeff wrote:
>
> > >
> > > How about CSMA/CD?
> >
> > It's not clear if the physical layer of RS-485 allows for multiple transmitt
ers
> > or what happens if multiple transmitters transmit different bits.
>
> If you are doing half-duplex RS-485, you just tie the UART tx line
> (inverted) to the RS-485 driver's R/W pin and tie the tx pin on the driver
> to ground. That way, the driver will only transmit when it wants to send a
> 0. A collision is defined when one transmitter is sending a 0 and another
> transmitter wants the line to be floating (i.e. it is sending a 1). There
> is an appnote on this somewhere (National Semi i think). Collisions can be
> detected in hardware with by: UART framing error, UART missing stop bit,
> UART parity error or in SW with CRC errors in the frames.

Wire-OR. That's an interesting idea. I'd be interested in the latency between
my scheme and true collisions.

>
> > Essentially I'm doing the multiple access part because even with
> > ethernet there is only a single transmitter on the channel at any
> > point in time. This protocol handles channel selection on a separate
>
> Well, there is only one transmitter sending error free data. When there
> are two transmitters (which is possible in ethernet) a jam signal is
> generated and both transmitters backoff.
>
> > Any commentary on the UDP/SLIP part of it? The responses I've seen have been
> > physical layer only which isn't a relavent as the protocols on top of that
> > layer.
>
> Only problem with UDP is that there is no guarentee that the data will get
> there correctly so if your physical layer is not error free you have to
> add a CRC field the data section of your UDP packet.

UDP already has a CRC field for the entire packet. Individual nodes would have
to manage sequencing, dropped packages, and I guess even the rare duplicate.

>
> Slip/UDP is cool but in the end there just isn't enough processing
> power/memory in a low end PIC to really make it worth while. You would
> probably be better off using a custom protocol and then have one big PIC
> convert from this custom protocol into Slip/UDP.

This is what I want to explore. IP and UDP are extremely simple if you are
not a router. Just specify the IP number and port number of the target and
package up your data. SLIP, unlike PPP, is just dropping raw IP packets on the
serial line with 2 characters out of 256 escaped. Most of both the IP and the
UDP packet is fixed (all the source, could fix the target port) with the
only variable part being the target IP and the data.

I agree that TCP is too much to handle. But UDP's simplicity of just wrapping
the data in a simple envelope should be simple enough to put in a 12CXX part.

BAJ