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: Double buffers using US_RPR and US_RCR


Hello Laurent,

>> This is a known issue in atmel's core

What issue? Please specify. And what is the solution? Without clues I cannot
find this back in your driver.

>> I discussed about that with ATMEL's engineer and we
>> together found the way to make it work without any char
>> loss. Have a look on my driver

I found it at http://sources.redhat.com/ml/ecos-patches/2003-10/msg00151.html .
Looks good. As I understand, it reads chunks of data from the serial port, and
if there is a timeout (pause in the serial transmission) the buffer is swapped
with an empty one and the data is processed in an interrupt/dpc.

However, it is still possible to lose data. If data is received without a
timeout, the receive buffer will be full. At this point an interrupt is given
and the buffer is swapped and the data is processed. If this interrupt is
delayed by another interrupt, and 2 more characters are received, there still
will be a character loss. This can happen with any burst transmission with more
data than the size of the receive buffer.

The only solution I can think of is polling the receive buffer and prevent this
buffer of ever getting full.

Eric de Jong

----- Original Message -----
From: "Laurent GONZALEZ"

Hello Magnus,

This is a known issue in atmel's core. I discussed about that with
ATMEL's engineer and we together found the way to make it work without
any char loss.
Have a look on my driver. I recently contributed in the ecos-patches
mailing list.



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