Is there any way to "pace" bytes in an I2C transmission?

[GoEk]

Hi,

I am interfacing to a TI device that requires a 100us delay between each I2C byte and I can't think of any way that doesn't involve "hacking", i.e. using timer delays, interrupts, etc. Is there a more elegant way to do it using the ST I2C implementation? Using CubeIDE on a STM32H750 device.

Regards

Goran

[Tesla DeLorean]

An docs or paper on this part and issues?

Perhaps clock at 10 KHz or less, create some lag on servicing interrupts/callbacks?

[S.Ma]

Weird slave chipset. Nack on polling is one usual way to tell the host that the slave needs more time. Some sensirion parts had similar limitation which do not comply with the standard, and provide a pre cooked sw driver of gpio bitbang with special sw delays. No need speed when need to wait...

[Pavel A.]

STM32H750 RM0433 says that its I2C supports clock stretching. Is this what you're looking for?

[GoEk]

The device is a TI MCT8316A motor driver. The major impression of this device it that it is "incomplete" (to be nice about it), for example, it uses the I2C General Call address 0x00 as device ID (geeez...). The 100us delay requirement is a "silicon bug that will be fixed in the next chip revision", i.e. the current device is apparently to be considered a Beta version.

[GoEk]

Well, AFAIK clock stretching must be initiated by the slave device and it does not. I get a feeling they have bit-banged the I2C implementation in the device with all the weird requirements.

[GoEk]

https://www.ti.com/product/MCT8316A

The data sheet does not contain all the quirks of this device, only the "100us" requirement, the rest you will have to search/find on the TI support forum. Actually, 10kHz is the suggested alternative to 100us delay by TI when I asked about it, my problem right now is that after doing the recommend HW updates I can't even get an ACK response from the chip, the bus hangs.

[Piranha]

For I2C protocol 10 kB/s translates to exactly 100 kbit/s bus speed. Just run the I2C bus at 100 kbit/s mode or slightly slower and you are fine.

[GoEk]

Well, this device doesn't mind 100kbit/s, it "only" requires a 100us delay between each byte which is hard to do. What TI recommends to not have to do this delay is running at 10kbits/s, i.e.1kBytes/s.

[S.Ma]

Make an interrupt base state machine which walk alternatively the timer 100us delay interrupt and the i2c data transfer. You need to dynamically turn on/off each interrupt enable. Both vectors go to the state machine having same interrupt level.