TM1640b 16 digit 7 segment common anode

[prairielandelec]

The TM1640b datasheet details an arrangement of 16 digits of 7 segments wired in a common anode configuration. From my reading of this library that is unsupported and the only common anode arrangement is a 8 digit 16 segment display.

It looks like the way the datasheet deals with the 16 digit 7 seg is to split half the digits to grid 1-8 and the other half to grid 9-16.

Is this something that has ever been considered for support by this library?

[maxint-rd]

Hello @prairielandelec , do you have a link to the TM1640b datasheet or could you attach it here to your post?

For the TM1640B I found some specs listed on the Titan Micro website, but couldn't find the datasheet. From what I read (with help of Google Translate) I didn't see much difference between TM1640/TM1640B.

It could very well be that while the TM1640 is aimed at 8SEG x 16GRD common cathode displays, the TM1640B targets 8SEG x 16GRD common anode displays. If that's the case I would expect the TM1640B to allow simply connecting the CA display segments to SEG and the digits to GRD. Then you could just use the regular TM1640 class to drive the display. Have you tested that? (The TM1637 uses a similar CA configuration).

Your observation is correct. I only have the TM1640 in my collection and only developed and tested support for the TM1640. The current chip specific TM1640 class supports 8SEG x 16GRD common cathode displays and I've also used it with dual 8x8 LED matrix displays. The TM1640Anode class was made to support 8-digit 16-segment CA displays with the 16 segments connected to the GRD pins.

The TM1640 datasheet (v1.6) only shows a regular 8SEG x 16GRD Common Cathode display configuration. I'd really like to read the TM1640B datasheet to see how that split-GRD configuration is supposed to be used. I haven't seen that before and so it hasn't been considered yet. If you supply me the datasheet I could experiment with a TM1640 chip in similar setup (using 8-seg CA displays) to see how such configuration could be supported.

BTW. In the past months I've been working on a generic class to also support chips that I don't have in my collection and that I'm unable to test. You can find the current state of that development in this repository branch. The generic TM16xxIC class uses chip specific defines that can used to specify the chip characteristics in the constructor. That branch also has a TM16xxICanode class to support connecting common anode segments to the GRD pins. Those generic classes have a slightly larger footprint, but still may be useful to support the various other chips in the TM16xx family.

[prairielandelec]

Hey thanks for the thorough response and all your work on this project, the generic class is very interesting I will take a look. Right now I am trying to keep footprint as minimal as possible since I am targeting a CH32V003 chip to act as a i2c to TM16xx two wire bridge.

Here is the datasheet, I just ran it through google translate. The relevant schematic is on page 9. Basically the first half use grids 1-8 and the second half of the digits use grids 9-16 as the segment sinks.

https://wmsc.lcsc.com/wmsc/upload/file/pdf/v2/lcsc/2201191030_TM-Shenzhen-Titan-Micro-Elec-TM1640B_C2962200.pdf

It does not have any specific messaging guidelines for the command structure so from what I can tell you just encode the raw segment commands? The translation is not optimal.

[maxint-rd]

Thank you for this swift contribution. It's not the first datasheet only in Chinese. Titan probably forgot to publish it on their own website, but good to see that LCSC has it. There were a few more chips with missing datasheets. When I can find some time I will have a deeper look at this datasheet and see if I can do some experiments. If I have some progress I will post it here.

After doing a quick comparison of the command code tables of the TM1640 vs. TM1640B, my first impression is that their commands are identical. Based on that I suggest you to give the regular TM1640 class a try. The footprint of that class is fairly small and fits fine even on smaller MCU's.

Interesting to see you're targeting the CH32V003. As I write this I was working on another project that uses the CH32V003 SOP8 and a TM1650 display. I'm using the WCH Arduino CH32 core, for which I've contributed some key functionality that I needed for my projects, including I2C slave support and EEPROM emulation.

