32x16 or 32x32 RGB LED Matrix - Where to start?

[tdg8934]

I am brand new to this forum as I did a search on Google the other day to start getting back into designing with LED displays again. Heres some of my background:

I have been out of the microcontroller world for about a year or so due to a job loss and moving and re-establishing myself again as a Test Engineer (Electrical Engineering degree). I started out about 7-8 years ago with the Parallax BASIC stamp and have been using Parallax SX-28/48 microcontrollers for many years in SX/B (Basic) especially working with many different LED displays primarily from Sure Electronics and some other outdoor display modules I got from China (both mono color and RGB) to hack into. I even designed my own PCB RGB controller board based of of the HT1632C chip and many other bi/tri colored LED displays. I wrote an article in Nuts and Volts magazine in Jan 2009 for a tri-color 16x16 LED clock interfaced to the Parallax SX-52. Since the Parallax SX chip line went end of the line, I started a year or so back with an Arduino Duemilanove to use what Arduino code was available online. I'm not a good "C" programmer (more BASIC oriented) but can understand alot of it through my 2+ years of study of AVRs and I even had a Teensy++ 2.0 to control a large custom built 8 board (32x16 RG - Sure Electronics) with a large custom case made for it. I have worked with almost ever LED matrix display out there but it's been a while.

Since Im working now and during the my move to Ohio, ALL of my displays, electronics, etc. was lost or thrown away so I am starting over fresh again. Working with LED displays has always been a passion of mine but Sure Electronics and a couple of other ones (SparkFun) seemed to be all that was available. Most have no PWM in the controller portion of the LED displays so pickings are not good. However, as stated earlier, I did a Google search and saw both of the Adafruit 16x32 and 32x32 displays and they are great looking (but pretty pricey). Even as such, I would like to start with one of them. I have used microcontrollers for many years and after reading that these displays are really suited for FPGA's, I thought perhaps I should go down that road and start with something new. Although I understand it will be very difficult and don't know what kind of support there is in the FPGA world in LED matrix's. I'm going back and forth with just staying with the Arduino 2650 MEGA or the UNO. I don't want to invest a lot into this to find out that I should have invested into a microcontroller like the Arduino or other one OR with an FPGA which I have no background experience with at all. The remarks in the Tutorial for the 16x32 / 32x32 are really PRO FPGA but which one to buy. They say the Arduino UNO has limited memory but I haven't seen anything on using it with the Arduino 2650 MEGA yet. Comments or suggestions please on where to start / what to buy.

Thanks again! Tim (tdg8934)

[adafruit_support_bill]

Hi Tim,

If you want to ease into it, we have tutorials for getting these up and running with an Arduino. They don't run super fast on an Arduino, but they do run. This would be a good and relatively inexpensive way to get familiar with the display.

We don't have any tutorials for running them with FPGAs, but the community here is pretty helpful and may be able to share some tips and/or sources.

[tdg8934]

Thanks for the Uno support information. What about support for the Mega 2560, Propeller or other high speed controller device? Has anyone developed for anything faster and willing to share their code and findings? I ultimately would like to add a few of these displays together and need to start probably with the Arduino Uno first to learn the display BUT really want to move on to something like an easy to learn very fast FPGA or preferably very fast micro-controller. Is anything available yet to support this inevitable high speed requirement? Trust me I have been using displays for years now with a couple of microcontrollers and have long seen the need for a very fast, higher memory microcontroller, FPGA, etc that is not going to take a year to learn or get fustrated and give up. Anything out there?

Thanks again for everyone's support and help on this.

[adafruit_support_bill]

WIring instructions for use with the Mega are in progress and should be up shortly. I don't know if anyone has taken a crack at getting it running with the Cyclone yet.

[adafruit]

mega is supported for the 16x32 at least - pburgess can chime in about it. we think there's even instructions up on how to wire it (its pretty simple)
there is a propeller driver for the 16x32 display as well that supports chained drivers. it can be adapted to 32x32. check the parallax forums for the thread

[pburgess]

I've not tried with the Mega yet, but another user in the forums got it working...some of the pins need to be shuffled around a bit.

The Mega won't gain you anything in terms of speed or bit depth, but does have more RAM for stuff like double-buffered animation on the 32x32 matrix.

[tdg8934]

Thanks for everyones comments. I'm more familiar with the Arduino than I am with the Propeller and SPIN language but it looks like the Propeller and/or other faster processing devices (FPGA's, etc.) will be the best alternative for me even though it means spending the time learning a new language again. I still may get an Uno or Mega 2560 when I buy the 32x16 or 32x32 RGB LED display but just don't want to spend if there is no beneficial value to me (although the code learning on the Arduino may make it a quicker start for me). Still not 100% sure what the best answer is and want to see what Ray or others from the Parallax forum writes back on.

http://forums.parallax.com/showthread.p ... ost1072077

[Andrewsi]

I built a smaller panel myself last year in a 24x8 configuration with a Propeller. I had a single shift chain driving the whole thing, including the row select, so the chain was 12 '595's long, and while I was ultimately able to get 60hz with about 6-bit PWM, even in a highly optimized form it was pretty hard to shove that many bits over a single serial wire and get to a good frame rate with a chain that long. I realized in hindsight that if I'd taken advantage of a few more GPIOs and, say, split the R/G/B lines into independent shift chains the throughput would have gone up dramatically.

I just ordered a 32x16 late last week and am currently working on a Spartan-6 FPGA design (using a Digilent Nexys-3 development board.) It's quite clear that this thing will blow the propeller out of the water based on some early simulations in terms of the PWM and output capabilities. Being able to read the frame buffer 256 bits at a time and process the PWM calculation on each pixel in the line in parallel is a lot of fun after doing it on the Prop the hard way. I'd be willing to post the Verilog once I get it all working.

