TM16xx
TM16xx copied to clipboard
maxint-rd
Example for TM1640 with common anode 8x8 bicolor led matrix?
Trying to do it with a RPi Pico but lack of luck 😢 TM1640 pinouts are like this:
Hello Leo,
Thank you for contributing this issue. I'm familiar with the pinout. The TM1640 projects that I've done myself include a 16x8 matrix module (see this video, this PCB and this PCB) and I've also used the bare chip to drive 15 segment alpha-numeric led displays. I don't have a bicolor led matrix in my collection yet. Are you using a PCB module or are you using a LED matrix display? Where did you buy it?
At the moment I don't have an example for a bicolor matrix readily available, but it sounds like an interesting project. Did you get the matrix to do anything at all? Please tell me your findings.
The current examples either use the simple TM16xxMatrix class or the TM16xxMatrixGFX class. Easiest start I think is to try this matrix example first. I made that for driving a single color 8x8 matrix in a very simple way. If connected correctly it should work for a single color within your display. (The Pico has been tested on various TM16xx chips. I'm not sure if the TM1640 was included),
~You could then modify that example to use the TM16xxMatrix16 class, which I made for another display, but should support 16x8 displays. Can you tell me if that class allows you to set the full range of leds within your matrix?~
Edit: the TM16xxMatrix class also works for 8-seg x 16-grid displays, provided you initialize using 16 columns:
TM16xxMatrix matrix(&module, 16, 8);
If it does work, the next step could be to make a derived class that supports your bicolor display and an associated example. After that I could see if TM16xxMatrixGFX can be updated to support multiple color depths. Before I commit to such effort, could you perhaps tell me your findings? I'm willing to begin developing support for your display, but without having one myself, this would be a "try and see"" effort requiring your cooperation for frequent testing. Are you willing and able to do so?
FYI: Another work in process is using a different multicolor led display, which wil probably require a bit more time, but is remotely related to yours. See this issue for more information...
My PCB design is almost the same with yours. I just add two more capacitors between DIN/CLK and GND, following TM1640 datasheet.
Fortunately I have a NodeMCU (ESP8266) on hand so I tried and got it work now! This is my code example, you could include in the lib with or without modification.
#include <TM1640.h>
#include <TM16xxMatrix.h>
#define MATRIX_COLS 8
#define MATRIX_ROWS 8
// for ESP8266: DIN = 13(D7), CLK = 14(D5)
TM1640 module(13, 14);
// depending on my wiring of bicolor 8x8, col 0-7 are green (lime), col 8-15 are red
TM16xxMatrix matrix(&module, MATRIX_COLS * 2, MATRIX_ROWS);
byte r;
byte smile_bmp[] = {
B00111100,
B01000010,
B10100101,
B10000001,
B10100101,
B10011001,
B01000010,
B00111100
};
byte neutral_bmp[] = {
B00111100,
B01000010,
B10100101,
B10000001,
B10000001,
B10111101,
B01000010,
B00111100
};
byte frown_bmp[] = {
B00111100,
B01000010,
B10100101,
B10000001,
B10011001,
B10100101,
B01000010,
B00111100
};
void setup() {
module.clearDisplay();
}
void loop() {
for (int i = 0; i < MATRIX_COLS; i++) {
r = rand() % 8;
matrix.setPixel(i, r, true);
delay(80);
}
for (int ii = 0; ii < MATRIX_COLS; ii++) {
matrix.setColumn(ii, smile_bmp[ii]);
}
delay(1000);
matrix.setAll(false);
for (int j = 0; j < MATRIX_COLS; j++) {
r = rand() % 8;
// offset for the red
matrix.setPixel(j + MATRIX_COLS, r, true);
delay(80);
}
for (int jj = 0; jj < MATRIX_COLS; jj++) {
matrix.setColumn(jj + MATRIX_COLS, neutral_bmp[jj]);
}
delay(1000);
matrix.setAll(false);
for (int k = 0; k < MATRIX_COLS; k++) {
r = rand() % 8;
// red + lime = orange
matrix.setPixel(k, r, true);
matrix.setPixel(k + MATRIX_COLS, r, true);
delay(80);
}
for (int kk = 0; kk < MATRIX_COLS; kk++) {
matrix.setColumn(kk, frown_bmp[kk]);
matrix.setColumn(kk + MATRIX_COLS, frown_bmp[kk]);
}
delay(1000);
matrix.setAll(false);
}
And it looks like this:
https://user-images.githubusercontent.com/519733/226166196-7c11e504-d63d-4142-8d38-1f8b7d1a50c2.mp4
.
However, still fail to run on Pico. According to this I use GP19 and GP18 to set it up TM1640 module(19, 18);, but nothing happens.
Nice! Thank you for uploading this. I will test it with my TM1640 pcb on both ESP and PICO as soon as I can find the time. Then I'll let you know my findings. To be continued...
In the beginning my plan is to drive an 8x8 bicolor with HT16K33. I've played it with 8x8 single color so it's familiar to me. Since the chip has 8 low pins and 16 high pins which are fixed (you can activate/deactivate, but you cannot set high/low), so common cathode is the only choice.
Then I checked Alibaba, all the others are selling common anode matrix except for one selling common cathode matrix. So I got one from it. But ironically it's common anode too. 🤣 Then I spent some time till I find TM1640, and your lib. That's the story.
BTW, such a matrix from Alibaba is very cheap, like around 1 USD.
Interesting. Recently I worked on support of the HT16K33 within the TM16xx library, to drive a 2 digit 15-segment LED display using that chip. It has some interesting features too.
I tried to find your module on AliExpress, but couldn't find it. Perhaps I missed something. Did you design your own PCB or did you buy a complete module? BTW. I do already own the TM1640 based single color matrix shield for the D1 mini (which I used to make my first matrix example). The JY-MCU8x8LED bicolor matrix I found was 28 euros for 5 pieces. Can you share a search term or a link?
No, I bought all the basic elements and solder them together by myself. In TM1640 datasheet there is a suggested schematic, I add the led matrix based on it. PCBs are from JLC.
Can you visit Taobao from your place? It's Alibaba group's B2C site mainly focuses Pacific Asian area https://detail.tmall.com/item.htm?id=25379784544&skuId=3817310181552
Just a short message to let you know that I'm testing the PICO. Good news: TM1637 works fine. Also good: TM1640 doesn't. Using my own TM1640 matrix example it only gives some initial blinking line on the matrix. I call it also good, since now I have something to debug! At the moment I think it may be related to the clock speed of the PICO. Will need to do a bit more testing. To be continued...
Latest findings: communication seems problematic. Commands are wrongly received and interpreted as "display off" commands. Frequent calls to setupDisplay(true, 7) will re-enable the display and show more of the intended patterns. Could be caused by signal noise, timing issues or by voltage level issues....
BTW: forget my earlier remark about using TM16xxMatrix16 - The TM1640 has 8 bit display memory. TM16xxMatrix16 was made for chips with 16-bit memory - such as TM1638 - which can handle more than 8 segments per grid. (I will edit that post to avoid confusion by other readers).
More findings: to get closer to the cause of errors of the TM1640 matrix on the RP PICO, I tried a number of things. Using level shifter or the 5V line instead of 3v3 didn't improve it, neither did adding a capacitor on the clock, data or power line or extending the bitdelay. (My version of the datasheet only had a capacitor on VCC/GND).
What did help a bit was using shorter wires and setting intensity low. My 16x8 matrix gave regular failures, depending on the number of LEDs lit and the selected intensity. At higher intensity the issues appeared more frequently. So the issue I experienced could to be caused by flakey breadboard connections combined with power usage.
I'm not quite sure why this issue only affects the TM1640 on the PICO and not a TM1637 module on the same PICO. I still need to do further tests, perhaps using an osciloscope. For now I suggest you to call setupDisplay() to set a low intensity and call it more often to restore the display after failing.
Here is a short clip of your example running on the RP2040 PICO, using my TM1640 16x8 matrix. As you can see it works for me. I added this line at the beginning of loop():
module.setupDisplay(true, 1);
That line sets the intensity low and resets the display in case it glitched.
In my case the display issues seemed mostly related to iffy wiring and power usage. I still need to hookup the scope to see what the precise effect is of setting high intensity on the data signal, I think it may affect noise-levels.
https://user-images.githubusercontent.com/22682220/226892677-40cad893-e50f-49d9-9443-945c654343ad.mp4
Ok, now I got it work on Pico at 3.3V, but not very stable. 5V doesn't work.
Are you experiencing similar behavior as i did? (See also video below)
To test I used the TM1640 matrix example, with 16 columns and 8 rows:
#define MATRIX_NUMCOLUMNS 16
#define MATRIX_NUMROWS 8
I added a setupDisplay() calls before each test case:
module.setupDisplay(true, 1); // set low intensity
In loop() I added this call right after the first for(...):
module.setupDisplay(true, (i%7)+1); // increase intensity depending on row
In that test I saw the chip glitching after either increasing the number of rows and after increasing intensity to a certain level. When it glitched the whole display would only show a single line of pixels and some blinking. Messing with the signal wires sometimes improved the behavior a bit.
It always glitches on the same line. Interestingly removing the left matrix didn't change that behavior. Do you have any thoughts? (BTW: earlier also disabled interrupts, but that gave no improvement)
I think this needs further investigation and testing...
https://user-images.githubusercontent.com/22682220/227016506-c65abad9-3ce7-4f0d-81d0-451dd2c36358.mp4
I tried to connect two modules together by creating two instances by TM1640 module1(19, 18); TM1640 module2(15, 14);. Both works with setupDisplay(true, 1). It doesn't have something like HT16K33's configurable I2C addresses, or MAX7219's DOUT to connect multiple modules in series. Two modules took me two pairs of TX/SCK pins.
Hello, it is possible to reduce it to one extra line per module, by sharing the data line. Each additional module then has its own clock line. In the TM16xxGFX class (which requires Adafruit GFX) I implemented a provision to combine multiple displays into one larger display. See this YouTube video for a project using three combined TM1640 matrices.
To further research the TM1640 PICO stability issue, I looked at the signals using my DSO112 scope as well as a logic analyzer. Unfortunately I did not see anything special. When testing with 3mm led matrices I saw more intensive flickering, as if the internal oscillator was some how effected. Using external 5V power didn't improve this either. I added a "help wanted" tag to this issue as I don't have any further means to investigate.
FYI, with help of a friend with a better scope I again looked at the signals from the PICO at time of the glitching. Unfortunately I didn't see anything special happening. I do intend to do further testing in different environments when I find some time (such as an ESP32 to see how that behaves). For now I don't have a solution yet. To be continued...
Another round of testing the RP2040 Pico gave some interesting findings: when using a module with the smaller (3mm) LED-matrices and printed circuit board, there was no glitching. After updating to latest core (arduino-pico by @earlephilhower, release 3.8.1), the latest TM16xx release (0.6.2404) on Arduino IDE 1.8.19, there still was glitching. Looking closer showed the glitching to be constant, mainly depending on the brightness level and the number of pixel-rows switched on. Testing then with other TM1640 chips/modules, the same code didn't show any glitches. This seems indicative of power issues, perhaps only for that particular chip, meaning it might be defective. To be continued...
Edit: after more testing with the glitching module it appears that the main cause is iffy breadboard connections.