Adafruit's Breadboard-friendly RGB Pixels on the QS
Buck Rogers
Posts: 2,185
Hello!
I have successfully used the available code for running the pixels. Currently its tweaking one so far but it should work with the four I have added the pins to.
They are listed here http://www.adafruit.com/products/1312
And are shown here they are the same RGB LEDs and driver chips as the ones found on the chain of pixels and drivers that the program was written for.
As shown here:
Not surprisingly I bought two sets from them the same time as when this program was written.
I have successfully used the available code for running the pixels. Currently its tweaking one so far but it should work with the four I have added the pins to.
They are listed here http://www.adafruit.com/products/1312
And are shown here they are the same RGB LEDs and driver chips as the ones found on the chain of pixels and drivers that the program was written for.
As shown here:
'' ================================================================================================= '' '' File....... jm_ws2812_demo.spin '' Purpose.... WS2812 demonstration program '' Author..... Jon "JonnyMac" McPhalen '' Copyright (c) 2013 Jon McPhalen '' -- see below for terms of use '' E-mail..... jon@jonmcphalen.com '' Started.... '' Updated.... 08 SEP 2013 '' '' ================================================================================================= con { timing } _clkmode = xtal1 + pll16x ' 16x required for WS2812 _xinfreq = 5_000_000 ' use 5MHz crystal CLK_FREQ = ((_clkmode - xtal1) >> 6) * _xinfreq ' system freq as a constant MS_001 = CLK_FREQ / 1_000 ' ticks in 1ms US_001 = CLK_FREQ / 1_000_000 ' ticks in 1us con { io pins } RX1 = 31 ' programming / terminal TX1 = 30 SDA = 29 ' eeprom / i2c SCL = 28 LEDS = 15 ' LED tx pin obj strip : "jm_ws2812" ' WS2812 LED driver var dat Chakras long strip#RED, strip#ORANGE, strip#YELLOW long strip#GREEN, strip#BLUE, strip#INDIGO pub main | pos strip.start(LEDS, 3) ' start led driver (3 leds) pause(10) repeat 10 color_chase(@Chakras, 6, 100) repeat repeat pos from 0 to 255 strip.set_all(wheelx(pos, 128)) ' 1/2 brightness pause(20) pub color_chase(p_colors, len, ms) | base, idx, ch '' Performs color chase repeat base from 0 to len-1 ' do all colors in table idx := base ' start at base repeat ch from 0 to strip.num_pixels-1 ' loop through connected leds strip.set(ch, long[p_colors][idx]) ' update channel color if (++idx == len) ' past end of list? idx := 0 ' yes, reset pause(ms) ' set movement speed con ' Routines ported from C code by Phil Burgess (www.paintyourdragon.com) pub color_wipe(rgb, ms) | ch '' Sequentially fills strip with color rgb '' -- ms is delay between pixels, in milliseconds repeat ch from 0 to strip.num_pixels-1 strip.set(ch, rgb) pause(ms) pub rainbow(ms) | pos, ch repeat pos from 0 to 255 repeat ch from 0 to strip.num_pixels-1 strip.set(ch, wheel((pos + ch) & $FF)) pause(ms) pub rainbow_cycle(ms) | pos, ch repeat pos from 0 to (255 * 5) repeat ch from 0 to strip.num_pixels-1 strip.set(ch, wheel(((ch * 256 / strip.num_pixels) + pos) & $FF)) pause(ms) pub wheel(pos) '' Creates color from 0 to 255 position input '' -- colors transition r->g->b back to r if (pos < 85) return strip.color(255-pos*3, pos*3, 0) elseif (pos < 170) pos -= 85 return strip.color(0, 255-pos*3, pos*3) else pos -= 170 return strip.color(pos*3, 0, 255-pos*3) pub wheelx(pos, level) ' update by JonnyMac '' Creates color from 0 to 255 position input '' -- colors transition r-g-b back to r '' -- level is brightness, 0 to 255 if (pos < 85) return strip.colorx(255-pos*3, pos*3, 0, level) elseif (pos < 170) pos -= 85 return strip.colorx(0, 255-pos*3, pos*3, level) else pos -= 170 return strip.colorx(pos*3, 0, 255-pos*3, level) con { ------------- } { B A S I C S } { ------------- } pub pause(ms) | t '' Delay program in milliseconds if (ms < 1) ' delay must be > 0 return else t := cnt - 1776 ' sync with system counter repeat ms ' run delay waitcnt(t += MS_001) pub high(pin) '' Makes pin output and high outa[pin] := 1 dira[pin] := 1 pub low(pin) '' Makes pin output and low outa[pin] := 0 dira[pin] := 1 pub toggle(pin) '' Toggles pin state !outa[pin] dira[pin] := 1 pub input(pin) '' Makes pin input and returns current state dira[pin] := 0 return ina[pin] dat {{ Terms of Use: MIT License Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. }}
Not surprisingly I bought two sets from them the same time as when this program was written.
Comments
One thing to watch out for is the NeoPixels don't always work well with the Propeller's 3.3V logic. You can see a few glitches in the first video of this thread and I found the glitches got a lot worse when I used a switching regulator.
A logic level shifter cleared up the glitches.
This reminds me, I need to update my NeoPixel thread. Yesterday I populated a 16 pixel PCB I had made at OSH Park. I need to show the world my version of a NeoPixel ring.
Hello!
Worked well enough. I did see a few glitches, but as the program ran they went away and the display of colors was cleaner then when running on either an Arduino Uno or on the one that's adapted from the original Arduino, the one that came out around the middle of 2009, and sat in an Altoids tin.
Still haven't figured out what the lady has against applying her pixels to a RasPi. I concede it would be an interesting problem to write code to do that. And I'm told an Netduino2 needs to have its core code specially written just for that process, otherwise the Netduino (first version) can't be applied there. It's supposed to be a timing thing, since those two, and oddly enough the Prop are supposed to be running interpreted code.
Everyone's ideas that was applied to that OBEX content tells me that the firm's belief isn't correct.
The driver for the LEDs isn't running interpreted code. It's PASM and wouldn't work if it were written in Spin. The WS2812 LEDs have very strict timing requirements which is hard for a lot of microcontrollers to meet.
Since the Propeller driver runs in its own cog, the LEDs are being continuously updated. This lets the master loop leisurely manipulate the bytes (and longs) in the buffers holding the color information.
This is one of those applications were the Propeller really shines when compared with other microcontrollers.
My guess the reluctance to trying to use a RasPi to control the NeoPixels is the RasPi may not have very tight timing on its I/O pins. If an interrupt came in while it's sending out bits to the LED, I'd think it would corrupt the data. Since there's no clock line, the data line has to be controlled very precisely.
Who's "everyone" and who is "the firm"? And what is the incorrect belief held by the firm?
BTW, These WS2812 LEDs also come in a "B" version. The "B" version has four leads instead of six and are presumably easier to solder than the six lead version. I haven't tried soldering the six lead version but I have a variety of PCBs designed for the "B" version and they seem to be reasonably easy to solder.
Hello!
In this case it is the company who makes these breadboard friendly devices, Adafruit. They and Sparkfun tend to overlap here, but Adafruit leads in making these, and the company also sells a remarkable series of pixels that are easier to bundle into the classic rolling marque type signage that there's too much of on store fronts.
Everyone in this case was largely the people behind Limor Fried the person who founded that company. The code comments that it contains a translation of the controlling C based code that Phillip Burgess who works with her wrote.
And regarding the RasPi, I'm not going to doubt yourself or them.
What I do is run with a 5vdc wall wart into the DC jack. While the DC jack normally expects 7~12v dc, it works fine at 5v, but the 5v regulator can't regulate and puts out a lower voltage (that the 3v3 still regulates to 3v3). I put the servo jumper on "Vin" setting (not 5v setting) to feed the PSU's 5v out to the led strips out the servo port. That way you can still use position 2 of the switch to turn on the led strip
I've been using that setup for 6 months or more, successfully. I did some early checks to see the voltage drop across the various parts of the circuit, such as the switch and the filter inductor feeding the servo output pins. I remember concluding it was probably good to an amp or two, ie about 40 leds or one of those adafruit neopixel shields. I should really revisit that given we're getting close to Christmas, and the prop is great at driving these strips (or multiples of these strips)