Thanks for your TC4427 circuit and the new LED driver. I got my RGBW ring today and the driver works fine with both my original RGB ring and the new RGBW ring. In fact, it even works with the circuit built on the PAB breadboard but I intend to transfer it to one of the Parallax PAB overlay boards next. After that, I'll try using your PASM code from C/C++. Thanks for all of your work on this!
I'm glad you and others are finding it useful.
in fact, right after I posted that message, my son asked me to make him a box that would simulate flames. I'm not sure if I can get enough intensity out of the NeoPixels but I'm going to give it a shot. The idea is to create a flame-like effect that would reflect on a cave wall and look like there is a fire behind the camera.
I've done that many times -- in fact, I wrote about it last year in Nuts & Volts magazine (Halloween issue). The key is to suggest flames, because they're impossible to accurately simulate with LEDs.
Here's one of my bigger Propeller-powered flame simulation/suggestions.
This is in the lobby of Riot Games in Santa Monica. The display was built by Steve Wang's team at Alliance Studios. It uses an EFX-TEK HC-8+ controller running several flame and embers cogs, and that data is being pumped out to small DMX bricks.
I've done that many times -- in fact, I wrote about it last year in Nuts & Volts magazine (Halloween issue). The key is to suggest flames, because they're impossible to accurately simulate with LEDs.
Here's one of my bigger Propeller-powered flame simulation/suggestions.
This is in the lobby of Riot Games in Santa Monica. The display was built by Steve Wang's team at Alliance Studios. It uses an EFX-TEK HC-8+ controller running several flame and embers cogs, and that data is being pumped out to small DMX bricks.
Unfortunately, my collection of Nuts & Volts only goes back to October 2015. I assume the Halloween issue was the September issue.
pub color_wipe(p_pixels,rgb, ms) | ch
'' Sequentially fills strip with color rgb
'' -- ms is delay between pixels, in milliseconds
repeat ch from 0 to STRIP_LEN-1
strip.use(p_pixels, STRIP_LEN, LEDA, BPP_A)
strip.set(ch, rgb)
repeat until (strip.okay)
strip.use(p_pixels+(STRIP_LENA*4), STRIP_LEN, LEDB, BPP_B)
time.pause(ms)
Now that it is running on two strips I'm trying to see if I can make it run on any number of strips that the may be needed
I got an SK6812 strip with warm white and tried the driver. Everything is working well. Thanks for posting this. I guess I have some under cabinet soldering to do today.
I probably did -- it's become one of my favorite devices. It's even available in DIP format which lets you hand build adapters. BTW... for high speed signals you should avoid breadboards (like that on the PAB); all those metal plates mean extra capacitance which can foul high-speed signals.
Seems I just found this to be the case. I had placed the TC4427 on a breadboard and a scope on the output of the TC4427 seemed to show only a reset time followed by a time which was variable based upon the number of pixels I told the program to drive. No high speed signals which I would have suspected to be there for 24 bit color. The waveform was rock solid but certainly not what the WS2812's expected.
Removing the TC4427 and driving the WS2812b directly from my QuickStart board worked like a champ with all the demo routines functioning perfectly. The breadboard not only fouled the HS signals but must have swamped them completely.
The driver software seems to be rock solid.
Now on to figuring out how to make a 200 pixel string look like an Aurora Borealis when bounced off a white wall behind a Christmas village display.
I probably did -- it's become one of my favorite devices. It's even available in DIP format which lets you hand build adapters. BTW... for high speed signals you should avoid breadboards (like that on the PAB); all those metal plates mean extra capacitance which can foul high-speed signals.
Seems I just found this to be the case. I had placed the TC4427 on a breadboard and a scope on the output of the TC4427 seemed to show only a reset time followed by a time which was variable based upon the number of pixels I told the program to drive. No high speed signals which I would have suspected to be there for 24 bit color. The waveform was rock solid but certainly not what the WS2812's expected.
Removing the TC4427 and driving the WS2812b directly from my QuickStart board worked like a champ with all the demo routines functioning perfectly. The breadboard not only fouled the HS signals but must have swamped them completely.
The driver software seems to be rock solid.
Now on to figuring out how to make a 200 pixel string look like an Aurora Borealis when bounced off a white wall behind a Christmas village display.
I'm working with SK6812 strips and getting useless output.
I could get my strips working with the another sk6812 demo, but that object can only support 256 LEDs. I made a display at 288 LEDs. When I tried to force it over the 256 mark it just locks up randomly.
Are you using the driver attached to the first post in this thread? It contains this method which will work with 24- and 32-bit SK6812 LEDs.
pub start_6812x(p_buf, pixels, pin, holdoff, bits)
'' Start pixel driver for SK6812RBGW LEDs
'' -- p_buf is pointer to [long] array holding pixel data
'' -- count is # of pixels supported by array at p_buf
'' -- pin is serial output to SK6812x string
'' -- holdoff is the delay between data bursts
'' * units are 100us (0.1ms) 10 units = 1ms
'' -- bits is 24 for SK6812, or 32 for SK6812RGBW
return startx(p_buf, pixels, pin, holdoff, true, bits, 300, 900, 600, 600)
The timing parameters are pre-set. You need to provide a pointer to your color buffer (can be up to 1024 longs now), the number pixels in your string, the pin to use, the hold-of period (typically 10 which gives 1ms), and the number of bits (you would use 24 for standard SK6812 LEDs).
If you are going directly from the Propeller to the string you'll want to keep that connection short. Also, do not use a connection from a breadboard as the added capacitance of the breadboard will foul the signal.
I can tell you for a fact your program won't work: you have mismatches in names. FWIW, I only use p_ at the front of a variable when it is intended to hold a pointer (the address of) another variable.
Here is corrected code in my style. I am writing about this driver for my March column and I have a test strip of SK6812RGBW LEDs connected. Note that the .use() method is only required when you want to change something about the driver (e.g., output pin or buffer used). I have run this code and it does work: the strip lights green.
con { timing }
_clkmode = xtal1 + pll16x
_xinfreq = 5_000_000 ' use 5MHz crystal
CLK_FREQ = (_clkmode >> 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 = 1 ' LED strip
con
STRIP_LEN = 288
obj
' main ' * master Spin cog
time : "jm_time" ' timing and delays
strip : "jm_rgbx_pixel" ' * unified pixel driver
var
long pixels1[STRIP_LEN]
pub main
setup
longfill(@pixels1, $00_20_00_00, STRIP_LEN) ' dim green
repeat
waitcnt(0)
pub setup
'' Setup IO and objects for application
time.start ' setup timing & delays
strip.start_6812x(@pixels1, STRIP_LEN, LEDS, 1_0, 32) ' for SK6812RGBW pixels
Comments
Here's one of my bigger Propeller-powered flame simulation/suggestions.
This is in the lobby of Riot Games in Santa Monica. The display was built by Steve Wang's team at Alliance Studios. It uses an EFX-TEK HC-8+ controller running several flame and embers cogs, and that data is being pumped out to small DMX bricks.
http://www.nutsvolts.com/magazine/article/September2015_McPhalen
They will also let you preview a few pages from each issue. Click the "View Digital Edition" button.
Really happy with the results.
Starts at the end of the second strip and runs backwards to the first pixel on the first strip.
Same setup as earlier post.
count := (STRIP_LEN * 2) + 1 if (RGBW == YES) count += STRIP_LEN repeat 3 p_pixels := @pixels1 repeat count strip.use(p_pixels, STRIP_LENA, LEDA, BPP_A) repeat until (strip.okay) strip.use(p_pixels+(STRIP_LENA*4), STRIP_LENB, LEDB, BPP_B) time.pause(100) p_pixels += 4Color wipe runs from the first pixel on the first strip to the last pixel on the second strip.
repeat 3 color_wipe(p_pixels,$10_00_00_00, 500/STRIP_LEN) color_wipe(p_pixels,$00_10_00_00, 500/STRIP_LEN) color_wipe(p_pixels,$00_00_10_00, 500/STRIP_LEN) if (RGBW == YES) color_wipe(p_pixels,$00_00_00_10, 500/STRIP_LEN)pub color_wipe(p_pixels,rgb, ms) | ch '' Sequentially fills strip with color rgb '' -- ms is delay between pixels, in milliseconds repeat ch from 0 to STRIP_LEN-1 strip.use(p_pixels, STRIP_LEN, LEDA, BPP_A) strip.set(ch, rgb) repeat until (strip.okay) strip.use(p_pixels+(STRIP_LENA*4), STRIP_LEN, LEDB, BPP_B) time.pause(ms)Now that it is running on two strips I'm trying to see if I can make it run on any number of strips that the may be needed
Very professional looking.
Can you do something about upcoming elections?
Seems I just found this to be the case. I had placed the TC4427 on a breadboard and a scope on the output of the TC4427 seemed to show only a reset time followed by a time which was variable based upon the number of pixels I told the program to drive. No high speed signals which I would have suspected to be there for 24 bit color. The waveform was rock solid but certainly not what the WS2812's expected.
Removing the TC4427 and driving the WS2812b directly from my QuickStart board worked like a champ with all the demo routines functioning perfectly. The breadboard not only fouled the HS signals but must have swamped them completely.
The driver software seems to be rock solid.
Now on to figuring out how to make a 200 pixel string look like an Aurora Borealis when bounced off a white wall behind a Christmas village display.
Long time no see, welcome back!
I'm working with SK6812 strips and getting useless output.
I could get my strips working with the another sk6812 demo, but that object can only support 256 LEDs. I made a display at 288 LEDs. When I tried to force it over the 256 mark it just locks up randomly.
The timing parameters are pre-set. You need to provide a pointer to your color buffer (can be up to 1024 longs now), the number pixels in your string, the pin to use, the hold-of period (typically 10 which gives 1ms), and the number of bits (you would use 24 for standard SK6812 LEDs).
If you are going directly from the Propeller to the string you'll want to keep that connection short. Also, do not use a connection from a breadboard as the added capacitance of the breadboard will foul the signal.
Wouldn't ya know it. I started going through the code again for the this post and found an error.
This is what have to make a working green tower. So I guess it's working.
con _clkmode = xtal1 + pll16x _xinfreq = 5_000_000 STRIP_PIN = 1 STRIP_LEN = 288 BPP_A = 32 var long p_pixels1[STRIP_LEN] obj time : "jm_time" strip : "jm_rgbx_pixel" pub main strip.start_6812x(@p_pixels1, STRIP_LEN, STRIP_PIN, 200, BPP_A) longfill(@pixels1, $00_20_00_00, STRIP_LEN) strip.use(@pixels1, STRIP_LEN, STRIP_PIN, BPP_A)Here is corrected code in my style. I am writing about this driver for my March column and I have a test strip of SK6812RGBW LEDs connected. Note that the .use() method is only required when you want to change something about the driver (e.g., output pin or buffer used). I have run this code and it does work: the strip lights green.
con { timing } _clkmode = xtal1 + pll16x _xinfreq = 5_000_000 ' use 5MHz crystal CLK_FREQ = (_clkmode >> 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 = 1 ' LED strip con STRIP_LEN = 288 obj ' main ' * master Spin cog time : "jm_time" ' timing and delays strip : "jm_rgbx_pixel" ' * unified pixel driver var long pixels1[STRIP_LEN] pub main setup longfill(@pixels1, $00_20_00_00, STRIP_LEN) ' dim green repeat waitcnt(0) pub setup '' Setup IO and objects for application time.start ' setup timing & delays strip.start_6812x(@pixels1, STRIP_LEN, LEDS, 1_0, 32) ' for SK6812RGBW pixelsThanks for the help.