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
