carlwilliamsbristol / pxt-tm1650display Goto Github PK

Having tried this out with a Micro:bit V2, it became apparent that, with the faster underlying processor, the overheads for the calls to the microsecond delay are shorter and the timing skewed (and faster) when setting rates greater than about 80kbps. Moreover, the calculation for rate was out by a factor of 2, as I'd compensated twice in different ways for the fact that one on or off clock pulse is half the clock period. Another timing diagram from a different I2C device datasheet suggests that there's a significant inter-byte period during which the slave device processes the byte. Originally, I had a fairly large gap (a whole clock) but it may be best to wait for the slave device to free SDA and base the delay on that. I've altered it to work in that way and removed the micro:bit version test I initially used to work around the V2 speed difference. Now it works up to the max speed - capped by the blocks interface to 200kbps - on v1 and v2 units, noticeably more slowly on v1 if you write to a couple of displays really intensively.

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.