Although, this will also depend on how things are implemented in the .c
code ... I only see the header at present. But from experience some
sensors require the stop to be handled differently between multiple read
or writes, so it's worth considering how to keep the STOP condition
flexible and under user control since there isn't a one size fits all
approach for every I2C sensor out there.
On 25/08/16 18:46, Kevin Townsend wrote:
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
