2013-11-21 09:35 AM
Hi,
I have an STM8S003F3 that is configured as a slave in a bidirectional half-duplex mode. During the time it receives bytes, I can wait on the RXNE flag to know the byte has been completely received. However, I want to know the same time for when it is transmitting. TXE doesn't help. Let me demonstrate. When there is a transfer, imagine this is the clock. (TXE)-_-_-_-_-_-_-_-_(RXNE) TXE at the beginning of the clocking of the byte becomes true because the TX buffer gets copied to the shift register. This happens of course only in transmit mode. But this shows the _beginning_ of the transmission. RXNE at the end of the clocking of the byte becomes true because the RX buffer gets copied to from the shift register. This happens only in receive mode. I want to be able to poll the same moment polling RXNE would, but in transmit mode. I have tried (and it seems to be ok) to use the BSY flag. However, the datasheet itself says:Note: Do not use the BSY flag to handle each data transmission or reception. It is better to use TXE and RXNE flags instead. If I can't use the BSY flag, what can I use then (Since RXNE doesn't get set in transmit mode)? #slave #bidirectional #spi2013-12-09 08:39 AM
My tests show that sometimes during transmission, the BSY flag doesn't even go down between two byte transfers (no matter what delay I put in between them), so it seems that BSY flag is indeed unreliable for this test.
I tried waiting for TXE and then looking at 13 clock changes which works for slow communication (e.g. 125Kpbs), but the resulting `for`-`while` loop combination results in about 1.2us detection delay for each edge, which is unacceptable for high SPI rates (e.g. 4Mbps). Has anyone ever used STM8 as bidirectional half-duplex in SPI slave-mode? Without knowing when it's safe to switch to receive mode after the transmission of a byte, this whole mode wouldn't be worth a squat! P.S. I tried switching to receive mode right after TXE is set (hoping the micro would wait for the transmission to end), but that immediately switched to receive mode which of course corrupted the output.