I'd have to look at all the datasheets for the support MCUs, but some
MCUs definitely don't play well with clock stretching, I just wish I
could remember some examples quickly. We've run into problems with
popular SoCs or ICs like the BNO055, which use CS.
See this for example for the ESP (though this is just from a quick
search on Google, I haven't tried):
http://www.esp8266.com/viewtopic.php?p=41401
K.
On 25/08/16 20:14, marko kiiskila wrote:
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
