we are using KL82 to interface to an I2C host.
Our application has to send 80kB of data to host CPU which is I2C master. All data is available in RAM of KL82 before the first read operation is called.
Host CPU can unfortunately only receive data in 8Byte chunks.
When using I2C slave driver of Mbed Os 5.15.5. the function
int write(const char *data, int length);
results in 11ms clock stretch following the transfer.
Without this clock stretching, the limitation of the host would hardly affect throughput.
But adding 11ms to every 8 Bytes causes the throughput to drop to a totally unacceptable level.
Please let us know if there is a way to get rid of that clock stretching, e.g. using other driver or patching it.
thanks and regards,
Christoph
Solved! Go to Solution.
Hi
Clock stretching takes place when the slave doesn't react to a read or write for a certain time and is not (normally) controlled by the I2C driver (nor the I2C controller).
See at about 7:00 in this video showing clock stretching in operation due to the fact that the Kinetis processor is presently in the process of programming flash and can't respond to the new I2C data: https://www.youtube.com/watch?v=awREsqeCEzQ
In this case the clock stretching is about 9ms long, whereby generally (when not programing flash) there is essentially no noticeable delay.
If you are using an OS it may be that its driver is in polling mode (rather then interrupt driven) and the task polling it is being scheduled periodically (eg. once every 10ms) which would possibly produce such a situation. An interrupt (or DMA) driven I2C driver mode would be preferable in such a case.
Note: The KL82 has the same I2C controller as the KL03 (in video).
Regards
Mark
uTasker project developer for Kinetis and i.MX RT]
Contact me by personal message or on the uTasker web site to discuss professional training or product development requirements
uTasker solution for KL82:
- https://www.utasker.com/kinetis/FRDM-KL82Z.html
I2C:
- https://www.utasker.com/docs/uTasker/uTasker_I2C.pdf
Hi
Clock stretching takes place when the slave doesn't react to a read or write for a certain time and is not (normally) controlled by the I2C driver (nor the I2C controller).
See at about 7:00 in this video showing clock stretching in operation due to the fact that the Kinetis processor is presently in the process of programming flash and can't respond to the new I2C data: https://www.youtube.com/watch?v=awREsqeCEzQ
In this case the clock stretching is about 9ms long, whereby generally (when not programing flash) there is essentially no noticeable delay.
If you are using an OS it may be that its driver is in polling mode (rather then interrupt driven) and the task polling it is being scheduled periodically (eg. once every 10ms) which would possibly produce such a situation. An interrupt (or DMA) driven I2C driver mode would be preferable in such a case.
Note: The KL82 has the same I2C controller as the KL03 (in video).
Regards
Mark
uTasker project developer for Kinetis and i.MX RT]
Contact me by personal message or on the uTasker web site to discuss professional training or product development requirements
uTasker solution for KL82:
- https://www.utasker.com/kinetis/FRDM-KL82Z.html
I2C:
- https://www.utasker.com/docs/uTasker/uTasker_I2C.pdf