64×32 bicolor 5mm LED Matrix with Arduino
Arduino Interface to Sureelectronic’s 6432 Dot Matrix 5mm Red LED Display Information Board.
Downloads:
Arduino Interface to Sureelectronic’s 6432 Dot Matrix 5mm Red LED Display Information Board.
Downloads:
This looks cool! I just got my 6432 board & I’m gonna give this a try!
-Andy
I’m trying hard to get this working with my Mega328 based Arduino. I’ve used the same pin order as you have (PIN_A…..PIN_EN) & I’m supplying the 6432 from an external 5V supply. There is a common ground between the display & Arduino.
I’ve triple checked my wiring with a scope. I wrote a very simple pde to toggle each control line so I can see that the connections are OK & there are no shorts between wires.
I can see some of the animation on the screen but it flickers terribly. It looks like some of the red pixels are written to the wrong rows.
I got the PIC based demo board from Sure & I’ve used it to check that the display is working. The datasheet is very vague about the timing & I’m going to hook up the demo board to a logic analyser to check the relationship of the enable, clock, rows & data.
Other people on the Arduino forums have had problems with ‘Ghosting’ with this display. I wonder if there is a difference between panels..
Any clues?
-Andy
BTW The Ikea table looks cool!
Do you have the 5mm or 3mm version? In the datasheet it’s mentioned some where that they use different logic levels for some signals with that versions (or was it with bicolor and monocolor panels?).
I got rid of the ghosting when changing the enable / row select procedure found on the Arduino forum. So I don’t see any ghosting using my firmware.
I have the 3mm panel.
I’ll swap it around and check.
Datasheet says: ‘The LED of matrix board (Dia:3mm) is effective when EN=0 while it’s 1 for 5mm LED matrix board’.
I think that this means that the row of LEDs are ON when the EN is low. At least it works the other way around than the 5mm board. It’s a strong clue why I’m seeing problems
-Andy
Aha!
Inverting the state of the PIN_EN makes a big improvement. Now I get a stable display, but there is still some odd artifacts. Any pixels written to row 31 are also show at line 24 (but row 30 is not shown at row 23..) For example, I can see bottom border of the display twice. If I move the bottom border to line 30, then the problem disappears…
I’ve dumped the contents of the redBuffer over the serial port & there is no corruption of the data. So it seems that the problem is in the display refresh (& not in the calculation of the screen contents)
The problem lines are all lines where A,B,C and D signals are high.
Do you have any words of wisdom?
great!
is row 31 the only one that gets displayed twice? How did you modify the code?
As row 31 (ABCD=1111) is on the same half of the display as row 24 (ABCD = 0001) I do not see a error. maybe some wiring problem?
If you write a simple code that lights each row from 0 to 31. what is the result then? Are there also problems with the columns?
Hi,
I’ve been a bit more methodical with the checking.
> How did you modify the code?
I’ve just exchanged the commands to Enable Display & Disable Display
PORTD |= (1< To Disable
PORTD &= ~(1< To Enable
I’ve tried changing the order of the Enabling Display / Latching Data & SetRow. But it doesn’t have any effect.
> If you write a simple code that lights each row from 0 to 31. what is the result then?
I patched drawFrame() so that it just makes a single row with setRed(x,row,1). Then I’ve patched out the ball & paddle updates. The aim is to get a single red line on the display.
These rows work fine: 0,1,2,3,4,5,6,8,9,10,11,12,13,14,16,17,18,19,20,21,22,24,25,26,27,28,29,30
Writing to row 7 will light rows 7 & 15
Writing to row 15 will light 7 & 15
Writing to row 23 will light 23 & 31
Writing to row 31 will light 23 & 31
It’s the same if I use setGreen. Columns are fine
> maybe some wiring problem?¨
This was my thought as well. The problem results would be different if the ABC or D lines are swapped. I’ve written some code to drive each line independantly & checked the signals at the display with a scope… I’ll triple check this again.
It looks like the 3mm panel works a little different to the 5mm panel. I wonder if the direct port accesses can give some glitches on the ABCD lines that don’t affect your setup.
I’ve tried the other codes from the Arduino forum and get the same affect so it’s a common issue.
I’ve got a few other things to try. I’m going to drop the refresh rate radically (~1 row per second) so I can see if the problem lines are really turned on at the same time.
I’ve just received an Arduino Mega; I want to get the SD card working! The extra IOs should give me the chance to put the control signals on different ports than the data signals if needed.
I’m sure that the solution is close. I ain’t gonna give up!
-Andy
maybe you should check the led board. i had troubles with mine and on one board i even had to replace a chip… check the soldering….
I have another LED panel….and it works!
It looks like there’s a fault with the first panel. But the wierd thing is that both panels test OK with the demo board from Sure…
More progress!
It seems that I’ve been having a grounding problem! I can ‘fix’ the faulty panel when I attach a scope probe ground to the 0v connection of the panel (in the 16 pin interface).
-Andy
How heavy and how big is that panel?
Can if be controlled with a single arduino, or arduino mega (or seeeduino mega)?
How do you power the panel? With the arduino, or externally?
Thanks in advance, if you can’t tell I’m a newb…
Hi,
to check size and weight of the module please check: http://www.sureelectronics.net/goods.php?id=419
One panel can easily be connected to a Arduino and Mega of course. The panels are power via a external 5V wall plug.