发送2个SPI字节

Question

When using the ATMega328 hardware SPI interface, the program gets suck on the second byte.

I have tried reading the SPDR to clear the SPIF bit in SPSR, I thought that the flag must be cleared before my code will continue

PORTB &= !(1<<SSDAC); // Pulling slave select low
_delay_ms(10);

Serial.println("Sending MSB");
SPDR = MSByte;
while (!(SPSR & (1 << SPIF)));

Serial.println("Sending LSB");
SPDR = LSByte;
while (!(SPSR & (1 << SPIF)));

Serial.println("Sent!");
_delay_ms(10);
PORTB |= (1<<SSDAC); // Pulling slave select high

My serial monitor is getting up to "Sending LSB". Removing the while loop after that allow the code to continue, but this implies the data isn't being sent.

PS After removing the first while loop, it continues through and reads "Sent!". However, when the code repeats for a second time; it again gets stuck at "Sending LSB"... I have now even tried using the Arduino SPI library... STILL STUCK!

PORTB &= ~(1 << SSDAC);
_delay_us(1);
Serial.println(bits, BIN);
data = SPI.transfer16(MSByte);
Serial.println("Sent!");
_delay_us(1);
PORTB |= (1 << SSDAC);

It prints the sent (sending) bits, but the code get's stuck and doesn't reach the "Sent!"...

Answer 1

Did you configure the SS pin as an output? This is a common oversight when using ATMega SPI.

From the manual:

When the SPI is configured as a master (MSTR in SPCR is set), the user can determine the direction of the SS pin. If SS is configured as an output, the pin is a general output pin which does not affect the SPI system. Typically, the pin will be driving the SS pin of the SPI slave. If SS is configured as an input, it must be held high to ensure Master SPI operation. If the SS pin is driven low by peripheral circuitry when the SPI is configured as a master with the SS pin defined as an input, the SPI system interprets this as another master selecting the SPI as a slave and starting to send data to it.