This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: AT91 serial driver


Paul said that it still loses some chars although not as frequently.
You can find the tgz in the archives ofr January 2002 if you want to 
look at how it's done.I just made some search and replaces on that code to have at91 instead of
seth as the platform name.Also you need to have amn implements SERIAL_IO_BLOCK_TRANSFER in te cdl.


> 
> 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
> 

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]