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

Reply via email to