64×32 bicolor 5mm LED Matrix with Arduino
Arduino Interface to Sureelectronic’s 6432 Dot Matrix 5mm Red LED Display Information Board.
Download PDE:
Arduino Interface to Sureelectronic’s 6432 Dot Matrix 5mm Red LED Display Information Board.
Download PDE:
February 16th, 2010 at 10:13
This looks cool! I just got my 6432 board & I’m gonna give this a try!
-Andy
March 8th, 2010 at 16:49
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!
March 8th, 2010 at 20:19
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.
March 10th, 2010 at 15:30
I have the 3mm panel.
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
I’ll swap it around and check.
-Andy
March 15th, 2010 at 17:17
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?
March 16th, 2010 at 00:28
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?
March 17th, 2010 at 14:18
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
March 17th, 2010 at 14:22
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….
March 22nd, 2010 at 16:51
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…
May 5th, 2010 at 14:41
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
June 8th, 2010 at 07:46
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…
June 21st, 2010 at 08:20
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.
July 30th, 2010 at 10:19
…
It’s a good stage!…