CarlWilliamsBristol
commented
1 year ago This has now been altered - it's still not exactly as the timing diagram because for various reasons I wanted the sendByte() method to leave the data line low, which means leaving a delay after the ninth clock to allow the display to release the data line, and the next sendByte() leads with a delay before writing the MSB to the data line. In other words, there's still a brief gap in the clock train between bytes, but at least (I think) ACK is now sampled at the right time. (The data sheet says that after a successful transfer, TM1650 takes SDA low after the falling edge of the eighth clock). The ACK is still discarded. Not planning to do anything with that for a while.
As-is the code deliberately waits before reading the ACK status from SDA, however, the timing diagram suggests that the ACK bit is valid during (and a little each side of) the ninth clock pulse. On reflection, the behaviour seen on a 'scope during development, where ACK went (fairly) high after a delay related to the clock timing, is likely to be the TM1650 releasing SDA to allow it to be pulled up by host or device pull-ups, i.e. the ACK is likely signalled with "LOW". The driver would be ever-so-slightly faster if it didn't hang around un-necessarily to wait for (then discard) an incorrect ACK. At some point I'll apply a fix and, if it doesn't break it, might even do something with the ACK, like use it to flag a re-try or something.