Poor mans LED controller?

[ids]

I was just wondering if it would be possible to wire up the poor mans LED controller using the parallel port, some flip-flops, and a demultiplexer.  Diagram attached shows my haphazard attempt at a 64 port controller.  LED's would need a common ground capable of supporting the current levels (typ 20mA, times 64, plus a bit for the components involved....say 1.3A max total).

I've put the parts (chips and socket) into Mouser, and I'm up to about $8.30.  If you solder chips direct (no sockets) you can save a fair bit of that, chips alone are $2.38.  You'd need a protoboard or something to connect it all up, and of course solder, wire, etc.

I'm no expert on using the parallel port, so maybe this would not work.  I think the power side is fine, as we are buffering via the flip-flops.  My biggest question is on using the IN/OUT control pins of the port (labeled C0-C3 in the diagram).  If we have total arbitrary control over at least 3 of those, I think we're good to go.  There are alternatives to this if those control lines become an issue - this is just the easiest imho.  And, iirc, mamehooker supports parallel port stuff - maybe such support could be added to other software as well.  

This simple circuit does NOT have the more interesting effects; fade, PWM, etc.

I'd appreciate it if someone with more knowledge could validate or reject this.  I'd be happy to wire up a prototype if someone confirms it should work.  Note also, the D( is the data-bus from the parallel port.

Thanks

[SavannahLion]

I just did the math for my circuit and figuring this stuff out so I may be wrong so.....

You're not going to be able to operate all 64 LEDs at once. Checking the first through hole componet 74hc574 at Digi, the specs state a max output of 35mA per pin with a total of 70mA for the entire chip. Best case would be a dim glow on the LEDs worst case would be a fried IC. That would be my guess anyways.

You'll need high and/or low side drivers to drive that much current and/or strobe the LED rapidly enough to maintain the illusion they're on bit still stay below the maximum draw specs.

I just got the first shipment of my own chips and haven't tested my math on that yet.

[MonMotha]

You do generally have essentially full control over the PC parallel port.  You'll run into some issues with Windows trying to fiddle with it upon startup looking for "Plug and Play" EPP/ECP devices, but you can jam it back into SPP mode and have your way with it pretty easily.  You'll probably end up with some weird initial states on your LEDs until you run your control software.

I would wire up the 4th control output to one of the enables on the 238.  Relying on the 238 to change all of its outputs simultaneously is not wise, especially since you can't necessarily rely on the parallel port to change all 3 select lines at the same time.  This could result in inadvertent clocking of some of your output flip flops.  Instead, disable the 238, change the select inputs, then enable the 238 to clock the register of choice.  You'll need pull-downs on all the outputs of the 238 to ensure they end up where you want them and don't clock things inadvertently when the 283 is disabled.

You might also consider a 573 type transparent latch rather than the 574 edge triggered flip flop.  That would allow you to continuously update one (pre-selected) register without having to fiddle with the handshaking lines to constantly clock the new data into it.

Don't be so quick to dismiss power ratings on those flip flops.  20mA is about the maximum you'll be able to get out of each output.  That's fine, but it's only 1 good bright LED or maybe a couple dimmer ones.  You can also only drive 5V loads, so no 12V LEDs with integral resistors.  There's also a per-chip limit that you'll easily exceed if you have more than a few outputs on at once.  Look at something like a ULN2803 to get around this.

It would also be somewhat typical to put the load switch on the low side rather than the high side you describe.  It doesn't really make much of a difference with CMOS devices, but LSTTL devices can sink more than they can source.  See again the ULN2803 (which would always be a low side switch).

You MAY run into some problems with logic levels.  Many parallel ports these days are 3.3V, not 5V.  Using HCT series ("TTL compatible inputs") devices should solve this.  You could also just use LS series devices, but see above.

[SavannahLion]

Oh, am I misunderstanding the schematic? Is he using eight *574 there? I wondered why he saw the need for a demultiplexer.... Nevermind my post then, Monmotha's, as always, is better.

[ids]

Yes, sorry, a bit sloppy in the original post, lots left unsaid.  There should be 8 of the *574's in there.

Thanks for the feedback.  Fwiw, I do have 2 LEDWiz's, and don't need something like this.  It just seemed like a decent challenge.  One more project to add to the list. 

MonMotha - thank you very much for having a look.  Disabling the 238 as suggested is absolutely required and illustrates a big gap in my thinking there.  Thanks for that one.  Same for the pull-ups - I should have known that one  (or not, still a newb at this electronics stuff).

The ULN's, if I understand what you are saying, would be one to one with the 574's, basically giving the 574 outputs more umph!  (putting it simply) That certainly adds a great deal of flexibility, but construction becomes more effort.  Costs not hugely impacted, but labour is.  Now, if we replace the 574's with ULN2803, we'd need the driver software to constanty cycle to refresh the LED's....so, if I understand correctly, this may not be what you are suggesting.

Driving 5V load...yeah, another big assumption I made there.  Hey, this is the poor mans LED controller thread isn't it?  I will humbly submit that there are many other options, such as the ULN you mention (this is quickly getting beyond my abilities to comprehend).

Is there a replacement for the 574 (inverted or otherwise) that could easily handle 8 LED's (e.g. 20mA * 8 )?  I have been hitting up Digikey and Mouser a great deal but...may not have quite the expertise in this area.

As for additional features, such as dimming, that would obviously have to become part of any driving software.  Putting work on to driving software will obviously put a bit of pressure on the CPU (probably not much), but for those on the edge with CPU this might just be an issue.  Otherwise, I would assume driving software would run in a different process and thus share CPU core(s), as well as mostly be idle as it waits for both IO and time-waits to perform the next step (only an issue for animation or dimming).  For those whose parallel port is already devoted to other concerns, yeah this might not be great.  One could perhaps use one of the control pins to disable (and cause a pass-through)....but that's a much bigger discussion.

In the end, I guess I was just trying to get a discussion going regarding homebrew, no-frills cheap-a** LED (and nothing else) controllers.  I guess I was thinking that if the community had a schematic, and software support, those who could not afford the existing products could put in the time and effort and build the the BYOAC solution, which would hopefully be supported by things like mamehooker, ledblinky, etc.  Oh, and I guess I was also looking to add item 173 to my to-do list. 

fwiw - I do not want to be seen as putting down quality products from GGG or Ultimarc, etc

[SavannahLion]

Is there a replacement for the 574 (inverted or otherwise) that could easily handle 8 LED's (e.g. 20mA * 8 )?  I have been hitting up Digikey and Mouser a great deal but...may not have quite the expertise in this area.

This is just a thought, is it a good idea to even bother with the LPT port anymore? Even though the parallel ports appear on about 90% of the PC's I own, I haven't actually purchased any PC in the last five years or more that sport a native parallel port.

Just a thought.

[ids]

I haven't actually purchased any PC in the last five years or more that sport a native parallel port.

I've heard this a lot but not experienced it myself so far (macbook excluded).  I'm sure you could get a card you could drop into your computer, but that sort of defeats the purpose of the poor mans LED controller.  Going with USB, to my limited knowledge, will drive up the costs and complexity.  I guess, in my mind, this is as much an exercise in thrift as it is an exercise in ability.  I guess one could simplify and go with the serial port.  It would be slower, but perhaps work out ok anyway.  Although, the same machines without parallel ports might also skimp on old fashioned serial ports as well.  As for me, I dug up an old, unused printer cable, ....

[MonMotha]

You'd use a ULN2803 along with the 74xx574 (I'd still suggest a 74xx573, instead).  The 57x would generate the signal which would gate the ULN2803.  The ULN2803 can handle pretty beefy loads, though I've had some trouble when switching all 8 outputs at once on 194/168 type incandescent lamps - it seems to blow up the common as the whole chip goes out - but this shouldn't be an issue with LEDs.

