[ECOS] Double buffers using US_RPR and US_RCR

[ECOS] Double buffers using US_RPR and US_RCR

[Magnus Nilsson]

Hi,

I'm doing speed tests using double receive buffers and US_RPR/US_RCR.
I don't have access to any flow control, and I'm losing a byte of every 
now and then, regardless of baudrate.
Presumably this happens when I receive a byte just as I'm switching buffers.

My buffer switching routine looks like this (it runs often enough not to 
get any overruns):
US_RCR = 0; // disable transfer
current_chars = US_RPR - (uint32)rx_buffer_1; // see how many chars 
there are in the buffer
US_RPR = (uint32)rx_buffer_2; // receive in the other buffer, as we're 
going to read the first one
US_RCR = BUFFER_SIZE; // re-enable transfer

I have experimented with using:
if ((US_CSR & US_TIMEOUT) == US_TIMEOUT) {
 // switch buffers
}
which greatly increased the accuracy, but I'm still losing ~1 byte every 
~100kB.

Do you have any ideas on how to switch buffers without using flow control?

Kind regards/Magnus




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

Re: [ECOS] Double buffers using US_RPR and US_RCR

[Eric de Jong]

I asume you work with an atmel arm core...

- Disable ALL interrupts before you disable the PDC (= DMA engine for the uart
on the atmel controller).
- Store the US_RPR pointer.
- Setup new transfer in buffer2
- reenable interrupts
- check US_RPR, see if it had reached the end of the buffer. if yes, your buffer
is too small, and you lost one or more characters. set an error flag.
- check if buffer2 was already processed. if not, you are about to overwrite non
processed data.
- check the time elapsed since your last swap. store the larges time for
debugging purposes.

Eric de Jong


----- Original Message -----
From: "Magnus Nilsson" <man@lundinova.se>
To: <ecos-discuss@sources.redhat.com>
Sent: Friday, October 24, 2003 12:19 PM
Subject: [ECOS] Double buffers using US_RPR and US_RCR


Hi,

I'm doing speed tests using double receive buffers and US_RPR/US_RCR.
I don't have access to any flow control, and I'm losing a byte of every
now and then, regardless of baudrate.
Presumably this happens when I receive a byte just as I'm switching buffers.

My buffer switching routine looks like this (it runs often enough not to
get any overruns):
US_RCR = 0; // disable transfer
current_chars = US_RPR - (uint32)rx_buffer_1; // see how many chars
there are in the buffer
US_RPR = (uint32)rx_buffer_2; // receive in the other buffer, as we're
going to read the first one
US_RCR = BUFFER_SIZE; // re-enable transfer

I have experimented with using:
if ((US_CSR & US_TIMEOUT) == US_TIMEOUT) {
 // switch buffers
}
which greatly increased the accuracy, but I'm still losing ~1 byte every
~100kB.

Do you have any ideas on how to switch buffers without using flow control?

Kind regards/Magnus




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



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

Re: [ECOS] Double buffers using US_RPR and US_RCR

[Laurent GONZALEZ]

On Fri, 24 Oct 2003 13:19:33 +0200
Magnus Nilsson <man@lundinova.se> wrote:

> Hi,
> 
> I'm doing speed tests using double receive buffers and US_RPR/US_RCR.
> I don't have access to any flow control, and I'm losing a byte of
> every now and then, regardless of baudrate.
> Presumably this happens when I receive a byte just as I'm switching
> buffers.
> 
> My buffer switching routine looks like this (it runs often enough not
> to get any overruns):
> US_RCR = 0; // disable transfer
> current_chars = US_RPR - (uint32)rx_buffer_1; // see how many chars 
> there are in the buffer
> US_RPR = (uint32)rx_buffer_2; // receive in the other buffer, as we're
> 
> going to read the first one
> US_RCR = BUFFER_SIZE; // re-enable transfer
> 
> I have experimented with using:
> if ((US_CSR & US_TIMEOUT) == US_TIMEOUT) {
>  // switch buffers
> }
> which greatly increased the accuracy, but I'm still losing ~1 byte
> every ~100kB.
> 
> Do you have any ideas on how to switch buffers without using flow
> control?
> 

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.

regards,

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

Re: [ECOS] Double buffers using US_RPR and US_RCR

[Eric de Jong]

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

Re: [ECOS] Double buffers using US_RPR and US_RCR

[Laurent GONZALEZ]

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

Re: [ECOS] Double buffers using US_RPR and US_RCR

[Eric de Jong]

>> My patch aims at reducing the interrupt load when using fast
>> transmission (high baud rates), while still maintaining responsiveness at
>> lower speeds.

