Skip to main content
LHarm.1
Associate III
Sep 26, 2021 5:35 PM UTC
Question

How do I switch SPI Communications from 2 line to 1 line and back?

I am using the HAL SPI driver for the STM32F411 v 1.26.2.

I want to perform a FULL duplex transfer to a slave device using HAL_SPI_TransmitReceive() then do either a RX or TX half duplex transfer using HAL_SPI_Receive or HAL_SPI_Transmit. I currently have the code working but the receive performance is much slower than the tx performance. My logic analyzer shows vastly different byte to byte timing between the two half duplex calls. It appears that the HAL drivers have provisions for changing modes. Should I call HAL_SPI_INIT() between full duplex and half duplex functions? Or can I adjust the driver at a lower level?

This topic has been closed for replies.

6 replies

TDK
Sep 26, 2021 6:13 PM UTC

The best solution is to use HAL_SPI_TransmitReceive for everything. Like it or not, there are signals on MOSI and MISO at all times even if you don't care about them.

The HAL driver can change modes if you deinit/reinit, but the hardware receive-only implementation is odd and can result in extra clocks and unexpected behavior, as it sounds like you've found out.

"If you feel a post has answered your question, please click ""Accept as Solution""."
S.Ma
Principal
Sep 26, 2021 7:02 PM UTC

Always use full duplex. Turn miso as input pin to disable the output if needed. Some external spi slave sensors use 3 wire spi: short miso and mosi externally.

LHarm.1
LHarm.1Author
Associate III
Sep 27, 2021 12:15 PM UTC

Is there an errata on this behavior?

TDK
Sep 27, 2021 1:15 PM UTC

Why would there be errata? It behaves as described in the RM.

"If you feel a post has answered your question, please click ""Accept as Solution""."
LHarm.1
LHarm.1Author
Associate III
Sep 27, 2021 2:07 PM UTC

you wrote " the hardware receive-only implementation is odd and can result in extra clocks and unexpected behavior, as it sounds like you've found out".

That sounds like a bug! I have checked the errata and there is no mention of this issue.

TDK
Sep 27, 2021 2:17 PM UTC
It's intended behavior that is documented in the RM. There is no need for an errata note that says "the RM is correct".
"If you feel a post has answered your question, please click ""Accept as Solution""."