Yes that's bad, especially with current msleep(5) is actually
msleep(20). However, please also keep in mind SPI tpms show a much
higher burst count value, (255) our I2C TPM SLB9645 even shows
something in the range of 1k. :)
Would another solution be to reduce the burst count poll and sleep
to, e.g., 100 usec or even 10 usec? This would probably help
greatly, but till not incur the wait states that triggered the
NACK.
If you use sleep it's not guaranteed that you wakeup after exactly xx
specified amount of time. Just that you sleep at least xx amount of
time. Otherwise you would have to do delay/busywaiting.
Imho the best option is to figure out whether any vendor can
determine the "FIFO flush time" i.e. how much time does it take to
empty the fifo and fillup the burstcount and use this on the lower
bound of an usleep range. I don't think tpms are in the range of < 10
us...
@Ken: Maybe can you check in DDWG?