One can use a low-cost uC for each 8x8 tile and use a multi-drop bus to control an array of these 8x8 tiles. (For example, it takes 80x60=4800 of these tiles to build a 640x480 CGA).LED Matrix - Tri Color - Large
SKU#: Comp-MTX-Tri
Price: $29.95
Description: Triple Color LED Matrix! This large matrix has 64 Ultra Bright-Red, 64 Ultra Bright-Green, and 64 Ultra Bright-Blue individual LEDs built into one common cathode housing. It’s a monster to control, but just imagine what kind of colors you could produce by mixing!
These are the new, readily available units that just arrived. Unit comes with a black finish and a opaque LED lenses.
Documents: Triple Color LED Matrix Datasheet
Dimensions: 0.33x2.38x2.38"
uh, 4800 x $30 wouldn’t exactly be cost effective. Hell, at $1 each, it would be friggin expensive. Plus, you’d basically have to build a video controller. very complex. I think even a very expensive micro would be nothing relative to the cost of the LED array.
The display would be nearly 20 feet (diagonal)! For the sake of fun numbers, if every LED element (3 per grid position) had a 150 ohm current limiting resistor, the supply was 5V, and each LED element required 20mA (assuming same voltage drop for all colors), you would end up needing a power supply that could deliver 18,432 amps and the current limiting resistors would dissipate a total of 55 kilowatts when displaying a white picture at full brigtness!
-Bill
More fun numbers! I don’t want 640x480, I want 1920x1200 which is slightly better than HDTV and is a computer monitor standard!
The screen would be 56’ corner to corner and assuming the same conditions as my previous example, it would require a 5V supply that would deliver 138,200 amps and the current limiting resistors would dissipate 414.7 kilowatts! :shock:
PWM might be needed for a solution this large! :lol:
-Bill
but other than that, it’s a great idea…
Speaking of which, does anyone know of some good sample code for simultaneously PWM controlling multiple channels of PWM on a PIC while also monitoring a bus for control information without affecting the PWM rate? I’m thinking at least 8 PWM channels for the LED matrix, for example.
There are a few ways to do it but I don’t have any code samples available at the moment.
First and foremost you will have to make your PWM code take up as little processing time as possible. If your PIC has them, make use of all the hardware PWMs first. Motor control PWM hardware in some PICs can have 4 separate PWM channels. Then make sure all of your code is interrupt driven to ensure no one function blocks critical communication or PWM generation code.
After that you will need to set up a timer to overflow at a specific interval which will be some fraction of your overall PWM period. You then need a variable to store the number of timer overflows (counts) there are in a PWM period, a variable to keep track of the number of counts that have occured, and a variable to keep track of the duty cycle for each pin you wish to control.
A quick for instance, if you have a 1 second PWM period and you need 25% duty cycle resolution, you would set your timer to interrupt every 0.25 seconds (25% of 1 second). Since there are 4 interrupts (counts) to a complete PWM_period, you would set your PWM_period variable to 4. Now say you want 2 outputs, one with 25% duty cycle and the other with 75%. You would make new variables dutycycle1 = 1 and dutycycle2 = 3.
Initialize a counter variable to zero and increment it every time your timer interrupts. Every time your counter matches PWM_period, reset the counter to 0.
Here is a quick runthrough of what would happen:
- increment counter
counter = 1
dutycycle1 matches counter - set output1 = low
- increment counter
counter = 2
no match so do nothing
- increment counter
counter = 3
dutycycle2 matches counter - set output2 = low
- increment counter
counter = 4
counter equals PWM_period so reset counter to 0 and set output1 = high and output 2 = high
That is just one way to implement your code. By adding more duty cycle variables, you can generate PWM on any number of pins. It is up to you to determine the period and resolution that you need. The shorter the period, the finer your resolution, and the more outputs you control, the more processor time it will require.
I hope this made sense. It was clear in my head but I fear it isn’t clear enough on paper!
-Bill
phalanx:
More fun numbers! I don’t want 640x480, I want 1920x1200 which is slightly better than HDTV and is a computer monitor standard!The screen would be 56’ corner to corner and assuming the same conditions as my previous example, it would require a 5V supply that would deliver 138,200 amps and the current limiting resistors would dissipate 414.7 kilowatts! :shock:
PWM might be needed for a solution this large! :lol:
-Bill
You’re forgetting that the screen will be scanned and not all LEDs will be on at once. I bet you could get away with a 5v supply of say 65 or 70 amps. 
It would make a heck of an outdoor movie screen, though.
Each LED will have its own 8-bit DAC so you can effectively latch an analog voltage to it. None of these seizure inducing scanning and PWM techniques! My house needs heat in the winter you know! :lol:
-Bill
Would scanning a large LED field that big be able to control the color output effectivly? Maybe if you scan it using modules of triple 8-bit DACs and put a small holding capacitor across each LED pin to ground. Sounds doable if you upgrade to a Coldfire processor, interleved rows, had a large board of analog switches/demuxes, and more time and money than you know what to do with.
Sadly enough, I’ve though about doing this when the discrete tri-color LEDs came out.
Similar principles are used in LCD and Plasma screens. With LCD’s, a variable voltage is used to adjust the amount of twist in each element which controls the amount of light that goes through.
Plasma’s use PWM on individual pixels to adjust their brightness.
Since most of the screen updating is high frequency repetative loops, FPGA’s make excellent display drivers. I have given several of my projects full 1024x768 XGA support using minimal resources on this FPGA board: http://www.digilent.us/Products/Detail. … od=S3BOARD . The SPARTAN 3 FPGA can move enough data to display 60 frames per second on the Dell 30" LCD panel which has a resolution of 2560x1600 and still have enough room on board to do many more tasks in parallel. Getting data to it fast enough would be the challenge.
A coldfire processor would be good for generating data to be displayed, but the FPGA would still be needed to generate the video timing signals and to handle the frame buffer.
-Bill
I figured an FPGA would probably be better as it is customizable hardware. I’m starting to think I should get into FPGA’s for this sort of reason (oscilloscope design, display/video chip, and custom northbridge chip). Got any suggestioin to get PIC guy started with some FPGAs?
For an FPGA board, the best bang for the buck is the one I linked to in my last post. I looked everywhere trying to find inexpensive development boards and the one from Digilent was the best. In fact, Digilent manufactures the board for Xilinx which it sells as its own demonstration board.
Unless you only intend to use schematic capture, the next thing you will have to do is learn a hardware description language (HDL). The two primary languages are VHDL and Verilog. Each one offers specific advantages over the other depending on what your ultimate goal is. I learned and used VHDL in school so that is what I code in. I have been meaning to learn Verilog but I always seem to put it off. Here is some good information comparing the two HDLs: http://www.angelfire.com/in/rajesh52/verilogvhdl.html
A good resource on FPGA projects is http://www.fpga4fun.com . He mostly uses Verilog but you can get a good understanding of what it takes to use an HDL. If you Google VHDL or Verilog tutorials, you will find quite a few sites that will help you with the basics.
-Bill
Yeah, I learned VHDL in college as well. Is a development board mandatory for development? Would it be possible to get by with the software (synthesizer…etc.), programmer??, and a chip, like I can with PICs? Actually, would I need to program the FPGA, or don’t they run of a configuration FLASH chip? I probably should probably take this to that site. I’ve been there once for some info on PWM DAC’s a long while back. Thanks!
Hmm… maybe sparkfun should diversify into FPGAs and other programmable logic devices? More embedded fun!
I did a rather massive short post on FPGA’s over on the get that camera working thread.
Anyway, you’re looking at probably $10 to $50 an FPGA for what’s programmable with the free software. Most FPGAs need a configuration memory unless you plan to upload the bitstream on every powerup. That can range from a low cost serial flash (Xilinx Spartan 3E and something from Lattice I believe, dunno about Altera) to a special ISP PROM that costs half as much as the FPGA. Then there’s the power sequencing hardware and power quality hardware (yeah, you can’t just turn it on).
Programming cables also vary. $10 will probably get you a basic parallel cable that will work from a 3rd party. Otherwise you’re looking at $100 or more.
This is why I see FPGAs as being a major hassle to start testing with without a dev board. Many IO are broken out on the boards for use.
My personal favorite, Actel, is impossible to get ahold of invidiually. The ProASIC3 dev kit is about $350. It’s 3.3V flash (or is that 1.8V now?). However, there’s no power sequencing, no off-chip PROM chip. Since no one “learns” on an Actel chip, there’s no low cost programmer, either. From what I’ve heard it would be about the same cost per chip as the other chips in its density range. The power pull is significantly less, also, I think I’ve seen believeable numbers of half that of a SRAM chip.
What do you lose? It probably runs at half the speed of an equivalent SRAM FPGA. Since the flash directly configures the chip (like a CPLD), if you do a lot of dev work it will eventually wear out. It doesn’t have pre-built hardware multipliers, so you’re going to lose real estate or RAM to building hardware multipliers.
Mind you, I don’t have one to dev on, but it’s the fact that the power pull is less and the support circuitry is so significantly reduced that I’m attracted to it. The new Fusion chips are nice, too.
As an architect, I’m very intrigued by the potential of this little array and am interested in using it for prototyping architectural applications using either a Basic Stamp or [Arduino and [Processing.
What kind of extra hardware would be required to control a relatively small number of these arrays? (I’m curious to learn more about ‘low cost uCs’ and the ‘multi drop bus’ mentioned earlier by OldCow.) Any good web resources on learning more?
Again, apologies for the newbie nature of the question; any help or resources you could direct me to would be greatly appreciated.](http://www.processing.org/)](http://www.arduino.cc/en/)
basically, it’s an array of LEDs. Driving them is pretty well understood. Basically. to avoid having a pin per led, you need to share a small numberof pins with a larger number of leds. This is called multiplexing. Here is a document that describes this technique. http://engineering.dartmouth.edu/~engs0 … trices.pdf
Here’s a project driving some arrays - http://www.hanssummers.com/electronics/clocks/matrix/
note that for color, you will need to drive 3 sets of arrays. It gets a bit complex. I’d start with one color.
phil
Maxim Integrated Products just introduces some chips that drive RGB LED arrays.
See, MAX6974, MAX6975 http://pdfserv.maxim-ic.com/en/ds/MAX6974-MAX6975.pdf
Each chip can handle 8 pixels (or 16 if you time multiplex it).
I’ve been meaning to get woking with TI’s TLC5940:
http://focus.ti.com/docs/prod/folders/p … c5940.html
16 channels at 12 bits per LED, plus a 6-bit “dot correction” to handle LEDs that take different current levels for the same effective brightness, all stored in EEPROM. They are cascadable, and you control the clocking, so I think it wouldn’t be all that hard to use with a matrix.
Plus, they have DIP versions and free samples!
I bought a couple of these RGB backpack displays and have a problem with a ghosted offset image when I scroll messages across 1 or more of them. If I send more than 64 bytes it causes this oddity. Has anyone else dealt with this issue?
Thanks.