On Mon, May 18, 2009 at 2:11 PM, Olin Lathrop <olin_piclist@embedinc.com> w=
rote:
> M. Adam Davis wrote:
>> But it's [collision detection network]
>> worth investigating and considering, given that the vast majority of
>> today's computers use it in the form of ethernet, and cars in the form
>> of CAN. =A0I think it's funny that it's one of the more popular methods,
>> but so many are against it.
>
> Then you haven't given it much thought. =A0Both ethernet and CAN do the
> collision detection in hardware. =A0That's rather different than doing it
> youself with RS-485, especially since some quick timing is needed.

It's non-trivial in terms of programming, but it only requires one
quick compare, and a physical medium that is only driven in one state
(the other state is the bus default, recessive).  You set up the
rs-485 receiver so it's always receiving, and if any byte you receive
while sending is not the byte you just sent, then you call it a
collision, announce it on the bus (usually a break on the bus which is
seen by the rx as a frame error), and everyone backs off according to
whatever algorithm you chose (generally random backoff and retry).
It's not hard or particularly tricky to implement well in a device
with a standard UART, such as a PIC.

Yes, it's nice to have collisions detection in hardware, but that's
hardly required.  It's nice to have quick timing so the bus can
recover quickly and you don't lose as much bandwidth on it, but quick
timing is not required.  In a good design with a normal UART you lose
about 3 bytes of bus time, assuming the collisions is detected based
on the first byte.  One byte for the first transmission.  The second
byte is being sent while the first one is being compared with what
should have been sent, and the third byte to push a break onto the
bus.  All quick timing and hardware sensing gives you is bit level
comparision and instant bus announcement at the first bad bit.

The extra comparison isn't any more work than the effort needed to,
for instance, catch, release, restart, etc a token - it's just time
spent at a different point in the network protocol.

Each method has it's own host of things that have to be carefully
considered to succeed.  I'm not saying the CSMA/CD is better or easier
to do, I'm saying it's not as hard as people make it out to be, and
one should not be afraid of it simply because so many people preach
against it.

So far there's nothing about his network requirements or skills that
would lead me to believe he couldn't or shouldn't implement it.  Nor
is there any reason to particularly avoid any other method we've
discussed so far.

But so many people seem to be cautioning him against CSMA/CD that it
makes me wonder, did ethernet bite them when they were kids?

;-D

-Adam

-- =

http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist