Basic SPI transmit

[John Adriaan]

I think I'm misunderstanding something with the generic SPI transmit procedure. I'm working with the STM32L432, but I think that's the standard SPI device for most MCUs. My scenario is with the MCU as Controller rather than Peripheral...

My issue is with knowing when to de-assert the CS line. According to the documentation, I can either use Hardware or Software control of the CS:

• For Hardware Control. CS is asserted while the respective `SPE` bit is on.
• For Software control, CS is under the control of the relevant GPIO.

Ummm... isn't that the same thing? The same trigger that could de-assert `SPE` could equally de-assert the relevant GPIO?

My SPI device requires CS for the duration of the transmit cycle, including the final few bits (which is my problem). I need to know when to de-assert CS:

• If I use TXE, it asserts on the final 1/2 buffer, before they have left the chip;
• If I use DMA Complete, it asserts when it delivers the final byte, before it and its predecessors leave the chip.

In short, the only way I can know to de-assert CS is to wait on the BSY bit... which has no interrupt. Is ST seriously expecting me to go into a Busy Wait loop? On every Transmit?

[S.Ma]

after few billions sold chips, obvious issues are probably not show stopper...

In master mode, bi dir, use rxne interrupt. txe kicks before transmitting the first bit. receivingis only when the last bit has been received. make sense? watcg out that there are few evolutions of spi ip. here is for the basic one.

[TDK]

> Ummm... isn't that the same thing?

Controlling a GPIO pin is often more convenient from a software side since the SPE bit behavior is embedded within the HAL library.

> In short, the only way I can know to de-assert CS is to wait on the BSY bit...

You could also trigger off of a transfer complete on the receive side. Receive data into a dummy buffer.