[ECOS] Simple serial comms

grahamlab graham.labdon@cranems.co.uk
Fri Jul 3 12:30:00 GMT 2009

Nick Garnett wrote:
> grahamlab <graham.labdon@cranems.co.uk> writes:
>> I have tried flow control but to no avail
>> there must be a way to receive more than 128 bytes has anybody got any
>> other
>> suggestions
> Flow control should entirely solve your problem. Did you enable the
> same kind of flow control at both ends of the connection?
> I have run tests that successfully transfer larger quantities of data
> at higher baud rates for long periods. So I don't believe there is a
> significant problem with the basic driver code.
> Some other things to try:
> - Test against a host with a real RS232 device. USB adaptors can do
>   weird things. It is worth eliminating this as a cause of problems,
>   particularly with regard to flow control.
> - Try increasing STM32_RXBUFSIZE in the driver source to 128 or
>   more. Also add a diag_printf() to the overflow branch in the ISR to
>   see if it triggers.
> - Avoid diag_printf() calls while waiting for data. If you are running
>   via GDB these calls can cause interrupts to be disabled while the
>   output is being sent. This may cause the driver to miss characters.
> - It may be instructive to work out exactly which bytes are lost in
>   each message. This may give a clue as to which FIFO or buffer is
>   filling up.
I wont be able to test against a 'real' host until monday
I have tried a variety of values for STM32_RXBUFSIZE  but nothing changes -
the overflow branch is not triggered
Is it possible for you to send me the programs you use to test the serial

View this message in context: http://www.nabble.com/Simple-serial-comms-tp24306125p24322375.html
Sent from the Sourceware - ecos-discuss mailing list archive at Nabble.com.

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

More information about the Ecos-discuss mailing list