SNIU028D February 2016 – September 2020 UCD3138 , UCD3138064 , UCD3138064A , UCD3138128 , UCD3138A , UCD3138A64
For many applications, clock stretching is acceptable, but there may be requirements for minimal or no clock stretching. The UCD3138 family PMBus/I2C architecture permits this for some cases
For example, write messages up to 3 bytes and command can be handled in one operation using the 4 byte buffer and automated ACK. This gives an entire byte time for the firmware to respond, assuming that the master sends another message to the slave immediately after the first message. Even at 1 MHz, this is about 8 µsec, which should be time enough for a quick interrupt function to collect the data.
Read is more problematic. Using conventional methods, it should be possible to handle read messages, at least at 100 KHz. Here is the relevant timing diagram, assuming automatic slave address ACK is used:
tX shows the timing caused by the combination of the firmware and the interface delays.
tX = tDREQ1 + firmware delay + tACKWRITE
To avoid clock stretching, tX needs to be smaller than the clock low time for the PMBus/I2C clock speed.
Since tDREQ1 + tACKWRITE = 1.076 µsec maximum, it’s possible to just subtract this number from the minimum clock low time for the data rate.
At 100 KHz, clock low minimum is 4.7 µsec, giving about 3.7 µsec for firmware, which should be attainable with an optimized interrupt.
Obviously the minimum clock low time of 1.3 µsec at 400 KHz gives less that .3 µsec for the firmware, which isn’t enough.