cancel
Showing results for 
Search instead for 
Did you mean: 

Interrupt callback function blocked by delay

TzuNa
Associate

Hey there !

I'm trying to use an ultrasound range captor on STM32 Nucleo. To beggin, I'm on a very simple case of use : User press a button, it's trigerring an interrupt, handled by a callback function `emettre_ultrason()`. Then, when the callback function have finished its work, the MCU should continue its stuff, until a reflected wave trigger a new interrupt.

`emettre_ultrason()`have to set a pin on `set` state for few x ms, then, to `reset` state. So the ultrasound emitter emit a wave during x ms.

The issue is : if I use `HAL_Delay()` to wait these x ms, the function is blocked because of this delay : I never go through the instructions next to the delay, I never go back to the main loop, as I can see with UART Trace.

I understood, by reading other topics as this one or this other one, that it's because delay are not supposed to be used in an interrupt handler. And even if it seems to be a bad practice, I tried yo put a higher priority on systick interrupts (with `HAL_NVIC_SetPriority` ) Without any result. But, I HAVE to emit this wave in my interrupt callback. Sooo I'm looking for what could be the better option.

I tried to improvise a solution like this : 

 

```c

void custom_delay(int delay_requesti){

    int core_frequency = 84e6;

    int loop_laps = delay_requesti*core_frequency;

    int i;

 

    for(i = 0; i < tours; i++){

        __NOP();

    }

}

```

but hell yeah ! I'm pretty sure it's worth than use a delay ! :o It will be okay while debugging, but it's not acceptable for a study project. Do you have any suggestion to impose a short delay, juste while emitting a short impulsion ?

 

Thanks

3 REPLIES 3
Pavel A.
Evangelist III

I understood, by reading other topics...., that it's because delay are not supposed to be used in an interrupt handler. And even if it seems to be a bad practice, I tried yo put a higher priority on systick interrupts (with `HAL_NVIC_SetPriority` ) Without any result.

So you already know this is a "bad practice", and found some links to proper solution, and still want it your way instead of a proper way... What kind of engineers graduate from that school ??

 

> I tried yo put a higher priority on systick interrupts

Higher than what? How high exactly?

> Without any result.

SysTick interrupt did not fire during the delay? How did you confirm that? One way to do that would be toggling a GPIO pin in the SysTick interrupt.

OTOH, are you sure your delay is based on SysTick interrupts?

JW

HAL_Delay() also has pretty rough timing. And usually dependent on an interrupt. Call-backs are under interrupt context, so honestly not the best place to block, or be dependent on other interrupts preempting, or not.

Perhaps use one of the 32-bit TIM, or 16-bit, clocking the CNT at 1 MHz, with maximal period, ie 0xFFFFFFFF or 0xFFFF, no interrupt.

And then delta the time elapsed between entry and exit, for TIM->CNT, in micro-seconds.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..