Making an I2C bridge sound perfectly doable. For another project I developed I2C slave functionality for the ATtiny13A. That was rather challenging as the 13A only has 1KB flash and a mere 64 bytes of RAM. I've published that project at its current state here on GitHub. In the examples you can find I2C bridge/gateway implementations for the TM1650 and the TM1637. Having these T13 gateways allowed me to connect multiple addressable displays to a single I2C bus.

To support that TM1650 gateway I made a modified TM16xx class that uses an I2C address in the constructor instead of the normally used CLK/DIO pins. I intend to merge these changes into the main TM16xx library at some later stage, but that requires a bit more time...

[maxint-rd]

After a second look at the figures on page 8 and 9 on the datasheet, helped by Google Translate, I get the impression that the difference between TM1640/TM1640B isn't CC vs. CA.
Translated text above illustration on page 8/page9:

Hardware connection diagram TM1640B drives common cathode digital tube hardware circuit diagram:

TM1640B drives the common anode digital tube hardware circuit diagram:

Comparing the figure on page 8 vs. TM1640 v1.6 page 9 shows identical setup for CC displays. So unfortunately the current TM1640 class probably only works fine for TM1640B when also using CC.
I will need to look futher into the configuration of TM1640B v1.2 page 9 to examine the split grid CA setup that is shown. From what I see such setup can also be tried on the TM1640. I will let you know my findings once I have done some experiments. At first sight it will require some changes to support this, but perhaps using TM1640Anode can already give some partial findings.

[prairielandelec]

You know, I thought your username looked familiar. I am indeed using your i2c slave fork of the ch32v003 wire library. Thank you for that as well! I actually got a pretty functional i2c bridge working with a real bare bones i2c protocol to move decimal values to the tm16xx.

Yeah my current plan for testing is to use the anode header for the first 8 digits and then make a character map to set individual segments for the other 8 digits.

You are correct in your assessment that the 1640b is by default a CC chip. However since there are exactly twice as many grids as segments you can effectively just split the grids in half and do the inverse to run common anode displays.

While I have not seen any common anode displays with a TM1640b on them, I made a custom pcb that uses discreet 0402 LEDs to emulate a vintage scoreboard look at a micro scale and initially tested using the 1637, but I need to drive a good number of these displays so moving up to the 1640b was the obvious choice. Did not do sufficient research to see if anyone else had actually used the configuration on page 9 before I built the boards.

Just for edification purposes, do the TM16xx chips take commands for whole digits? Or does the library map digits to segments and then send segment commands? From what I have read it is the latter but the datasheet is a bit confusing even when translated.

[maxint-rd]

Always good to see my work being used! :-) @TianpeiLee has merged many PR's including mine, so it will probably be part of the next CH32 release (v1.0.5). I only have the CH32V003, so no idea if others will work. I've also made some other improvements for the CH32 core. Latest work that still needs to be published is interrupt driven HW serial to support Serial.available(), Serial.peek() and dependent stuff.

As it isn't CC vs CA I still have to see what the precise difference is between TM1640 and TM1640A. Please let me know if you found something (other than a different datasheet). From what I saw the TM1640 could also support such split GRD configuration.
Can you post a picture of your PCB? I guess for you it would be easiest if your PCB had common cathode layout, but alas, that ship has sailed... ;-)

The command interface of all TM16xx chips is oriented around their display (and keyscan) memory. The library converts numbers to segments. It assumes a specific segment wiring (eg. segment A is SEG1) and supplies a 7-segment font to map the numbers (and letters) to segments. The regular font is for 7 segment (alpha-) numeric. An additional font is included to use 14-segment alpha-numeric displays.

The main command is to send segment data into the display memory. Other commands control brightness, read scanned keys, etc. Just now I uploaded v1.6 of the English TM1640 datasheet here. It includes a readable list of commands.

FYI: The TM16xx base class provides basic functions to display numbers and handles generic functionality. The chip specific derived classes such as the TM1640 class implement chip specific behavior, such as differences in the hardware interface and in memory layout. (The new generic TM16xxIC class tries to unify the most commonly used interfaces and various memory layouts).

[prairielandelec]