I assume the DSR has interrupts enabled. When there are other interrupts and/or
other DSR's have a lot of workload, your patch has certainly advantages.

Thanks for your explanations, Thomas and Laurent.

Eric de Jong



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

Re: [ECOS] Double buffers using US_RPR and US_RCR

[Thomas Koeller]

Eric de Jong wrote:
> Alright, It took a while before I figured it out, but I think your code
> works as follows:
>
> ISR:
> - receive 1 character, store the character in a buffer
> - disable receive interrupt
> - start the PDC engine to store any further characters
> - trigger DPC
>
> DPC:
> - stops PDC engine, process all received characters
> - reenable receive interrupt

Not quite. Interrupts are re-enabled _before_ the data just received
is processed. So any data arriving during this time is not lost.

>
> As the first character is received in the ISR and not in the DPC as it used
> to be, the latency is smaller. However, if another interrupt is handled
> first, it is still possible to miss characters. Would the following code
> not do exactly the same? I know interrupts are not enabled for the ARM
> target during DPC, but it should. Else there is no need for a DPC anyway
> (please correct me if I am wrong, I am not up-to-date).
>

A DPC (actually called a DSR in ecos terminology) is required in any case,
because the callbacks into the hardware-independent driver module cannot
be executed from interrupt context.

> ISR:
> - receive 1 character, store the character in a circular buffer, increase
> count - trigger DPC
>
> DPC: (ISR stays enabled)
> - copy circulair buffer
> - disable interrupts, decrease count, enable interrupts
> - process data
>
Would probably work, but causes more CPU load by requiring an interrupt for
every single character even at high baud rates, while not giving any speed
advantage. My patch aims at reducing the interrupt load when using fast
transmission (high baud rates), while still maintaining responsiveness at
lower speeds.

tk 
--------------------------------------------------

Thomas Koeller, Software Development

Basler Vision Technologies
An der Strusbek 60-62
22926 Ahrensburg
Germany

Tel +49 (4102) 463-162
Fax +49 (4102) 463-239

mailto:thomas.koeller@baslerweb.com
http://www.baslerweb.com

==============================


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

Re: [ECOS] Double buffers using US_RPR and US_RCR

[Eric de Jong]

Alright, It took a while before I figured it out, but I think your code works as
follows:

ISR:
- receive 1 character, store the character in a buffer
- disable receive interrupt
- start the PDC engine to store any further characters
- trigger DPC

DPC:
- stops PDC engine, process all received characters
- reenable receive interrupt

As the first character is received in the ISR and not in the DPC as it used to
be, the latency is smaller. However, if another interrupt is handled first, it
is still possible to miss characters. Would the following code not do exactly
the same? I know interrupts are not enabled for the ARM target during DPC, but
it should. Else there is no need for a DPC anyway (please correct me if I am
wrong, I am not up-to-date).

ISR:
- receive 1 character, store the character in a circular buffer, increase count
- trigger DPC

DPC: (ISR stays enabled)
- copy circulair buffer
- disable interrupts, decrease count, enable interrupts
- process data


Eric de Jong


----- Original Message -----
From: "Koeller, T." <Thomas.Koeller@baslerweb.com>
To: "'Eric de Jong'" <list_ericdejong_10@gmx.net>;
<ecos-discuss@sources.redhat.com>
Sent: Monday, October 27, 2003 11:10 AM
Subject: RE: [ECOS] Double buffers using US_RPR and US_RCR


Eric de Jong wrote:
> 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.

If you are concerned about loosing characters by not being
able to respond fast enough, you may want to look at the
driver patch I recently submitted
(http://sources.redhat.com/ml/ecos-patches/2003-10/msg00132.html), which
should not suffer from this problem.

tk
-----------------------------------------------
Thomas Koeller, Software Development

Basler Vision Technologies
An der Strusbek 60-62
22926 Ahrensburg
Germany

Tel +49 (4102) 463-390
Fax +49 (4102) 463-46390

mailto:Thomas.Koeller@baslerweb.com
http://www.baslerweb.com






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

RE: [ECOS] Double buffers using US_RPR and US_RCR

[Koeller, T.]

Eric de Jong wrote:
> 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.

If you are concerned about loosing characters by not being
able to respond fast enough, you may want to look at the
driver patch I recently submitted
(http://sources.redhat.com/ml/ecos-patches/2003-10/msg00132.html), which
should not suffer from this problem.

tk
----------------------------------------------- 
Thomas Koeller, Software Development 

Basler Vision Technologies 
An der Strusbek 60-62 
22926 Ahrensburg 
Germany 

Tel +49 (4102) 463-390 
Fax +49 (4102) 463-46390

mailto:Thomas.Koeller@baslerweb.com 
http://www.baslerweb.com 


 

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