Pages: [1]   Go Down
Author Topic: Is it possible to use SPI in interrupt and 'regular' code  (Read 316 times)
0 Members and 1 Guest are viewing this topic.
Offline Offline
Full Member
***
Karma: 0
Posts: 100
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

My sketch uses an interrupt which is called every 50 microseconds. In the interrupt function I use SPI (the hardware SPI pins from the atmega328) to read flash memory. I was wondering if it is possible to use the same SPI-pins in the regular loop() function to communicate with another device - say a DAC - or might there be interference between the two parts of my sketch ?

Jack
Logged

Global Moderator
Offline Offline
Brattain Member
*****
Karma: 452
Posts: 18694
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Read this before posting a programming question

Quote
My sketch ...

What sketch?
Logged

Global Moderator
Offline Offline
Brattain Member
*****
Karma: 452
Posts: 18694
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

In principle I don't see a problem except possibly a timing one. 50 uS isn't that much. Also you would need to ensure that the interrupt doesn't occur while you are in the middle of accessing your DAC.
Logged

Offline Offline
Full Member
***
Karma: 0
Posts: 100
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Thank you for your reply.

I understand your remark regarding "my sketch" but the question is of more general nature. Please let me rephrase it:

I make use of an interrupt function. This will interrupt 'regular' program execution. Now my program basically breaks down to assembler codes for the processor, and program execution can jump to the interrupt-function after finishing any of these assembler instructions. This could mean for example that program execution jumps to the interrupt in the middle of a Serial.println()-statement.

Is this correct ? Because then your answer regarding the timing issues is enough for me to work on.

I did some extensive testing with a scope on my interrupt, it absorbs about 50 % of cpu time; all SPI access up till now is done from within the interrupt to prevent timing issues. However... the coding would be shorter and simpler if I could also use it from loop(); I might fix timing issues or double usage with some flags.
Logged

North Queensland, Australia
Offline Offline
Edison Member
*
Karma: 53
Posts: 1802
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

I have written a library that may help you here. The library allows a selection of ways to provide atomic operation to your code.

The 'Protect' function in particular helps with a single operations that cannot be interrupted:

Code:
BlockType::Protect( Serial.PrintLn )( "My Text" );

Or an object that when created locally, will provide a 'critical section' until it goes out of scope:

Code:
void Foo(){

  //This code can be interrupted.

  BlockType b;

  //This code cannot.
}
Logged


Global Moderator
Offline Offline
Brattain Member
*****
Karma: 452
Posts: 18694
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

I understand your remark regarding "my sketch" but the question is of more general nature.

Oh well, if we are talking generally ...

http://www.gammon.com.au/interrupts

You can "guard" code by putting noInterrupts () ... interrupts ()  around it.

I presume you have working the need to set the appropriate SS lines, as you say it is more-or-less working.

Quote
This could mean for example that program execution jumps to the interrupt in the middle of a Serial.println()-statement.

Virtually anywhere. Some code is already guarded to make sure that variables are accessed atomically. You may also need to do that.

Just be aware that doing X when interrupts are off will defer X until interrupts are re-enabled. Plus a timer interrupt may be queued as well. You may be reducing the window of time in which X (plus timers etc.) are done so small that you run out of time.
Logged

Offline Offline
Full Member
***
Karma: 0
Posts: 100
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Gentlemen,

Thank you very much for the reply. I will study both the link and the library in further detail. The explanation in the link was exactly what I was looking for. The code is working fully, I'm just going over it again to see if I can simplify things.

Cheers !

Jack

ps @nick: that is an awfully big collection of notes you've got there, very nice !
Logged

Pages: [1]   Go Up
Jump to: