AVR Hardware SPI

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

Hello ,

if I use the hardware SPI , I see an unexpected long delay between
2 consecutive bytes.I put one byte into SPI data register, then query the 'SPI transmit ready flag' in a loop , and transmit the next byte etc.
This is the normal way to do it , I think.
The delay (or gap you see on an oscilloscope) between two bytes should only be
some clock cycles (in my case 8 MHz ) for the 3 or so commands between 2
byte transmissions. But the delay is much bigger, about the same time you
need to transmit one byte with 2 MHz SPI-Clock ( abt. 8*(2*4) CPU-Cycles
= 36 clock cpu clock cycles ).
I also saw postings in other AVR-related groups about this phenomen , but no
solutions or explanations.

My question: Does anyone know why this delay appears? Or is it only a problem
of my special application, and other SPI-Implementations run without this delay?

Best regards

Thomas Rudolph
email: rudt@teleconnect.de

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

Thomas,

The behaviour you see is probably correct. There is no Send buffer, so the software has to detect end of transmission before the next byte can be transmitted.

To reduce the time delay between bytes, you can rewrite your interrupt handler to calculate the next byte while the transmitter is working. By putting it in a single global variable, you save the time required to look up the byte from the transmit array.

- Detect transmission ended (interrupt start)
- Read data to send from TEMP register
- Send data
- Read incoming data
- Store incoming data in receive buffer
- Read next data to send from transmit buffer
- Store next data in TEMP register
- Exit interrupt

Regards,

Haakon Skar

AVR Expert
Atmel Corporation

admin's test signature
 

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

On a question about the maximum clock rate for an
ATmega103 SPI slave interface Morten Reintz FAE AVR products, Atmel Norway claimed 1/4 of the device clock speed.
Is this really true?
I understand that it's true for an SPI master, but for a slave?
/Janne

admin's test signature
 

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

The behaviour you see is probably correct. There is no Send buffer, so the software has to detect end of transmission before the next byte can be transmitted.
Hello Haakon,

many thanks for your reply, but maybe I did not explain my problem correct:.
I have no interrupt handler, no transmit queue, no delays to lookup bytes.
I made a very simple sample program to test SPI:
I just send a byte to the SPI bus, query the 'transmit ready flag' ,
and the send the same byte again ... and so on.There are no other commands
between, I even don't read the incoming data.
But I see this unexpected delay I mentioned, if I use a good digital Oscilloscope.

Best regards and many thanks for your patience

Thomas
email: rudt@teleconnect.de

>To reduce the time delay between bytes, you can rewrite your interrupt handler >to calculate the next byte while the transmitter is working. By putting it in a >single global variable, you save the time required to look up the byte from the >transmit array.
>
>- Detect transmission ended (interrupt start)
>- Read data to send from TEMP register
>- Send data
>- Read incoming data
>- Store incoming data in receive buffer
>- Read next data to send from transmit buffer
>- Store next data in TEMP register
>- Exit interrupt
>
>Regards,
>
>Haakon Skar

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

Thomas,

There would still be a small delay between bytes, as the interface doesn't signal the end of transmission until the last bit has been read. The typical pause between bytes would be 6-10 MCU clock cycles.

To shorten the delay to a minimum, you can write code that relies on the WCOL flag. Write the next byte and you will either succeed (great) or collide (no problem). Keep writing the next byte until the WCOL flag doesn't get set. Check the datasheet for the details. WARNING!!! There is a hardware error in some early AVRs that make this method useless in master mode; in master mode only, if you write the next byte to the SPI in the same cycle as the previous transmission ends, the interface won't read the new data. The transmission will continue, sending the most recent incoming byte instead. Check the device erratasheet.

Regards,

Haakon

admin's test signature
 

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

Yes, slaves are also bound to 1/4 of the device clock speed.

Haakon

admin's test signature
 

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

In SPI, it is always the master who determines the clock. The slave just listens in for the clock and uses it to set the line accordingly.

admin's test signature