Initially I'm just going to have my Propeller app (which does lots of buffer composition, color fades, etc.) just pass buffers to the FPGA which will then handle the fast PWM and shifting out to the 16x32, but eventually I'll probably add a picoblaze core to the thing and move the message composition and color fading logic to the FPGA as well.

Cheers!
Andy

[tdg8934]

Andy,

I started going through the Altera online FPGA training and VHDL programming. It's a lot to take in with a different perspective from my background in microcontrollers. I think I will take a step back and go with the Propeller to learn that with SPIN and Assembler before I jump and invest too much into FPGA's. Where did you get trained or others get training on FPGA's? Once I get familiar with the Propeller language(s) I will start looking into FPGA's later in the year. Why did you choose the Spartan vs another FPGA? Just currious about the learning aspect.

Thanks,

Tim

[Andrewsi]

The propeller is a great chip and the IDE for it is well done. The language is not hard to learn but the chip itself requires a little advanced understanding to make the most of. Having 8 cores to divide among tasks is fantastic but learning to synchronize these in software is, frankly, more complicated than writing an interrupt handler. With power comes responsibility. Spin is also a little slow due to being interpreted. The perf critical stuff really needs to be done in assembly which is way faster but yet another challenge- but fun. There's a great debugger for pasm from the community.

As for the Spartan6, I am actually doing some eval work with it at work using Labview, but U wanted to learn how to use it "raw" with Verilog for hobbyist fun. We didn't have these when I was in school and I saw it as an opportunity to update my skills. In the last couple weeks I've taught myself a fair amount of Verilog entirely from online articles and the coding examples in the Xilinx ISE.

As of last night I have the fpga successfully driving the 16x32 from an RGB frame buffer.
The max clock rate the panel seems to accept is surprisingly low though. Above about 8mhz, the panel no longer seems to respond. I need to put a scope on it and see whether maybe the inputs need some termination or perhaps 3.3-5v level shifters. The input looks like a Chinese hc545 latch and it may not be happy with the 3.3v fpga outputs.

Andy

[tdg8934]

Andy,

Thanks for the encouragement with the Propellor and FPGA. My Propellor Platform should arrive today or tomorrow (Gangster gadget had a 20% off sale, audio/video sheild and a 7.5vdc power supply - which unfortunately Adafruit was out of the 9vdc power supplies for the moment). I did order from Adafruit the 32x16 RGB display, hookup wires, 1/2 breadboard and 5v 10A power supply. I was going to get an Arduino also but Adafruit was out of them also. I'm on the email list for when they will be in stock. I was also highly thinking of ordering from Adafruit their DE0-Nano FPGA http://www.adafruit.com/category/products/451 to see if this would work with the RGB Display once I learn VHDL or Verilog and can write code for it.

However, I think with the Propeller comming this will keep me busy for a while learning SPIN and how the COGs work together.

Thanks again,

Tim

[Sunbuzz]

As of last night I have the fpga successfully driving the 16x32 from an RGB frame buffer.
The max clock rate the panel seems to accept is surprisingly low though. Above about 8mhz, the panel no longer seems to respond. I need to put a scope on it and see whether maybe the inputs need some termination or perhaps 3.3-5v level shifters. The input looks like a Chinese hc545 latch and it may not be happy with the 3.3v fpga outputs.

Andy,

I am very interested in what you find out. Don't forget to post your results.

[Andrewsi]

Turns out I had miscalculated the rate at which I was driving the latch based on an error in my Verilog simulation code. As it turns out it runs fine at 25Mhz but fails at 30Mhz, which are much more sane numbers, particularly given the lengthy leads and no termination. So with 10-bit PWM I can get just shy of 90hz on this panel, but for every additional bit that you increase the PWM cycle you chop the max frame rate in half, assuming you drive the serial line as fast as possible shy of failure. I'll see if I can get higher rates once I shorten up the lines.

I spent last night hooking up my first Picoblaze embedded proc in the Spartan 6 to the Verilog I've already got written, and got it to drive some simple output to the frame buffer, so now it's going to be more of an exercise in Picoblaze software assembly more than additional Verilog, I think - traditional software makes a heck of a lot more sense than a pile of complicated state machines for tasks like frame buffer composition.

Once it actually does something interesting I'll be happy to post some results.

[Sunbuzz]

That is very interesting, I just wrote support for this panel on a chipKIT uno32 (80Mhz PIC32), and I had the same issue with the frequency.

If I clocked it as fast as I could (4 instructions on the PIC) the first column of the panel flickered and was acting up (should be approx 20Mhz)
so I had to put a "NOP" in there, lowering it to ~16Mhz where worked fine.

Code: Select all

    lbu  $t3,0($a0)
    sh   $t4,LATDCLR      // CLK HIGH
    sb   $t3,LATE
    nop
    sh   $t4,LATDSET      // CLK LOW
    lbu  $t3,1($a0)
    sh   $t4,LATDCLR      // CLK HIGH
    sb   $t3,LATE
    nop
    sh   $t4,LATDSET      // CLK LOW
    ... and so on


So I have 8 bit BCM running the panel at 200Hz with plenty of CPU to spare, and it looks great, the FPGA will have to wait until I need drive a couple of these... not there yet, the chipKIT can handle 2 or 3 for sure.

[Andrewsi]

What's the LATE instruction in between your clck high and low instructions do? I'm trying to think what could cause just the first column to flicker but not the rest if you're writing a whole row at a time before latching them in. Datasheets for typical shift registers like a 545 typically show a certain minimum time required between clocking in the last serial bit and raising the latch enable...just a random thought.