Go Down

Topic: SPI - Bitbang VS. SPI library (Read 4 times) previous topic - next topic

MarkT

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...
[ I won't respond to messages, use the forum please ]

dhenry

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.

dc42

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.
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.

MarkT


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.
[ I won't respond to messages, use the forum please ]

dhenry

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.

Go Up