You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Since we can only receive EXTI interrupts on one pin per port on the STM32s, it's difficult to use EXTI for "oneshot" GPIO interrupts. A task which only needs to receive an IRQ from a GPIO level change once will nonetheless permanently allocate that port, preventing any other task from ever receiving GPIO IRQs on pins on that port. It might be nice to add to the stm32xx-sys API to permit a task to temporarily claim an EXTI port, and then give it back once it's done using it.
See, for instance:
On the other hand, I don't think we currently have an interface for a task to release a claimed EXTI notification, so using EXTI for this would permanently occupy our ability to receive interrupts for pin changes on port B, so...we probably shouldn't do that. It might be a good idea to have a way for a task to release its configured EXTI interrupt, so that we can use EXTI for one shot stuff like this without tying up that port forever...
If we did something like this, it would introduce another locking-type IPC protocol and might, therefore, require the planned priority-ceiling protocol work @cbiffle and I keep discussing but not actually working on...
The text was updated successfully, but these errors were encountered:
Since we can only receive EXTI interrupts on one pin per port on the STM32s, it's difficult to use EXTI for "oneshot" GPIO interrupts. A task which only needs to receive an IRQ from a GPIO level change once will nonetheless permanently allocate that port, preventing any other task from ever receiving GPIO IRQs on pins on that port. It might be nice to add to the
stm32xx-sys
API to permit a task to temporarily claim an EXTI port, and then give it back once it's done using it.See, for instance:
If we did something like this, it would introduce another locking-type IPC protocol and might, therefore, require the planned priority-ceiling protocol work @cbiffle and I keep discussing but not actually working on...
The text was updated successfully, but these errors were encountered: