Re: Inconsistent HAL GPIO semantics

2017-11-14 Thread Łukasz Rymanowski
Hi, On 14 November 2017 at 03:16, will sanfilippo wrote: > +1 Sounds good to me. > > > On Nov 13, 2017, at 5:24 PM, Christopher Collins > wrote: > > > > On Mon, Nov 13, 2017 at 04:32:58PM -0800, will sanfilippo wrote: > >> Chris: > >> > >> Personally, I

Re: Inconsistent HAL GPIO semantics

2017-11-13 Thread will sanfilippo
+1 Sounds good to me. > On Nov 13, 2017, at 5:24 PM, Christopher Collins wrote: > > 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

Re: Inconsistent HAL GPIO semantics

2017-11-13 Thread Christopher Collins
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

Re: Inconsistent HAL GPIO semantics

2017-11-13 Thread will sanfilippo
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

Inconsistent HAL GPIO semantics

2017-11-13 Thread Christopher Collins
Hello all, It appears there is some inconsistency among implementations of the `hal_gpio_irq_enable()` function. There are two behaviors associated with this function: (1) Enable the interrupt associated with the specified pin. (2) Clear any pending interrupt associated with the