On Mon, Nov 13, 2017 at 04:32:58PM -0800, will sanfilippo wrote:
> Chris:
>
> Personally, I think there should be separate API as it is more flexible and
> the API names more accurately describe what the API is doing.
>
> I do realize that this is more work and given that there currently is no API
> to clear a pending interrupt, I suspect that everyone who used the enable API
> expected the interrupt to be cleared prior to enabling.
>
> Another possible solution (and yes, I suspect folks might think this crazy):
>
> * Rename the API to something like: hal_gpio_irq_clear_and_enable()
> * Make all implementations consistent and use this API.
>
> This way we could add the separate API over time and the code will work as
> expected. Yeah, I know, crazy thought :-)
I don't think that is crazy, but I think it might be a bit disruptive
for some users. Any code that calls `hal_gpio_irq_enable()` will fail
to build after the rename. I assume that is the point: make sure things
break loudly if they are going to break. At the risk of sounding lazy,
that seems like it could be a lot of work for everyone :). Especially
if we plan on ultimately deprecating `hal_gpio_irq_clear_and_enable()`.
Here is an alternative plan for introducing the API change:
v1.3:
- Don't change any implementations of `hal_gpio_irq_enable()`
- Add the `hal_gpio_set/clear` to the API
- Notify users that the behavior of `hal_gpio_irq_enable()` will
be changing in the future (for some MCUs).
- Modify code in apache-mynewt-core such that it doesn't assume
that `hal_gpio_irq_enable()` clears the pending interrupt.
That is, explicitly call the new `clear` function prior to
enabling the interrupt.
v1.x [not sure if this is v1.4 or a later release]:
- Modify implementations of `hal_gpio_irq_enable()` such that
they only enable the interrupt (don't clear it).
Chris
