Is it possible to receive GPIO edge type in an interrupt handler (ISR)?

[RMandR]

I'd like to set up a few gpio inputs pins to trigger on both rising and falling edges.

Once the ISR is called, I'd like to know what exactly triggered the interrupt. The gpio interrupt example shows how to the GPIO pin that triggered, but reading the status of said gpio at the time of ISR execution does not guarantee that the pin-state has not changed since the moment the trigger occurred.

It feels like this is a simple thing, can someone point me in the right direction?

thx

-a

[username]

Following the gpio interrupt example, and just to be clear this one here.
https://github.com/espressif/esp-idf/bl ... ple_main.c

In the following task below from that example, you can add this to it to re-read the pin.

Code: Select all

static void gpio_task_example(void* arg)
{
    uint32_t io_num;
    for(;;) {
        if(xQueueReceive(gpio_evt_queue, &io_num, portMAX_DELAY)) {
            printf("GPIO[%d] intr, val: %d\n", io_num, gpio_get_level(io_num));
            printf("Re-read the pin: %d\n", gpio_get_level(GPIO_INPUT_IO_0 ));	// to read IO4 
        }
    }
}

[RMandR]

@username thank you for your suggestion.

It's possible that the pin value will have returned to it's original value between the trigger time and when the handler runs (interrupt latency). This means you can see gpio level 0 for rising edges and gpio level 1 for falling edge triggers.

[WiFive]

@username thank you for your suggestion.

It's possible that the pin value will have returned to it's original value between the trigger time and when the handler runs (interrupt latency). This means you can see gpio level 0 for rising edges and gpio level 1 for falling edge triggers.

Ok but even if some register held the edge type it would be possible to have another interrupt and the edge type change before you read the register. So then there would have to be some kind of hardware queue for edge types. There will be constraints on the signal based on the hw/sw capabilities. If you use two pins you can have one as rising edge and one as falling. Even then you will be limited by interrupt latency, what if there are 3 edges before your isr runs?

[RMandR]

So then there would have to be some kind of hardware queue for edge types

That's exactly it. Most MCU architectures pass the edge type to the interrupt handler as an argument. For example

Code: Select all

//NOT ESP32 CODE: static void IRAM_ATTR gpio_isr_handler(int pin, int egeType)

That way even with interrupt latency, you get a real snapshot of what did happen.

[WiFive]

https://stackoverflow.com/questions/487 ... i-callback

But for mcu sdks that do support it is it just the upstream code that calls the handler that checks the level or is it actually hardware? Because in the first case it still comes down to latency. On esp32 you have options such as a custom high level interrupt or using rmt to capture the whole pulse train at 6ns precision.