[En-Nut-Discussion] SPI in IRQ

Klaus Kloos klaus.kloos at gmx.de
Fri Mar 2 09:02:30 CET 2012


Am 16.02.2012 um 15:25 schrieb Ulrich Prinz:

Hello Ulrich

Your mail gave me some areas to think about. Now it is working.
I was thinking a IRQ/NutOS problem was driving me crazy, but the main problem was a simple memory fault.
Writing one byte further than the allocated space is always interesting.
In my application bus_transfer can be called in IRQ without problems. Now ive extracted the code of bus_transfer to get a bit faster.

Is there a way to find such memory problems more easily?
Im aware of the NUTDEBUG_CHECK_STACK which is very helpful in other situations.

Greetings Klaus

> Hi Klaus,
> 
> If I understand the datasheet of the ADC correctly it serves you with
> /DRDY signal every time a sample is complete.
> So if you write a GPIO IRQ handler that reads the SPI at this time,
> you are done with the first part.
> 
> For reading SPI you need to throw out dummy bytes that just trigger
> SCK so the ADC can write via MISO to your AT91.
> To get more free CPU time, you should think about using DMA transfer for SPI.
> So you set up a dummy region of RAM that hold a fixed pattern of
> control words and dummy bytes.
> Then you set up another region to store the read values into.
> Then you setup and start DMA with completion interrupt set.
> 
> The DMA completion interrupt then shows your application that there is
> a new value available.
> 
> If you need several values at a time, you can expand the regions of
> dummy and reception values and setup the DMA to transfer this bigger
> regions. The DMA Interrupt then only counts down the number of samples
> per block and calls your application after counter has reached 0.
> 
> To be more flexible and gather some additional time:
> You can set the AT91 DMA to work with separate pages. So if a DMA is
> completed you can flip to a nother page where it continues to work
> right away. So after you sampled one page, you have time to decode and
> move the date from there, while the DMA continues to write into the
> second page. After the second page is completed the DMA flips back to
> the first page or even a third page.
> 
> If I remeber my last AT91 devel over a year ago, it should be possible
> to implement you ADC routines with just DMA and a single DMA interrupt
> handler.
> 
> In general:
> You should keep a state variable in you code, that shows if your
> sampling is active. If not active, you can use normal nut/os SPI
> functions to setup / program your ADC. After activating your sampling,
> the variable should state that no normal nut/os function should
> trigger SPI.
> 
> You did not state the reason for this construction but in general I
> would suppose to use the I2S interface of an AT91 or STM32 and use the
> special features of this interface that automates constant time
> sampling and delivery of data with very low software overhead
> including multi buffer handling ( work in one while the other is
> filled, then switch)
> 
> I2S is just a derivate of SPI...
> 
Interesting, I2S is new for me. I will look at this and at the DMA stuff if I will get some spare time.....

Thanks for your help.

Greetings Klaus


More information about the En-Nut-Discussion mailing list