I have been working on a temperature display/controller and ebay had thse for cheap. A lot less wiring with only two wires for communication and 2 for power supply versus sement wires, digit wires and "keep it scanning" on a regular 7 seg display.
The above code crashes the GCBasic compiler extremely easy and generally doesn’t work (the main reason is that communication between MCU and TM1637 is too fast), so I wrote a patch. Tested and works fine on the GCBasic versions 0.95, 0.97 and 0.98. I've also included some new features:
Original and Siekoo character set
changing the brightness of the letters
additional special characters: °,) and ?
more options for the TMdec command
I'm wondering if I should attach the my code here or somewhere else?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, please attach the code here so we can enjoy your improvements. this is the contributors forum where we share code . Anobium can check it out and update the library.
Thanks
Mike
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The attached zip file contains:
tm1637a.h - new version of TM1637.h library
tm1637.doc - list of commands
tm1637demo.gcb - simple demo program
tm1637.avi - video clip on how the demo program works
Please note that English is not my language, so check the grammar in the .doc file is OK.
I don't have one of these displays so I can't check, but having used 7-segment displays I know that many letters cannot be rendered with just 7-segments (K,W,M...there are many). So how does it do it?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, I agree, this is a known problem of 7-segment displays. For this reason, I have added the Siekoo character set (http://en.fakoo.de/siekoo.html), which solves this problem quite well. However, in some cases, the default character set looks better, so I kept both (for example, OPEn sometimes looks better than oPEn).
Because of this, in my version of the TM1637 library, a programmer can combine both character sets.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you on behalf of the community and thank you for your contribution to the development of Great Cow BASIC.
Most grateful.
Evan
I have got to code reviewing and adding your documentation to the Help. You have written a great library. Well done and thank you.
Code review
I have reviewed the library and sample code.
Library - I am recommending a few naming changes of methods() and variables. This is for consistency across your solution and to ensure your variables do not clash. (trust me YY as a variable name will clash).
The few names changes are reflected in the draft Help see later.
The functional change I am recommending relates to the TM_CHARBRIGHT and TM_BRIGHT. I think these do the same thing therefore I have rationalised.
I also reformatted the indents and a few variables needed sorting when I added #option explicit.
IDE Helps
I will add the IDE helpers. This means your command pop up in the IDE and then the command gets the correct Help page once you have completed a review of the Help.
So, I compiled the new library with the demo. It compiled. It would be best for you to test also before we release to the world. :-)
Thank you again.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The library is working fine, the demo program needed some minor fixes and now it works flawlessly. Also I changed the name of the variable in the last for/next loop into (hopefully more appropriate to understand the program): time_to_end
The revised demo program (with hex and other stuff) is attached below.
Thank you Evan and the others for this great project.
Here is another simple, slightly different demo program for ATtiny85 (tested on the Digispark module) and a video of the operation. Unfortunately, I don't have any Microchip MCUs at the moment to be able to check the operation of the library on it.
I'm sorry for late answer, I have a huge lack of free time last weeks.
Thanks, really very interesting development board.
About the communication speed between MCU and TM1637 module.
At the beginning of this discussion, there is a fear that slow communication will cause the display to flicker. This simply is not true. Flickerless operation is guaranteed with the TM1637 chip itself.
However, this fear probably caused the communication speed in the first version of this library to be set too high (commented out Wait 5 us lines).
When I started fixing this library, turning on these lines was among the first changes.
Unfortunately, after a few hours of testing, the TM1637 module failed. I don't know the reason, but I preemptively set an even lower communication speed and it's fine for now, as I don't want to hear complaints that someone has broken the module only by using my library.
I think about 100 "FPS" for this LED display (on an Arduino UNO) is quite enough.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi FB,
many thanks for this code - works great.
one point to note is that the TM1637 doesn't work reliably at 4.9V (on my sample of 1) - it still displays, but misses incoming messages, which may be the problem you saw above.
Your timings are well within chip spec, 290kHz vs ~1MHz.
It depends also on brightness and number of segments lit, so might be an undervoltage within the IC, or poor decoupling (nope - extra 10uF X7R has no effect - but datasheet asks for 100uF)
Any chance of a TM1638 driver? - similar part with 8 digits, 8 LEDs, 8 buttons.
best regds
Bonkers
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I also noticed the unreliable operation on one of my 0.56" modules. In my case, the problem was a broken/bad GND trace from both headers to chip. Low price - low quality. I fixed it with a wire, it doesn't look nice, but the module now at least works properly.
I don't have any TM1638 module at the moment. I just wrote a slightly different library for TM1637 modules with the 6 digits, as they have a different layout of digits (and decimal points) than modules with the 4 digit clock display.
No probs FB, difficult to complain about quality when the modules are far cheaper than the parts.
I don't know if it is the right thing to post the code right here - that ramps brightness up and down, and shows the low-voltage fault? I can do...
I've now got the 7-segment text running, amazing that we can understand more or less the restricted character set if there are real words in there, I used "the quick brown fox jumps over the lazy dog".
I note however that the WriteChar routine has a "Bright = 15" instruction, I think its better to comment this out, and let brightness remain as it was - i set it with a dummy Write4Dig command, or ultimately, have an optional parameter passed like with Write4Dig.
Sounds like I'm complaining about quality of free SW - no, it's great what you've done, much appreciated. I can send you a TM1638 board if you like, as a token of thanks, if you can PM me or something?
best regds
bonkers
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Update: second display works fine down to 4V, so not a problem with the TM1637.
I'm delighted and amazed that the same code - just changing the processor type (AVR to PIC) and the 2 pins - and it all works first time - that's never happened before. I will be spending some more time with this.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have been working on a temperature display/controller and ebay had thse for cheap. A lot less wiring with only two wires for communication and 2 for power supply versus sement wires, digit wires and "keep it scanning" on a regular 7 seg display.
Thanks to viscomjim for giving a starting point
This is the demo main:
This is the library:
Last edit: mmotte 2017-08-14
Well done! Got an operational video?
The above code crashes the GCBasic compiler extremely easy and generally doesn’t work (the main reason is that communication between MCU and TM1637 is too fast), so I wrote a patch. Tested and works fine on the GCBasic versions 0.95, 0.97 and 0.98. I've also included some new features:
I'm wondering if I should attach the my code here or somewhere else?
nice work. I saw one on ebay for £1.39 free postage.
Yes, please attach the code here so we can enjoy your improvements. this is the contributors forum where we share code . Anobium can check it out and update the library.
Thanks
Mike
The attached zip file contains:
tm1637a.h - new version of TM1637.h library
tm1637.doc - list of commands
tm1637demo.gcb - simple demo program
tm1637.avi - video clip on how the demo program works
Please note that English is not my language, so check the grammar in the .doc file is OK.
I don't have one of these displays so I can't check, but having used 7-segment displays I know that many letters cannot be rendered with just 7-segments (K,W,M...there are many). So how does it do it?
Yes, I agree, this is a known problem of 7-segment displays. For this reason, I have added the Siekoo character set (http://en.fakoo.de/siekoo.html), which solves this problem quite well. However, in some cases, the default character set looks better, so I kept both (for example, OPEn sometimes looks better than oPEn).
Because of this, in my version of the TM1637 library, a programmer can combine both character sets.
Friderik thank you.
Thank you on behalf of the community and thank you for your contribution to the development of Great Cow BASIC.
Most grateful.
Evan
I have got to code reviewing and adding your documentation to the Help. You have written a great library. Well done and thank you.
Code review
I have reviewed the library and sample code.
Library - I am recommending a few naming changes of methods() and variables. This is for consistency across your solution and to ensure your variables do not clash. (trust me YY as a variable name will clash).
The few names changes are reflected in the draft Help see later.
The functional change I am recommending relates to the TM_CHARBRIGHT and TM_BRIGHT. I think these do the same thing therefore I have rationalised.
I have put the libary in the repository. This means it is now under version control. This just means you need to get it from the repository, make any changes and then we can upload for you. See here: https://sourceforge.net/p/gcbasic/code/HEAD/tree/GCBASIC/trunk/include/tm1637a.h
Please make further changes to make perfect.
I also removed the comments regarding the methods as we have the Help (see next)
Help
Thank you for the Word document.
I have just spent a few hours hacking it into the Great Cow BASIC help. I have used the revised naming.
But, the Help needs a good review and edit. I added an introduction and then a page for each command.
In the Help I bumped the existing to 'legacy' and included your works in the same section. I have retained your copyright in the ADOCs.
There are two documents - these two documents contain all of your pages. I needed to add two pages to control the CHM file.
See https://github.com/Anobium/Great-Cow-BASIC-Help/blob/master/source/TM1637.adoc and https://github.com/Anobium/Great-Cow-BASIC-Help/blob/master/source/TM1637Sections.adoc
You can edit these files online by cloning the GIT or directly in my GIT but I need to give you access.
To see the draft pages, see the formats here: http://gcbasic.sourceforge.net/help/output/ The CHM is the one that we release with the IDE.
Can you review and revise these Help pages please?
Demo code
I took you demo code and adapted for the new naming.
See https://github.com/Anobium/Great-Cow-BASIC-Demonstration-Sources/blob/master/7_Segment_LED_Solutions/7_Segment_TM1637_Solutions/TM1637_7Segment.gcb
I also reformatted the indents and a few variables needed sorting when I added #option explicit.
IDE Helps
I will add the IDE helpers. This means your command pop up in the IDE and then the command gets the correct Help page once you have completed a review of the Help.
So, I compiled the new library with the demo. It compiled. It would be best for you to test also before we release to the world. :-)
Thank you again.
Thanks Evan, great works.
The library is working fine, the demo program needed some minor fixes and now it works flawlessly. Also I changed the name of the variable in the last for/next loop into (hopefully more appropriate to understand the program): time_to_end
The revised demo program (with hex and other stuff) is attached below.
In the Help, I found only one small mistake:
https://github.com/Anobium/Great-Cow-BASIC-Help/blob/master/source/TM1637.adoc
The TM1637 chip supports the reading of the LED matrix however that is not supported in the library.
Not LED, must be keyboard:
The TM1637 chip supports the reading of the keyboard matrix however that is not supported in the library.
About the my Copyright Notice, if this is not common practice in the Help file, you can remove it, no problem.
Thanks again-
Friderik
One more thing, I don't know if it is necessary or not, in the attached zip file there is documentation about the TM1637 chip.
Thank you!
I am truly amazed I did break your library. But, it was laid out well and no strange coding. :-)
I will update the Help. Please check at some time to make sure I followed your instructions.
I will update the demo with the one from the ZIP above.
And, I have uploaded the PDFs to the website and then linked from the Help.
Wonderful stuff.
Thank you again.
Thank you Evan and the others for this great project.
Here is another simple, slightly different demo program for ATtiny85 (tested on the Digispark module) and a video of the operation. Unfortunately, I don't have any Microchip MCUs at the moment to be able to check the operation of the library on it.
Thank you. I will update everything.
Nice video!!!
Go and get a LGT8FX328P. Then, ping me for the latest RC release... you will then see how fast you can update the TM1637!!!
One, probably stupid question, what is this LGT8FX328P?
See https://github.com/Anobium/Great-Cow-BASIC-Demonstration-Sources/tree/master/LGT8F_core_based_solutions then follow the links....
I'm sorry for late answer, I have a huge lack of free time last weeks.
Thanks, really very interesting development board.
About the communication speed between MCU and TM1637 module.
At the beginning of this discussion, there is a fear that slow communication will cause the display to flicker. This simply is not true. Flickerless operation is guaranteed with the TM1637 chip itself.
However, this fear probably caused the communication speed in the first version of this library to be set too high (commented out Wait 5 us lines).
When I started fixing this library, turning on these lines was among the first changes.
Unfortunately, after a few hours of testing, the TM1637 module failed. I don't know the reason, but I preemptively set an even lower communication speed and it's fine for now, as I don't want to hear complaints that someone has broken the module only by using my library.
I think about 100 "FPS" for this LED display (on an Arduino UNO) is quite enough.
Hi FB,
many thanks for this code - works great.
one point to note is that the TM1637 doesn't work reliably at 4.9V (on my sample of 1) - it still displays, but misses incoming messages, which may be the problem you saw above.
Your timings are well within chip spec, 290kHz vs ~1MHz.
It depends also on brightness and number of segments lit, so might be an undervoltage within the IC, or poor decoupling (nope - extra 10uF X7R has no effect - but datasheet asks for 100uF)
Any chance of a TM1638 driver? - similar part with 8 digits, 8 LEDs, 8 buttons.
best regds
Bonkers
@Bonkers
TM1638 is a different protocol and has 3 comm lines data,clk,stb.
I have been playing with one and have the 7 seg display working but not the leds nor the pushbuttons.
Thanks MM, I will look-up your postings on TM1638, not sure they were there last time i looked.
Sure, the chip is a different protocol, like a 3-wire SPI, it's not a small variant of TM1637, even if there are many similarities. I bought a few boards, about £3 each if you buy 5, otherwise £5. https://www.banggood.com/5Pcs-TM1638-Chip-Key-LED-Display-Module-8-Bits-Digital-LED-Tube-p-1156507.html
Thanks Bonkers for your feedback.
I also noticed the unreliable operation on one of my 0.56" modules. In my case, the problem was a broken/bad GND trace from both headers to chip. Low price - low quality. I fixed it with a wire, it doesn't look nice, but the module now at least works properly.
I don't have any TM1638 module at the moment. I just wrote a slightly different library for TM1637 modules with the 6 digits, as they have a different layout of digits (and decimal points) than modules with the 4 digit clock display.
https://sourceforge.net/p/gcbasic/discussion/629990/thread/de80c6381a/
No probs FB, difficult to complain about quality when the modules are far cheaper than the parts.
I don't know if it is the right thing to post the code right here - that ramps brightness up and down, and shows the low-voltage fault? I can do...
I've now got the 7-segment text running, amazing that we can understand more or less the restricted character set if there are real words in there, I used "the quick brown fox jumps over the lazy dog".
I note however that the WriteChar routine has a "Bright = 15" instruction, I think its better to comment this out, and let brightness remain as it was - i set it with a dummy Write4Dig command, or ultimately, have an optional parameter passed like with Write4Dig.
Sounds like I'm complaining about quality of free SW - no, it's great what you've done, much appreciated. I can send you a TM1638 board if you like, as a token of thanks, if you can PM me or something?
best regds
bonkers
Update: second display works fine down to 4V, so not a problem with the TM1637.
I'm delighted and amazed that the same code - just changing the processor type (AVR to PIC) and the 2 pins - and it all works first time - that's never happened before. I will be spending some more time with this.