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

[S.Ma]

Some high end STM32 have DMAMUX which may trigger a byte transfer with a timer trigger signal.....

[GoEk]

Well, I see a race condition here since I use the ST HAL functions. I cannot disable interrupts, then call HAL which will enabled them. I also cannot call HAL, then disable interrupts since I theoretically may get interrupted between HAL return and interrupts disable.

However, it may be possible by manipulating the NVIC priority levels for the I2C port sinceST HAL doesn't touch them, i.e. set PrioLevels to highest, call I2C HAL and then 100us later restore prio levels.

A second option might be to disable interrupts globally, call HAL and at return, disable I2C port interrupts and then finally reenabling global interrupts. After 100us, the I2C port interrupts are enabled.

[Piranha]

What I meant was that with a 100 kbit/s bus speed the byte period is already 100 us. But it seems that TI actually means an interval, not a period.

[GoEk]

Yes, first one actual byte at 100kHz SCL, then one "byte" of I2c bus idle (100us at 100kHz), then one actual byte, a.s.o.