Re: [ECOS] AT91 serial driver

[Scott Dattalo <scott at dattalo dot com>]

On Fri, 13 Dec 2002, Jani Monoses wrote:

> Hi
> In january this year Paul Sheer sent an improved serial driver for
> the at91 (eb40).I just came across that tgz today tried it and works
> great.Now SLIP works at 115200 bps just fine.With the default driver
> it loses chars even at 19200bps.
> Paul's main improvement consist in using the peripheral data controller
> attached to the uart - (and SERIAL_BLOCK_TRANSFER) and some buffer flipping
> in the IRQ_handler.
> 
> If I polish those files would they be considered for acceptance?
> Maybe after Thomas Koellers AT91 work goes in? Hint,hint ;)

I'd certainly like to see them.

In particular, I'd be interested in seeing how the RCR and RPR registers 
are dynamically updated. In my recent experience, I discovered that flow 
control is absolutely necessary. In my case, I've configured one of the 
USART's as a synchronous slave that uses the DMA capabilities of the AT91 
usart peripheral. A master device transmits tiny packets ( 8 to 16 bytes) 
in sporadic bursts. The reason for synchronous over asynchronous is that 
the master device is running from a variable frequency clock source (and 
hence baud rate timing is variable). An added bonus is that the master 
device, which is a tiny 8-bit microcontroller, wastes little time 
bit-banging data to the AT91.

As you might expect, errors can occur if the RCR and RPR are modified
while data is being received by the AT91 usart. What you'd also expect, is
that by simply resetting the USART it would be sufficient to recover from
the errors.  Unfortunately, the only way to recover (that I could find) is
by either resetting the processor or by fortuitously receiving another
error. My experimentation was extension, but not exhaustive. For example,
I did not try something like sending the receiver a break character (e.g.
by using local loopback). On the other hand, I tried all of the obvious
things like setting Receiver Reset bit in the USART Control Register. The
error condition was a "Framing Error"  followed by "Overrun errors" for
all subsequent bytes. 

My conclusion: if you're using RCR and RDP with the AT91 usarts then flow
control (either hard or soft) is absolutely necessary.

Scott


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss