Display device compatibility testing with STM32 boards

[KenWillmott]

I tested the TM1637 example sketch with a few different boards using STM32 series IC's. They are all 3.3V powered, so I also powered the TM1637 from the same 3.3V power. I used a somewhat arbitrary PB8 and PB9 for I/O. I tried first Blue Pill with the STMF103C8T6, it worked with this configuration:

OS - Windows 10 Home version 21H1
pins - 3.3V, gnd, PB8->DIO, PB9->CLK
display: DM 6 digit TM1637 (basically Robodyn clone)
IDE: Arduino 1.8.12
core: stm32duino core 2.1.0
test program: TM1637_extended

Subsequently, I went on to test an STM32F401CC, and STM32H705x and the display did perform the test up to a point. However, during this I went down a wrong path for a while, I think. I saw that the display just went blank after a while. Anxious about the hardware, I quickly shut it down and only realized later when looking at the test code, that it seems to actually do that. Is it true, at the end of the TM1637 test, it goes dark and samples keys?

For results, I am wondering if I should put it together more as a table or spreadsheet because it would facilitate keeping track of which pins are used, not just in the code, but also in a place where you can compare them all.

I made some previous modifications to the test program and had some after thoughts... one is to differentiate between "test" and "example" sketches. The examples do make good demonstrations, but for this testing I want something more purely test, along the lines of a factory test but simplified. It should include some burn in test - extended on, extended off and so on. Lacking light measuring instruments, a slower and more self labelling brightness change test. Inter segment shorts. Stuff like that. So I am building a generic test sketch, with a header file defining the target display, and the board/processor. I think it will make it easier to test the many boards that I have.

However, in the mean time, I intend to repeat the display tests of the F103, F401 and H705 with the distributed example sketch, and combine them in a table that I will put here.

I almost forgot to add - I received a TM1650 display today, and it ran with a modifed TM1650 sketch on the Blue Pill. It will also get a repeat and be added to the table.
But, unless I was wrong about the example sketch ending up blank, the current result is that those 3 boards passed, and that it's then highly likely that most of the almost 100 different variants would also pass.

[maxint-rd]

Hi Ken,

Thank you for submitting this item and for the effort you are putting into testing. I look forward to see your table with test results. I have quite a collection of various TM16xx chips, modules and MCUs. If this topic is not suited to show the test results, they could also be put in the documents folder, or in a Wiki page. In the readme I would like to add an overview listing a summary of compatibility findings.

As you correctly saw, my examples are mainly used to demonstrate features. As mentioned before, the TM16xx_basic example is still waiting to be added.
An easy example to test basic functionality is the TM16xxDisplay_Print example, which shows a simple second counter. (For 4 a digit display you need to remove the line display.print("Count:");
Another simple example is in this readme section.

You state you used the TM1637_Extended example, that example was made for my modified TM1637 module. The display should first show a segment test. After setup() is done it should show a count of millis() while blinking LED_BUILTIN and show the buttonstate when a button is pressed. I'm not sure why the TM1637_Extended example would end up blank. You can look at the serial output to see at what point the sketch is running...

I've never made a test aimed at the rigourous testing you intend to do. I welcome such a sketch and if you approve I will add it to the example sketches. I also intend to test my own STM32 blue pill module, but that item hasn't reached the top of my priority list yet...

[KenWillmott]

Okay, I will have a look at the TM16xxDisplay_Print example. I have not had time yet to compare all the different variants, to see how much they have in common, for example. Thus I have to do some basic research to interface each one with the test sketch. Fundamentally, I just want to be sure that the test sketches that I write are correct for the target IC.

One thing that I haven't solved in a satisfactory way, is the number of display digits. This affects the test implementations, and has roots that go fairly far down in the code, for example when not using the print class, the format string in sprintf() that is used (for me, it's usually when I need leading zeros in the display), must be different. This suggests two alternative approaches and I'm not sure which one to use - one, use conditional compilation within a single sketch to select the right parameters - two, write individual sketches that are specific to the display in use. Since the maximum number of digits is IC dependent, it can't be specified in the base class... I'm confused about how it should be managed for all the IC variants.

Also, what I'm doing here sprang from a rather simple need, actually. So it would be nice to keep in mind that original purpose and its ramifications. Before finding this library, was using (and modifying) a different library in order to drive the new on the market 6 digit decimal display from Robodyn, and the DM board which I am fairly sure is a clone of the Robodyne. The other library proved to be extremely awkward to modify for this purpose, while this one was super easy.

The main issue is that the digits are not physically mapped consecutively, 0-5. Instead, the mapping is like 012345 -> 210543. So the digit output method in the TM16xx class had to be over-ridden in a new TM1637 class specially made for that purpose. It went together very cleanly and I was quite happy. But then I thought, it's a class designed for a specific module. But looking at the library as a whole, it seemed that 4 digits were mostly assumed, at least, although a defined constant does define the maximum number of digits, I didn't find an easy, flexible way of choosing 4 or 6 digits for a given implementation. Perhaps I overlooked something obvious. Anyway, for that module there is both the number and the position of digits to change in order to test and use it.

I hope that is not too much of a diversion, I just didn't want to open a new topic for that, at least not now.

[maxint-rd]

For more standardized testing I intend to make a TM16xx_minimal example and to show some basic functionality a TM16xx_basic example. The minimal example would show the minimal code needed to display something on the smallest module and MCU I have (probably a 4 digit TM1650 on an ATtiny44A). Comment out it would show constructors and pinouts for some alternative modules and other MCUs.

The TM16xxDisplay_print example might make your test case a bit easier. It extends the Arduino Print class, allowing for simple left-to-right printing of text and numbers using the familiar print() and println(). As the text is left-aligned, printing a short number on a 4 digit display defined as a 6 digit display won't skip text and show blank when an only one digit number is printed.

I chose to define chip specific constants in the driver header file, to represent the maximum number of digits that the chip can address. The base class has two constructor parameters, one for the chip specific maximum number of digits and one for the module specific actual number of digits. When creating the object the sketch can override that last numer, by providing the parameter in the constructor. TM1637.h has the maximum properly specified: #define TM1637_MAX_POS 6, but the default number of digits is set to 4 as I only knew of 4 digit modules.

I think making a separate module specific class for your deviating digit mapping is the proper way, assuming you derive your class from the original TM1637 class, overriding only the methods that require change. Something similar was done for the inverted TM1638 and the QYF-TM1638 modules.

[KenWillmott]

Yes, that is what I did. It looks like:

void TM1637DM6::sendData(byte address, byte data)
{
  const unsigned char positions[] = {2, 1, 0, 5, 4, 3}; //remap digit positions 012345 -> 210543 as module is wired
  sendCommand(TM16XX_CMD_DATA_FIXED);							// use fixed addressing for data
	start();
  send(TM16XX_CMD_ADDRESS | positions[address]);						// address command + remapped address
  send(data);
  stop();
}

[KenWillmott]

The "Robodyn black" STM32F303CC also passed with the TM1637. I tried the STM32F030, but it doesn't have enough flash memory to load any but a trivial Arduino sketch. I tried to upload to the STM32F407VE, but my boards are giving me a hard time, I remember having that issue before but it was a long time ago. So I may just pass over that to save time. The H7 is of note because the Arduino Portenta uses it.

I think it is reasonable to assume that most STM32 will work, but so far the testing has only been with the TM1637. It seems like a good idea to shift the focus to the displays so there is a matrix of processors vs. displays. I found earlier that the TM1650 accepts commands from the TM1637 class. I want to spend a little time looking at what I need to extend my test sketch to cover all the different processors. Some displays will need level converters so I started work on that today.

Incidentally, the TM1636 based multifunction board arrived yesterday, so I will add it when I get a chance. It's for the UNO/Mega though, not STM32.

Things have become busy here, so I may not meet my promise of elegant presentation but I will at least pass along all my findings here first.

[maxint-rd]

Hello Ken,

Thank you for your efforts and for informing me of your findings. I understand your position. In my case work and family also takes priority over this hobby activity. Any progress is welcome, so I'm thankful for your contribution so far.
Your input inspired me to put some time in this project, resulting in more testing and subsequent bug fixes, as well as new functionality that requires more testing, but that I intend to publish in the near future. FYI: the new features involve chaining multiple display modules and support for 15-segment displays using the TM1640.

I still intend to install the environment for my STM32 blue pill module. I'm not quite sure which version that MCU is, but I understand it should be largely comparable to the ATmega328. I also have some STM8's which I assume to have far less resources. The base library does work on a meager ATtiny44A, which doesn't have a lot of memory either.

For the TM1650 you should be using the TM1650 class. Although these two share commonalities, there are some protocol differences between the TM1650 and the TM1637. The main difference is the bit ordering. In contrast to most other TM16xx chips, the bit-ordering of the TM1650 is MSB-first. The main deviation of the TM1637 is that the TM1637 uses an ACK to confirm reception of command/data (like I2C but without addressing).

EDIT: for your TM1636 module you can try the TM1637 (or any other class...), but no guarantees. I haven't looked at the datasheet yet, but perhaps it reacts. Is your TM1636 module the Arduino shield with the DS1307 RTC clock (Aka "MissBirdler Clock Shield" on Amazon, aka "LED Real Time Clock Temperature Sensor Shield for Arduino" from PMD Way as described here)? That module sure looks interesting!

[KenWillmott]

The Blue Pill uses the STM32F103C8T6. It's much more powerful than an ATmega328. It's a puzzle about the memory size issue of the F030 vs. the AtTiny. I really have no idea. I can tell you that previously, I gave up on using the Arduino core with that processor due to the same memory problem, and used STM Cube IDE instead. It's not a big worry as it's not a very commonly used part.

Thanks for the detail about the TM1650 and TM1638, I will fold that into the testing. Anecdotally, I have read that the TM1636 is like a reduced pin TM1637, but I haven't had time to check. The clock module is indeed the PMD Way one you linked to.

[maxint-rd]

Hi Ken,

I know that the ATtiny core fits large programs into smaller space by using optimization in the linker. As result a small sketch on the ATtiny13A is much smaller than the same sketch on the ATmega328p. Of course that only affects flash, not RAM, but as the ATtiny13A only has 64 bytes, RAM usage also seems optimized. Perhaps the difference has to do with the size of an int or with 32-bit alignment in RAM or perhaps with core-specific code such as I2C and Serial buffer size definitions?

FYI: Just a minute ago I published my latest updates. It includes support for a 8x14-segment common anode configuration on the TM1640 and support for combining multiple modules in the TM16xxDisplay class. I still need to add some example code. At the moment I have tested this on an ESP8266 and a LGT8F328P.
A few days ago I received a QYF-0231 module. It's a 4x14-segment display based on the VK16K33, which is probably a clone of the HT16K33, an I2C LED driver for 8x16 segments. Similar size as the TM1640, but with a few additional features. I'm thinking of adding support for that chip to the TM16xx library.

[KenWillmott]

Who knows? If I had more time, maybe I could find out how to optimize the memory footprint for the STM32F030. But I definitely don't want to get sidetracked with that right now. I think it's the flash size not RAM that is the problem there. The official STM core is a layer on their HAL, which is the reason for the great support of so many chips, but it isn't very efficient. That's probably the main reason it won't fit.

Thanks, I downloaded your updated bundle and ran up some tests again. I'm developing a test sketch, it has a header file with sections for processor and display module. At the moment I'm keeping the selection simple by just commenting in/out the appropriate sections, later I'm sure that can be improved. So far I have only tried it with TM1637 and TM1650 on the Blue Pill, and a previous version on the Nano. All that works as expected so far.

I'm playing with a new module, it is a TM1650 with 4 20mm high digits, provided with a black plastic panel housing and red filter window. It has a depopulated position for a processor and RS232 level shifter, so it must be a chopped version of some panel voltmeter or like that. It's nice because of the big digits. Here is a link:
https://www.aliexpress.com/item/4001271820158.html

I also have 2 16 segment modules on order, not here yet. When it arrives, it will be interesting to see whether it uses the HT16K33 or the VK16K33. Sometimes the vendors will substitute parts if they think that they won't get any complaints.

I've made so many projects with the HT16K33 "purple expander board", including a custom wired 8x2 digit 7 segment clock. That was before you could easily obtain colours other than red in modules. Testing those with the TM1640 driver is just another thing that was pushed aside to get the other stuff done. Probably, the day the 16 seg modules arrive I will not be able to stop myself from trying it out.

Also as a side note, I obtained some 20mm red 8x8 matrix boards, that stack end to end in groups of 2 and 3. Those use the MAX7219 and so are strictly 5V devices. With those, I wondered if it would be possible to build a version where each 8x8 mini matrix is also a push button. Then you could have buttons with dynamic displays on them.

So little time, so much to do... I find it hard to share details of the test program because I'm forced to develop on two different machines, one Linux and one W10 because there are some bugs in the Linux implementation of the STM32 software for one reason. So my browser is over here and I can't copy paste. But it's coming along nicely. I'll find some way to show you later on.

[KenWillmott]

I've made pretty good progress with the generic test sketch. Right now, it's configured for the black TM1650 module I mentioned, later today I'm going to test it with the DiyMore 4 digit TM1637 modules. I am wondering, I haven't really learned to use the proper Github workflow, so although I'd just like to revert the changes I made to my fork so I can roll in your recent changes, I can only imagine deleting the fork and starting over. But in the meantime, I'm asking what is the best way to share the test program with you so you can have a look and maybe try it out on some modules that you have and I don't... at the moment it should work with any 4 digit 7 seg display that has an IC driver to match it.

[maxint-rd]

Hi Ken, you've got a lot going on! I agree... So little time, so much to do...

Yesterday I soldered two more of my 4-digit TM1650 displays and their accompanying button modules. If you add them to a fork of the library in your account, I can download them from your fork. Within that fork you can do whatever you want (... but if you want any changes merged they should comply ;-).
To revert your changes, deleting the fork is perhaps easiest. I'm no Github wizard either and probably miss out on much of it's power. I only use the web interface. I have merged a few pull requests by other contributors. I think they made their fork, committed their changes to Github and then issued their pull request.
Alternatively you can also send your sketches to me by e-mail, or add repository in Github containing only the sketches. I'd be happy to test your sketches on my modules and I currently have a test setup on my desk with a LGT8F328P, an ESP8266, an ESP32 TinyPico, an ATtiny44A, ATtiny84 and an ATtiny85. (I haven't started a setup for my STM32 103C blue-pill module yet).

That black TM1650 module looks quite nice, ready to be placed in the housing of larger project. I tried to see what MCU it would take but couldn't recognize it from the footprint. As it is now it has the same functionality as my TM1650 module with buttons included. I've programmed a simple DS1307 clock to run on an ATtiny85. I think I'll make this into a generic Arduino example to demonstrate various aspects of the library in a real-world useful device.

I have some variants of the regular size MAX7219 matrix modules. One consists of four displays already attached. They are great fun to play with and work nicely with the AdafruitGFX compatible library. Based on that experience I made the TM1640 mini-matrices that I used for my 16x24 dot-klok project.

Your idea of mounting a button beneath is interesting. The buttons I now have on the side of an adjacent PCB are not very practical. Having them underneath movable matrices would allow for a very tidy device. I can imagine the mechanical design to be an interesting puzzle to tackle. The easiest approach for my 16x8 modules would be to have a simple dual pushbutton PCB underneath, with some 3D-printed frame and perhaps some springs, to make the display seesaw on the buttons. Sounds like a cool addition to my projectlist. Thanks!

[KenWillmott]

Okay, I will start a new fork for that. I've also merged pull requests, although I can't recall how. But that is a basic mechanism that should work. There are a few things left to add to the test program - mainly to handle the differences transparently. Right now it only works with 4 digit displays. Because the serial port is not always active during a typical upload using the ST-LINK method for STM32, I'm trying to build the program so that the LEDs display the important information as well as the serial monitor. It runs through the following tests:

1. print "Halo you LED nuts" (hey there aren't a lot of letters :)
2. cycle through brightness levels while displaying the number
3. speed test - clear and write the screen 100 times, report the time consumed
4. digit test - enable all segments, cycle through all digits 1-n
5. segment test - enable all digits, cycle through all segments 1-n
6. display a seconds counter, test for buttons if equipped

Step 4 and 5 together test for any row/columns that might be shorted together. The button test reads buttons, then displays the bit offset number 0-31 on the display. From this, I learned that my black module has 3 switches on bits 0, 4, and 8.

Another thing left to add is something to test the decimals and colon if equipped. The method of commenting/uncommenting really needs some improvement. I suppose I'll think of some solution but it's better if I share it with you in the state it's in now, to get some opinions.

[KenWillmott]

I created a new fork, didn't really want to make it public, but I'm forced for "security" reasons. Anyway, I added the new test sketch
https://github.com/KenWillmott/TM16xx/tree/master/examples/TM1637_test_7segment_generic
I had a chance to test it with the TM1636 on the Tick-Tock Multifunction board on an UNO. In that case, I used the TM1637 driver, so rumours of compatibility between the 1636 and the 1637 must be true. There were no buttons to test, the major differences might be there.