| Main > Main Forum |
| Poor mans LED controller? |
| (1/3) > >> |
| 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(8) 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. ;D 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. ;D fwiw - I do not want to be seen as putting down quality products from GGG or Ultimarc, etc |
| Navigation |
| Message Index |
| Next page |