Shop OBEX P1 Docs P2 Docs Learn Events
Adafruit's Breadboard-friendly RGB Pixels on the QS — Parallax Forums

Adafruit's Breadboard-friendly RGB Pixels on the QS

Buck RogersBuck Rogers Posts: 2,185
edited 2013-12-01 20:49 in Propeller 1
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
leds_Breadboard.jpg
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.

360 x 270 - 43K

Comments

  • Duane DegnDuane Degn Posts: 10,588
    edited 2013-12-01 13:31
    Those NeoPixels are a lot of fun.

    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.
  • Buck RogersBuck Rogers Posts: 2,185
    edited 2013-12-01 18:41
    Duane Degn wrote: »
    Those NeoPixels are a lot of fun.

    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.
  • Duane DegnDuane Degn Posts: 10,588
    edited 2013-12-01 20:12
    and oddly enough the Prop are supposed to be running interpreted code.

    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.
    Everyone's ideas that was applied to that OBEX content tells me that the firm's belief isn't correct.

    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.
  • Buck RogersBuck Rogers Posts: 2,185
    edited 2013-12-01 20:35
    Duane Degn wrote: »
    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.
  • TubularTubular Posts: 4,703
    edited 2013-12-01 20:49
    I haven't had any problems with the prop proto board, and that's after testing with about 10 different styles of led chain from various suppliers, densities etc.

    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)
Sign In or Register to comment.