GPIO Interrupt Latency - once more

[mTron47]

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!

Peter

[michprev]

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?

[mTron47]

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.

[holopaul]

Hi there!
Did you get any results capturing the input with mcpwm? I'm trying to capture a signal that is 60uS and had all kind of crazy/random results from this peripheral.

[mTron47]

Hi holopaul

I could indeed resolve my problem using mcpwm. However my issue to resolve was on the output side. If I understand you correctly you are using the (hall-sensor) input of mcpwm and are seeing "funny things". I do not have any experience on that side - sorry.

[holopaul]

[quote="mTron47"]Hi holopaul

I could indeed resolve my problem using mcpwm. However my issue to resolve was on the output side. If I understand you correctly you are using the (hall-sensor) input of mcpwm and are seeing "funny things". I do not have any experience on that side - sorry.[/quote

no, i'm using a very fast phototransistor to detect the signal. So input is ok, i checked on the scope. i think the problem is the print function. i suspect is taking too long . i'm using just the example code.
thanks