RE: [avr-gcc-list] Implementation RS485 communication in c

[Henko Gouws \(H\)]

Hi

Do you intend to later add more controllers to your RS485 bus in a
multidrop architecture?  If you intend to do this I might be able to
help a bit with the 9 bit multidrop protocol where all the slaves
listen to their address with the ninth bit set.  I have implemented a
simple 9-bit multidrop using the 8051 but if the AVR supports
multidrop in the same way then it should not be difficult to do this
using the AVR.  Just had a quick look at the ATMega16 and this chip
seems to have a similar 9th bit address capability.

RS485 and RS422 are suitable for communication between more than two
devices whereas RS232 is normally just suitable for two endpoints
communicating with one another.  As far as I am aware RSxxx is just an
electrical interface spec.  RS422 is in a way just a full-duplex
version of RS485.  The real power is what you can do with each of the
RSxxx specs and the communication layers that you put on top of it.

Initially all slaves have their interrupts for ninth bit set.  All
other frames that do not have ninth bit set do not cause the slave to
interrupt.  The master sets the ninth bit of the address byte to
identify a slave.  All the slaves, who have their ninth bit interrupt
set, encounter a 9 bit interrupt and know that it is an address from
the master and they should each check if the communication is intended
for them.  If a slave detects that a frame is intended for it and not
for other slaves then it disables the ninth bit interrupt and
communicates with the master until the session/slot is over.  During
this time the other slaves do not get interrupts because there are no
frames with ninth bit set - which means that they do not have overhead
when it is not required.

Furthermore: Do you require reliable communication?  If you do then I
recommend 16 bit CRC (If your frames are not extremely long) for each
frame to ensure each frame is transmitted and received correctly.  You
might also require sequence and acknowledge numbers to allow for
retransmission of frames in error and prevent misinterpretation of
duplicate frames.  However if you intend to just send over data that
does not 'care' if a few bits are received in error such as video or
sound then you might be better off without CRC and
Sequence/Acknowledge numbers.

Not exactly sure what your needs are.

Regards
Henko

-----Original Message-----
From: address@hidden
[mailto:address@hidden On
Behalf Of Erik Christiansen
Sent: Monday, 02 April, 2007 2:27 AM
To: address@hidden
Subject: Re: [avr-gcc-list] Implementation RS485 communication in c

On Wed, Mar 28, 2007 at 06:43:01AM +0200, Christian Engel wrote:
> I think for implement a communication between two ATmega 162 with
the RS485
> standard.
> 
> Has anybody before implement a communication with RS485 in c? I'm
sure that,
> but has anybody more information about it for me?

Whether you're using RS485, RS422, or RS232 is simply a matter of
which
line interface chip you choose, surely?

Whether you're able to use full or half duplex RS485 will also depend
on
your chip choice. The only impact on the code is when you feel
inclined
to disable the transmit side, IIUC.

On the atmel website you can find:

AVR306: Using the AVR® UART in C
         Setup and Use of the AVR UART
         Code Examples for Polled and Interrupt Controlled UART
         Compact Code
         C Code Included for AT90S8515

Beyond that, the topological design of your RS485 network, and higher
level protocol choice would dictate what you'd do next, I'd expect.

Have fun!

Erik

P.S. This topic is perhaps more suited to the avr-chat mailing list.
:-)


_______________________________________________
AVR-GCC-list mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This e-mail and its contents are subject to the Telkom SA Limited
e-mail legal notice available at 
http://www.telkom.co.za/TelkomEMailLegalNotice.PDF
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~