Making TM1637::getButtons() work

[vitorafsr]

Hello.

I assembled a circuit on a protoboard to check "uint32_t TM1637::getButtons()" on a TM1637 but it is not working with the actual library code.

Then I checked clock and data signals as in the pictures below. It seems the circuit is working.

5.bmp
4.bmp

What I saw in the datasheet of TM1637, TM1638 and TM1640 and the oscilloscope says the same is that data signal is available after rising edge of clock, and then I corrected "byte TM16xx::receive()" to make "digitalRead()" after clock rising edge. Now it is working.

Before submitting a pull request I came to check if it seems reasonable to make the correction below at "byte TM16xx::receive()".

for (int i = 0; i < 8; i++) {
temp >>= 1;

digitalWrite(clockPin, LOW);
bitDelay();		// NOTE: on TM1637 reading keys should be slower than 250Khz (see datasheet p3)

digitalWrite(clockPin, HIGH);
bitDelay();

if (digitalRead(dataPin)) {
  temp |= 0x80;
}

}

Hope it helps someone else because it corrected my case.

[maxint-rd]

Hello, thank you for posting this issue. I have tested the buttons on TM1637 (and other TM16xx chips) many times, but perhaps in different circumstances.

To properly reproduce this issue, I'd like to know more about your test environment.
What processor do you have and at what clock speed does it run?

Since this receive() function is in the base class I need to verify that changing anything wont break reading buttons for any other chips. As you can see in this list, many other TM16xx chips support reading buttons, so changing receive() has broad impact. Next to comparing several datasheets I probably need to include my logical analyzer and do broad testing to make sure...

BTW. currently I'm working away from home, so it may take some time for me before I'm able to put the right components on a breadboard. I appreciate any feedback you can give in the mean time...

[vitorafsr]

I am using a MHET_Tiny board (attiny88 at 16MHz), Arduino IDE 2.3.8, Ubuntu 26.04. The connection from the board to the TM1637 is via pins 8 (DIO) and 9 (CLK) of the board.

The sketch is in the end. Pin 14 is used to see data in the oscilloscope.

The breadboard contains a TM1637 with decoupling capacitors close to Vcc. The DIO and CLK lines contain each a cap 100pF to ground and a 10K pull-up resistor. No 7seg display. The button connects K1 to KS1.

I agree that receive() cannot be changed before analyzing impact on other chips. And that is why I did not submit a pull request directly. What I did was to read at least three datasheets to check what I was doing. The important phrase is: "DIO signal should not change for high level CLK and DIO signal should change for low level CLK signal" from TM1637 datasheet.

#include <TM1637.h>

TM1637 module(8, 9); // DIO=8, CLK=9

void setup()
{
pinMode(LED_BUILTIN, OUTPUT); // Initialize the LED_BUILTIN pin as an output
pinMode(14, OUTPUT);

module.begin(true, 7);
module.clearDisplay();
}

void loop()
{
uint32_t dwButtons = module.getButtons();

for (uint8_t i=0; i<8; i++) {
if ((dwButtons & _BV(i)) == 0) {
digitalWrite(14, LOW);
} else
digitalWrite(14, HIGH);
delay(1);
digitalWrite(14, LOW);
delay(1);
}
delay(1000);
}

[maxint-rd]

Thank you for the detailed extra information. I appreciate your participation and your considerations.
When you say "but it is not working with the actual library code", do you mean you got no button detection whatsoever until you changed the code?

Since I'm working elsewhere now, I have limited access to my hardware. I did bring along a TM1650 display with a three-button board. I also brought an ESP32-C3 and a bunch of CH32 chips, which are great for their real-time debugging capabilities. (Unfortunately I didn't take a TM1637 or ATtiny with me).

As soon as I have some spare time I will test your sketch (with the TM1650) and compare some other datasheets and post my findings in this topic.

FYI: The TM16xx library was first released in 2018, based on the TM1638 library by Ricardo Batista. It has evolved quite a bit in those eight years, but I don't think that the receive() function changed a lot. Compared to the original I only added the bitDelay() and some CH32 specifics. Since it worked for me and many other users it didn't draw much attention, but I guess now it's time to have a closer look...

Edit: I looked at your proposed change and understand what it does. I just need to be careful and do my due dilligence...

In the mean time you may find this TM1618 simulation on Wikwi interesting. It simulates the whole chip, including button support. (Although it works fine with the TM16xx library, I may have included errors/omissions in my interpretation of the datasheet. :-)

To be continued...

[vitorafsr]

"do you mean you got no button detection whatsoever until you changed the code?"
Yes. The oscilloscope shows the real signal in the DIO and the CLK lines.

[maxint-rd]

Hello @vitorafsr - I did some first testing on what I have with me.

The TM16xxButtons_clicks example worked just fine using the TM1650 on a CH570D. Then I found that in all of the TM16xx library, the TM1650 is the only one with its own receive() function (because TM1650 send ACK and data is MSB-first). Interestingly, that implementation (which I made myself) reads data after setting clock high.

