RS485 CSMA/CD protocol

Hi, I would need to implement an CSMA/CD L1 protocol code for RS485 in my 
new AVR project for home automation.
Any link, hint or help for the similar source code? 

My hint would be...Don't.


I've been curious about this sort of thing myself, and as far as I can
tell from web research no one out there has ever got it working
satisfactorily for real, as opposed to demonstration projects.

AFAIK it's just not feasible to reliably detect collisions on a
real-world bus with "standard" UART and RS485 hardware.

This is what CANBus is for.

<richardlang@my-deja.com> wrote in message 
news:1127439995.520337.174470@g44g2000cwa.googlegroups.com...
> My hint would be...Don't.
>
> I've been curious about this sort of thing myself, and as far as I can
> tell from web research no one out there has ever got it working
> satisfactorily for real, as opposed to demonstration projects.
>
> AFAIK it's just not feasible to reliably detect collisions on a
> real-world bus with "standard" UART and RS485 hardware.

Hmmm. It is possible, but you have to enable both Tx and Rx, and monitor 
that Tx = Rx. If not, back off and try again later.

Steve
http://www.fivetrees.com 

> My hint would be...Don't.

> I've been curious about this sort of thing myself, and as far as I can
> tell from web research no one out there has ever got it working
> satisfactorily for real, as opposed to demonstration projects.

> AFAIK it's just not feasible to reliably detect collisions on a
> real-world bus with "standard" UART and RS485 hardware.

> This is what CANBus is for.

I got to the same conclusion.

Btw. what are the differences between RS485 / CAN2.0 on physical layer
?

However, here is a thought:

1. sender waits until bus is idle and then sends SOF (say 0) and
bit-bangs message ID at low speed with software CD.

2. if no collision is detected, the sender continues sending the
content at desired speed using HW UART.

Even with simple mechanism of pulling bus active before sending the
message and checking for idle before doing so decreses the probability
of later collision substantially so the bit-banged priority is just a
fail-safe mechanism in rare case multiple senders decide to pul bus
active within same microsecond.

If system does not need 100% bandwidth and can withstand latency of
occasional 1-2 retries, you may succeed with the active start symbol
and random back-off timer.

Yeah, yeah, that's how you would do it *in theory*

In practice I'm not at all confident that "standard" RS485 drivers &
UART Rx. hardware will reliably detect and report the effects of
another RS 485 driver at the other end of a sub-optimal (long, heavily
loaded) real-world bus trying to drive to a conflicting signal level

rziak wrote:
> > My hint would be...Don't.
>
> > I've been curious about this sort of thing myself, and as far as I can
> > tell from web research no one out there has ever got it working
> > satisfactorily for real, as opposed to demonstration projects.
>
> > AFAIK it's just not feasible to reliably detect collisions on a
> > real-world bus with "standard" UART and RS485 hardware.
>
> > This is what CANBus is for.
>
> I got to the same conclusion.
>
> Btw. what are the differences between RS485 / CAN2.0 on physical layer
> ?

CANBus drivers only actively drive one signal level, relying on
termination resistors to passively assert the other level in absence of
any other nodes trying to actively drive the bus.  This allows CAN's
non-destructive collision arbitration mechanism.

Some early CAN systems used RS485 drivers, but with the TTL Tx. signal
from the higher level controller wired to the drivers chip enable line
rather than the Tx. input.

richardlang@my-deja.com wrote:
> My hint would be...Don't.
> 
> 
> I've been curious about this sort of thing myself, and as far as I can
> tell from web research no one out there has ever got it working
> satisfactorily for real, as opposed to demonstration projects.
> 
> AFAIK it's just not feasible to reliably detect collisions on a
> real-world bus with "standard" UART and RS485 hardware.
> 
> This is what CANBus is for.

However, you can use CAN bus Transcievers, and UART uC, especially if
it is all your own network.

RS485 drivers have LowZ outputs, and so with real cable impedances, you 
cannot reliably sense contentions.

CAN drivers are open-collector, so OR tie, and can detect collisions 
within the transit times of cables.

So a vanilla uC can send, checking the RX to verify no differences, and
if it detects a difference, it has to go to collision mode.

UART systems will take longer to detect/respond to a collision than CAN, 
but in  a simple network, with low traffic, the lower cost of devices 
might make that worthwhile.

Since most uC UARTS have 9 bit modes, you can still use the CAN_Txcvr & 
collide detect, but have a master that allocates timeslots, if you need
deterministic performance.

-jg

Steve at fivetrees <steve@nospamtafivetrees.com> wrote:
> <richardlang@my-deja.com> wrote in message 
> news:1127439995.520337.174470@g44g2000cwa.googlegroups.com...
>> My hint would be...Don't.
>>
>> I've been curious about this sort of thing myself, and as far as I can
>> tell from web research no one out there has ever got it working
>> satisfactorily for real, as opposed to demonstration projects.
>>
>> AFAIK it's just not feasible to reliably detect collisions on a
>> real-world bus with "standard" UART and RS485 hardware.
> 
> Hmmm. It is possible, but you have to enable both Tx and Rx, and monitor 
> that Tx = Rx. If not, back off and try again later.
> 

That kind of setup doesn't work reliably in my experience. What you
can do is to only drive one level actively and have the termination of 
the bus define the other level. Then you connect outgoing data to the
output enable of the RS485 driver. But then we're not within the RS485
spec any more. I have seen this work for synchronous communication at
megabit speeds. At least some members of the QUICC/PowerQUICC family
from Freescale has a mode called HDLC Bus that can be used for
this. It is really designed for a direct connection between MCUs but
with a few tricks it can be used to work with RS485 drivers.

/Henrik

-- 

On 22 Sep 2005 21:37:02 -0700, richardlang@my-deja.com wrote:

>CANBus drivers only actively drive one signal level, relying on
>termination resistors to passively assert the other level in absence of
>any other nodes trying to actively drive the bus.  This allows CAN's
>non-destructive collision arbitration mechanism.
>
>Some early CAN systems used RS485 drivers, but with the TTL Tx. signal
>from the higher level controller wired to the drivers chip enable line
>rather than the Tx. input.

This could work quite reliable.

However, you would need a XOR gate between the TTL level Rx and Tx
signals to detect coincidence, but you would still have some spikes at
each bit transition due to the limited rise and fall times and
possibly due to reflections. You would have to filter out these
spikes, but how do set the threshold, in order to quickly detect when
two transmitters starts to send the same character at say 1/4 bit time
after each other.

If the collision is done purely in software after the UART, much more
timing information is lost, especially if a FIFO is used on Rx and Tx.
If the protocol always starts with the same character, say STX, how do
you know, if that STX you got from the Rx FIFO is from your
transmission or not. 

Starting the message with _your_ address (not the destination address
as in Modbus) would at least get some assurance that you got your own
ID back, get the ID of an other station or a garbled character
signifying collision, but still there would be false triggering due to
time shifts by 2, 4 or 6 bits. On way around this would be to limit
the number of stations to 8 and have station addresses with only one 0
bit, i.e. EF, DF, BF, 7F, FE, FD, FB, F7 (hex).

With low expected collision rates, it might even be acceptable to
detect collisions from failing CRCs at the end of frame.  

Paul
  

"therion" <therion0@yahoo.com> wrote in message
news:dgv8ou$smm$1@sunce.iskon.hr...
> Hi, I would need to implement an CSMA/CD L1 protocol code for RS485 in my
> new AVR project for home automation.
> Any link, hint or help for the similar source code?

How many devices and how much comms? I have seen people implement servers
which poll all devices and end up with just as good throughput