Hi All, I need to transfer 24 bit of data through STM 32 SPI , the challenge is that the IP only allow to transfer 8 or 16 bit of data .

[RSree.1]

Things that have tried.

1. Used the GPIO as chip select . In this configuration , the width of chip selected pulse is more than expected. ( Attached oscilloscope short for your reference ).

Kindly requesting to sent the procedure or sample code to sent 24 bit of data through STM32 SPI

[TDK]

Send 8 bits of data 3 times in succession. That will give you 24 bits of data. On some families, you can send 24 bits in a single operation.

If you want super tight timing of the CS line, you can make your own SPI driver. HAL has a lot of overhead. You can also compile on higher optimization levels. But CS being low for longer poses no problems for communication.

Include your chip number in your post.

[waclawek.jan]

What STM32?

And what system clock? It seems to me that even with Cube/HAL, 20us-60us between setting GPIO and any other action is too much.

As TDK said, get rid of Cube and switch on optimization.

JW

[RSree.1]

Hi All,

Really thanks for your quick response ,please find the inline answers.

>>Include your chip number in your post.

STM32F746IGTx

LQFP176

The SPI interface chip is ADAR 1000.

https://www.analog.com/en/products/adar1000.html

>> And what system clock?

Internal 16 Mhz clock , attached screen shot for the clock configuration.

So with my understanding from the above reply .

1. it is not possible to generate a 24 bit of data through the SPI IP ( Attached IP setting) and require to write own SPI logic ?

>> If the answer is yes , any example is available for reference ?

1. Can I use the SPI DMA function (HAL_SPI_Transmit_DMA(hspi, pData, Size) ), for this requirement .

Lastly apology , if I am asking silly question as I am new to STM32 Microcontroller.

Regards,

Rs

[RSree.1]

..

[TDK]

Sending 3 8-bit bytes adds up to 24 bits. There is no functional difference between a single 24-bit write and 3x8-bit writes.

The F7 has a 32-bit TXFIFO which can buffer the 3 bytes immediately without having to wait for data to be shifted out.

You can use DMA if you want, but it's not necessary.

[RSree.1]

Hi ,

Please find the inline answers.

>>Sending 3 8-bit bytes adds up to 24 bits. There is no functional difference between a single 24-bit write and 3x8-bit writes.

When sending 3 8 bits, the chip select is asserted for two times ( attached screen shot ) , so my peripheral chip is assuming a different SPI cycle during the assertion of each chip select. That is the problem, I am facing

[TDK]

Looks like you're using NSSP mode.

Manage CS as a GPIO output and toggle it manually.

[RSree.1]

Hi ,

Thanks for the answer. Please find the inline answers.

>>Looks like you're using NSSP mode.

Yes , the screenshot provided is in NSSP mode.

>>Manage CS as a GPIO output and toggle it manually.

Yes , I have tried to toggle manually . But the issue is that the CS to assert is taking long time. Attached the screen shot for reference .

Any idea how to reduce the assertion time ?

The code I was using given below.

HAL_GPIO_WritePin(GPIOA, GPIO_PIN_4, GPIO_PIN_SET);

         HAL_GPIO_WritePin(GPIOA, GPIO_PIN_4, GPIO_PIN_RESET);

         HAL_SPI_Transmit(&hspi1,(uint8_t *) &EEPROM_WRDI , 1, 100);

         HAL_GPIO_WritePin(GPIOA, GPIO_PIN_4, GPIO_PIN_SET);

Really glad for your help.

[TDK]

> Any idea how to reduce the assertion time ?

Use your own code driver instead of HAL, or increase optimization level and/or clock frequency.

If you want the convenience of HAL, you live with its drawbacks.

[waclawek.jan]

TDK,

while I agree with everything you wrote, but, even if clock is 16MHz and Cube/HAL is used, isn't cca 10us for pulse generated by two consecutive HAL_GPIO_WritePin() calls too much? That's like 160 clock cycles...

This is 'F7, can AXI be the reason? I don't use 'F7...

[EDIT]

From the bus structure it appears that in 'F7 GPIO (and both AHB buses going to peripherals) don't go through the AXI attachment, but directly through AHBP. Pity the RM does not deal with this in details...

But then the "slowness" is a mystery to me...

[/EDIT]

JW

[TDK]

> even if clock is 16MHz and Cube/HAL is used, isn't cca 10us for pulse generated by two consecutive HAL_GPIO_WritePin() calls too much?

Yes, seems like too much. I can't really explain that either, but could be the OP simplifying code. I don't use F7 either.

> HAL_SPI_Transmit(&hspi1,(uint8_t *) &EEPROM_WRDI , 1, 100);

Actually, since the word size is limited to 16 bits, I don't see how the exact code presented (which sends 1 word) could have produced the scope screenshot (which shows 24 bits). Could be missing something.

[waclawek.jan]

The hardware NSS of SPI in master mode is mostly useless.

One way to make SPI timing more deterministic and avoid "manual" wiggling of NSS is to generate the clock signals using cascaded timers, and connect them externally to SPI set as a slave. Not trivial.

JW