Add new GPIO APIs for adding shared GPIO handlers, and improve docs #850
Conversation
kilograham
force-pushed
the
gpio_irq_improvements
branch
from
bd42d25 to
4cf55b4
Compare
| * | ||
| * This method adds such a explicit GPIO IRQ handler, and disables the "default" callback for the specified GPIOs. | ||
| * | ||
| * A raw handler should check for whichever GPIOs and events it handles, and acknowledge them itself; it might look something like: |
There was a problem hiding this comment.
This is probably a dumb question, but if the user has to manually check for GPIO numbers inside their callback-function themselves, what's the advantage of using these "raw handlers" over the "shared handler"? From looking at the implementation of gpio_add_raw_irq_handler_with_order_priority_masked it seems like if you added multiple raw-handlers (each with a separate callback), then each of the callbacks would get called for every GPIO IRQ that's registered to be handled by a raw-handler?
So you could just do the same thing with the shared-handler, by calling a different function depending on the GPIO number that it was passed?
No doubt I'm missing something obvious / fundamental 😕
There was a problem hiding this comment.
Yes, you can, but only one person can set the shared calback function. Therefore if you have two independent/unrelated bits of code that want to respond to GPIO IRQ they would stomp on each other if they used the old API. Most people will continue to use the existing API, but libraries that need to hook a GPIO should add their own handler.
There was a problem hiding this comment.
Ahhh, "libraries that need to hook a GPIO should add their own handler" was the bit I was missing, thanks 😃
(is that worth clarifying in the doxygen?)
There was a problem hiding this comment.
i think these comments are outdated as I don't see the text "libraries that need to"
There was a problem hiding this comment.
Happy with this, other than discussion about whether to assert on double-hooking the same pin, and the comment nits.
At risk of bikeshedding, I'm not crazy about the name raw, as opposed to e.g. per_pin, but I don't feel strongly enough about this to not approve
note it isn't per pin anyway, as it can be more than one pin :-) sticking with raw for now |
Note this PR includes the get_core_num() change as they are dependent