My typical projects for micros have more outputs than pins that do not need to respond all that fast, like milliseconds. I use 74HC595s. My company buys them in 100s at $0.17 USD each.
The '595 has a serial input, a serial output, 8 parallel outputs and some control pins. I believe each output could drive one typical LED, especially if you don't have to be sure the output voltage stays in the logic range.
I'm trying to control hundreds of LEDs from my parallel port (8 data pins - will soon be replaced with the output of a programmed PIC, also 8 pins).
I'm not an electronics guy (I'm a software developer), so trying to control x00's of LEDs from 8 pins looks a bit tricky...
There's no way to change them all at the same time, so I reckon I'll need some sort of "addressing" system. Using some of the pins to select which LED I'm controlling, and one for the data.
Trouble is, even using 7 bits as the "address", I've only got 128 channels, but I imagine I'd need a bit for "send" too, so I can set the address and the data, then have it read in one go.
What are my options? And what components would I need to achieve something like this (I imagine right down at the end, I'll need a number of registers for the LEDs. If these come in chips with 8 output legs, I guess I'll need 38 for 300 LEDs. The bit between my 8 data pins and the computer isn't my area though, so I'm stuck!
Oh, and this is just a hobby thing, so the cheaper the better. I'm sure I can already buy scrolling screens, but I don't have the money, and I want the fun of building one! :)
Hi, Danny. Look up the datasheet for the 74HC595. You can control as many LEDs as you want by shifting data out serially, limited only by how fast you can shift. You'll only need three pins (use Data In, CLK and Latch) and have the Data Out of the first chain to the Data In of the second, and so on. CLK and Latch drive all the '595s. Just shift out all the data you want, clock after every bit is asserted, then toggle the latch after you're done to set all the data at all the outputs. Easy. One IC for every 8 LEDs (which can be driven directly, source or sink, with only one series resistor per LED). 38
16-pin ICs for 300 LEDs.
Note that, if you're going over extended distances, you'll want to buffer the signals to achieve sharp transistions. The '595 doesn't behave well with slow logic edges. And watch for noise -- that can mess up your data.
You'll have no problem transferring from a printer port to a PIC.
If system speed is a consideration, you might want to look into latching data and multiplexing control of the LEDs. But for "real time" control, the '595 is the easiest way from the hobbyist perspective.
By the way, you might want to look at Jan Axelson's "Printer Port Complete" for an explanation of how to do this, as well as the website:
There's a lot of good stuff there.
Hobbyist questions of this type usually get a better reception at sci.electronics.basics.
You could use a bunch of series wired 8 bit shift registers, that allows one data bit, one clock bit, and some control bits to run the whole show. Some of these have a shift register and an output register, so you could change all the LEDs at once. If you don't require maximum brightness, and you could find a shift register in the 40xx or 45xx series logic parts you could get by without needing a series resistor to limit current for each LED. The 74hc or 74hct series parts have about 20 ma. of current output so you would need a resistor for each led to limit current. An easy way to add the resistors would be to use a resistor pack, the kind that have a common on pin one work well.
Another way if your up for it, is to use a Large IC that has a JTAG test port and then send your data to the shift registers built into these chips for testing. I did this a few year ago using an unprogrammed Xilinx CPLD as a shift register. This is a bit tricky but is a good introduction to using these test ports.
Unless very high brightness is needed anyone designing for this requirement would arrange the LEDs in a matrix, typically 8 rows and in your case about
The rows are driven from the top probably with P channel MOSFETS and the columns driven from the bottom with a latched shift register. Others suggested the 74HC595, there are better chips if you can obtain them such as Allegro A6276ELW or ST STP16CL596 which are 16 bits and have high power constant current LED drive outputs.
You need 6 or 7 control lines.
data, clock, and latch strobe for the column drive.
3 lines to select which row is driven optionally another line to disable all columns or all rows which can be used to control brightness and can ease timing requirements on switching row drives.
You do have to multiplex the display in real time (typically 2ms per row) which isn't hard for a PIC, software on a PC will likely be a bit jittery.
So for a 348 LED display you need 3 A6276ELW chips, 8 suitable P channel MOSFETS, something like a 74HC4051 to drive them and a (big if you want bright) 5v power supply.
It looks like you are in the UK, you can get the Allegro parts from
about L3.50 each. They also do RDF15P05 MOSFETs which might be suitable for driving the rows.
Someone in sci.electronics.basics suggested 74HCT259. Looking at them both (I'm not that familiar with geek-speak in datasheets!), is the main difference that one uses 3 bits for addressing, while the other increments the bit I'm modifying using a single pin?
But to control 38, I'll need another 5, right? So my parallel port controls 5, which control the 38, attached to the LEDs?
I don't understand what you mean by "One IC for every 8 LEDs (which can be driven directly, source or sink, with only one series resistor per LED)"
Directly, source or sink?
As for resistors, I'm currently running the LEDs directly from 5V on my parallel port. Would the chip not output a similar voltage, and hook up straight to the LED?
While Googling earlier, I found lots of references to "demultiplexing", but couldn't figure out what on earth it was. The context seems to suggest it might help, but even google didn't link to dictionary.com for it :-(
Yeah, I posted there too, unsure exactly which was best. Had good answers from both. Thanks :)
The last few characters usually specify the package, so be careful to check this. Each manufacturer has a different package code.
Regarding your original problem of controlling LEDs:
There's a whole lot of issues to consider:
You say that eventually a PIC will control the LEDs. If the software of the PIC has some spare time and RAM, it is possible to use a multiplexed driving scheme. This saves hardware, but uses the PIC to cycle through the rows at regular intervals. This may be easy to do with a PIC but hard with the parallel port of a PC. This is a good solution if hardware cost is the paramount issue.
If the compatibility between parallel port and PIC is the overriding issue, then you will probably prefer static drive. This needs no software interaction as long as the LED display doesn't change. It is somewhat more expensive on the hardware side, however.
I take it that if you say you've got 8 bits worth of data port you also have got some control lines, like strobe and busy lines on the PC's printer port. If the 8 data bits is ALL you've got, things are different.
Many PICs also have a built-in serial port (SPI compatible), which is very handy when talking to shift register chips like the 74HC595. The PC parallel port doesn't have this, so again this raises the question how compatible you need to be.
In the case of static drive (as opposed to multiplexing) you also need to know whether you want to be able to change a single LED or whether you are prepared to output the complete status for all LEDs each time anything changes.
If you accept to output the complete data for all LEDS each time something (or everything) changes, you may consider shifting out the data bytewise. You need 2 control signals in addition to your 8 data signals. On the PC parallel port this could be STROBE and (for example) INIT. With STROBE you'd clock out bytes, and with INIT, you'd latch the bytes shifted out into the output register (of a 74HC595 or 74HC4094). You would use 8 shift register chips in parallel, each being connected to one of your data outputs. This gives you 64 outputs (for LEDs), and you can expand this in increments of 64 by making the shift registers longer, ad infinitum.
A more PIC-specific solution would be to string the shift registers up in serial fashion rather than 8-bit wide fashion. This would save PIC pins, but is only useful if the PIC has a built-in SPI port.
If you prefer changing individual LEDS without affecting any other, you may be better off with the addressable latch method (using 74HC259 chips). You have already noticed that you need 7 bits for addressing 128 LEDs, plus one data line that controls whether the LED is set on or off. You also need a strobe signal for timing. Again, using the 8-bit parallel port for addressing, and one control signal each for strobe and data, you could address 256 LEDs. This could be done with 32 chips of type 74HC259 and 4 chips of type 74HC138, plus an inverter.
The hardware cost between those two methods is pretty similar, but they are radically different regarding the way they are driven by the software. The multiplexing method is different again and cheaper in hardware. Make sure you understand the impact on software before you make a decision.
Yes. Driving 384 LEDs requires 4 chips and 8 3 pin transistors (MOSFETS) instead of 48 chips and 384 resistors. Depending on how you want to physically arrange the LEDs it can reduce the required wiring by a factor of 8 also.
Search the web for LED, matrix, and multiplex. You should something that gives you the idea.
There was a seperate column for package (I think I want DIP - it's going into a breadboard for now!), so I'll just go with the cheap ones for now (I'm sure I'll blow a few up ;o))
Compatibility with the Parallel port isn't important, it's just my current test bed. My PIC programmer should arrive this week, so as long as it works, although tedio swapping the chip between programmer and breadboard, that would do me fine. The chips I've got coming with it are
PIC16F627 and PIC12F629
Multiplexing keeps cropping up. Is this sending data serially, and using timing (or another bit) to denote the changes? If so, does this my chip would send multiple signal across single pins, and another chip would de-code these into more signals? Is there a limit to the number of singals I can send in serial?
As for controlling invidiual LEDs, it'd be nice for testing, but I don't think it's important - as long as it's not too slow to draw the whole board, I can live with that (animations etc. would either involve most frames being different, or some processing to decide which have changed, which'll probably slow things down anyway).
The hardware costs aren't *too* important, it's just gotta be easy and educational! I'll make a list of all the different methods being suggested, and make an informed (!) decision :)
Ok, I think multiplexing really is the way to go for what you want to achieve. It is also quite an interesting educational project.
The PIC16F627 has a USART port, but no SPI compatible port. In its synchronous mode it can be used to drive shift registers, but I guess you would rather like to use this port for a connection to a PC (using RS-232) for controlling purposes. The PIC12F629 lacks even this, so you would have to do everything by wiggling the port pins with software. The PIC12F629 is also a bit low on SRAM, this will limit the number of LEDs you can control (you need to store their current state somewhere).
In multiplexing, only one row of LEDs out of (say) 8 rows will be active at any time and the PIC needs to step through the rows quickly enough for the eye to perceive a steady state. Aim for cycling through all rows within 12ms or faster.
As the LEDs are on at most 1/8th of the time, they need to be operated with higher currents than normal, so that the perceived brightness averages out to normal. Standard LEDs usually can take 60mA pulse current easily, some are specified much higher. With an 8 row multiplexing scheme your pulse currents needn't be too high, and you can use standard LEDs and standard small signal transistors as column drivers.
For example, the column drivers could be standard supercheap NPN transistors like the 2N3904, the row drivers would be higher power PNP transistors, as they need to drive the current for an entire row of LEDs.
Let's say for example you want to drive 512 LEDs. That's a 64 x 8 matrix. You need 64 NPN transistors, 64 current limiting resistors, and
8 PNP transistors. When you operate at 60mA pulse current per LED, a row will consume a maximum of 64 * 60mA = 3840mA. The PNP transistors will thus need to be rated for 4A, keeping in mind that each will only be on
1/8th of the time. Something like a BD434 would be called for, but try to get a transistor with better hfe if possible.
A fully illuminated matrix will draw 4A of current, so make sure that your power supply is up for that.
In order to control these driver transistors, you can use ordinary 74HC type logic chips. Use eight 74HC595 or 74HC4094 shift register chips for controlling the column drivers and one 74HC138 for controlling the row drivers. Use series resistors to limit the base current for the transistors, but drive the base of the row transistors as hard as the
The 74HC138 is controlled from the PIC, using port pins. More port pins are used to shift the data into the column drivers. You can select whether you want to string them together serially, using only one data port pin on the PIC or whether you feed the data into each shift register in parallel, using 8 port pins for the data lines. Clock and control lines are common for all shift registers. The former is ideally suited to using the USART port, the second uses more port pins on the PIC, but is faster to drive with software.