GPIO Interrupt Latency - once more

Posts: 2
Joined: Fri Jul 13, 2018 2:52 pm

GPIO Interrupt Latency - once more

Postby mTron47 » Fri Jul 13, 2018 3:39 pm

Hi there
Being new to this forum, let me briefly introduce myself.
I am a retired electrical engineer who has spent the last 15 years of his career in software engineering for other people. Now I have found the time to do it for myself and with the ESP32 and some other platforms. Depending on the project at hand I switch between two development environments:
either ESP-IDF, running under Eclipse on Ubuntu 18.04 in a VirtualBox under Windows 10
or Arduino-IDE running under Windows 10

My current question arose in the ESP-IDF. Starting with the example program gpio_example_main.c I modified the ISR to this:

Code: Select all

static void IRAM_ATTR gpio_isr_handler_v(void* arg)
    if (gpio_get_level(GPIO_V_IN)) {
       // rising edge
       gpio_set_level(GPIO_V_LO, 0);
       gpio_set_level(GPIO_V_HI, 1);
    } else {
       // falling edge
       gpio_set_level(GPIO_V_HI, 0);
       gpio_set_level(GPIO_V_LO, 1);

Interrupt preparation is done as given in the example code, i.e. using gpio_install_isr_service(0) and gpio_isr_handler_add(...).

Looking at the signals by oscilloscope I found a pretty stable time skew between the signals GPIO_V_IN and GPIO_V_HI of 5.6 microseconds. In view of a clock frequency of 40 MHz (?) and a simple ISR I expected much less. My application needs a skew of less than 1 microsecond. Is there anything I can do to get close to that?

Indeed there seems to be a lower-level interrupt handling as declared in ...esp-idf\components\esp32\include\esp_intr_alloc.h. But no usage examples are given - or then I could not find them. Moreover higher level interrupts (above level 3) seem to require coding in assembler which means another steep learning curve. :(

Thanks for any help!


Posts: 43
Joined: Fri Aug 04, 2017 8:57 pm

Re: GPIO Interrupt Latency - once more

Postby michprev » Sat Jul 14, 2018 8:38 am

Hello mTron47,
from my experience I can only recommend you using higher level interrupts in assembly.

What would you like to do in an interrupt routine?

If you need to set some pins high / low in reaction to a gpio input you can probably take a look at hardware peripherals - MCPWM capture mode maybe?

Posts: 2
Joined: Fri Jul 13, 2018 2:52 pm

Re: GPIO Interrupt Latency - once more

Postby mTron47 » Sun Jul 15, 2018 9:26 am

Hello michprev

Thank you for your reply which does get close to what I am trying to do. I want to control a small 3-phase synchronous motor by feeding it 3 sinewaves with 120 degrees phase offset. The sinewaves are table-lookups to produce e.g. 24 interpolated values/rev converted to PWM modulated pulses.

I did look at MCPWM, but found that it didn't fill my bill, because I do not have hall-element feedback and I do want to use sinewaves for smoothness of operation. Maybe my dismissal of MCPWM was too fast ...

Instead I currently use ledc-PWM which works fine so far. Every one of the 3 ledc-channels produces a pulse train on a gpio pad(named GPIO_OUTPUT_V_GEN in my example). What I need though are two non-overlapping pulses per motor line to control its half-bridge MOSFETs. That's where the interrupts come into play: GPIO_OUTPUT_V_GEN is physically connected to a gpio input (GPIO_V_IN) which is declared as an edge-sensitive interrupt source. The ISR first checks whether we have a rising or a falling edge by reading the level of GPIO_V_IN. On a rising edge the driving signal for the low-side MOSFET ist first pulled low and then the driving signal for the high-side MOSFET ist pulled high. On a falling edge the sequence is inverse. That's how power-supply short circuits are avoided. But when the interrupt latency is longer than the narrowest pulse from ledc the edge polarity detection fails and the output-pair is wrong.

Did you ever use higher level interrupts in assembly? If yes could you provide me with some example code showing the interrupt setup. I imagine that gpio_install_isr_service(0)) and gpio_isr_handler_add(...)) won't work in that context and that the syntax of an ISR is different.

In any case I shall give MCPWM a second and more profound glance.

Who is online

Users browsing this forum: kolban and 8 guests