[ECOS] Serial buffer overrun
Mon Jan 13 03:50:00 GMT 2003
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
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.
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
More information about the Ecos-discuss