petrows/esp-32-tm1637

ESP-32 IDF library for control TM1637 LCD 7-Segment display

esp-32-tm1637's Issues

Issue observed with esp32c6 dev board

Since the gpio driver is in use for the latest IDF's. The issue is observed with the initialisation of the GPIO pins for clk and data

Invalid handling of ACK signal: short?

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:

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!

Problem with tm1637_set_number_lead_dot

Hi, looking for some help here... I am using the example code and its working for the most part. I am having a problem speicfically with:

tm1637_set_number_lead_dot(lcd, time_number, true, z%2 ? 0xFF : 0x00);

Two issues....

1. Not displaying leading zeros when time is using 24hr clock
2. Not understanding how the mask is working for the dot.

with regards to the dot, I am calling the display to change every 1 second based on an interrupt. I would like the dot to change every other cycle. If I use the code as above, I get a faint blip, but not consistantly. If I change the %2 to %4, I get a consistant blip every second, but it only stays on for what is probably 1/4 of a second.

Any help is appreciated!

ESP32 S2- It will work or not

Whether it will work with all esp32 series i.e S2,S3,c2,c3 ???

Huge blocking time

Hi,

I'd like to start by thanking you for this library, I'm using it regularly :-)
However I noticed some unexpectedly high blocking times when updating the display: about 20ms to update all 4 digits (using 4 calls to tm1637_set_segment_raw()). This is huge!
It all boils down to the tm1637_delay() function, which blocks for 50us by calling ets_delay_us(50).
A 50us delay between clock pin changes gives a 100us clock period, which means a 10kHz clock frequency (this is ignoring CPU time to process data and toggle GPIOs, which brings the frequency even lower in real life).
10kHz is waaaaay below the maximum clock frequency of the TM1637: 250kHz as per the datasheet.
As an experiment, I reduced the delay to 1us (which would give a 500kHz frequency, ignoring CPU time) and my display was still working perfectly fine, even on 3.3V, while blocking time was reduced from 20ms to about 1.1ms.
However this was on ESP8266 RTOS SDK v3 (which mimicks the ESP-IDF APIs) so YMMV. The ESP32, being much faster, might actually reach the frequency limit.
But I guess a delay of 5us (100kHz) or 4us (125kHz, or half the max frequency) would probably be safe in most cases, while still speeding up the communications process considerably.

What do you think?