Hi,
I was toying with a new logic analyzer, and noticed something strange looking at the signal coming out of this library.
Here is what sending the TM1637_ADDR_FIXED
byte (the first byte sent by tm1637_set_segment_raw()
) looks like:
![scrn-2020-09-07-13-55-30](https://user-images.githubusercontent.com/1636924/92410518-58d0b680-f112-11ea-93ab-06098ad8e634.png)
So basically: start condition (S), the 8 individual bits, ACK, and stop condition (P).
What struck me is what happens when CLK goes down at the end of the 8th bit.
Looking at the code, after sending the 8th bit, the library pulls CLK down, and DIO up: https://github.com/petrows/esp-32-tm1637/blob/master/tm1637.c#L89-L90
But looking at the capture above, it appears that DIO stays down.
The most logical explanation is that while we pull DIO up, the TM1637 itself pulls it down (and "wins the fight", according to the logic analyzer).
So I looked at the TM1637 spec, and it actually makes sense:
TM1637 data transfer carries with answering signal ACK. For a right data transfer, an answering signal ACK is
generated inside the chip to lower the DIO pin at the failing edge of the 8th clock. DIO interface wire is released at the
end of the 9th clock. (Interface interpretation - page 3)
The TM1637 actually pulls DIO low as soon as CLK goes low after the 8th bit.
So pulling it up in the code is a mistake, and generates a short-circuit for a few microseconds after each and every byte.
Probably not very good for the chips...
To my understanding, the code would need to be modified to follow these steps right after sending the 8th bit, basically making sure DIO is set as input for the whole duration of the ACK, to prevent any shorts:
- set DIO as input
- pull CLK down (TM1637 ACK starts, pulling DIO low)
- delay
- pull CLK up
- wait for DIO to be low (it should be low since we pulled CLK down above)
- delay
- pull CLK low (TM1637 ACK stops, "releasing" DIO)
- delay
- set DIO as output
- pull DIO low
Then, as CLK is already low, we don't need to pull it low again in tm1637_stop()
so line 69 could be removed.
These are just initial findings. I'll play with the code, and see if I can come up with a PR.
Cheers!