WS2812 Question
Ray0665
Posts: 231
So I was playing with jm_ws2812 in particular the wheel and wheelx routines
and I was using the rainbow and rainbow_cycle routines in the demo. Now I
understand the wheel routine as selecting a color from the color wheel
represented by the pos parameter pretty straight forward.
But (theres always a but isnt there?) then I ran the rainbow_cycle routine
and I see setx(ch,wheel(ch*256/num_pixels+pos)&$ff) in the inner loop and I see the
colors cycling (I have a 7 unit strip for testing) from light to light. Now since the
parameter given to wheel is ultimately ANDed with $ff it is in the range of
0-255 and the setx reduces to setx(ch,wheel(0..255),lvl) BUT the channel
seems to be changing and if I change the parameter given to wheel() then
the all the lights change in unison and the apparent cycle stops
Am I missing something? is the cycling an illusion? how is the channel
number affected by the parameter to wheel? My old brain is spinning!!
confusion, does not compute, danger will.... Oh sorry I drifted off there
for a moment.
and I was using the rainbow and rainbow_cycle routines in the demo. Now I
understand the wheel routine as selecting a color from the color wheel
represented by the pos parameter pretty straight forward.
But (theres always a but isnt there?) then I ran the rainbow_cycle routine
and I see setx(ch,wheel(ch*256/num_pixels+pos)&$ff) in the inner loop and I see the
colors cycling (I have a 7 unit strip for testing) from light to light. Now since the
parameter given to wheel is ultimately ANDed with $ff it is in the range of
0-255 and the setx reduces to setx(ch,wheel(0..255),lvl) BUT the channel
seems to be changing and if I change the parameter given to wheel() then
the all the lights change in unison and the apparent cycle stops
Am I missing something? is the cycling an illusion? how is the channel
number affected by the parameter to wheel? My old brain is spinning!!
confusion, does not compute, danger will.... Oh sorry I drifted off there
for a moment.
Comments
The channel # is not affected by a call to the wheel() methods. The rainbow type routines simply iterate through a group of pixels. If the color offset is zero, then all pixels will get the same color.
I just got back from a trade show where I had a strip of 49 WS2812s connected to and EFX-TEK controller. In my little demo, I wanted to run a rainbow for five seconds. This is the code that did it.
Note how I'm multiplying the channel number by the pixel-to-pixel spread for the color span I want across the LEDs (255 / 49). I'm using wheelx() to control the brightness level. In my case, I'm decrementing the wheel position index because I wanted the apparent movement to go in a specific direction.
In this demo, the LEDs show the complete spread of wheel(). If, for example, I only wanted the spread to be across two primary colors, I would have changed the spread calculation to 85 / 49 (there are three primary colors; 255 / 3 is 85).
Philosophically, I'm of the opinion that one should send correct values to methods, but those methods should make double-dog sure that parameters are correct, hence the apparent redundancy of ANDing with $FF in multiple places. Once code leaves my hands I cannot control what a person will do with hit, so I try to make it a s error-proof as I can. In my own apps, a lot of that is removed because I have control.
Thanks for the reply and for the driver to play with.
You broke thru four inches of bone in a way I understand.
I was stuck in the mode where I was thinking only color. Making color a function
of the channel and color spread, wonderful walking rainbows appear.
Ray