# Atmega16 SPI Questions

i have a problem understanding the transmitting function of SPI in atmega16 the function that i don't understand is

void SPI_SendByte (s8_t data){
SPDR = data;

/* check if operation of transmit or receive is running */
while (bit_is_clear(SPSR,SPIF));


}

i think it should replace the two lines like this one here

void SPI_SendByte (s8_t data){

/* check if operation of transmit or receive is running */
while (bit_is_clear(SPSR,SPIF));

SPDR = data;


}

aren't we suppose to check if busy first , then write the data ?? why we did otherwise , in other communication protocol like UART for example we first check for busy then we write to register , why it's not the same in SPI !!?

• Where is this function coming from? What library are you using? Please also edit your question to better use the code blocks and to use better capitalization and spacing. – user2943160 Aug 28 '16 at 0:41
• it's not important where this functions are coming from, i am asking a question and i don't see why you need any other thing , the code copy and pasted from atmega16 Datasheet ! – Mustafa Bahaa Aug 28 '16 at 0:46
• The rest of the context is absolutely necessary. For example, the timing of the code that manipulates the select line. And if you hope to ever read data with a corresponding receive() or transact() method (in SPI these are all nearly the same), the timing of that, too. – Chris Stratton Aug 28 '16 at 1:33

You assume that SPIF is initially 1, which would indicate that SPDR may be safely written -- in other words you expect SPIF to be a ready/busy indicator. However this is not consistent with the actual definition of SPIF being an operation finished indicator (Serial Peripheral Interface Finished).

According to the ATmega16 data sheet, SPSR - SPI Status Register bit SPIF Initial Value is actually 0, not 1. So in your second code example, the statement

while (bit_is_clear(SPSR,SPIF));


is an infinite loop if SPIF is initially 0 and no data has been written to SPDR.

An operation cannot finish before it begins. SPIF will never be 1 until after the first byte of data is written to SPDR and the data is subsequently transmitted by the SPI.

• i understand the function of SPIF , what i don't understand is why the first code works but the second doesn't – Mustafa Bahaa Aug 28 '16 at 3:58
• Initial value of SPIF is 0, not 1. – MarkU Aug 28 '16 at 4:30

From the datasheet:

... writing a byte to the SPI Data Register starts the SPI clock generator, and the hardware shifts the eight bits into the Slave. After shifting one byte, the SPI clock generator stops, setting the end of Transmission Flag (SPIF).

Writing the byte is what initiates the SPI transfer. If you don't write the byte then the transfer won't start and hence can never finish.

I don't consider either approach "good," as both of them represent a busy wait method. I use different approaches, unless all I'm doing is a test of some kind and it's not going into regular use (or I have no other choice.)

However, the two approaches are equivalent.

In the first case, the routine always presumes that the data buffer is available for writing. So it just writes the value, without delay. Then, afterwards, it waits. In this way, the routine never leaves until it can guarantee that the data has already been sent and that the buffer is once again ready to accept data. The next time in, so long as this assumption remains valid, it should work.

In the second case, the routine doesn't assume that the data buffer is ready. So it waits. Then it writes out the data and leaves immediately, where it is almost certainly not yet transmitted. So this routine must, of course, check to see if it was sent at the start of the code.

It is just two ways of doing the same thing. The two routines are NOT compatible, though. You use one. Or you use the other. But not both.

• The problem that method number 1 works , but the second method which i think it's more logical , is not working ! – Mustafa Bahaa Aug 28 '16 at 1:05
• @MustafaBahaa: That may be because different approaches don't mix and you may be using library code that is only compatible with one, or the other of them. They truly are equivalent, if used consistently. – jonk Aug 28 '16 at 1:44