running SPI at lowest speed...

Go To Last Post
6 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm wondering how many people are running their SPI bus at very low speeds, say, less than 1mhz. It seems (at least to my perception) that most people run the SPI at a very high speed and have the processor run in a busy loop while the transfer finishes. However, this kind of speed seems unnecessary in alot of AVR applications, unless perhaps you have a large number of SPI devices. Case in point: an Atmel SPI dataflash chip takes 20ms to erase and program a page, however, transferring the full page over SPI at 250khz only takes 16ms. The SPI running full time would easily keep the page buffers full. At such a low speed an interrupt driven approach becomes feasible (I wrote a full-duplex transfer routine in C that takes 62 cycles in the ISR). My busy loop transfer at 8mhz takes 49 cycles. Is this a worthwhile tradeoff? I would think that the lower speed could have significant EMC benefits at some applications.

Anyway, food for thought I guess.

JeremyB.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Helle Jeremy,

I am thinking about switching the way I communicate with some SPI devices.

At first I had a timer interrupt in which I talk with some external devices via SPI. Since it it not "nice" to wait longer than necessary in an interrupt service routine, I tried the following:
I programmed an SPI buffer for sending and receiving data autonomically. So in the timer ISR I only have to read from / write to the buffer. The rest is done in an SPI-ISR (must be triggered at first by sending one byte!).
But I am not sure if this is the right / best approach, because the SPI communication is not synchronously to the timer interrupt anymore.
Also, the SPI timer interrupt must fullfill some requirements: the frequency of transceiving data must be higher than the timer interrupt, otherwise SPI data is lost...
The interrupt load is higher now: timer interrupt and SPI interrupt.

I think, I will variate the SPI clock frequency, and see if there is better performance.
But I think you are right, that the transmission bursts generate more EMI than a constant (lower-frequent) SPI signal...

Maybe some others have any experience (or did some EMI measurements).

Have a nice Sunday,
Michael

In the beginning was the Word, and the Word was with God, and the Word was God.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The interrupt load does increase, but it does allow the application to do some useful work while a transfer is in progress, which is a bonus if a low speed transfer is required and not optional. Personally, I just worry about EMC issues possibly corrupting my data, generally it is the only section of my communication links that is not protected by some sort of error detection. I'm setting up a queue driven system to allow queueing of multiple transfers to multiple devices. It changes the way your program has to be structured if it uses alot of SPI communication, I'm switching some things that were sequential to state machines polling the SPI status to see if its transfer is done. If the transfer isn't finished, the state machine will return and the next task in the main loop can execute.

JeremyB.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think, the best way of accessing any serial peripheral devices depends on the communication events you need at minimum:
If you only have to read/write sometimes an external device (e.g. SPI realtime clock) with only a short data telegram it is better to wait for transmission is complete.
If you have to read/write the whole time any devices (ADC, DAC etc.) it may be better to have a several interrupt routine for communication. But here you have to be careful, when accessing data structures which are bigger than one byte...

Michael

In the beginning was the Word, and the Word was with God, and the Word was God.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I use separate speeds for seperate devices. I have an ADC which is connected via SPI through optocouples. Because of the opto speed, I use a low speed. For the SPI memory I use the maximum speed, it is connected directly to the uC. I don't use interrupts for SPI. If possible I prefer state-machines instead of interrupts. The reaction is not as fast as an interrupt but for SPI it works great. And I find it more readable and I can do easier priorities when doing it in a statemachine instead of interrupt.

Patrick

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello Patrick,

I know what a state machine is, but how do you use it exactly for SPI? - Are you doing this in the main loop?

State 1: send high speed data over SPI => State 2
State 2: data is send, decrease SPI clock frequ. => State 3
State 3: send optocoupler data at low speed => State 4
State 4: data is send, increase SPI clock frequ. => State 1

Similar to this, or how?

Michael

Michael

In the beginning was the Word, and the Word was with God, and the Word was God.