Why does HAL_SAI_Receive_DMA() return an 8bit-value?

[JTedot]

• Most commonly used busses like I2S use a framesize of 64bit (32bit left, 32bit right)
• DMA uses the bus width (also 32bit)
• Audiodata with bit depth 8bit is almost useless anyways

So why does HAL_SAI_Receive_DMA() return an 8bit-value? Wouldn't it be much easier to obtain data by passing uint32_t values?

[Mohamed Aymen HZAMI]

Hello @JTedot​  and welcome to the community,

In fact the SAI data can be presented in three different way which are 8 bits, 16 bits and 32 bits.

It's ST implementation choice to be an 8 bits data length

Mohamed Aymen

[waclawek.jan]

/**
  * @brief  Receive an amount of data in non-blocking mode with DMA.
  * @param  hsai pointer to a SAI_HandleTypeDef structure that contains
  *              the configuration information for SAI module.
  * @param  pData Pointer to data buffer
  * @param  Size Amount of data to be received
  * @retval HAL status
  */
HAL_StatusTypeDef HAL_SAI_Receive_DMA(SAI_HandleTypeDef *hsai, uint8_t *pData, uint16_t Size)
{

i.e. HAL_SAI_Receive_DMA() returns a value of HAL_StatusTypeDef type, which is an enum, and its actual width is compiler-dependent.

But you probably talk about the pData parameter. Its type is formal, it's just a pointer to an array of bytes. How are those bytes filled up, i.e. what datawidth is used by SAI and DMA, is probably determined by respective fields in SAI and DMA init structs; you can look that up. I don't use Cube.

JW

[Piranha]

For universal buffer passing normal developers use void* type for read/receive and const void* for write/transmit and cast it to the required type internally.

[JTedot]

I found out. Short answer: just ignore it, it will fit any unsigned integer pointer you provide it with. `uint8_t*` in this case is just a choice, a placeholder if you will. 8-bit, 16bit and 32bit work just fine.