[En-Nut-Discussion] AT91 RS485

Coleman Brumley cbrumley at gopolar.com
Fri Sep 4 17:07:19 CEST 2009


> -----Original Message-----
> From: en-nut-discussion-bounces at egnite.de [mailto:en-nut-discussion-
> bounces at egnite.de] On Behalf Of Harald Kipp
> Sent: Friday, September 04, 2009 11:03 AM
> To: Ethernut User Chat (English)
> Subject: Re: [En-Nut-Discussion] AT91 RS485
> 
> Coleman Brumley wrote:
> > Harald,
> >
> > I am also using half duplex RS485 on the AT91 platform.  However, I
> > specifically set up the registers in the CPU to do this at startup --
> I
> > don't rely on the "USE HW RS485 on UARTx" feature.
> 
> I read about problems with some RS485 level translators taking too long
> to switch from receive to transmit or vice versa. The AT91 offers a
> timeguard value for the latter, but not for switching back to transmit
> mode.
> 
> It's a kind of academic question because the driver will support
> switching a GPIO anyway. I'm just curious if this is a real world
> problem or just an urban legend. And I'm wondering why Atmel
> implemented
> this timeguard at all. In RS485 mode the RTS status is tied to TXEMPTY,
> which ensures, that the last character had been completely shifted out.

It's absolutely a real world problem.  The protocol I work with, BACnet
MS/TP, has a requirement that TX enable be dropped within x milliseconds
after the last byte of a packet has be TX'd.  This timeguard setting in the
AT91 chips does that automatically so there's no polling involved in
software.  It makes life much, much easier. 

> 
> Harald
> _______________________________________________
> http://lists.egnite.de/mailman/listinfo/en-nut-discussion




More information about the En-Nut-Discussion mailing list