HAL_SPI_TransmitReceive

[Geoffrey1]

Posted on June 03, 2016 at 01:54

I'm having some peculiar behavior using the polling mode spin routines (F3), so I took a look at the HAL code.      I'm sending 8 bit data using an array of 8-bit quantities.  Inside the TransmitReceive routine I see this:

HAL_SPI_TransmitReceive

(

SPI_HandleTypeDef

*

hspi

,

uint8_t

*

pTxData

,

uint8_t

*

pRxData

,

uint16_t

Size

\

,

uint32_t

Timeout

)

/* Transmit and Receive data in 8 Bit mode */

else

  {

while

((hspi->TxXferCount > 0) || (hspi->RxXferCount > 0))

    {

/* check TXE flag */

if

((hspi->TxXferCount > 0) && ((hspi->Instance->SR & SPI_FLAG_TXE) == SPI_FLAG_TXE))

      {

if

(hspi->TxXferCount > 1)

        {

          hspi->Instance->DR = *((

uint16_t

*)hspi->pTxBuffPtr);

          hspi->pTxBuffPtr +=

sizeof

(uint16_t);

          hspi->TxXferCount -= 2;

        }

There's just so much wrong with this code.  First there's the cast from uint8_t * to uint16_t *-- really ?  All of a sudden you're introducing non-aligned accesses.  Then there's the assumption that I want to send a multiple of 2 bytes -- NO NO NO.It appears I'll have to write my own transmission SPI routines since I can't trust these libraries.Geoffrey

[Walid FTITI_O]

Posted on June 03, 2016 at 15:49

Hi brown.geoffrey.001,

This IP version is supporting the Data packing: as Data Register is 16bit (DR), IP is able to compute two data (2* 8bits) to packet a nex ata (16bit)

so in case of 8bits data, data are sent by packet of 16bits (2 datas)

“

I'm having some peculiar behavior using the polling mode spin routines (F3)��

-->    Otherwise, Can you describe clearly (in details) the issue/behavior that you faced.

-Hannibal-

[Geoffrey1]

Posted on June 03, 2016 at 21:20

Sure -- suppose I want/need to send a single byte -- i.e. to check response of  device.  The library code will always send two.  

Suppose I need to send a buffer with 9 bytes -- the library code will always send 10.  BTW, the last byte will always be whatever garbage happens to be in memory.I don't understand why anybody thinks there is a performance advantage here.  The peak rate is 20Mbps (2.5 Mbyte/second) which is significantly longer  than the code overhead.  Also, as a very general rule -- programmers expect an interface that takes an array of bytes to work properly with any number of bytes.   While the M4 cores support unaligned accesses, it's absolute folly to build a general library that depends upon this behavior.Geoffrey

[tau]

Posted on March 01, 2017 at 09:44

Hi. Does this help at all:

https://community.st.com/0D50X00009XkfrtSAB

Seems there is some contention on the HAL 8/16bit access, but I wrote my own driver after experiencing issues. Code snippet available at the link.