Skip to main content
Visitor II
September 26, 2021
Question

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

  • September 26, 2021
  • 4 replies
  • 1419 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.

    4 replies

    Super User
    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.

    Visitor II
    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.1Author
    Visitor II
    September 27, 2021

    Is there an errata on this behavior?

    Super User
    September 27, 2021

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

    LHarm.1Author
    Visitor II
    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.

    Super User
    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".