# 200 LED through arduino via SN74HC595N shift register

I'm very new to any forms of multiplexing let alone electronics itself. From what I have researched, I can add more inputs/outputs to an Arduino via a shift register. I bought 10 SN74HC595N shift registers that have 10 outputs each (I think). I need to control two main strips of LEDs, that branch off in certain segments.

I know very basic electronics, and I think using multiplexing will give me more inputs/outputs. If I have 10 shift registers that give me 10 inputs each that gives me 100 extra inputs/outputs. ideally, I would only need to try to get two LEDs per input, so I could technically use charlieplexing. Can someone please explain what to do to connect 2 individual strips of LEDs (100 each) to a shift register using multiplexing.

• Like you are 3? Ok, let me try "Magic pixies make blinkenlights" – PlasmaHH Feb 1 '17 at 22:33
• Your text (and therefore requirements) are quite unclear. – Wesley Lee Feb 1 '17 at 22:35
• Start with a block diagram of inputs and outputs with functions required. 8-Bit Serial-In, Parallel-Out Shift we call this a SIPO register. – Tony Stewart Sunnyskyguy EE75 Feb 1 '17 at 22:37
• Hi Emily, welcome to the Electronics Engineering forum :-) Can you give us some background on you i.e. is this a school project, are you at college etc. Without knowing your starting point, it's hard to know how to phrase a reply. – TonyM Feb 1 '17 at 22:42
• Uhh each shift register only has 8 outputs, so 10 will only give you 80 outputs. – Bradman175 Feb 1 '17 at 23:40

As far as I understand you want to control two strips of LEDs where each strip has 100 LED and you want to control each individual LED in each strip. So really what you want to know is how to do it with one strip - then just copy the circuit again for another strip. I'll explain how its done by building your own LED strip. You need to connect the enough 74hc595 chips together in "daisy chain" configuration- to make up as many outputs as you require (100 in your case). The you need to connect the "daisy chain" to a MCU. The MCU will actually make the patterns you require-by sending the pattern to the "daisy chain" circuit , and the 74hc595 "daisy chain" circuit just expands the output of the MCU. You will need to connect an LED to each of the 100 outputs to build your LED strip. You will need suitable power supply to light so many LEDs too. Personally I think charlieplexing by hand will be too tedious to do for so many LEDs.

TL;DR: Multiplexing cannot remove complexity. In fact, nothing can remove complexity. If something is inherently complex, all you can do is move that complexity to an area where you can handle it.

In the case of multiplexing, it moves the complexity of a ton of individual wires that are relatively slow to a few wires that have to work like mad to get all that information across. With a few exceptions like charlieplexing, most techniques boil down to using some kind of predefined communication for an MCU running software to tell another, relatively dumb chip like a shift register, what to do.

I did this with SPI (Serial Peripheral Interface) a few years ago. In fact, I had both inputs (buttons) and outputs (LEDs) multiplexed into just 4 MCU pins. Since you asked about the outputs, here's my LED schematic:

This specific shift register might not match yours, but it's the same idea. Using the SPI signal names:

• CS = Chip Select
• When it goes low (Chip Selected for data transfer), the shift registers shift one bit per clock.
• When it goes high, the shift registers output whatever byte they've ended up with to their Qx pins.
• This is the only signal out of the four that is not managed by the SPI peripheral (a chunk of hardwired logic that is built into the MCU chip to control this type of communication while the software goes off and does something else). Thus, it could be any convenient output pin from the MCU.
• SCK = Serial ClocK
• Every transition from inactive to active shifts one bit from MOSI into the first shift register. All bits move over by one, and the one that comes out the other end goes into the next shift register, and so on as far as you want to go.
• I can't say high or low here because SPI allows the designer to determine which state means what. But in this case, the shift register's datasheet will probably determine it for you.
• MOSI = Master Out Slave In
• This is the actual data that you want to be displayed, presented one bit at a time and committed by the appropriate clock edge.
• MISO = Master In Slave Out
• This is data being received at the same time as you're commanding all those outputs. It's not used on this particular board, but connected straight through to the other connector.
• I have another variant of this board that does a similar thing with buttons and can daisy-chain with this one in any order and with any number of copies, so that the same SPI peripheral and the same software driver can read a ton of buttons and drive a ton of LEDs at the same time.

So that's the hardware design.

In software, I:

• Set up the SPI peripheral and two equal-sized arrays, one for LEDs and one for buttons
• They have to be equal-sized in software, even if they're not physically, because for every byte out, one has to come in. Of course, you could get around this requirement by making the ISRs a bit more complicated, but my project had them close enough to equal anyway that I didn't see the need.
• Define the appropriate Interrupt Service Routines (ISRs) so that this driver can "just work" without the main software having to do anything special
• A timer ISR starts a full refresh by loading the first LED byte into the SPI peripheral's shift register (built into the MCU), starting that transmission, and enabling the shift-done ISR
• The shift-done ISR continues the refresh by putting whatever has ended up in the SPI peripheral's shift register into the button array, writing the next LED value in its place, and starting that transmission. If it's just gone through the entire array, it also disables itself.
• Write the main software to just use those arrays as if they were magic. The ISRs take care of the rest.

Of course, that's a simplified explanation. You'll also have to twiddle the CS signal explicitly in the ISR(s) somewhere. Look through the datasheets and think carefully about timing.