I was wondering about clock stretching as well, and if it all targets do it properly. If not, maybe there should be a way of controlling the data clocking speed. At the moment I read the API such that the MCU would try to clock out data as fast as it can?
> On Aug 25, 2016, at 10:45 AM, Kevin Townsend <[email protected]> wrote: > > 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 >
