You might want to consider how to handle the STOP condition ... some
sensors have different behaviour about when the stop condition should or
shouldn't be set. See the Arduino Wire library for example, who make
the stop condition optional when you end the transaction:
https://www.arduino.cc/en/Reference/WireEndTransmission
Kevin
On 25/08/16 01:37, Sterling Hughes 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
