Skip to main content
LHarm.1
Associate III
September 26, 2021
Question

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

  • September 26, 2021
  • 6 replies
  • 1445 views

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
September 26, 2021

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
September 26, 2021

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
September 27, 2021

Is there an errata on this behavior?

TDK
September 27, 2021

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
September 27, 2021

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
September 27, 2021
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""."