gpio_irq_enable/disable are not well defined as they might disable just one pin interrupt or disable entire port, depends on a target. The default behavior is sw emulated - gpio irq contains an array of registered interrupts, and if it's NULL, it is not registered.
I recall these gpio irq enable/disable were added as a quick way to enable/disable gpio interrupts (mainly for platforms that operate on ports, where you have 32 pins on one port). Since then there have been improvements (binary search for some targets, I recall for KL25Z it was).
A suggestion would be to deprecate those 2 methods, and propose a good implementation for GPIO handlers, in case they operate on PORTS. We should have a look at gpio_irq_free/set and gpio_irq_enable/disable.
Description
Question
The InterruptIn defines 2 methods:
enable_irq()
anddisable_irq()
- https://github.com/ARMmbed/mbed-os/blob/master/drivers/InterruptIn.h#L138. These are wrappers forgpio_irq_enable/disable
HAL functions - https://github.com/ARMmbed/mbed-os/blob/master/hal/gpio_irq_api.h#L73gpio_irq_enable/disable
are not well defined as they might disable just one pin interrupt or disable entire port, depends on a target. The default behavior is sw emulated - gpio irq contains an array of registered interrupts, and if it's NULL, it is not registered.I recall these gpio irq enable/disable were added as a quick way to enable/disable gpio interrupts (mainly for platforms that operate on ports, where you have 32 pins on one port). Since then there have been improvements (binary search for some targets, I recall for KL25Z it was).
A suggestion would be to deprecate those 2 methods, and propose a good implementation for GPIO handlers, in case they operate on PORTS. We should have a look at
gpio_irq_free/set
andgpio_irq_enable/disable
.Open for discussion.