[En-Nut-Discussion] Timing problems with UART

[Klaus Kloos]

Hello Ulrich
>> Is it NUT_IRQPRI_UART0 in ih_at91uart0.c? ive changed it to 7 but there is not much change.
>> (Ive change the code directly in the nut-directory. How to add such defines to the makefile?)
>> 
> In your local Makefile add
> CFLAGS += -DNUT_IRQPRI_UART0=xyz
> 

Ive added this line to nutapp/UserConf.mk, rebuild nutOS using the configurator and rebuild my project but the debugger still shows the unchanged value.

>>> 2nd) NutEnterCritical disables all interrupts until NutExitCritical is
>>> called. And therefore yes: It might influence your USART timing.
>>> 
>> Is it a way (for me) to modify NutEnterCritical/NutExitCritical for leaving the USART-IRQ unchanged?
> 
> The problem with atomic operations is that who comes first, serves
> first. So if someone already entered atomic mode your atomic code cannot
> be executed until the first one left it.
I will try the DMA way

> A hint:
> As you like to transmit packet oriented data which you already prepared
> in your own part of the software, you can and should use your own sender
> function.
yes ...

> So write a function that throws out your packets with your features.
> It is no tricky thing. You can reregister the interrupts from the USARTs
> in your own piece of code without a problem. If you don't call the code
> that Nut/OS provides it will either not compiled in or it stays silently
> in the background.
> 
> The packet thing you need is a pretty easy one, as you only prepare your
> packet in a memory, put address and size into DMA registers. Enable the
> empty-Interrupt and start the DMA transmission via USART control register.
> 
sounds to easy :-)

> I guess about 8 lines of code and the data rolls out.
> 
> The spi code is in at91_spi.c. AFAIK I implemented it as I had to drive
> a larger OLED display and a radio chipset on the same bus. And with both
> of them using DMA gave real big performance boosts.
> 
> If you could tell me some more details of how you need to use the USARTs
> for your application, I re reactivate my AT91SAM7X-EK and test or
> support a bit. If it's company secret, use my PM.
> 
many thanks for this in advance.
Ive transfered the code from http://www.sparkfun.com/datasheets/DevTools/SAM7/at91sam7%20serial%20communications.pdf
The syntax is completely different not using the outr() functions but c-structs and different defines. So my conversion might by wrong. The result is not working. Ive had got one irq somehow which im not able to reproduce.
Im sending this 5k of code by personal mail, to go easy on the mailing-list resources. If someone else is interested please send a mail.

Greetings Klaus