Hi Sterling (et al),
start() and stop() and probably clearer to anyone familiar with I2C, and
it removes any ambiguity about if cached data is also being sent. Or the
single control() command with a parameter seems fine as well, though
that's just my opinion.
Something concerning blocking or non blocking calls as well ... I think
having a user-defined timeout makes sense (as Marko mentioned) with an
appropriate return code on timeout, but the API should also keep clock
stretching in mind (http://www.i2c-bus.org/clock-stretching/). I'm not
sure what the solution would be, though. If the I2C slave uses clock
stretching and is holding the clock low, that's still in a valid state
for the transaction, but what takes priority if the timeout expires
first? I suppose the explicit timeout should take precedence and the
transaction should be aborted, but it's worth considering. We've also
had issues with clock stretching on some HW since not every I2C
peripheral on every MCU handles it properly either ... it might be worth
having a flag and the MCU abstraction level to indicate of the I2C
peripheral supports clock stretching, just to know when working with
drivers that require it.
K.
On 25/08/16 19:36, Sterling Hughes wrote:
Hi Kevin,
On 25 Aug 2016, at 9:49, Kevin Townsend wrote:
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.
Yeah, most of the vendor APIs I see have the stop bit as an option
(or by default) after a write() command, whereas our HAL APIs use
begin() and end() to generate stop conditions. Frankly, I think it
might make more sense to label these start() and stop(), because a lot
of the I2C protocols can have multiple start conditions and multiple
stop conditions. Or maybe a control() command that takes either START
or STOP, to make it clear that it’s not modifying transaction state in
anyway.
Sterling