Hi, I’d like to have an option to timeout the blocking operations.
> On Aug 25, 2016, at 9:38 AM, will sanfilippo <wi...@runtime.io> wrote: > > Hello: > > Comments: > > +1 on no non-blocking interface. Adding a non-blocking interface later (for > those desiring one) should not be terribly difficult. > > The API seem reasonable although I am no i2c expert by any means. > > >> On Aug 24, 2016, at 4:37 PM, Sterling Hughes <sterl...@apache.org> wrote: >> >> Hi, >> >> While we’re doing the HAL changes, I’d like folks to check out the I2C APIs, >> and provide any comments they have: >> >> https://github.com/apache/incubator-mynewt-core/blob/sterly_refactor/hw/hal/include/hal/hal_i2c.h >> >> I was relatively happy with these APIs, except for maybe the >> hal_i2c_master_data: I think write/read should just take these three as >> arguments: but I didn’t see this as significant enough to change. >> >> However, the one difference between SPI (new SPI HAL APIs) and UART is that >> I2C does not have a non-blocking mode. I didn’t think this was a huge >> issue, because I assume that I2C is likely going to be mostly slow >> communication in a low-priority task context. However, I’m interested to >> know if folks think an interrupt based/non-blocking API is desirable for >> I2C, and worth the implementation overhead for people developing the HAL. >> >> Also, folks should feel free to review the new HAL which is here: >> >> https://github.com/apache/incubator-mynewt-core/tree/sterly_refactor/hw/hal/include/hal >> >> With the caveat that Will’s new SPI HAL interface isn’t committed, and we >> are missing a watchdog HAL (coming soon.) >> >> >> >> Sterling >
