Electronic – How to use libraries with delays inside within a time critical STM32 HAL application

delayhal-librarylibrarystm32

I want to use a library for an LCD for STM32: LiquidCrystal, and possibly some other libraries.

I noticed this library is full of HAL_Delay calls, not only during initialisation but also during processing functions.

My application needs to read MIDI data and process them, preferably within 10 ms, so a HAL_Delay of 1, 2, 5 and 50 ms as are part of e.g. that LiquidCrystal library is messing up the MIDI data.

What should I do (in general or specific) to use libraries using HAL_Delay calls inside a time critical application? Things I can come up with:

Rewrite the library using interrupts? (seems like a lot of work)
Use another MCU (STM32) to handle that (more hardware/soldering work)
A better solution?

Best Answer

If your cycle time allows for it (read: is fast enough) another approach is to split the library so that the function is returning at each delay.

The function will be called at each cycle and it then can decide if the necessary time has passed since the last action and do the next steps to the next delay.

Though you might want to use this approach only if the library is quite relaxed to the maximum time needed and your system has a well defined cycle time.

Related Solutions

Electronic – STM32F7 gets stuck in external interrupt callback function

Update: I found the mistake. The SysTick interrupt priority was set to the lowest (15), so calling HAL_Delay() from an ISR with the same or higher priority caused an infinite loop in the HAL_Delay function.

So, take care: If you are using the default HAL settings provided by ST, the priority for SysTick IRQ is set to 15 when calling HAL_Init(). You have to change that in the stm32f7xx_hal_conf.h file or by using the HAL_InitTick(TickPriority) function.

Here is what the HAL documentation of HAL_InitTick says about that issue:

Care must be taken if HAL_Delay() is called from a peripheral ISR process, The the SysTick interrupt must have higher priority (numerically lower) than the peripheral interrupt. Otherwise the caller ISR process will be blocked. The function is declared as __weak to be overwritten in case of other implementation in user file.

Electronic – RFID RC522 with STM32F769I-Discovery

Your suspicion seems to be correct and your SPI clock settings are incorrect. It can be observed in the logic analyzer's image that the data changes on rising edge and stable on the falling edge.

If you check the SPI timing diagram in the datasheet of the RC522. You can see that the clock is LOW before the communication, the data is sampled on the rising edge and the data changes on the falling edge.

Now the STM32 has the CPOL and CPHA settings which you assumed to be wrong. The description for those from the STM32F7xx reference manual:

Bit1 CPOL: Clock polarity

0: CK to 0 when idle

1: CK to 1 when idle

Bit 0 CPHA: Clock phase

0: The first clock transition is the first data capture edge

1: The second clock transition is the first data capture edge

For you CPHA setting: SpiHandle.Init.CLKPhase = SPI_PHASE_1EDGE; is correct, on the timing diagram the data is sampled on the first clock transition. But it should be a rising edge and not a falling.

For CPOL your setting is idle HIGH while on the timing diagram it is idle LOW. If you observe that if your clock signal would be negated then the first clock transition would be a rising edge while the data is stable and the data would change on falling edge.

So all in all I would try changing this line:

SpiHandle.Init.CLKPolarity       = SPI_POLARITY_HIGH;

to:

SpiHandle.Init.CLKPolarity       = SPI_POLARITY_LOW;

You can also go with trial and error because you have a maximum 4 types of clock and the logic analyzer to check the signals.

Best Answer

Related Solutions

Electronic – STM32F7 gets stuck in external interrupt callback function

Electronic – RFID RC522 with STM32F769I-Discovery

Related Topic