A way to control 8x strips of RGB without using 8 pins

S

SteveSFX

Well-known member
Hey all

My 4.1 has 3 or 4 spare pins, but I now need to control 8x strips of 5M RGB leds. Can be NeoPixel, Fastled.... whatever, but I am short of pins.

Any ideas?

Wondered if there was any way maybe of sending the data to a remote IC and assuming that programming doesn't change constantly, it can continue the sequencing stand-alone. Just changing parameters when requested.

I could add a second processor I suppose, but that starts to make it all a bit untidy with a whole second load of coding.

Pimoroni make these:
shop.pimoroni.com

Adafruit NeoDriver - I2C to NeoPixel Driver Board - Stemma QT

NeoPixel LEDs (a.k.a WS2812 / SK6812 family) are a super-easy way to add addressable RGB lighting with only one GPIO.
shop.pimoroni.com shop.pimoroni.com

Bit slow on the updating I think, but they might solve my problem. Not sure of their limitations yet.
I am guessing this runs a ATtiny or Pic and has onboard coding. I don't think this is an 'off-the-shelf' IC.

It's also going to be a bit pricey for 8 of these.

Just fishing for ideas
 
A simple Arduino Nano or so could do the job (*). Sending some commands and parameters via serial connection or so. Possible with one TX pin on the Teensy via soft serial if necessary. The communication part is the only additional effort. Programming the LED part via Fastled or whatever is needed anyway.

(*) it depends on the number of LEDs on your strips if one Arduino is sufficient. The limiting factor is the memory here. I think it is about 500 pixels. If necessary you could use more than one Arduino Nano or another Teensy (4.0). There is also a library which puts out the data on the fly without needing the full memory for all pixels.

Depending on the desired or needed framerate, the placement of the strips and the number of LEDs per strip it could be also an option to connect 2 of your strips. So you need only 4 data lines. (connect the output data line of every second strip to the input data line of another strip...)

I assume you would like to control all LEDs independtly. But if you shouldn't have thought about it, it might be an option to connect strips in parallel. Then these strips show the same pixel data.
 
Yes I did think of halving the amount of control by doubling the length of the strips (so one set of command effectively controls 2x strips of leds).
Not sure what the max length of Leds is. I will have to investigate.

I am thinking of basically having a small processor to oversee the control of the strips. Not exactly sure how I implement that yet.
I have a a spare Serial port available.

My problem will be how I implement the system. I think the 'receiver' will effectively have to have all the different possible types of output set up and then I write some comms code to enable me to pass the required commands over to it.

I am thinking (not being a super coder), something along the lines of dismantling something like the Fastled demo100 code and making all of it's variables available for remote adjustment.

Whether that is the correct approach I am not sure.

Ideally, I was trying to find a small processor for the job, such as an ATtiny, but they don't appear to be up to the job.
 
SteveSFX said:
I am thinking of basically having a small processor to oversee the control of the strips. Not exactly sure how I implement that yet.
I have a a spare Serial port available.
...
Ideally, I was trying to find a small processor for the job, such as an ATtiny, but they don't appear to be up to the job.
Click to expand...
You might want to look at the RP2040 (Raspberry Pi Pico etc) for a "small" processor. Very cheap, dual cores, reasonable Flash, RAM and speed for the purpose, and it looks like the PIO / DMA can be set up to drive LED strips with very little CPU overhead. I've used it myself, though not for ambitious numbers of LEDs so I didn't look into the PIO / DMA route. I did search a bit first, and it seems that others have already done much of the heavy lifting on that score.
 
Given 8 possible outputs you would need 3 pins of addressing and 1 pin of data as an absolute minimum unless you add some form of external memory either in the form of a processor or a latch of some sort.

You could do it in 4 pins using something like a 74238 demultiplexer.

Connect 3 pins to A0-A2 as your LED chain select pins.
Connect the data to the LEDs to CS1

If you use the HCT version (so a 74HCT238) and run it from 5V then it will be ok with the teensy 3.3V output but the part will output 5V which removes the voltage issues you sometimes hit with neopixel / WS2812 parts. They require 0.8*Vcc on the data input for reliable operation, a 5V LED doesn't always play nice with a 3.3v driver.
 
Yes, I had thought about a multiplexer approach. I quite like that idea.
I have some 74238's in my workshop.... time to breadboard

From what I read there, cs2 and cs3 need to go to ground, with just cs1 as the data in.
I can reduce my pins even further, as there is already an MCP23017 multiplexer in the remote module that I can used to control the 3x address pins over an existing i2c bus.

This needs some experimenting
Not sure how the strips will react to having the data 'strobed' across 8 outputs? Hmm
 
Last edited:
SteveSFX said:
Not sure how the strips will react to having the data 'strobed' across 8 outputs? Hmm
Click to expand...

Their idle state is to maintain the current colour. So as long as you don't need need a fast update rate it doesn't matter if the signal is sitting in an idle state while you talk to the other strips. You just need to make sure you wait until the one chain has finished updating before you set the multiplexer to the next one, you need to do a whole chain at a time rather than the first LED on each then the second on each.

Extra processors wouldn't gain you anything if all you do is send them the LED colours to display. You still have to send all the LEDs in a chain to change one and if you don't do anything the current state is maintained. However if you can put some intelligence into them then that could help a lot. e.g. send them a command to fade from red to green over 2 seconds and then let them handle all the updates required to do that.
You could define your own set of commands that include the strip the command is for and send them over serial. That way all of the controllers can listen to the same serial bus and pick out the commands that are for them. You could use a couple of spare IO pins on each controller to tell them what their ID is to keep the code on them all identical.
 
I think I have 2 options here then.
A dumb controller that effectively controls the strips if the required output is slow or not complicated (lots of chasing, fading etc).

The other option is an ATtiny as above, programmed with as many output options as I can fit on it, and then you tell it to run a specific function that may well be complicated, but you only update it when that output needs to change.

I think I am going to breadboard both options and may well make one of each.

Thanks for the advice!
 
I'm gonna plug the Pi Pico or similar one more time here ... the ATtiny only has 3k of RAM, so will max out at say 1000 LEDs per strip. I'm assuming you didn't really mean 5 million LEDs per strip, but 5 metres ... so maybe 300 per strip ... but maybe more. Then you have to build something with them, so it's not just going to be 76p. And figuring out how to talk to 4 or 8 of them may be non-trivial.

You can pick up a Pi Pico for £3.90 plus shipping. One single Pico should be capable of running ~70,000 LEDs, if you push it (way more than practical). You can probably (I haven't tried*) use USB Host on the Teensy to talk to it, so communication bandwidth shouldn't be an issue, and you won't touch your remaining Teensy I/O ... gets more complex if you're already using USB Host, of course.

* hmmm ... interesting thought ... definitely one to have a go at soon!
 
I tend to think that having multiple processors of different types will add to your complexity. You will need to deal with various incompatibilities.

I would think if you are going with multiple processors, it may be better to use a Teensy 4.0 to control the LEDs, and have a high level stream to control the LEDs. I.e. from the master processor, don't send out detailed settings for the LEDs, but instead send a command that says do pattern #1, etc. That way you don't have to worry about detailed timing issues. You have one processor that does inputs, etc. and one that controls the lights. You could use something like RS-485 (I may be mis-remembering this) to allow for longer distances between the master and slave processors.

For 5M leds, I would think you would want to break this down even further. Rather than have 5M LEDs all controlled by a single processor, maybe at most 5-10K LEDs per processor, and have your communications host then send out commands to each processor. If you make your communication be on a serial port, you can start each message with the sub-processor number, and all light processors are on the same serial port and each one is listening for its ID, and ignoring everything else (i.e. essentially like I2C works). That way you only need one serial port. If you consider the cost of 5M LEDs, it shouldn't be that much more to throw in a couple of Teensys.

Lets see, according to https://www.pjrc.com/store/octo28_adaptor.html that with using 8 parallel I/O strands, a single Teensy could control 10,920 LEDs. I don't know how you would control 5M LEDs from a single Teensy. Let alone the issue of how do you power that many LEDs.

I would think at that scale, you would then have backups in case any one Teensy fails. I would worry that in practice it would not be reliable if everything is controlled by a single processor. I.e. you have several Teensys ready to replace the ones that may become problematical on hand.

Another thought is if you aren't using the 2 memory pads underneath the Teensy, you have 7 more pins that can be used. If you aren't using the SD card, there are 6 pins that you can use.

In terms of communication, besides a serial port, remember that the Teensy 4.1 has USB host support, and I imagine you could hook each sub-processor up via USB (using a USB hub to multiplex the USB connections). That way you can scale up the process to add more sub-units. Ethernet is also a possibility.

If you using most of your pins for reading digital inputs and/or controlling single LEDs, consider using one or more I2C I/O expanders to handle the simpler I/O. Or possibly again, have more sub-processors, where each one handles some amount of I/O and talks to the master host.

I'm curious what you are using all of the pins for.
 
Last edited:
Trouble is.... I have never programmed a Pi Pico. So I have a large hurdle to overcome before I start

No.... not 70,000 leds! 8x Strips of a maximum of 300 per strip.
SD card an memory are used.

My 'Bus' runs through all the attached equipment on a Din rail. This bus has an i2c setup for nothing but I/O expanders

I need to tinker
 
SteveSFX said:
Trouble is.... I have never programmed a Pi Pico. So I have a large hurdle to overcome before I start
Click to expand...
Or as I said, use a Teensy 4.0 or 4.1 for the secondary processor. That way you don't have deal with the issues of the differences. That being said, at the Arduino level things are pretty much the same thing, but of course when you are dealing with parallel LEDs and DMA/etc. then you get into the inner details of the stuff.

SteveSFX said:
No.... not 70,000 leds! 8x Strips of a maximum of 300 per strip.
SD card an memory are used.
Click to expand...
That is a more realistic amount of LEDs.
SteveSFX said:
My 'Bus' runs through all the attached equipment on a Din rail. This bus has an i2c setup for nothing but I/O expanders

I need to tinker
Click to expand...
Yep. It is best to do things in smaller self contained units, once you have gone past using a single processor for everything. That way you can debug each unit separately.
 
Thought I had a 74238 demultiplexer but can't find it...

Found a 74HC4051 Multiplex switch which seems to work. Whether it is 'as good' I have no idea.

I can drive 4x rolls of 300 WS2815 RGB leds using a NeoPixel demo, and switch the data (through a level shifter) and control all 4 strips OK.

It does slow down the speed you can update obviously, but it's not too bad.

But... there are issues and reliability of the data does appear to be a bit suspect (random leds appearing).
Not sure this multiplexing idea is going to be all that reliable.

I will continue to tweak
 
When not selected the outputs of that part are high impedance, do you have pullups/downs on the data lines for the individual LED chains? If not when not selected they will be floating, I could believe that in that situation crosstalk / glitches may cause the first few LEDs in the unselected chains to get confused.
 
Yes, I tried pull downs. Didn't make much difference.
The random data was actually all over the string of leds at random points.

This I think could work in maybe batches of 4. I think 8 multiplexed LED strips is pushing it and doesn't allow for any real timing based effects that are not super slow.

I'll have a go with a slave processor next
 
Nope, but I can't imagine they've done anything too radical, Atmel / Microchip are usually pretty consistent. Of course, it does have to receive updates from your main controller as well as "spit out Fastled data"...

In other news, just for fun, I put a Pi Pico on a Teensy 4.1's Host USB port, just using CDC serial and looping characters back. As expected, it worked fine, though I haven't bothered to do any speed testing. I expect the same would be true for any downstream processor with USB Device capability, though unfortunately no Atmel / Microchip parts with USB seem to be helpful to you - the ATmega32U4 would be the nearest, but it's definitely not "cheap as chips". But it sounds like your "3 or 4 spare pins" will do the job OK, so USB may be a bit of a red herring.
 
Well I basically plan to load a butchered version of the Fastled Demo100 example + some basic illumination commands and then send over the base commands.

These could do achieved with i2c, Serial or SPI. I imagine SPI is fastest.
 
Am I missing something here? Every schematic of an Arduino Mega I have found so far has the USB circuitry missing?

I was going to stick a CH340 on my board for ease of programming, but Digikey says they are obsolete. Hmm.
Wondered what the Mega was using.

I'll continue my Googling...
 
You must log in or register to reply here.
Back
Top