Hello all
I have a project where I would like to run 8x individual strips of RGBW leds from an Arduino (not sure which one yet).
But, I don't want to tie up the processor with the control of the LEDs.
I was thinking of a serial link between my Arduino (probably a Pro-Mini) and a slave ATtiny processor.
The ATtiny can then take over the actual timing and processing.
Does that sound like a reasonable possibility? Not something I have ever tried and I am not really a user of ATtiny chips.
Thanks
Hmm.. doesn't look like you get too many PWM pins on an ATtiny
Why PWM? Are these serial pixel LEDs, like WS2812B or similar, or individual-pin-multicolour LEDs?
If WS2812B or similar, you need a pin per string, OR you need to wire them all in series and run them from one string.
How many items total?
However, how are you talking to the tiny from the Arduino? Serial? Then you need to do the math about how often you intend to make changes to the LEDs. Occasional, sure. Fancy waves of varying colours at eyepopping speeds, don't bother to try.
Why was I thinking they were PWM then?
Well, not super fancy, but I want some level of control.
Basically, I want to control multiple Fastled strips of LEDS (no specific length yet), but I want to take that load off the main processor.
Maybe just a simple Pro-mini linked over serial will do
You tell us 
You are aware that each pixel in a strip eats 4 bytes of RAM?
And that neopixel timing is critical and hence the libraries (FastLED and Adafruit_Neopixel) disable interrupts during the update of the strip which can result in loss of serial data.
What else does that main processor has to do?
I find that "600" WS2812 is near the limit. Much fewer on ATtiny85. You can get a few hundred on MH-ET-tiny88.
A lot of ESP32 with WLED examples are out there, and youtube channel "Chris Maher" does a lot of home lighting.
The main processor is doing some DMX stuff, which is already pretty timing sensitive.
I am happy to run a processor per Led strip if needed, but I do want to be able to drive a decent string of leds... 5m at least
I suggest for easing the dev process that you use regular Arduino boards, so you have easy serial monitoring for informational purposes and way enough resources so that isn't an issue.
Maybe even boards with multiple real UARTs. But serial may not be the best for this exact inter-board communication need. You could use serial in a manner such as to allow exchanging at a somewhat low level the serial implementation for one that used SPI or I2C, for examp,e.
Later if you still want or need to, take the working sketches and embark on the heroic struggle which will be getting them to work on the less powerful chips or boards.
But I am with any who said or hinted that throwing more microprocessors at this may not be necessary or the best way to proceed. You have to marvel at what ppl can do with only one.
a7
Maybe this is a better option?
This is a cool little LED controller
https://electromage.com/
Note that the smart LEDs only "tie up" the processor when you change their values. That's significant if you're doing some sort of animation, but not nearly so much if you're just changing colors "occasionally" (say, once per second or less.)
If you were going to send full data for a strip of LEDs over serial, the overhead would be somewhat higher than the WS2812 protocol (because serial is slower, and you'd probably have enough data to cause it to block.)
If you wanted to define serial commands like "set all to RGB value" or "Rainbow" and perhaps "shift pattern N Leds in Direction", there would potentially be significant savings, but ... you have the difficulty of pre-defining all the commmands.
Sounds like you're looking at individually addressable WS2812 aka neopixels.
You're basically replacing the communication with the LEDs (you just tell them what colour they have to be, after that there's no further communication) with communication with an second Arduino (telling it what colour the LEDs should be, after which it will pass on the message to the LEDs).
I don't see any improvement here, really. On the contrary: now you have to implement a communications protocol and program a second controller to read it and put it into the desired LED info. That's much more work for you, while it's not any less (possibly more, actually) work for the host Arduino.
I only have a few pins left on my main processor, and I wanted to run multiple (individual) strips of Leds.
But, after investigation, it's not going to be all that easy.
I think I may have to have a LED controller that you program separately, and then the main controller just sends basic commands to it (on, off, dim, speed etc)
Here's one approach to address what you seem to want to do.
Given that the interrupt demand of the LED update(~30 us per LED, more or less, * the number of LEDs in series) is too much to tolerate for your main processor, which is doing 'something else'. Have your LED string controller simply wait for a complete block of data, update the LEDs with it, and drop back into the wait.
Your main controller then goes about it's business, and sends a block of data to the LED controller when it wants to - but it does need to know the LED controller is 'waiting for more', so some query is needed.
Something like this would evolve:
Main controller - "Are you ready?"
LED controller - "Yes"
Main controller -
LED controller - /
Main controller repeats "Are you ready", if nak was sent.
if ack was sent, both go about their business
But again, the main advantage here is that the main controller needn't suffer the long sustained interrupt structure of the pixel update(which only ever happens with show() anyway), but then needs to transfer (3*n plus a few) bytes whenever the pixels need updating.
In one case I'm working on, the main controller would only ever be changing one or two LEDs at a time, to one of 6 colours, so this becomes much more feasible - the traffic on the serial bridge is very light, so it becomes quite easy to see benefits from offloading the pixel update to a 'Tiny operating as 'LED coprocessor'. Any update would be "update pixel with colours <x,y,z>", but might take the form of . An 8 byte message where
stx - traditional 'start transmission' character
cc - a single character command
* could be any number of commands. Reset, dim all by 10%, dim all
* to 10%, fade over duration, etc. YMMV
nn - an LED designator, from 0->255, if the context of the command needs it
rrggbb - three byte colour set for an LED, again, if the context needs it
checksum - simply the 8-bit sum of the previous bytes(traditionally, omits stx)
etx - traditional end of transmission character
and the controller simply replies ACK or NAK
ETX, STX, ACK, NAK are all traditional characters in the ASCII chart.
substitute at will, it's just a concept.
I found this. I do have an i2c bus currently available
You are just moving the problem to sending all the data over i2c. From that website:
now, to be fair - its not super fast because we have to write each pixel over I2C, but with a 800KHz or 1MHz I2C clock and as long as you're not writing the whole strip at once, its not so bad!
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.