[Answered] Clarifications on GPIO interrupt types "low level" and "high level"
Posted: Tue Feb 07, 2017 10:32 pm
While studying the GPIO interrupt handler routines in the ESP-SDK, we find definitions for a number of types of interrupt ... see the following:
http://esp-idf.readthedocs.io/en/latest ... int_type_t
Most of these are self explanatory but I am not comprehending the types known as "GPIO_INTR_LOW_LEVEL" and "GPIO_INTR_HIGH_LEVEL"? My gut feel is that they would be used to indicate a pin going low and staying low or a pin going high and staying high ... but implicit in that concept is a duration of time ... i.e. how LONG a pin needs to go low and stay low before registering as an interrupt.
Can anyone help me understand the purpose of these interrupts and how they are anticipated to be used?
Re: Clarifications on GPIO interrupt types "low level" and "high level"
Posted: Tue Feb 07, 2017 11:06 pm
In most microcontrollers (including ESP32), the main distinction is edge vs level interrupts.
GPIO_INTR_POSEDGE = Rising Edge interrupt = on the previous clock cycle, the pin was low and on this clock cycle it's high.
GPIO_INTR_NEGEDGE = Falling Edge interrupt = on the previous clock cycle, the pin was high and on this clock cycle it's low.
GPIO_INTR_ANYEDGE = Any Edge interrupt = on the previous clock cycle the pin was different to what it is on this clock cycle.
GPIO_INTR_LOW_LEVEL = Low level interrupt = on this clock cycle the pin is low.
GPIO_INTR_HIGH_LEVEL = High level interrupt = on this clock cycle the pin is high.
So the essential difference between "edge" and "level" is - do you only want an interrupt to be caused by the event when the pin changes state, or do you want multiple/repeated interrupts if the pin stays in a particular state?
The clock in question is the GPIO peripheral clock, which defaults to 40MHz. So I'm fairly certain the length of time an input has to stay stable to guarantee the GPIO hardware will register it is 25ns, although I can confirm this if you need a definite answer. A shorter glitch may still trigger an interrupt, depending on when the digital input is sampled relative to the glitch. There also be some filtering in hardware, and the capacitance of whatever is connected to the pad comes into play for very short glitches. This doesn't usually matter, though, due to interrupt processing time.
Specifically. the time for the CPU to actually process an interrupt is significantly higher than 25ns: just because you can generate interrupt signals this fast doesn't mean you can handle them this fast. Once the interrupt line is asserted (ie the interrupt has triggered) (for any reason) it will stay asserted until the CPU clears it as part of the interrupt handler, so very high frequency interrupts still look like a single interrupt to the CPU.