Re: [ECOS] Serial buffer overrun

[Jonathan Larmour <jifl at eCosCentric dot com>]

Shannon Holland wrote:
> The data point I was using regarding overrun was that if I unplug the 
> serial cable while everything is running, the at91 keeps plugging away 
> with new data for a while until it finally empties the buffer. Making 
> the serial buffer larger or smaller changes this time appropriately.
That does sound more like an overrun then.

> Flow control is definitely a solution. I also need to implement a 
[snip]

If it is an overrun ,flow control is exactly what's intended to solve 
this. To detect an overrun you could poll just once a second (using an 
alarm) using cyg_io_get_config and the 
CYG_IO_GET_CONFIG_SERIAL_BUFFER_INFO key to see what the buffer usage is 
like. How to use this key is in the docs.

With a data protocol, yes you could start over if you detect an overrun, 
but it seems better to me to prevent it happening at all with flow control.

> > In my application, the only way to get around this byte-dropping problem
> > was by implementing flow control. I chose to implement it at the software
> > (i.e. protocol level) instead of hardware. (Strictly speaking, hardware
> > flow control is not automatic with the at91 USART. So what I'm really
> > saying for hardware flow control, is dedicate an I/O pin and call it DTR
> > [or whatever] and drive it manually with the software.)
eCos has support for this. If you implement hardware flow control in the 
same way as the 16x5x driver, it should all just work theoretically. The 
generic serial driver layer (in io/serial) will call into the hardware 
driver to diddle your flow control lines if the generic layer is going to 
run out of space.

Jifl
--
eCosCentric       http://www.eCosCentric.com/       <info@eCosCentric.com>
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine