Does anyone know of an I2C driver for the DB410c that supports clock stretching?
I have run code using the mraa and the smbus libs and both work with ‘fast’ slaves, but not with ‘slow’ slaves that use clock stretching. Arduino boards have no problems with the ‘slow’ slaves since they support clock stretching. The ‘slow’ slaves are ATtiny85 devices using the USI interface and software to do TWI I2C.
Also, ic2detect finds the ‘fast’ slaves, but not the ‘slow’ slaves.
I did find a comment that mraa does not support clock stretching, but I had assumed the linaro kernel would.
I’ve tried several i2c-dev type libs that I have found and no luck so far.
Any suggestions? or can anyone state that the board doesn’t support I2C clock stretching?
I have a little adapter board with a level translator to handle the 1.8v to 3.3v and 5v levels.
Thanks.
Two thoughts… neither of them directly related to the capabilities of
the 410c I2C controller (I’m afraid I don’t have any I2C peripherals
that perform clock stretching).
Firstly, the FX2 based controllers that work with sigrok are awesome
for double checking assumptions and things like that. They are widely
available on eBay and can be got very cheaply. Search for “USB 24MHz
logic analyzer”. Ignore any software that is bundled with it, sigrok
provides a complete software stack for these devices, including firmware.
Secondly, if you cannot get the hardware controller to work then
switching a bitbang driver such as i2c-gpio.c (CONFIG_I2C_GPIO) might
allow you to work around things in the short term. See
https://www.kernel.org/doc/Documentation/devicetree/bindings/i2c/i2c-gpio.txt
for some clues on how to configure this within device tree.
Hi @CmdrZin
Sorry to take a day to get back to you on this. I had to contact the designer of the I2C block in the chip to be 100% sure of my answer. Clock stretching is a basic part of the I2C spec and all I2C controllers need to respond to clock stretching. so the answer is YES, the APQ8016 (and all other Qualcomm APQ chips) does support clock stretching in hardware. The Library you use (except the soft I2C driver) shouldn’t make any difference.
I would caution you that clock stretching requires the use of a bi-directional level shifter on the clock line.
Full Disclosure: I am an employee of Qualcomm Canada, any opinions I may have expressed in this or any other post may not reflect the opinions of my employer.
Thanks for the response. So I’ll go with the kernel code should be supporting clock stretching and use danielt’s suggestion [quote=“danielt, post:2, topic:2282”]
… switching a bitbang driver such as i2c-gpio.c (CONFIG_I2C_GPIO) …
[/quote]
to verify the hardware voltage translator. It may be something else though because if the translator was not passing through correctly, the ACK pull down would not be getting through. It’s a PCA9306 chip designed for I2C.
Thanks for the input all.
Through the I2C slave could activate clock stretching to co-operate with I2C bus speed, it
shouldn’t be used for purpose such as delaying I2C bus/tranfers for too long time.
From I2C driver layer, there has specefic timeout limitation of every single I2C tranfers, this is
a pure software level limitation.
And the timeout setting varies depending on current tranfer’s data size, logging level and
other coefficient.
If timeout limitation exceeded, I2C driver would reported timeout err and returns.
Further details, please reference to I2C drvier API, i2c_msm_xfer_calc_timeout.
static void i2c_msm_xfer_calc_timeout(struct i2c_msm_ctrl *ctrl)
PATH: kernel/drivers/i2c/busses/i2c-msm-v2.c
