Most cost-effective way of addressing thousands of bright LEDs

[NiHaoMike]

Since you only need one direction communication, couldn't you use a daisy-chained SPI-like link?

[.o:0|O|0:o.]

Maybe try having I2C regions to separate the bus capacitances. Inter-device communication is a difficult part of this too... which is why an FPGA or massively parallel MCU like the XMOS is the way to go for something like this.

I really like the idea of experimenting with FPGAs at some point, but a suitable programmer and a couple of devices seems to become really expensive... In fact if it were not for the disproportionate costs for the hardware and also the software licenses then I would chosen this route very early on. FPGAs would also make the system more compact which is always desireable.

Also, see this: doesn't seem too bad to drive a 64x64 display
http://forum.sparkfun.com/viewtopic.php?t=10960

Thanks for that link I am going through it now.

 .o:0|O|0:o.

[.o:0|O|0:o.]

Since you only need one direction communication, couldn't you use a daisy-chained SPI-like link?

If I am to base the design around multiple PICs then I would want a two way system to allow for the possibility of making full use of the parallel processing potential. It would be a secondary use of the circuit, but one I wouldn't be willing to let slip away...

 .o:0|O|0:o.

[joelby]

I really like the idea of experimenting with FPGAs at some point, but a suitable programmer and a couple of devices seems to become really expensive... In fact if it were not for the disproportionate costs for the hardware and also the software licenses then I would chosen this route very early on. FPGAs would also make the system more compact which is always desireable.

What have you been looking at? Unless you're using a high-end FPGA, the tools are free. The cheapest development boards I'm aware about are the LatticeXP2 Brevia (was on sale for $29 and may still be for a few more hours) and the Butterfly One ($49). These both come with programming cables/interfaces.

[.o:0|O|0:o.]

Thanks for those links. I wonder if I can convert that to USB without there being problems...

What have you been looking at? Unless you're using a high-end FPGA, the tools are free.

Well, I have been taking another look and just stumbled on this post concerning someone with a similar issue, but I need to learn more so I am not sure how relevant it is: http://forum.allaboutcircuits.com/showthread.php?t=13719 (post #8) Also, from what I have read it seems that FPGAs are more versatile than CPLDs, so maybe it is worth embarking on the right learning curve.

