Pages: 1 [2]   Go Down
Author Topic: SPI - Bitbang VS. SPI library  (Read 4195 times)
0 Members and 1 Guest are viewing this topic.
0
Offline Offline
Shannon Member
****
Karma: 214
Posts: 12424
Arduino rocks
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

You stick a 'scope on the SCLK pin and trial and error - the exact delay might be sensitive to the nature of surrounding
code and the avr-gcc version and optimization flags used, so its not perfect technique.   The ratio of SPI clock to system
clock is fixed by the prescaler divide ratio so if you get it working at 16MHz it should still work at 8MHz system clock too...
Logged

[ I won't respond to messages, use the forum please ]

Offline Offline
Edison Member
*
Karma: 116
Posts: 2205
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Quote
The code I grabbed was actually waiting for a reply.

That's why it is so much faster if you do it via the interrupt: you can just keep loading up the next byte to be sent in the isr, freeing up the mcu.
Logged

United Kingdom
Offline Offline
Tesla Member
***
Karma: 227
Posts: 6637
Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

See http://arduino.cc/forum/index.php/topic,129824.0.html. Yes of course the number of NOPs required will depend on clock frequency; but below the maximum available SPI clock frequency (8MHz on a 16MHz Arduino), the speed gain of not using a busy wait loop will be proportionately lower, so it's probably not worthwhile.
Logged

Formal verification of safety-critical software, software development, and electronic design and prototyping. See http://www.eschertech.com. Please do not ask for unpaid help via PM, use the forum.

0
Offline Offline
Shannon Member
****
Karma: 214
Posts: 12424
Arduino rocks
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Quote
The code I grabbed was actually waiting for a reply.

That's why it is so much faster if you do it via the interrupt: you can just keep loading up the next byte to be sent in the isr, freeing up the mcu.

If you run SPI at 8MHz the overhead of calling the interrupt handler routine is likely more than the SPI transfer (16 clocks)
and busy-waiting will be more efficient?  Be interesting to compare at 8MHz/4MHz/2MHz etc.
Logged

[ I won't respond to messages, use the forum please ]

Offline Offline
Edison Member
*
Karma: 116
Posts: 2205
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

The math is slightly different.

When pulling, you are waiting 16 ticks to transmit and load the next char.

In interrupt, your transmission starts as you load up the char. You then exit the isr and the mcu is doing other things. 16 ticks later, the isr fires; With isr latency (~16 ticks), you load up the next char. So every 32 ticks, you send a char. Of that 32 ticks, the mcu is working on something else for 16 ticks. The net result is that the actual transmission is slower (8Mhz spi running at 4Mhz over the long run).

However, if you lower the spi speed (to 100khz for example), the interrupt approach offers considerable advantage, in terms of efficiency and convenience: it is load-and-forget from the programmer's perspective.
Logged

Pages: 1 [2]   Go Up
Jump to: