HAL_SPI_Receive() explanation

[valerio2]

Posted on March 09, 2016 at 14:21

Hi,

I am examining

HAL_SPI_Receive()

. At some point it calls

return
HAL_SPI_TransmitReceive(hspi, pData, pData, Size, Timeout);

where

pData

is the pointer to the rx buffer and

Size

is its size passed to

HAL_SPI_Receive()

. So,

pData

is used as tx buffer and rx buffer in

HAL_SPI_TransmitReceive()

. So, do I have to be sure the rx buffer is empty before the reception?

[andrewbmcclain]

Posted on March 11, 2016 at 15:10

So, what's happening here is:

1) Data register is loaded with first byte from pData.2) Data register copied into transmit shift.3) Bits are clocked, with Rx shifted in.4) Rx shift copied to data register.5) First byte of pData is is set to the value in the data register.That means that each byte from pData is sent, then replaced by the received byte.You don't need to ''clear'' anything for simplex communication.  If you want to send all 0's, you probably want to set the buffer beforehand.

[valerio2]

Posted on March 11, 2016 at 16:28

Thank you for the reply. I changed the topic because I noticed it was wrong (I am asking an explanation for HAL_Receive() actually).

In my case I think I have to clear the rxbuffer in advance because the device I am communicating with supports full-duplex.Regards.

[andrewbmcclain]

Posted on March 11, 2016 at 19:39

Yes, if the device you are connecting to expects 0x00 or 0xFF bytes, then you'll have reset the buffer each time for correct MOSI behaviour.  The library assumes that a receive sends ''don't care'' bytes or is simplex and irrelevant.  You could have a constant buffer of 0x00 or 0xFF bytes and just use the TransmitReceive instead of Receive, so it doesn't have to be ''reset'', at the cost of some memory.  But, hey, everything is a trade-off, right?

[valerio2]

Posted on March 15, 2016 at 11:07

😉 Yes everything is a tradeoff. However, I would have expected that ST had mentioned this in some user/programmer manual.

Regards.