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.