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

RMandR
Posts: 75
Joined: Mon Oct 29, 2018 3:13 pm

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

Postby RMandR » Fri Jun 07, 2019 5:36 pm

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
Posts: 477
Joined: Thu May 03, 2018 1:18 pm

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

Postby username » Fri Jun 07, 2019 7:28 pm

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
Posts: 75
Joined: Mon Oct 29, 2018 3:13 pm

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

Postby RMandR » Sun Jun 09, 2019 3:30 pm

@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
Posts: 3529
Joined: Tue Dec 01, 2015 7:35 am

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

Postby WiFive » Mon Jun 10, 2019 4:13 am

RMandR wrote:
Sun Jun 09, 2019 3:30 pm
@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
Posts: 75
Joined: Mon Oct 29, 2018 3:13 pm

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

Postby RMandR » Mon Jun 10, 2019 6:48 pm

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
Posts: 3529
Joined: Tue Dec 01, 2015 7:35 am

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

Postby WiFive » Mon Jun 10, 2019 9:26 pm

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.

Who is online

Users browsing this forum: No registered users and 108 guests