Alright so looking at the 1640 vs 1640B datasheets on LCSC, the 1640B appears to be a lower cost but lower "SEG pin drive source current" option.

The 1640 can do up to 80ma at VDD=3V but the 1640B only does 50 max. This makes the 1640B roughly a 16 channel Common Cathode TM1637.

As far as I can tell the messaging is identical and they are both designed for CC applications (however they both feature the schematic detailing how to wire one up for common anode).

My current PCB is a test board that breaks out 6 digits of 7 segments made up of discrete LEDs in different arrangements of parallel and series pairs for the connections within each segment to see how viable a discrete led 7 segment display was. I broke out the seg and grid pins to headers and put on breakouts for both a TM1637 as well as a TM1640B so I could analyze both options.

So my plan was to just cycle through the seg pins on the 1640B to make sure it would theoretically work with a larger display before I make a large 16 digit display that is closer to my final application.

I can upload it later but it is nothing special, just breakouts for the chips and 7 seg displays.

Thank you for the debrief of the messaging protocol. I think I will give it a go with the base class and see if I can figure out the mapping. If I can I will
Update here and maybe it can migrate to a .h file in the future. If you have any progress though please let me know.

Thanks again for the help and library, especially the generic class. Hopefully the details about the 1640 vs 1640B are of some use.

[maxint-rd]

Excellent! Thank you for your further reading in finding the difference.

I think I will give it a go with the base class and see if I can figure out the mapping

You can try both TM1640.h and TM1640Anode.h to use those classes. The TM16xx_setSegments or TM16xx_setSegmentsDebug examples may be helpful in checking out what works for you. You probably find the TM1640 class to show strange effects as setting the segments of one digit will affect others when using CA displays. TM1640Anode fixes that.
NOTE: if you're using the CH32V003 SOP8 model, you may want to stay away from using serial. When you do use serial the SWIO pin will be made inaccessible, requiring a full erase using the LinkE Utility program to recover the otherwise bricked chip.

The main difference between the TM1640 and the derived TM1640Anode class is that the latter transposes segments and grids, to allow using SEG pins as common anodes for the digits and the GRD pins to be used for the segments. Ìt was mainly made to drive 14-segment displays, but when using only GRD1 to GRD7 it should also support 7-segment displays.

I'm not quite sure if I fully understand how one could use 16 CA digits, other than using the split GRD method mentioned before. When I find some time I will do my own experiments to see how a supporting "TM1640SplitAnodes" class could best be made. It could be quite simple, but I won't know before I tried...

Edit: just read you also tried the TM1637. Nice! I also used that chip for various purposes. The popular 4 digit module is not using the full capabilities. On my YouTube channel you can see how I modified such a module into a LED&KEY module that has extra LEDs and buttons. I also used it in a small LED matrix with button interface for a clock project.

[prairielandelec]

Yeah I don't think there is any other way to do it besides the split grid configuration they detail in the datasheet.

The only I figure it would work would be to store the state of any of the lower 8 digits and then doing a masked bit wise and or something like that any time a digit for the upper 8 digits is passed in. So the setDisplayToxxx would be a bit more complicated than the other classes but should be doable.

The biggest thing would be figuring out how to overload the setDisplayToxxx functions in the TM16xx.h and cpp files. That is a bit out of my wheelhouse.

I don't think a new font is needed since you can just use the single byte fonts but AND then on the upper byte of the data sent to the 1640.

[maxint-rd]

The biggest thing would be figuring out how to overload the setDisplayToxxx functions in the TM16xx.h and cpp files. That is a bit out of my wheelhouse.

My first attempt would be to modify the setSegments method of TM1640Anode. All the setDisplayToXxx functions call that method to display their data. Instead of transposing a 16SEG x 8GRD matrix, it would do some juggling to massage two 8SEGx8GRD CA matrices into the required 8SEGx16GRD CC map.
This weekend I have some appointments, so I'm not sure how soon I will find some time. I will try to squeeze it in between my other responsibilities and let you know when I have some progress, To be continued...