Support for TM1618?

[ArnieO]

Any chance of extending this library to TM1618? (Link to datasheet)

Can I use constructor for TM1620 to drive it?

[maxint-rd]

Hello @ArnieO, since I don't have one in my collection, I have not experimented with the TM1618 yet. A quick glance at the datasheet shows that it has these general features: Type	Segments x digits	Buttons	Interface	Notes
TM1618	5 x 7 - 8 x 4	5 x 1 single	DIO/CLK/STB	not tested yet

Compared to the TM1620, its memory map has a similar split location of segments (unlike chips like the TM1628), but only 5 are in the same byte. Unlike the TM1620, it also has support for 5x1 keys. From that perspective it is more like the TM1630 (which I also don't have, but it is supported by contribution of @tokuhira).

Based on all this I think it wont hurt to do some experiments yourself. Make sure to select a part with same DIO/CLK/STB interface. I suggest you to also try the TM1630 class. First try out the base class before trying classes like TM16xxDisplay and TM16xxButtons. To get the TM16xxDisplay class properly working for 8 segment displays, I think some mapping will be required. Having the keys properly read may also require some changes.

Can you tell me a bit more about your project? Are you using bare chips? Did you buy a display module or are you trying to revive a salvaged module? Does it have keys connected? Unfortunately lacking the chip in my collection means I probably can't offer you much support.

[ArnieO]

Hi @maxint-rd and thank you for your rapid response.

My project is for bare chip, controlling the TM from an ESP32.

I have successfully breadboarded 7-segment displays using TM1638, for which there are many libraries. Searching for a library that can control other TM models, I found your library - but 1618 is not covered.

My project needs a chip with smaller form factor than the huge TM1638 - and TM1618 fulfills my need. I do not use it to read buttons, only drive 7-segment (I won't need the decimal point) displays.

I'd be more than happy to send you 2pcs TM1618 to supplement your collection! Please email me on (deleted email address)

[maxint-rd]

Hello @ArnieO ,

Thank you for posting some more details of your project and for your kind offer to send me a pair of TM1618 chips. I'd be glad to see what I can do to help out and I just send you an e-mail. (You can edit your mail-address from your post now, to keep the spammers away...)

If you e-mail me your address, I'm happy to send you some things in return. (BTW. If you're looking for a small chip, I can recommend the TM1650, which has the SOP-16 footprint and uses only two data lines to drive 8x4 leds and 7x4 keys.)

Your PCB looks quite impressive. Based on that photo I assume you've wired the TM1618 to the 5 digit LED display, and you're going to use display mode 1 (5 bits 7 segments). I'm a bit curious to know how you will drive the other leds. I see a semi-circle of 25 big leds and a row of 21 smaller leds. Do you have more driver chips on the back of the PCB?

I'm looking forward to experiment with another TM16xx chip and add the TM1618 to the list of supported chips...

[ArnieO]

TM1618 chips are packaged and soon on their way to you! 👍

Yes, the TM1618 will drive the five displays. I need 5 digits, so the smaller TM you proposed earlier will not work. TM1618 seems to fit perfectly.

The other LEDs are all addressable LEDS (WS2812). There are two groups of LEDs:

1. The large 5x5mm ones in a half circle
2. The small 2x2 mm ones in a stripe below the 7-segment displays.

Each group will be driven by a GPIO of the ESP32. So all the addressable LEDs are driven by two GPIOs.

The 7-segment displays are blue, and will probably not work on 3.3V, so I am running the TM1618 on 5V, and do level conversion of the 3.3V data signals from the ESP. The board is powered by a USB-C socket placed on the back side. This is an "advanced prototype" / proof of concept board. I have not ordered the PCB yet, as I want to breadboard the TM1618 first against at least one display.

And that is where I got stuck this weekend - not finding a suitable library for TM1618...

[maxint-rd]

Nice! A few years ago I also tested the WS2812 LEDs (as well as a bare WS2811 chip). These neopixels are quite nice. I have a bunch of the bigger once, as well as some similar LED featuring the comparable SK6812 in a RGBWW (warm-while) LED package.

And that is where I got stuck this weekend - not finding a suitable library for TM1618...

I'll do my best to help out.

I am running the TM1618 on 5V, and do level conversion of the 3.3V data signals from the ESP.

In my tests with the ESP8266, a 3v3 Arduino Nano and the 3v3 LGT8F328P I tried various red LED TM16xx displays on 3.3V. Some worked some didn't. Since you're using blue LEDs, I think you're right to run the TM1618 at 5V. In some experiments also used 5V for the display and it worked fine without level conversion, but I guess you're better safe than sorry!

In your schematic I see you're using a common anode display. Is that right? The TM1618 datasheet lists on page 15 the typical use of a common cathode display. That is the most often used configuration for most TM16xx chips. (The TM1637 is the only family member I know that is aimed at common anode displays). For that reason the TM16xx library assumes the LED segments to correspond with the SEGx lines and data is manipulated when that's not the case.

Although, as shown on page 9, it surely is possible to use the TM1618 with common anode displays; it is a bit more complicated and often involves using a memory bitmap to transpose the bits. You can check out the TM1638Anode and TM1640Anode classes for such implementation. Although more complicated, I don't think this is a problem in practice since the ESP32 has plenty RAM, flash and CPU-cycles to spare...

Also note that the datasheet that you linked has some confusing parts:

• the display mode table on page 5 seems incomplete (you would use mode 3 for 5-SEG x 7-GRD);
• SEG6 is absent, whereas it's mentioned in some figures and text on page 8.

I think I need to check out the physical chip to see what's correct and what's incorrect.

To get started; if you have time, you could try out the TM1630 class on the TM1618 and `play with the TM16xx_setSegmentsDebug example to see what it does... You can use the setSegments16() method to address the SEG12-SEG14 segments. Next you could change that example to use the TM1638Anode class to see changes in behavior. Looking forward to see your findings. Good luck!

[ArnieO]

I'll do my best to help out.

Great! 👍

it worked fine without level conversion, but I guess you're better safe than sorry!

Exactly - and that is why I prefer to include it.

Regarding CA/CC I was not able to find CC displays, so it is CA. My initial tests of TM1638 was also with displays CA, so I have assumed it would be feasible to use CA also on TM1618 - and made the schematic as indicated in the (partly confusing) datasheet. Which I now want to breadboard before moving on.

I agree, the datasheets for the TM16xx are far from impressive, even some times confusing. I guess you've already seen that on other chips.

I'll do some testing as you propose when I find time!

[maxint-rd]

Hello @ArnieO , thank you for contributing the TM1618 to my collection. 👍 I released a first version of this latest addition to the TM16xx library, after plenty debugging and some cleanup.

I tested your chip with both a common cathode display (8 segments x 4 digits) and a common anode display (7 segments x 4 digits). Use the TM1618 class for CC and TM1618Anode for CA. Note that you need to install both classes. Also note that the default is 4 digits. I tested the 5th digit by connecting its wire to SEG5 and specified it in the constructor. I also tested using buttons.

Everything worked fine for me (within an experimental version adapted to support STM32/CH32). Last year I encountered problems on some ESP32 cores, due to uninitialized timers when the constructor is called. To fix that I want to release an updated TM16xx class with clean/setup in a begin() instead of the constructor. When you find some time to test, please let me know your experience. Good luck!

[ArnieO]

Hello @ArnieO , thank you for contributing the TM1618 to my collection.

You're most welcome -and thank you for the extension of your library!

I will let you know when I get to test this (probably later this week) - but just to be sure that I understand what you write here: Was there any particular problem with getting the 5th digit to work, or is your comment regarding 5th digit only related to the issue we have discussed (bug?) in the datasheet?

[maxint-rd]

Was there any particular problem with getting the 5th digit to work, or is your comment regarding 5th digit only related to the issue we have discussed (bug?) in the datasheet?

No problem, it was just that I didn't have a fifth digit wired up (used a four-digit display). Since I saw on your picture that you are using five digits I tested the fifth digit by configuring as if I had 5 digits, by just wiring SEG5 to my fourth digit. As a test I used the display_print example and the buttons_click example. Both worked fine with four and with five digits. (Just be aware that I set the default to 4 digits, so you need to specify 5 in TM1618Anode object declaration and in the TM16xx_display object declaration).

The datasheet has some errors, but nothing too serious as the chip operates very much like its siblings. I'm considering to implement a generic driver class that can be provided with some chip specific settings. Such a class may get a bit too large for use on smaller processors like ATtiny, but can come in handy to support untested chips that operate in a similar way.

[ArnieO]

Both worked fine with four and with five digits.

Good to hear - thank you for confirming!

[ArnieO]

I released a first version of this latest addition to the TM16xx library, after plenty debugging and some cleanup.

Did you do a release after adding TM1618, or did you update the code without a formal release? The Releases page indicates there has only been one release, in 2021? https://github.com/maxint-rd/TM16xx/releases Arduino Library manager also does not seem to know of any new release.

I will install the library manually (and get the latest update) but I think it's an advantage for most users if you can do a formal release so that Arduino Library manager can see it.

[maxint-rd]

Hello @ArnieO , you're correct. As you noticed I didn't update the formal release. Main reason was that I have some more updates being tested in development that I intend to include in the new release, The changes include support for I2C chips (eg. TM1680) and support for STM32 and similar platforms (e.g. CH32) that require changes in the current constructors. Another change is the addition of a generic class supporting untested chips that I don't have in my collection. I'm still testing those changes with the challenge to keep them compatible with the current examples.

You are correctly stating that a formal release is much easier for Arduino users. Such release is definitely is on my to-do list. For now you can indeed use the latest versions found in this repository. (Just download the zip of the latest version, unzip it at the install location of the formal release and then restart the IDE).

[ArnieO]

You are correctly stating that a formal release is much easier for Arduino users. Such release is definitely is on my to-do list. For now you can indeed use the latest versions found in this repository. (Just download the zip of the latest version, unzip it at the install location of the formal release and then restart the IDE).

No problem at all - I'm happy that you are maintaining the library!

[maxint-rd]

FYI: added new release to reflect currently published code. All new developments are nice, but not ready for publication yet. Hopefully sometime soon...

[maxint-rd]

Just a moment ago I added a generic class TM16xxIC to support untested chips that I don't have in my collection. The class should support most chips with 2 or 3 wire interface. It's been tested to work with the chips I do have in my collection (including the TM1618 kindly provided by @ArnieO).

The code still experimental, so it's published in a separate branch that will be merged at later stage. That branch can be found it here.