Re: [ECOS] Double buffers using US_RPR and US_RCR

[Laurent GONZALEZ <laurent dot gonzalez at silicomp dot fr>]

On Mon, 27 Oct 2003 10:59:09 +0100
"Eric de Jong" <list_ericdejong_10@gmx.net> wrote:

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

There is only one place in the code where to find something that does
what Magnus Nilsson quoted.

RCR = 0
work_pointer = RPR
RPR = spare (swapped) buffer
RCR = size of the previous buffer

It is in the ISR.
Anyway....

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

The buffer is swapped every time you receive an interrupt: after the
reception buffer becomes full or the timeout occurs.

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

Even at 230400 baud, 1 char requires around 43 us to be received, in
eCos it is more than needed to run an ISR (I say ISR, not DSR), or your
system (your application) has no more real time caracteristics. But It
is true, that if you receive 2 chars before running the swap trick in
the ISR, there will be a lost char.
I think you really should try the driver if you're interrested in. I can
succesfully drive the serial line at high speed on very slow machines
without any loss. For example: an mp3 player that receives the stream
through SLIP at 230400 on an eb40a at 66Mhz. It uses the openbsd stack
and decodes a 128kbit mp3 stream to 48Khz PCM.

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

And it is possible for other thread to run ?

-- 
GONZALEZ Laurent
Silicomp Research Institute
Tel: 04 76 41 66 98

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