EEVblog Electronics Community Forum
Electronics => Microcontrollers => Topic started by: Falcon69 on September 21, 2014, 09:07:12 am
-
Okay, I'm a newbie. Thinking of getting started on all this.
I've been working on a circuit for some time now, and I think a Micro-controller is the way to go.
My project calls for 43 outputs and 17 inputs (all switching different ways, different times, etc.).
8 of the outputs would goto a mosFET to control an external circuit. The other 35 outputs would be just LED's. I would like to be able to control LED's directly (with resistor in series of course) on all the outputs. That's 20mA x 43 = 860mA. So the Micro-controller needs to be able to sink that. I really do not want to use transistors or mosFETs to control them. Since it's only LED's on those outputs.
Now, I've looked at PICaxe and read up alittle about them, even downloaded the software and played around with it abit. However, the largest chip they have is only 32 I/O. And, they are NOT surface mount. Big and bulky looking. I have a reflow oven I invested money in building, so I want to put it to use and use Surface Mount Technology as much as I can in my circuit. I'd like to get something in a TQFP package or something with the leads coming out. Makes it easier to visually inspect that all the leads soldered okay in the reflow oven. DFN would be nice, but it's hard to tell if the pins have been soldered right.
So, it looks like I would need a chip to perform the operations of controlling those mosFETs and LED's. I know I would need some type of a programming module. I've seen ones that are USB and the chip goes into some kind of a holder that allows the info to download to. Would it be easier to just implement something on the circuit itself to download/program the info to the chip?
What software would I use? I would need something very newbie friendly.
I looked at the PIC chips from Microchip, and looked at PICaxe software, however, if I understood it right, I can only use the PICaxe chips with that software because they have preloaded firmware on the chips that allow the software to download/program the chip. So I'm stuck, not sure where to go now to look. There's just so much information out there on this subject. Confusing to this old newbie.
If I could manage to use a Micro-controller on my circuit, it would eliminate about 60 logic gates and a whole bunch of resistors and decoupling caps. Would save ALOT of board space.
The other thing I wanted to ask....
If an input becomes floating....say for example a wire is accidentally cut for that input and the input becomes floating......is there a way the microcontroller will know this and send a signal to one of the output pins? FYI, the input goes from negative or positive, depending on what is switched for that input, so I can't just simply tie the input to one or the other in case of wire cut. The Microcontrol would just default, as if the switch had been swtched on/off.
Thanks in advance for all your help. :)
Jason
-
I would like to be able to control LED's directly (with resistor in series of course) on all the outputs. That's 20mA x 43 = 860mA. So the Micro-controller needs to be able to sink that. I really do not want to use transistors or mosFETs to control them. Since it's only LED's on those outputs.
20 mA/LED sounds far more than necessary unless they are 20 mm LED's
IMO budget on 5-10 mA.
Better still get those you intend to use and trial various series resistors to obtain the brightness you need.
-
The Red LED's I am using need to be as bright as they can be, so that's 20mA.
The Green ones will probably be half that. The green light is just too bright to the eye, so making the resistor value higher, lowering the mA through the LED, should make them appear to be the same brightness as the Red LED.
That 20mA per LED is just a worst case scenario.
-
That's 20mA x 43 = 860mA. So the Micro-controller needs to be able to sink that. I really do not want to use transistors or mosFETs to control them. Since it's only LED's on those outputs.
I believe that this will eliminate ALL modern microcontrollers. For instance, the STMF32 chips that are currently being discussed in other threads have max current into/out of the supply pins of 150mA, and that's pretty typical (on the chip scale.) Now, that would probably be OK at 2mA per LED, which might be sufficient for "indicator" LEDs, using modern LEDs.
But I think you're being silly. There's little real reason to us "direct drive" of that many LEDs. Eliminating that requirement would let you use a microcontroller with fewer pins, and probably simplify your wiring as well. (For instance, I have on the desk in front of me one of these: http://blog.theledart.com/blog/archives/1965 (http://blog.theledart.com/blog/archives/1965) - 60 LEDs driven from one 28-pin microcontroller. (although - not particularly "well behaved", circuit-wise.)) From a software point of view, once you write your SetLED(n, state) function, it doesn't matter if the LED is directly wired, multiplex, charlieplexed, or on some kind of external expander chip.
is there a way the microcontroller will know [whether an input is floating]
Yeah; if you have a resistor between the signal and the pin, you can periodically switch the pin to be an output, output +5 and 0, switch back to an input, and see if the pin "remembers" the last state written. If the pin is floating, it will have enough capacitance to retain the last state written for "a while" (sorta like a DRAM cell!) If it's being driven, it will "instantly" revert to the driven level. (you need the resistor to prevent outputting a 0 to the connected thing driving 1, which would be a max-pin-current exceeding event.)
-
Each LED switches on based on one the inputs are doing. I can't tie them together and run off one or two mosfets/transistors.
That wont work with the floating thing. If the signal goes to float, I need it to default to either 0 input or 1 input, whichever I program.
It's sounds like you are talking about using like a shift register or something to control the led's? That sounds pretty complicated, especially for the programming.
-
20mA is also right up to the absolute maximum specification of many/most microcontrollers. It can't do that on every I/O pin at the same time. The GPIO on microcontrollers are not power drivers. 800mA will violate almost any specification for total power through VDD pin(s) I'm pretty certain.
How "fast" is this circuit? Are we talking MHz or Hz here?
Microcontrollers are plenty fast for Hz-kHz region, especially if those LEDs are just indicators that are perceived by humans. If that is the case, you can really easily hook them onto a few shift registers and update them at will.
That avoids you violating the current specification of microcontrollers, but also can avoid you to use a very big chip. 60 I/O is often only found on 80 or 100 QFP devices, which are getting into the region of "paving stone"-packages.
If you can offload those 35 I/O externally, you can save 30 I/O pins on your controller. You then only need 17 Inputs, 8 + 5 outputs and maybe some debug port (a serial port can really be handy at times). That sounds to me like it would fit in a 44 TQFP (0.8mm pitch) chip, which are much easier to work with instead of 64/80/100 LQFP (0.5mm pitch) chips.
I would personally try to get rid of PICaxe if you can. You're completely tied into one vendors programming language, supply and tools.
As for "programming tool"; I would get a in-circuit programming tool. Not only is that a necessity for SMT, it's also much more portable to other boards (just whack the ISP/debug connector onto the board and start uploading programs).
Building it yourself is IMO not worth the effort. AVR ISP MK2 and PICKIT2/3 are only 40 euro's or something like that.
As for the inputs; if it goes floating at some points you can use a pull-down or pull-up to pull it into a idle state (be it a 1 or 0).
To detect if the pin is floating is less trivial, you can maybe use a combination of pull-up and pull-downs + some software to figure out if the pin is indeed floating. This is something to consider in selecting microcontrollers, because not all chips have programmable pull-up and pull-down on GPIO's.
-
That's 20mA x 43 = 860mA. So the Micro-controller needs to be able to sink that.
You are unlikely to find any mcu that can deal with that much current directly. 20ma per pin and 150ma - 200ma per chip are at the high end of the current capabilities for mcu.
SMD is easy to find, pretty much any mcu offers that. the number of pins can be from a few to over 100 so that's not a problem either.
If you want to drive those leds, one led per pin, you can use transistors / mosfets or arrays.
A better solution, in my view, is to use a few pins (2-4 pins, depending on configuration / devices used) to drive a few high-current shift registers wired to those leds. They can handle up to 8 leds, and 150/350ma continuous per chip. You just need 6 of those devices to handle your 43 leds.
-
Have a look at the WS2813B intelligent LEDs. You can control 100s off of a single pin, the power problem is solved as it is seperate from control. The are also bright and can be had for approx $0.30....
-
If you need to drive that any LEDs, doing it with MCU pins is not the way to go. Use external drivers - cheapest would be 74HC595s but there are plenty of drivers with more functionality (constant-current, PWM) out there
-
mike got ahead of me. use just a simple led driver, like max7219 will easily allow you to drive 64 leds with simple spi or bitbanging, using a simple and easy to start with attiny mc :) or you can always go arduino route, they have plenty of libraries for drive leds for various drivers etc.
-
Hamster,
Those are LED strips, totally different.
What I'm trying to do is use it for indicator LED's, each will switch on, based on what the inputs are.
If I have to use mosfets or transistors to turn on each LED. I'll forget about the micro-controller then. The mosfets and transistors use about the same foots print on the board as a logic chip, which I would have to use anyway if no micro-controller. So Id be looking at the same footprint, with or without the micron-controller, actually more because of the micro-controller.
Shift registers, how exactly do those work?
Here's a snip-it of what I am trying to do. This is just one of 8 channels. The 4 switches on the left is to simulate of a cable has been cut. inverter connected to the mosfet on the left is the magnetic Hall sensor. The there is only one test led, upper right corner for the entire circuit. Only one of the circuit on the bottom (the stuff connected to the 8-input NAND gate.
Everything else is 8. Meaning, the circuit shown, other then the test led switch and led, and the circuit on bottom right with the NAND gate, is all just 1/8 of the entire circuit. There will be 8 hall switches total.
A front panel with lights, a rear panel the hall switches connect to, then they all connect to a mainboard. I'm still working on the schematic.
If you don't have the falstad simulator to view the file, here it is here. It's simple to use, just import the file to see it. http://www.falstad.com/circuit/ (http://www.falstad.com/circuit/)
To import the file, open it in notepad, copy it all. Then select File/Import on the simulator and Paste.
The circuit is operating exactly how I need it to. The comparator is there just to make sure that if any noise is picked up through the double shielded cable of up to 30ft, it will send a solid signal to the logic gate, ensuring it operates as it should.
Frequency? MHZ? I still have no idea what any of that means yet. I'm just a newbie. Still learning. I know that frequency is the amount of something in a certain time frame. That's as far as my knowledge goes right now.
-
Shift registers, how exactly do those work?
Read the datasheet for 74HC595/164, or TPIC6x595 from TI.
Basically you send 8-bit data to the shift register via a few wires and it outputs that 8-bit value on 8 pins - in your case, wired to 8 leds.
-
So based on that 8 bit data, one, or all, or a sequence, or a random number i choose will turn on?
What is the best micro-controller to use for the application, best shift register, and what program software that is shareware that I can use? I will download the software and play with it tomorrow. 4 am here, time for bed. I'll check on how those shift registers work tomorrow.
I liked the PICaxe program. You can do the programming using a flow chart. Still dont know how to do it, but was fun playing with it.
-
So based on that 8 bit data, one, or all, or a sequence, or a random number i choose will turn on?
What is the best micro-controller to use for the application, best shift register, and what program software that is shareware that I can use? I will download the software and play with it tomorrow. 4 am here, time for bed. I'll check on how those shift registers work tomorrow.
You send 8 bits, and there are 8 LEDs. There's a one-to-one mapping between them.
The nice thing about shift registers is that you can cascade them together. Want a 48 bit shift register? Just get 6 8-bit registers, and wire the out from one into the in of the next. Examples will be in the datasheet. Then your uC just sends out 48 bits, wiggles one other pin to say "go", and all your 48 LEDs are set. Shift registers are versatile and very, very easy to use.
Any uC on the market is perfectly capable of controlling a shift register, it doesn't require any special capabilities on the part of the uC. And a shift register is pretty much a jellybean part, there's no "best shift register" out there. There are some with special features, like extra strong outputs, and constant current outputs, but if the 74HC595 suits your needs, then it suits your needs.
-
the 74HC595/164 uses SPI, you can use the hardware builtin to the micro-controller, or just use bit-banging (<- control pins yourself) technique, both are straightforward
the chips are daisy-chained together (only requires 3 signal wires) and can control 8 leds (pretty quickly if required), so you'll need 6 chips
as to what micro-controller to use ....
-
Hamster,
Those are LED strips, totally different.
I don't understand what you're saying here. WS2812B come in standard 5050 LED package. Just daisy chain them together with a few decoupling caps, and you can individually control an unlimited number of RGB LEDs from a single MCU pin. No more logic needed.
-
MICROCONTROLLER VS. DISCRETE RANDOM LOGIC
We don't really have an overall sense of what your system looks like here. You could almost certainly implement it with random discrete logic, but that involves sourcing chips that are becoming rare because most of us find it so much easier/cheaper/faster to use modern microcontrollers. If you are doing this just to create your gadget, then maybe discrete logic is the way to go. But if you have any future plans for creating systems like this, then it is to your advantage to learn how to do this with a microcontroller. Implementing this with a microcontroller will almost certainly be far more compact, fewer components, and less fiddly than doing it with discrete logic.
WHICH MICROCONTROLLER?
Far and away the microcontroller family with the most options and best support (both commercial hardware and peer assistance) is Arduino. You can buy Arduino controller boards that are the size of a postage stamp and cost little more than a postage stamp which will easily handle something 10x as complex as the system you have described. And the programming environment is open-source and free. And there are online support communities (primaryly at http://forum.arduino.cc/ (http://forum.arduino.cc/)) to offer hand-holding assistance even for users starting with zero previous experience.
SENSING OPEN-CIRCUIT INPUT CONDITION
If you arrange your sensors (undisclosed?) so that they always output "hard high" or "hard low" then use a high-impedance voltage divider back at the control circuit, you can sense that if the sense signal is hard-high or hard-low, the sensor and the wiring are OK. But if the input signal floats somewhere inbetween high and low, then you know that something is wrong somewhere.
SOURCING "HIGH" CURRENT LOADS
Except in very tiny and trivial circuits, driving loads like LEDs directly FROM the microcontroller is just not done. It is NOT the job of the microcontroller to PROVIDE the load current. It is the job of the microcontroller to CONTROL the load current. The universal implementation is to use external switches (transistors, transistor arrays, shift registers, etc. etc.) to switch the current to each load (LED).
CONTROLLING MULTIPLE LEDS
There is no particular advantage to using a microcontroller with enough pins to separately control all the loads. And there are many disadvantages. For this reason, it is VERY common to use shift-registers to control multiple loads. There are even shift-registers which have built-in high-current drivers which is exactly what you appear to need.
FURTHERMORE
There are now RGB LEDs available (in several form-factors) which have BUILT-IN drivers. You can take ANY NUMBER of them and connect them in series. Then with a SINGLE PIN from your microcontroller, you can control ALL the LEDs. Not just on/off, but 256 shades of red, green, and blue to display. Adafruit calls them "neopixels", for example: https://www.adafruit.com/category/168 (https://www.adafruit.com/category/168)
-
Thanks for the info.
Ive checked out those LED intelligent chips. They will not serve my purpose. I need to use 3mm flat Top LED's for my application. Plus, I don't need the RGB.
I still don't understand the shift registers, and spending an hour this morning to watch youtube videos on them and searching info, it looks like they can't individually control an LED. They only work in sequence with each other.
I thought about maybe using a Matrix LED pattern. Like in the picture below, however, when more than one LED is on in a column or row, the mA drop through the LEDs. Lowering their brightness, is there a way to fix that?
Using a Matrix would work with an easy to program Microcontroller. I could control alot of LEDs with leass then half the required in/out of the microcontroller.
-
I need to use 3mm flat Top LED's for my application.
You can hardly expect us to suggest things that meet you requirements when you don't reveal your requirements.
Plus, I don't need the RGB.
Indeed, not worth the expense if you need only one color. But those things are getting so cheap, it almost doesn't make a difference.
I still don't understand the shift registers, and spending an hour this morning to watch youtube videos on them and searching info, it looks like they can't individually control an LED.
Of course they can. Millions of them are working just like that even as you read these words. The whole point of shift-registers is to convert between serial and PARALLEL. There are shift registers that convert PARALLEL bits into a serial stream (as for sending input switches, etc.), and there are shift registers that convert serial data back into PARALLEL outputs (such as for driving LEDs. And because driving LEDs from a serial bitstream is so common, there are shift registers that have high-current buffers on the outputs to control higher current loads.
They only work in sequence with each other.
1) They are LOADED in sequence with each other. That is a SEPARATE function from OUTPUT. Many shift registers have a separate "latch" function that controls the outputs separately from loading the data.
2) Even if the outputs DID change while sending the serial data down the chain, it is SO FAST that the human eye can't perceive it. So it is not uncommon to find LED controllers without the latch function at all.
I thought about maybe using a Matrix LED pattern. Like in the picture below, however, when more than one LED is on in a column or row, the mA drop through the LEDs. Lowering their brightness, is there a way to fix that?
Sure. It is VERY common to "multiplex" LEDs like that. WHether serially, or in a 2-dimensional grid. The solution is to drive the LEDs at a HIGHER current so that the AVERAGE current (when integrated over time) is achieved.
Using a Matrix would work with an easy to program Microcontroller. I could control alot of LEDs with leass then half the required in/out of the microcontroller.
Yes. There are chips like MAX7219 and MAX7221 that can control 64 LEDs. From a simple serial interface.
-
watch youtube videos on them
That would be a poor way to learn. Read the datasheet instead.
-
I have to first learn HOW to
read UNDERSTAND the info in the data sheets.
-
Then learn that. Still beats out watching videos.
-
There are some very good tutorials about shift registers on the Arduino website.
-
Arduino.cc even have a tutorial (http://www.arduino.cc/en/Tutorial/ShiftOut) on exactly what you need.
-
Sigh. We experts always make fun of "beginners" blinking their LEDs. But Blinking LEDs in various ways is actually quite a valid path to understanding the workings of embedded programming on Microcontrollers, and by the time you understand multiplexing and charlieplexing and shift registers and port expanders and LED controllers and LEDs with built-in controllers... Well, you understand more about embedded programming than MANY professional software engineers. (pessimistically, you can look at it the other way as well: in order to blink LEDs in all their glory, you need to learn a daunting amount about embedded programming.)
And then you run into someone who doesn't have any of that programming experience, is ready to dedicate 35 pins to light 35 LEDs, and doesn't understand levels of "abstraction" that everyone is using to explain that they don't really need those 35 pins... :-(
You need to stop worrying about datasheets, and learn more about programming.
Hardware wise, most of the LED control mechanisms being suggested are essentially latches. You present some data at some inputs, and the hardware latches that data and shows it on the LED(s). Whether the latch is inside the microcontroller (as it would be for a pin-per-LED implementation), or is talked to via a web browser connection of a wireless internet link is only a "small matter of programming."
-
Using a Matrix would work with an easy to program Microcontroller.
Two potential ways to deal with that:
1) two shift registers and you can display one column (or one row) at a time: it is the simplest solution but requires extensive data rate: since only one column / row is on at a given time, to avoid blinking, you have to constant send the shift registers data.
2) dedicated drivers like 7219: all you need is to send the 64-bit data and the chip handles it. Serial input so minimum wiring. They are also quite inexpensive, but works only at 5v.
Which is best will depend on the rest of your design.
-
The 74HC595 (serial in parallel out shift register) is my first choice when driving a relatively small number of LEDs and other outputs as well. For 35 LEDs I would consider multiplexing still using a 74HC595 and a 74HC138 1-of-8 decoder which would easily allow 64 LEDs. The MOSFET drivers should probably not be multiplexed but could be on their own 74HC595 which conveniently supports synchronous updates so glitches will not be a problem.
-
The 74HC595 (serial in parallel out shift register) is my first choice when driving a relatively small number of LEDs and other outputs as well. For 35 LEDs I would consider multiplexing still using a 74HC595 and a 74HC138 1-of-8 decoder which would easily allow 64 LEDs. The MOSFET drivers should probably not be multiplexed but could be on their own 74HC595 which conveniently supports synchronous updates so glitches will not be a problem.
For many I've helped with something like this, with projects intended for only a few final boards, they were able to wrap their mind around serial chaining multiple 74HC595s where they never understood muxing. This makes things easier on software, and easier to think of for hardware. After a certain number of chips though, it begins to get silly.
-
The 74HC595 (serial in parallel out shift register) is my first choice when driving a relatively small number of LEDs and other outputs as well. For 35 LEDs I would consider multiplexing still using a 74HC595 and a 74HC138 1-of-8 decoder which would easily allow 64 LEDs. The MOSFET drivers should probably not be multiplexed but could be on their own 74HC595 which conveniently supports synchronous updates so glitches will not be a problem.
Actually a TPIC6C595 is a much nicer device to drive relays and leds. It has an output register reset input (which a 74HC595 doesn't have) and it can drive loads up to 33V. The TPIC6C595 also has short circuit limiting.
-
Far and away the microcontroller family with the most options and best support (both commercial hardware and peer assistance) is Arduino.
Just a technicality, but Arduino is not a microcontroller familly. Arduino defines electrical interfaces, physical form factors and a programming language, but can use very different microcontrollers within the range (e.g. ATMega, ARM Cortex M3 and ARM Cortex A8 on official products and numerous others on the clones).
-
The 74HC595 (serial in parallel out shift register) is my first choice when driving a relatively small number of LEDs and other outputs as well. For 35 LEDs I would consider multiplexing still using a 74HC595 and a 74HC138 1-of-8 decoder which would easily allow 64 LEDs. The MOSFET drivers should probably not be multiplexed but could be on their own 74HC595 which conveniently supports synchronous updates so glitches will not be a problem.
I just recently made a board that uses 595s for both the rows and the columns. If your LED array is square, you can clock in the column (or row pattern) along with the selected row (or column) at the same time. You need two data pins but can share clock and latch. You can make careful use of the OE to turn off the LEDs when new data is being latched.
I just made a 16x16 array LED clock with four 595's and it works pretty well, and with fewer uC pins used and lower parts count. In my design, the 595s are driving BJT pullups and pulldowns so that I can drive high-current LEDs, but I think for normal LEDs you can do without the transistors.
-
Just a technicality, but Arduino is not a microcontroller familly. Arduino defines electrical interfaces, physical form factors and a programming language, but can use very different microcontrollers within the range (e.g. ATMega, ARM Cortex M3 and ARM Cortex A8 on official products and numerous others on the clones).
As the OP is a self-identified "newbie", going into the minutiae of component selection for a well-supported consumer end-user brand/development environment like "Arduino" seems counter-productive and irrelevant in the context.
-
I just made a 16x16 array LED clock with four 595's and it works pretty well, and with fewer uC pins used and lower parts count. In my design, the 595s are driving BJT pullups and pulldowns so that I can drive high-current LEDs, but I think for normal LEDs you can do without the transistors.
I wish there were an octal high-side driver/switch IC product like there are for low-side switching. That would make constructing arbitrary-size arrays so much easier.
-
I wish there were an octal high-side driver/switch IC product like there are for low-side switching. That would make constructing arbitrary-size arrays so much easier.
Yes, there aren't even x8 PNP or PFET arrays. There must be some reason such things don't exist, but I don't know it.
Transistor arrays usually also have the base resistor, too, which is nice.
-
The 74HC595 (serial in parallel out shift register) is my first choice when driving a relatively small number of LEDs and other outputs as well. For 35 LEDs I would consider multiplexing still using a 74HC595 and a 74HC138 1-of-8 decoder which would easily allow 64 LEDs. The MOSFET drivers should probably not be multiplexed but could be on their own 74HC595 which conveniently supports synchronous updates so glitches will not be a problem.
Actually a TPIC6C595 is a much nicer device to drive relays and leds. It has an output register reset input (which a 74HC595 doesn't have) and it can drive loads up to 33V. The TPIC6C595 also has short circuit limiting.
The 74HC595 may be used with weak pull-downs or pull-ups allowing the output enable pin to take the place of an output register reset. Simple common emitter or common base output transistor level shifters allow for high voltage operation. With some cleverness, the 74HC595 updates can be pipelined during the multiplexed display on time allowing a lower performance SPI link and a higher display efficiency.
I have always been leery of single sourced expensive custom interface drivers preferring instead to roll my own.
-
The 74HC595 (serial in parallel out shift register) is my first choice when driving a relatively small number of LEDs and other outputs as well. For 35 LEDs I would consider multiplexing still using a 74HC595 and a 74HC138 1-of-8 decoder which would easily allow 64 LEDs. The MOSFET drivers should probably not be multiplexed but could be on their own 74HC595 which conveniently supports synchronous updates so glitches will not be a problem.
For many I've helped with something like this, with projects intended for only a few final boards, they were able to wrap their mind around serial chaining multiple 74HC595s where they never understood muxing. This makes things easier on software, and easier to think of for hardware. After a certain number of chips though, it begins to get silly.
It does get silly. I think the largest displays I have done without multiplexing had 64+ LEDs in the form of two groups of four 7-segement display plus decimal points plus some status LEDs and keyboard inputs.
I am not a fan of multiplexing because of human factor issues but another reason I might avoid it is because of reliability. If the system freezes, a static display driver will correctly display the last state. An independent multiplexed display driver would avoid this problem of course and that would be my choice before using a custom ASIC. Dedicated microcontrollers are good at this sort of thing.
-
The 74HC595 (serial in parallel out shift register) is my first choice when driving a relatively small number of LEDs and other outputs as well. For 35 LEDs I would consider multiplexing still using a 74HC595 and a 74HC138 1-of-8 decoder which would easily allow 64 LEDs. The MOSFET drivers should probably not be multiplexed but could be on their own 74HC595 which conveniently supports synchronous updates so glitches will not be a problem.
Actually a TPIC6C595 is a much nicer device to drive relays and leds. It has an output register reset input (which a 74HC595 doesn't have) and it can drive loads up to 33V. The TPIC6C595 also has short circuit limiting.
The 74HC595 may be used with weak pull-downs or pull-ups allowing the output enable pin to take the place of an output register reset. Simple common emitter or common base output transistor level shifters allow for high voltage operation. With some cleverness, the 74HC595 updates can be pipelined
I have always been leery of single sourced expensive custom interface drivers preferring instead to roll my own.
The tpic6c595 is pretty cheap compared to your solution (less parts and more rugged) and it is made by TI and ST so there is a second source.
-
Just a technicality, but Arduino is not a microcontroller familly. Arduino defines electrical interfaces, physical form factors and a programming language, but can use very different microcontrollers within the range (e.g. ATMega, ARM Cortex M3 and ARM Cortex A8 on official products and numerous others on the clones).
As the OP is a self-identified "newbie", going into the minutiae of component selection for a well-supported consumer end-user brand/development environment like "Arduino" seems counter-productive and irrelevant in the context.
I'm not going into the minutae of component selection, just trying to avoid a newbie being confused by incorrect terminology. Arduino provides a cheap, well supported development system for beginners which is great, but if said newbie is asked which microcontroller he has used and he says "Arduino", it make no sense.
-
I wish there were an octal high-side driver/switch IC product like there are for low-side switching. That would make constructing arbitrary-size arrays so much easier.
Allegro used to make a shift register/high-side driver but there are reasons these are not common. I am sure other ICs like this exist.
Low side integrated switching is preferred because NPN/N-channel transistors are more efficient than PNP/P-channel transistors making it more economical to use the low-side driver and an external PNP/P-channel transistor if necessary. For the same reason, open collector/drain outputs are usually (always?) pull-downs instead of pull-ups but you can simulate a logic level high-side pull-up using a tri-state driver which most microcontroller support on a pin by pin basis.
-
use some WS2803's. serial constant current PWM led chip. each chip can do 18 LED's. feed it like a shift register.
feeding the WS2803 5v you can set each led up to 30ma per pin output, if you feed it 3.3v you can set it to max 20ma per pin output.
daisy chainable and needs only 2 pins, clk + data (it is NOT i2c) attached to your microcontroller.