I haven't got a hue
Erlend
Posts: 612
I would like to control a single WS2812B to set its hue - using it as a status indicator. It would only need to be set/changed when events occur - every few seconds or so. I am PASM-blind, and after having waded through a number of drivers I have found, trying to simplify and extract exactly what I need, I am thinking I am spending too much time getting nowhere. Can anyone help me with a simple solution? - ideally SetHue(pin, hue), where hue is a pointer to a long having the value $RR_GG_BB_WW
Note, I am approaching my 32k limit for the total project, so I need to avoid extensive driver objects.
Erlend
Note, I am approaching my 32k limit for the total project, so I need to avoid extensive driver objects.
Erlend
Comments
An interesting development with the P2 is that you can implement small sections of PASM2 in your Spin code. I used this to create a no-frills output routine for WS2812s.
Again, this is Spin2:
pub ws2812b(pin, count, p_colors) | outval, t0, t1, tc, cycle '' Assumes 24-bit colors are MSB aligned (red in byte3) t0 := (clkfreq / 1_000_000) * 400 / 1000 - 6 ' 0 bit timing t1 := (clkfreq / 1_000_000) * 800 / 1000 - 6 ' 1 bit timing tc := (clkfreq / 1_000_000) * 1250 / 1000 ' cycle ticks @ 800kHz org drvl pin ' make output waitx t0 ' allow reset led_loop rdlong outval, p_colors ' get color add p_colors, #4 ' point to next mov cycle, outval ' swap R & G bytes shr cycle, #16 setbyte outval, cycle, #3 shr cycle, #8 setbyte outval, cycle, #2 getct cycle ' start timing frame rep @.bitz, #24 ' 8 bits x 3 colors rol outval, #1 wc ' get MSB drvh pin ' pin on if_nc waitx t0 ' hold for bit timing if_c waitx t1 drvl pin ' pin off addct1 cycle, tc ' update cycle timer waitct1 ' let cycle finish .bitz djnz count, #led_loop ' do next LED endIt wouldn't be a direct translation but you could pull the PASM code from your favorite driver and stick it into your main object with a couple methods to start and stop it. Since your code is controlling the LED color, all the methods normally included in a standard smart LED object could be chucked out. You can also save a bit of space in the PASM by changing the byte order you send to the driver. Many drivers use RR_GG_BB_WW to simplify creating constants, but the PASM code has to swap the red and green bytes. If you send GG_RR_BB_XX to the embedded driver then you can save a bit of code there.I wrote the code a bit more generically than you asked. You can add your set_hue() method like this:
pub set_hue(pin, rgbx) | color color.byte[3] := rgbx.byte[2] ' red/green swap color.byte[2] := rgbx.byte[3] color.byte[1] := rgbx.byte[1] ws2812b_update(pin, 1, @color)ws2812b_update(pin, 1, @color)The WHITE2 did not seem to work for this led, so I took that one out. For anyone interested this is the table:DAT ' GG RR BB WW BLACK LONG $00_00_00_00 RED LONG $00_FF_00_00 GREEN LONG $FF_00_00_00 BLUE LONG $00_00_FF_00 WHITE LONG $FF_FF_FF_00 CYAN LONG $FF_00_FF_00 MAGENTA LONG $00_FF_FF_00 YELLOW LONG $FF_FF_00_00 CHARTREUSE LONG $FF_7F_00_00 ORANGE LONG $60_FF_00_00 AQUAMARINE LONG $FF_7F_D4_00 PINK LONG $5F_FF_5F_00 TURQUOISE LONG $E0_3F_C0_00 REALWHITE LONG $FF_C8_FF_00 INDIGO LONG $00_3F_7F_00 VIOLET LONG $7F_BF_BF_00 MAROON LONG $00_32_10_00 BROWN LONG $06_0E_00_00 CRIMSON LONG $28_DC_3C_00 PURPLE LONG $00_8C_FF_00Erlend
Also in lockdown.
Have fun, and stay healthy.
Thanks, and double thanks, and same good wishes to you.
I am tempted to continue your color prose... but now's dinner time. Chartreuse by the way is also the name and color of a very nice liquor made traditionally by French monks.
I've been involved with projects where status or event needed to be communicated, and in most cases subtlety in color discrimination was not desirable. For one example, wildland fire fighters carried an armband that indicated threshold levels of smoke exposure. The simple green, yellow and red had to be supplemented with a geometric pattern formed of several LEDs, green dot, yellow square, bright red X, so that the meaning could be picked up at a glance. Also, so that persons with red/green or other color blindness would have a primary que besides the hue. I've used a single RGB Led for similar purposes, where the additional que of what is true was a flashing or pulsating pattern.
I do not plead guilty.
My 'hue indicator' is not the primary (or critical) source of information. It is intended as a 'shortcut', such that when the user (repeatedly) want to make a menu selection, a hue is visible accordingly. The user will/can after a while, having noticed the association of a hue with a menu item, simply turn the knob until the desired hue is shone, and push the knob to activate. Or - for the color blind - continue to read the menu text before making a selection.
I can see your scheme nicely in context with a display shortcut. I don't mean to criticize! I'm interested and have used RGB leds (but not the smart kind) for color signals too, coupled with a text display and sound cues. It is effective and a lot of fun to play with. A university project on "behavioral intervention" even got to the point of using a focus group to parse the colors and sounds.
I also have fun experimenting with different combinations of sensory communication (been looking for a simple smell-generator, but may have to build it myself) in order to connect man-machine on a more intuitive level.