[En-Nut-Discussion] SPI in IRQ

[Klaus Kloos]

Hello Harald

Thanks for your fast answer.

> On 16.02.2012 08:22, Klaus Kloos wrote:
>> So I tried to use the NutOS functions. (*spiBus1At91.bus_alloc) and (*spiBus1At91.bus_release) are called outside the IRQ,  (*spiBus1At91.bus_transfer) is called at IRQ time.
>> The transfer of the 3 bytes last ca. 12us using 10MHz SPI. It is working, but unreliable. Sometimes my device freezes.
> 
> Probably. In general, it is not allowed to call API functions in
> interrupt context, except NutEventPostFromIrq(). As a special exception
> it is possible to use stdio functions on a polling device, usually devDebug.
> 
ok, i was aware that this is not the right way. It was only a test and it gave me a 'near to working' result :-) My hope was to get bus-transfer() IRQ save somehow......
What is necessary to make a function IRQ save?

>> What are my possibilities? Is there a recommended way to solve such time-critical SPI-requests?
>> Can I get the Nut/OS functions IRQ save somehow?
> 
> Nut/OS allows to use native interrupt handlers. For the AT91 you can use
> 
> static void MySpiIrqHandler(void) __attribute__ ((naked));
> void MySpiIrqHandler(void)
> {
>    IRQ_ENTRY();
> ...your code here...
>    IRQ_EXIT();
> }
> 
> In your main code you need to write the address of the handler into the
> related AIC service routine register.
> 
> outr(AIC_SVR(SPI0_ID), (unsigned int) MySpiIrqHandler);
> 
Interesting, this might give me back the 1us which I loose between an IRQ and the calling of my IRQ-routine using the NutOS way.

But that's not the main problem. How do I get the SPI-Value in my 30us slot? I see these ways:
Is there a way to generate a fast context-switch from IRQ to the thread which is allowed to call bus_transfer()? Can this be done reliable in ca. 10us?
Then I can use the NutOS SPI routines.

An other way is the read the data in the IRQ. But then I have to code a function like bus_transfer() by myself (?). Not a nice chance...

A simple solution would be working without an IRQ and do everything in a thread without allowing a context-switch. So the sam7 will freeze for up to 50ms (i have to read 1000 values).

> And...not to forget...it is always a good idea to check the datasheet. ;-)
> 
Not that I have completely memorized it, but Ive read it several times. The problem seems clear. Im too slow.
There is also a 128kSPS variant of the chip available. Then the time slot is less than 8us. Im happy that Im not forced to solve this problem....

Greetings Klaus