If you want an integrated solution, TI has a nifty line of "power + logic" devices.  Check out the TPIC6273.  This is an edge triggered device like your 574, but it does have a different pinout.  It's supposedly available in an experimenter-friendly DIP package.  You might also check out the TPIC6259.  This is an addressable latch, and you could use 8 of them to replicate the functionality you've described without needing the 238, though the banking/topology would be different (each device would be modified one bit at a time but all 8 devices would have one output changed when that happens).  From the looks of it, you may be able to get by with nothing but 8 of those and some connectors.  They'll probably sample you a few of these, at least, maybe even all 8 that you need.  There's also the 6B259 and 6C259 that are similar but have different output current ratings.

Regarding USB, yes, it's quite a bit more complicated than the parallel port.  Many people not familiar with it (especially management types) often want to use it as though it's a simple serial port without realizing how complicated even a minimal USB device software stack is.  You can relatively easily run it (completely bit banged in firmware) on a low end 8-bit MCU, though.  It'll just require a fair bit of firmware work that you probably don't want to do.  There are unfortunately not many MCUs with USB in hardware that are available in through-hole packages.

[ids]

Sorry, I had a lot more typed up in response but lost it....

Many thanks again for your responses which are priceless to a newb like me...so to be brief (I'll get more detailed again later)....

Keeping with the theme of low cost (MonMotha I mean no disrespect whatsoever as, per usual, your solutions are superior) I found the SN74ACT564 which, if I understand the spec sheet right (http://www.ti.com/lit/ds/symlink/sn74act564.pdf) can handle both 3.3V and 5V LPT port types, while also supplying sufficient current for 8 LEDs (~20mA each).  If that is the case, we could use this as a replacement for the *574 from the diagram, which keeps the component count down (and thus complexity of build) - but it raises costs a bit: $1.09ea for small quantities (<25).  But, 8 of those, the *238, and the odds 'n' ends to finish the job, produces a very cheap 64 port LED controller...for 5V LEDs... in the 20mA range....with no features like dimming (software could do this however).

FWIW, I'm not stuck on the edge-triggered chips, I really have no idea what I'm doing, the transparent latch seems much better.  In my ignorance laced search I found the SN74ACT564, which appears to be a potential candidate, but I'm open to cheapo components of any type.

So, based on a haphazard selection from mouser, I've got:

part #	desc	unit cost	qty	total
771-HC238BQ115	Demultiplexer	$0.393	1	$0.39
595-SN74ACT564N	Flip-Flop	$1.09	8	$8.72
649-DILB20P-223TLF	IC Socket, 20 Pin	$0.218	8	$1.96
649-DILB20P-223TLF	IC Socket, 16 Pin	$0.142	1	$0.14
TOTAL				$11.21

Shipping is extra, as is a protoboard, DB25 cable, solder, wire, etc

As mentioned earlier in this thread, I'd be willing to prototype such a thing.  I would also be willing to kick off coding of such a driver.  I'm not sure how much interest there is in such a thing, but I think I'll try it just for kicks anyway.  I have no need for such a thing, it just seems like a cool challenge    because of course we've all got too much time on our hands 

[ids]

Thanks again for all the info.  Looking at costs, effort, etc:

• The ULN2803, at $1.02 (Mouser) would add $8.16 to total cost, not a big deal, just a bit more work to connect it all up.  OTOH, adds a great deal of flexibility on the outputs.
  
• The TPIC6273 looks great, however at $4.38 ea (Mouser) - multiply by 8....getting too close to the cost of an LEDWiz to make this worthwhile, unless you're doing this just for the fun of it.  The TPIC6259 is $4.43, so same thing there.
  
• The TPIC6B259N is more reasonable at $2.74.  Using addressable latches I can see two approaches.  One is a simple design in which you use the demultiplexer to select an enable line for one chip, 3 address lines common to all chips, and a common data line.  This setup can address only one LED at a time - might be a bit slow to do full updates.  Otherwise, you can use 8 lines, one for each chips enable pin, so that the data line (connected to all) can be fed to one or more chips at a time (where the value being assigned is common for those LEDs).  This is a bit more complicated to code a driver for, but not a big deal.  Worst case behaviour is 1 LED update at a time, best case is 8.
  

I've also sketched out circuits using the SN74ACT564N (attached).  I've added the pull-downs on the *238 outputs (thanks), the extra control line into the *238 (thanks again), etc.  First pic is basic overview, 2nd is getting ideas how to lay it out on a board and wire it up.  8 lines to 8 chips is a lot, but some sort of "bus" idea here....for each data line, connect from LPT to chip 1, jump to chip 2, 3, 4, etc.  And if you run chips in two rows back to back it might be easier.  Fortunately, the pinout on the *564 makes this really easy.  Working in the *238 - still thinking about that one.  Maybe also add some screw terminals for LED outputs to make it easy to use this thing.  Oh, and a DB25 connector for the LPT cable.  I think this could all be done easily and very cheap.  With software support, we could have a really viable solution for basic CP lighting (or other uses).

[ids]

Added the 238 (attached)

[Unstupid]

I have some flip flops for you but I don't know if it's going to be of much use!

[ids]

Perfect - how much you asking?  By the way, I only need the left one....and 8 of them 

[MonMotha]

The trick when using the addressable latch is to bus the address inputs but connect one unique data line to each latch.  This means that a write will still update 8 bits, but it will update a single bit on all 8 latches rather than all 8 bits on a single latch.  It's equivalent to the 238+574 solution, but the update order is different, and you save one chip.  There's also less bussed wiring (4 wires rather than 8).

Also, you might look into the TPIC6A259, TPIC6B259, and TPIC6259 (I'm not sure all of these exist).  They have different current handling capabilities and wil have different prices.  Same with the TPIC6273, TPIC6A273, TPIC6B273, and TPIC6C273.  TI will probably sample these to you for free (including shipping!), too, but they may limit you to 4-5 pieces.

The classic way to run busses on perfboard is to "weave" the bus along using uninsulated/tinned bus wire (hence the name) the length of the board, then tap jumpers (insulated except on each end) from the bus lines to the chips in question.  If you prefer to use all bus wire, you can just make sure that the bus is on the opposite side of the board wherever there would be a crossing.