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

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

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

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

> > > > 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 betwee
n
> > my scheme and true collisions.
>
> That's what I (almost) did. In my case, the physical layer also performed
> arbitration (some of the datalink layer trickled down). After the last
> byte of a message was transmitted, the active master would enter an
> arbitration mode. This consisted of extending the stop bit for a
> pre-defined interval and then asserting an 'arbitration edge'. All
> potential masters monitored this edge with a hardware input-capture pin.
> After the edge was initiated, the active master would relinquish control
> by tri-stating its transmitter. The RS-485 termination resistors, which
> are necessary for reliable long-distance communications, were configured
> such that they would also passively maintain the DC level of the RS-485
> differential pair in the 'active low' state or the state to which the
> arbitration edge drove the bus.

>
> Now each master was preassigned an ID. This ID was used to determine an
> 'arbitration slot' or a time period that the masters would wait after the
> arbitration edge to attempt arbitration. An output compare module was
> programmed to generate the "I want the bus" edge. Finally, a master
> ascertained whether it had won arbitration by comparing when it sent the
> bus request to when the bus really went active. If the bus went active due
> to his request, then he was the winner. If the bus went active before his
> request then another master won.
>
> The comm rate was 38.4k baud, the arbitration slots were about 20uS, there
> were upto 32 nodes. This schem worked reliably for more than 300 meters of
> copper and 1500 meters of fiber. If it weren't for propogation delays
> through opto-couplers (the RS485 bus was optically isolated) the distances
> could be extended even more...

>
> On Sat, 14 Aug 1999, Byron A Jeff wrote:
>
> > Scott, I'm unclear on one thing. This seems to be almost the same scheme I
> > came up with originally (which makes me happy because now I know it'll work)
.
> > But how do the UARTS react to channel activity? Also how did you prevent
> > starvation? It seems the lower ID'ed masters could swamp the channel. That's
> > why I went to a primary/secondary ID where after successfull transmission
> > a station went to its secondary ID until either it got the slot or until
> > no other primaries wanted to transmit.
> >
>
> Well, there were masters and there were Masters. Actually the network
> consisted of up to 8 'Masters' and up to 32 nodes capable of assuming
> control of the network. The 'Masters' had two arbitration slots. If they
> had something really urgent to say then they could arbitrate in slots 0-7.
> Otherwise, they would always arbitrate in slots 40-47. So if no nodes had
> anything to say, then the highest priority master would win arbitration by
> default. It would just transmit a 'sustaining' message and the whole
> process would repeat. So like your case, the 'Masters' had a primary and
> secondary ID. This idea could be extended to make all nodes "Masters'. The
> one with the highest priority would just have a little extra work keeping
> the network active.
>
> A state machine kept track of the state communication channel. The UARTs
> were programmed according to the state of the network: idle, listen, talk.
> As long as a nod maintained sync with the network, there was no problem
> for its UART to monitor the activity.
>
> Scott