Andreas Schwarz wrote:
daniel.n...@sigicom.com (Daniel Néri) wrote:
Andreas Schwarz <andrea...@web.de> writes:
I'm talking to a MMC in SPI-Mode, and if I don't check TXEPT (or
alternatively URXIFG0) it doesn't work reliably!
It's actually pretty simple: UTXIFG gets set when UTXBUF becomes
empty, i.e. when the data has moved from UTXBUF to the transmitter
shift register and starts to shift out on the output pin. TXEPT is set
when UTXBUF *and* the transmitter shift register are empty, i.e. after
the last bit of the data has been shifted out (and no new data has
been written to UTXBUF).
Then I don't understand why it isn't sufficient to test UTXIFG in my
application:
#define SPI_TXC (IFG2 & UTXIFG0)
#define SPI_RXC (IFG2 & URXIFG0)
...
TXBUF0 = 0x40+command;
while (!SPI_TXC);
for(count=0;count<4;count++) {
TXBUF0 = 0x00;
while (!SPI_TXC);
}
TXBUF0 = 0xFF; // CRC not used, send 0xFF
while (!SPI_TXC);
TXBUF0=DUMMY; // 8 clock cycles
while (!SPI_TXC);
// while(!SPI_RXC); // <- only _here_ I need to test URXIFG or TXEPT to make
it work!
TXBUF0=DUMMY; // send dummy byte to read response
while (!SPI_TXC);
while (!SPI_RXC);
response=RXBUF0;
The code I posted runs reliably on a 449. However, I don't think the
particular chip is significant. I don't know of any SPI quirks with
other family members. I never check the Rx status, as I am only driving
a DAC. For everything I have done, Daniel's comments are accurate.
I only need to test UTXIFGO to see if the Tx register is clear to accept
another byte. At the end, I need to test TXEPT to see that all bits have
gone out to the wire before turning off the select line.
One quirk, which I don't think is documented, seems to affect all modes
of the UART. If you use interrupts for transmission, you don't get the
first Tx interrupt until you kick the transmission register the first
time. Most freshly initialised UARTs will interrupt as soon as the Tx
interrupt enable is selected. Just write a zero to the Tx register to
get things started, and interrupt based transmission works OK.
Regards,
Steve
