Re: [ECOS] AT91 interrupt driven functionality

Re: [ECOS] AT91 interrupt driven functionality

[harri.siirtola]

I wrote:
>> 1. I can't find any references to the tx & rx buffer pointers & char
>> counters (US_RPR, US_TPR, US_RCR, US_TCR), not even in the register address
>> definitions in plf_io.h. Shouldn't there be some in order to use buffered
>> I/O (or non-blocking transfers)?

Jifl:
>All we need to know is that data is ready, and we can just read the RHR to
>get it, surely? I'm not particularly familiar with the AT91 driver, but the
>driver code seems to make sense.
 
Looking at the USART description, the Peripheral Data Controller takes care
of buffered USART I/O. I think one should init the buffer pointer (US_TPR
in tx case) and write data count to US_TCR. The transfer is triggered by
TXRDY and ENDTX interrupt is asserted when the buffer is empty. Transfer is
restarted by writing a non-zero value to US_TCR. There's still something
unclear in the rx case, so please look at it when you have time.

I don't use any net functionality, nor did I enable it in my config. I
updated my CVS a month ago, are there some modifications to USART
functionality or just networking?

Thanks,
	Harri

Re: [ECOS] AT91 interrupt driven functionality

[Jonathan Larmour]

harri.siirtola@vtt.fi wrote:
> 
> I wrote:
> >> 1. I can't find any references to the tx & rx buffer pointers & char
> >> counters (US_RPR, US_TPR, US_RCR, US_TCR), not even in the register address
> >> definitions in plf_io.h. Shouldn't there be some in order to use buffered
> >> I/O (or non-blocking transfers)?
> 
> Jifl:
> >All we need to know is that data is ready, and we can just read the RHR to
> >get it, surely? I'm not particularly familiar with the AT91 driver, but the
> >driver code seems to make sense.
> 
> Looking at the USART description, the Peripheral Data Controller takes care
> of buffered USART I/O. I think one should init the buffer pointer (US_TPR
> in tx case) and write data count to US_TCR. The transfer is triggered by
> TXRDY and ENDTX interrupt is asserted when the buffer is empty. Transfer is
> restarted by writing a non-zero value to US_TCR. There's still something
> unclear in the rx case, so please look at it when you have time.

I'm afraid time is not something we have in abundance. Can I suggest you
have a go at it yourself? You seem like you have a promising theory, so
perhaps just follow it up and see if it works!
 
> I don't use any net functionality, nor did I enable it in my config. I
> updated my CVS a month ago, are there some modifications to USART
> functionality or just networking?

It was just a suggestion as if you had had the net package enabled, it
might mean a particular bit of code may be responsible for the dropped
characters.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine

[ECOS] AT91 interrupt driven functionality

[harri.siirtola]

1. I can't find any references to the tx & rx buffer pointers & char
counters (US_RPR, US_TPR, US_RCR, US_TCR), not even in the register address
definitions in plf_io.h. Shouldn't there be some in order to use buffered
I/O (or non-blocking transfers)?

2. start_xmit and stop_xmit exist, why not similar functions for rcv?

The reason I'm asking this: I'm losing rx chars coming from port 0 as
there's no hardware handshaking available on AT91R40807 (and xon/xoff is
somewhat undesirable in my application). If the system really uses buffers
of 128 bytes, this shouldn't be happening. So, what am I missing here?

Thanks,
	Harri

Re: [ECOS] AT91 interrupt driven functionality

[Jonathan Larmour]

harri.siirtola@vtt.fi wrote:
> 
> 1. I can't find any references to the tx & rx buffer pointers & char
> counters (US_RPR, US_TPR, US_RCR, US_TCR), not even in the register address
> definitions in plf_io.h. Shouldn't there be some in order to use buffered
> I/O (or non-blocking transfers)?

All we need to know is that data is ready, and we can just read the RHR to
get it, surely? I'm not particularly familiar with the AT91 driver, but the
driver code seems to make sense.
 
> 2. start_xmit and stop_xmit exist, why not similar functions for rcv?
> 
> The reason I'm asking this: I'm losing rx chars coming from port 0 as
> there's no hardware handshaking available on AT91R40807 (and xon/xoff is
> somewhat undesirable in my application). If the system really uses buffers
> of 128 bytes, this shouldn't be happening. So, what am I missing here?

Are you using recent anonymous CVS? If so, this may be something we've been
looking at ourselves here with a recent change to make network debugging
more reliable. Do you have CYGPKG_NET included in your configuration? If
so, try removing it, rebuilding eCos (from scratch), and seeing if that
improves things. Please let us know what happens.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine