Oh, I should add to this:
I think we’re missing a timer interface HAL and a cputime itself
should move from being a HAL to OS service. cputime should use the
timer HAL IMO.
sterling
On 24 Aug 2016, at 16: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