(With previous projects there was never a real need for FPGAs or other complex logic devices so I hadn't looked into them seriously; I was going by what you find listed in places like RS and Altera/ Xillinx products pages.

.o:0|O|0:o.
 

[joelby]

Thanks for those links. I wonder if I can convert that to USB without there being problems...

Sorry, convert what? The Butterfly One has a USB-serial chip, and is programmed over USB. However if you do need a hundred-odd I/Os, there are better boards that expose all of the pins (though nothing as cheap as these). Some sort of serial protocol is probably going to be better than connecting a hundred LEDs to one FPGA, though.

[.o:0|O|0:o.]

Thanks for those links. I wonder if I can convert that to USB without there being problems...

Sorry, convert what?

This is what I was referring to...

Please note that Lattice programming software does not operate with a 3rd party USB to parallel port adapter. Instead the USB ispDOWNLOAD Cable,HW-USBN-2A, should be used.

Some sort of serial protocol is probably going to be better than connecting a hundred LEDs to one FPGA, though.

You'd be surprised at the differences in opinion so far. Note that I wouldn't be connected the LEDs all at once and there would be some form of current amplification, based on transistors, perhaps Darlingtons or Sziklai pairs. I tend to agree with a previous poster that FPGAs would offer the best solution, especially if I wanted the produce in quantity in a commercial sense.

After reading that post#8 I posted above, I am interested in how FPGAs are actually programmed in-circuit. Maybe that would save me a bundle.

Off to consult a device datasheet for the time being.

.o:0|O|0:o.
PS. (I wonder how Dave is implementing his recently mentioned RGB LED design. It doesn't look like he is using FPGAs...)

[joelby]

Thanks for those links. I wonder if I can convert that to USB without there being problems...

Ah, it's pretty much guaranteed not to work with a cheap USB-parallel adaptor. You'd need to get the official USB cable, which costs $149 (!). If you're just experimenting, you probably want to investigate cheaper options. The official Xilinx USB cable is also expensive (~$90?) but the board I linked to before has an on-board USB interface.

After reading that post#8 I posted above, I am interested in how FPGAs are actually programmed in-circuit. Maybe that would save me a bundle.

Generally it's done through a JTAG interface. While JTAG is a standard, what happens at the PC end of a JTAG cable is not. Many development boards cut costs by implementing a proprietary USB protocol with a custom (typically) Windows application that uploads bitstreams to the FPGA or flash.

[.o:0|O|0:o.]

An intro to FPGAs and CPLDs:
http://www.instructables.com/id/A-Beginners-Guide-to-Programmable-Logic-Devices/

According to http://www.mouldy.org/using-cplds-and-fpgas-in-hobby-electronics

JTAG is the usual interface used to program a PLD (although many other options exist). You need a JTAG cable to link the FPGA and your computer. Usually, these would come as part of a development kit, with the associated 'development kit tax' which made it infeasibly expensive for hobbyists.

Now, more options are available; many devices can use SPI or I2C for programming, and free interfaces are available for that. If you want to stick with JTAG, you can build an 'official' Xilinx design, or a cheap and nasty cable. You use your free design software to program the devices over JTAG.

http://www.xilinx.com/itp/3_1i/data/common/jtg/dppb/appb.htm

Another circuit I found:
http://www.fpga-faq.com/FAQ_Pages/0036_Config_FPGA_with_PIC_and_Cheap_SEPROM.htm
http://www.fpga-faq.com/Images/piccfg.pdf

Hmm:
http://www.instructables.com/id/Ghetto-Programmable-Logic-CPLD-Development-Syste/

This looks cheap if it can be adapted for my purposes:
http://uk.farnell.com/jsp/search/results.jsp?N=0
Ns=PRICE_PLS_006_PRICE1|0&Ntk=gensearch_001&Ntt=Xilinx+Coolrunner&Ntx=mode+matchallpartial
http://www.farnell.com/datasheets/84321.pdf
http://www.xilinx.com/support/documentation/data_sheets/ds094.pdf

.o:0|O|0:o.

[nyo]

Have a look at the ht1632 (google it), it can drive 256 leds with one chip

[slburris]

Another way to go with this is to use CAT4016 chips, basically a shift register
with constant current outputs, 16 outputs per chip:

http://www.onsemi.com/PowerSolutions/product.do?id=CAT4016W-T1

Form one or more serial chains building modules with these chips and drive
them up to 25 Mhz.  With a large enough micro, you could drive, say, 16
serial chains at a time, by outputting bytes to two ports and toggling a
clock line.

Or for I2C fans, there's the SAA1064 which can do some light multiplexing:

http://www.nxp.com/#/pip/pip=[pip=SAA1064_CNV]|pp=[t=pip,i=SAA1064_CNV]

But really I'd do this with an FPGA and memory driving the serial chains
and have the micro just update the memory.  You could easily do flashing and
fading effects as well with this.

Personally, I've moved away from multiplexing entirely.  Too many issues
of insuring your micro doesn't stop and then burn out the LEDs and you
have nasty current spikes and associated noise to deal with.  I just drop a
constant current driver near each display (or group of LEDs) and address
them serially and be done with it.  Quite failsafe and program bugs just give
you incorrect displays.  And you don't have to start switching with MOSFETs
or other such things.  Plus the current drivers really help with brightness
matching (more important for 7 segment displays).

My 2 cents.

Scott

[.o:0|O|0:o.]

Thanks for those links. I will likely compare several of the LED driving solutions offered so far, once I get the control/logic side off the ground. Then hopefully I will be able to post some feedback on the results and any other useful information I might come across.........

But really I'd do this with an FPGA and memory driving the serial chains
and have the micro just update the memory.  You could easily do flashing and
fading effects as well with this.

I think that as far as the control/logic side is concerned, for a design of this type with the constraints mentioned, there are only two good (reliable and financially sound) ways of moving forward:

1) Using multiple pics communicating in a master-slaves arrangement with I2C (which seems made for this). This approach makes the design modular and scalable and there are other perks like being able to experiment with parallel processing.
 
2) Then there is the proper way, using CPLDs or FPGAs, which is how you would go if you wanted to mass produce and market the design (though I have no such plans for that). Considering the cost of the equipment and the costly devices, in my case this is probably not much cheaper than solution (1); however, it drammatically reduces the area of PCB required and probably saves on the power consumption before the drive/LED stage.

So I have two possible ways to proceed (all the other methods being less than satisfactory for this particular design)...

I will attempt the design around the FPGA or CPLD and if the technology proves to be inaccessible in terms of cost of equipment or the associated learning curve, then I will be able to fall back on the other solution which is comparably straightforward.

Many thanks to anyone who has helped on this thread. I will share any successes and if anyone has any good FPGA/CPLD advice it would be really welcome.

Regards,

.o:0|O|0:o.