How cause a 60ms delay within a callback without using HAL-Delay()?

[Clark Sann]

I want to cause a 60ms delay within a callback. I am sending data using a UART and the serial protocol requires certain delays.

I would prefer not to change the Systick priority so that means the callback has a higher priority than Systick and HAL_Delay is not available.

Anyone have any good methods for creating delays in callbacks?

[Tesla DeLorean]

The "good" method is to leave immediately, with a secondary task/callback occuring 60 ms later to pickup where you left off.

[Tesla DeLorean]

If you absolutely can't refactor a better approach, how about having a TIM that ticks at 1us, is maximal, and you measure elapsed time with that?

[Clark Sann]

@Community member​ 

I can refactor. I'm being dense....I am not using an RTOS so how do I create a secondary task/callback?

I've seen some examples where in the callback they raise a global flag which causes a function to run in the while loop of main. In my case that function would handle the entire serial protocol. In main there would be code like this:

while (1) {

if (flag) {

do serial procedure

}

}

That seems so goofy to me. Is there a better way?

In my particular case, the callback is called by the RTC. In the callback I get data from the ADC, then I send it out the UART. I need the delay while I am using the UART.

Should I do something similar to the above to exit from the callback asap rather than taking time to get the data from the ADC?

If so then the only code I can think of would be this:

while (1) {

if (ADC_Flag) {

get data from ADC

}

if (Transmit_Flag) {

do serial procedure

}

}

Is this a good way to handle this problem?

[Tesla DeLorean]

Have a flag which is a down counter, in SysTick if this if this is non-zero decrement it, if it hits zero call your secondary routine. Set the count to 60 in your callback where you'd normally block.

That way you can do other productive things in the meantime.

If all your real interaction occur under interrupt/callbacks, your main loop could contain a __WFI() so it sleeps between interrupts changing things.