About the interrupt flag:
Send one byte of data from SPI:
void SPI_Set_SD_Byte(unsigned char txData)
{
UCB0TXBUF = txData; // Write to the transmit buffer
while ((UCB0IFG & UCTXIFG) == 0); // Waiting for sending to complete
}
Analysis: It takes about 1ms to send one byte at 9600bps, and about 1us to execute at 12MHz clock (UCB0TXBUF = txData;).
So a terrible thing happened. Waiting for the transmission to be completed requires wasting 3999 CPU cycles to query. How nice it would be if the waiting process was replaced by sleeping!
Look at the following program:
void SPI_Set_SD_Byte(unsigned char txData)
{
UCB0TXBUF = txData; // Write to the transmit buffer
LPM3;
}
#pragma vector=USCI_B0_VECTOR
__interrupt void USCI_B0_ISR(void)
{
//order interrupt service
switch (__even_in_range (UCB0IV,8))
{
case 0: break;
case 2: break;
case 8: while (!(UCB0IFG&UCTXIFG));
break;
LPM3_EXIT;
}
A clever thing happened, your CPU rested first, let me SPI work alone.
But when the system opens the SPI send interrupt only, the above is OK, but the question is, only send but not receive? Sometimes SPI communication may not be
There is only one peripheral, and in order to achieve low power consumption, it will often wake up the low power interrupt.
How can you ensure that the SPI has been sent when the other terminal wakes up the CPU?
Here comes the focus of this article. The global communication variable flag is a sharp sword.
void SPI_Set_SD_Byte(unsigned char txData)
{
UCB0TXBUF = txData; // Write to the transmit buffer
SPI_TxFlag_sd = 0; // Clear the global flag
while (SPI_TxFlag_sd == 0 ) // CPU wakes up during transmission
{
LPM3;
}
}
__interrupt void USCI_B0_ISR(void)
{
//order interrupt service
switch (__even_in_range (UCB0IV,8))
{
case 0: break;
case 2: break;
case 8: SPI_TxFlag_sd = 1;
LPM3_EXIT;
break;
}
Analysis: Any interrupt may wake up the CPU, but SPI_TxFlag_sd is set to 1 only after the SPI transmission is completed.
|