In the project box that I brought along, I also found a CH32V003 connected to a TM1628 with 4 digit alpha-numeric display and a TM1618 with 4 digit 7-segment display. For that setup I used a slightly modified version of the same example. Again it worked fine.

The wording in various datasheets differs, but I compared datasheets of some chips in my collection and found these relevant quotes:

chip	datasheet
TM1618 TM1628 TM1668	"The operation of reading and receiving 1 Bit is on the clock rising edge"
TM1620	"Reading and receiving 1 Bit are all operated at the rising edge of the clock."
TM1623 TM1624	"A BIT is received at rising edge of the clock"
TM1630 translated	"Reading and receiving one bit both occur on the rising edge of the clock."
TM1637	"When data is input, DIO signal should not change for high level CLK and DIO signal should change for low level CLK signal"
TM1638	"a BIT is read and received at rising edge of the clock"
TM1650	"When CLK is high, the signal on DAT must remain unchanged. Only when the clock signal on CLK is low, the signal on DAT can be changed"

I think we can safely conclude that data is set to be read at the rising edge of the clock, meaning that first clock needs to be set high, then data can be read. What I find most interesting is that after all those years, you are the first one to encounter this issue. (Congratulations perhaps?)
I have tested multiple chips myself with various MCU's. My first TM16xx was the TM1638 LED & KEY module. Then others followed. In one of my earlier YouTube video's I even showed a TM1637 display module that I modified into a mini LED & KEY module.
I have no explanation why I never had any buttons not working on any TM16xx chip.

So then I tested the TM1628 and TM1618 with a modified order of the clock signal. The example still worked fine. Somehow the different order doesn't seem to matter much. Perhaps it's a combination of the delays used, the used MCU frequency and not having capacitors on the data lines. I don't have any test equipment here, so I can't dig deeper or tell for sure.

Your initial analysis appears to be 100% correct. Thank you again for your elaborate description of this issue.
A moment ago I uploaded a modification that is similar to the TM1650 implementation into the master branch. Currently I can only test it myself using the setup mentioned above, so I would appreciate if you could test that change in your ATtiny88 setup. It would be great if you could then also check the signals with your oscilloscope and post the BMP's.
(Before publishing this into a new release, I will probably test a few more cases, such as TM1638 on a different MCU).

[vitorafsr]

Hello @maxint-rd, indeed we are going to a better understand of the chips behaviors. I think I have an answer to your thought: "I have no explanation why I never had any buttons not working on any TM16xx chip.".

An answer is that the chips varies in behavior. I tested two different breakout boards with TM1637 in the oscilloscope and data are as follows.

4.bmp

13.bmp

Some chips maintain DIO signal in high longer (13.bmp), and the input reading during CLK low or high are the same. But others only answer in CLK high (4.bmp). The last case only works with the readings after rising edge.

I'll do the test you asked me as soon as possible.

[maxint-rd]

Interesting to see that difference in the oscilloscope. Would those two be different generations, both made by Titan Micro, or is one of them a clone by a competitor? They probably both adhere to the specifications in the datasheet, but it appears that their inner components are wildly different. The one in 4.bmp clearly shows some capacitor being charged by the clock, while the one in 13.bmp shows a cleaner digital signal without the intermediate voltages. Quite interesting indeed,

Looking forward to see your findings regarding my modification. Thank you for your help in testing this and for the opportunity to learn a bit more about these chips.

[vitorafsr]

Hello @maxint-rd , the preliminary tests I did show that your last modification works with my chip TM1637 that was not working before.

My setup is the one in the following image. I switch breakout boards as needed.

Both chips (in blue and in green) are from Titan Micro as can be seen in the images below.

The one whose DIO signal behaves best is on the breakout board that I bought already assembled (in blue). The other breakout board (in green) I bought the chip alone and made all setup myself accordingly to the datasheet. I need to say that some more tests are needed. As my project continues, I'll be back here with more information if appears some useful.

Thank you for the prompt replies. TM16xx library is very useful.

[maxint-rd]

Thank you to for your detailed feedback. To read that my modification works is excellent!

I couldn't quite read the numbers of the chip on that breakout board, but when back I can a closer look at the various TM1637 chips in my collection and do some measurements to search for one with similar behavior. I also have a couple of those modules as well as a bunch of bare chips. I used one of those to make a small led-matrix that was then combined with an ATtiny and a DS3231 RTC to make a scrolling LED clock. Years ago I made this video about it. (Feel free to skip all my chatting and see the result at the end...)

BTW. Your breadboard setup is quite like what I use, but I don't have a shortcut button on the power lines. Seems like the ultimate remedy when nothing wants to work the way you want! ;-) (... just kidding; I see its between K2 and KS1...)

If you do more testing, I would appreciate another screenshot from your oscilloscope, showing the more sensitive chip responding to my modified code. Thanks again for your time and effort!