I found a small "gotcha" in the drivers that support 32-bit pixels. BIT31 of the mailbox value is used as a flag and I wasn't masking that off when extracting the transmit pin which is passed in the next five bits (BIT30..BIT26). Updates posted above.
Yes, those will work with the consolidated driver! I'm testing using that same one right now. I do want to point out that they are 6812rgbw. I believe the info on the Adafruit website indicating that they are the same as 2812b is copy pasta from the rgb version of that product.
I have a 16 RGBW ring on order. I'll try the driver on that and my old RGB rings when the new one arrives and also try using the PASM code with a C and/or C++ wrapper as well. I suppose I should just translate Jon's code using spin2cpp but I would rather write my own.
Doing a little testing with multiple types of strips in one system using the neopixel demo and the consolidated driver. I am finding it necessary to manually put in a delay between calling the "use" functions. (please excuse incorrect terminology)
Okay. I made another change. There is a new method called .okay() which returns true when the new connection details have been picked up by the PASM cog. Here's how you would use it in place of the delay between .use() methods.
So, are those RGBW really all that? I had always hoped they would add a yellow LED. Is it feasible to augment a warm RGBW with the RGB elements making a cool white color?
The last buffer assigned to the LEDs is pixels3 which held blue up at the top for the buffer switching demo. At the bottom of your demo loop the .clear() method is operating on pixels3 which means the blue array is being erased. If you move the buffer filling into the loop the problem will go away.
I got back to this tonight, thanks for the explanation. I see how the buffers in the new driver work.
I like to use the TC4427 MOSFET driver as a level shifter; it provides very stiff output. At EFX-TEK we have been building it into products like the HC-8+ and our new AP-8+ so that users can drive servos, pixels, and other 5V loads. I tested my new driver code using a prototype AP-8+. While I can get WS2812b pixels to work directly from the PAB (3.3v out), the SK6812s would not.
I like to use the TC4427 MOSFET driver as a level shifter; it provides very stiff output. At EFX-TEK we have been building it into products like the HC-8+ and our new AP-8+ so that users can drive servos, pixels, and other 5V loads. I tested my new driver code using a prototype AP-8+. While I can get WS2812b pixels to work directly from the PAB (3.3v out), the SK6812s would not.
I think you recommended that to me before. Sorry to have had to ask a second time. Sorry also for being a hardware dunce but do I need any external components or do I just connect the input to the Propeller pin, the output to the NeoPixel chain and VDD to 5V?
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.
I've attached a schematic for driving pixel chains.
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.
I've attached a schematic for driving pixel chains.
Jon, what a marvelously well documented program and quite clever.
After 1 stroke and 3 stop/restarts on my heart, I am trying to get back into the propeller world and needed a driver for the WS2812s. Your great documentation is helping me immensely rebuilding my memory on the Propeller.
I went line by line in your assembly routine and it was very clear what you had done.
Now to the SPIN portion which was never my strong suit. Again, your documentation will be invaluable.
I had a bunch of these WS2811s left over from a MegaTree project 3 years back and want to place about 10 feet of them behind a bunch of small buildings in a Christmas scene display and want to create two scenes.
1) Just a solid back light, dim-able, with the ability to alter the apparent color temperature. Static display. [baby steps]
2) An Aurora Borealis like display behind the buildings with some movement to simulate an Aurora Borealis. [after the baby steps]
Not looking for any assistance at this point but just wanted you to know about another use of your driver.
Jon, what a marvelously well documented program and quite clever.
After 1 stroke and 3 stop/restarts on my heart, I am trying to get back into the propeller world and needed a driver for the WS2812s. Your great documentation is helping me immensely rebuilding my memory on the Propeller.
I went line by line in your assembly routine and it was very clear what you had done.
Now to the SPIN portion which was never my strong suit. Again, your documentation will be invaluable.
I had a bunch of these WS2811s left over from a MegaTree project 3 years back and want to place about 10 feet of them behind a bunch of small buildings in a Christmas scene display and want to create two scenes.
1) Just a solid back light, dim-able, with the ability to alter the apparent color temperature. Static display. [baby steps]
2) An Aurora Borealis like display behind the buildings with some movement to simulate an Aurora Borealis. [after the baby steps]
Not looking for any assistance at this point but just wanted you to know about another use of your driver.
Thanks!
Thank you for the kind note, and I'm very pleased you'r back with us -- hopefully, any health difficulties are now a thing of the past.
I always try to write simple, straightforward code. Like many, I have benefited from good ideas and the council of others in these forums.
Have fun with the driver. I was just working with it on a client project this morning.
JonnyMac
Have you posted this as yet on the OBEX?
I've been following along and am very interested.
I'm more of a lurker on this type of subject, because my skills are not good enough to make intelligent comments.
I have a small project I'm working on using the old driver you had placed on the OBEX, but am having troubles getting the colors I want consistently.
When this driver is in good shape to place on OBEX, I would like to try it.
..
Thanks
Gary
Not yet. I try not to post there until I feel like an object is fully wrung out. As this one incorporated requests from others, I have been waiting a little extra time.
The driver is in good shape now; no need to wait for me to move to ObEx.
So, are those RGBW really all that? I had always hoped they would add a yellow LED. Is it feasible to augment a warm RGBW with the RGB elements making a cool white color?
I was never really happy with the white color I got from mixing RGB and there seamed to always be weird RGB shadows. The warm white gives me very usable task lighting for my project. I haven't done a lot color mixing with white yet but it supposed to be able to create nice pastel colors.
Okay. I made another change. There is a new method called .okay() which returns true when the new connection details have been picked up by the PASM cog.
.okay() is GREAT!
I'm doing a few more multi strip tests this weekend. Wrapping my brain around the colorwipe and rainbow routines in a multi strip project. Almost got it I think.
I may change .okay() to .connected() as that makes more sense when reading code.
I'm glad the driver is working for you.
And exactly decisions like that is what makes your code so easy to read. I am programming most of my life but bow deep to you every time I go thru your examples. You are truly a artist, making listings of code beautiful to read and to learn from.
I may change .okay() to .connected() as that makes more sense when reading code.
I'm glad the driver is working for you.
And exactly decisions like that is what makes your code so easy to read. I am programming most of my life but bow deep to you every time I go thru your examples. You are truly a artist, making listings of code beautiful to read and to learn from.
thank you for this.
Mike
Thank you, Mike, that is very kind and means a lot to me, because I consider myself first, and foremost, an artist. My friend Steve Wang (he created the Predator and a lot of other well-known movie creatures) once said to me, "You paint with light and ones and zeroes." That made me smile, too. I do put considerable time into my code so that it looks and reads as well as it works.
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.
I've attached a schematic for driving pixel chains.
As of tomorrow I will have collected all of the parts I need to test both RGB and RGBW LEDs using your new driver. However, I'm wondering if I will run into trouble if I try to implement your suggested circuit on a breadboard. When you mention that I should avoid breadboards for high-speed signals, were you suggesting that the signals needed to drive these LED chains fits into that category? If so, how would you suggest building the circuits short of having a custom PCB made?
When you mention that I should avoid breadboards for high-speed signals, were you suggesting that the signals needed to drive these LED chains fits into that category?
Yes. The signal is 800kHz which, in my experience, doesn't play well with the capacitance created by the parallel metal plates in the breadboard.
The Overlay Board is a better way to go. My friend Matt had me create a stand-lone TC4427 board for him so that he could deploy them anywhere he needs. It's tiny, and useful.
I just created a PAB shield for a client -- no surprise, it has my two favorite interface circuits:1) TC4427, and 2) bi-directional level shifter with FETs for a secondary I2C buss.
When you mention that I should avoid breadboards for high-speed signals, were you suggesting that the signals needed to drive these LED chains fits into that category?
Yes. The signal is 800kHz which, in my experience, doesn't play well with the capacitance created by the parallel metal plates in the breadboard.
The Overlay Board is a better way to go. My friend Matt had me create a stand-lone TC4427 board for him so that he could deploy them anywhere he needs. It's tiny, and useful.
I just created a PAB shield for a client -- no surprise, it has my two favorite interface circuits:1) TC4427, and 2) bi-directional level shifter with FETs for a secondary I2C buss.
Thanks! I'll use the overlay board. It will let me supply the 5V from the PAB. There will probably be enough power to drive my two 16 LED rings.
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!
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!
Comments
Yes, those will work with the consolidated driver! I'm testing using that same one right now. I do want to point out that they are 6812rgbw. I believe the info on the Adafruit website indicating that they are the same as 2812b is copy pasta from the rgb version of that product.
I guess you have to pick the driver based on what they ship.
I though only the SK6812 would drive the RGBW.
Off topic: Every time I go to the Adafruit site, Chrome slows to a crawl and I have to kill it. Is anyone else having this issue?
Doing a little testing with multiple types of strips in one system using the neopixel demo and the consolidated driver. I am finding it necessary to manually put in a delay between calling the "use" functions. (please excuse incorrect terminology)
Setup:
LEDA = 1 ' LED tx pin LEDB = 2 con #0, NO, YES RGBW = YES BPP_A = 32 BPP_B = 24 STRIP_LEN = 35 STRIP_LENA = 24 STRIP_LENB = 11Bad results:
repeat 3 ' demonstrate buffer switching strip.use(@pixels1, STRIP_LENA, LEDA, BPP_A) strip.use(@pixels1, STRIP_LENB, LEDB, BPP_B) time.pause(500) strip.use(@pixels2, STRIP_LENA, LEDA, BPP_A) strip.use(@pixels2, STRIP_LENB, LEDB, BPP_B) time.pause(500) strip.use(@pixels3, STRIP_LENA, LEDA, BPP_A) strip.use(@pixels3, STRIP_LENB, LEDB, BPP_B) time.pause(500) if (RGBW == YES) strip.use(@pixels4, STRIP_LENA, LEDA, BPP_A) time.pause(500)Good results:
repeat 3 ' demonstrate buffer switching strip.use(@pixels1, STRIP_LENA, LEDA, BPP_A) time.pause(5) strip.use(@pixels1, STRIP_LENB, LEDB, BPP_B) time.pause(500) strip.use(@pixels2, STRIP_LENA, LEDA, BPP_A) time.pause(5) strip.use(@pixels2, STRIP_LENB, LEDB, BPP_B) time.pause(500) strip.use(@pixels3, STRIP_LENA, LEDA, BPP_A) time.pause(5) strip.use(@pixels3, STRIP_LENB, LEDB, BPP_B) time.pause(500) if (RGBW == YES) strip.use(@pixels4, STRIP_LENA, LEDA, BPP_A) time.pause(500)Everything else is exactly the same as the demo.
Certainly a perfectly acceptable fix but thought I would document it and point it out.
repeat ' demonstrate buffer switching strip.use(@pixels1, STRIP_LEN1, LEDS1, BPP1) repeat until (strip.okay) strip.use(@pixels1, STRIP_LEN2, LEDS2, BPP2) time.pause(500) strip.use(@pixels2, STRIP_LEN1, LEDS1, BPP1) repeat until (strip.okay) strip.use(@pixels2, STRIP_LEN2, LEDS2, BPP2) time.pause(500) strip.use(@pixels3, STRIP_LEN1, LEDS1, BPP1) repeat until (strip.okay) strip.use(@pixels3, STRIP_LEN2, LEDS2, BPP2) time.pause(500) if (RGBW == YES) strip.use(@pixels4, STRIP_LEN1, LEDS1, BPP1) repeat until (strip.okay) strip.use(@pixels4, STRIP_LEN2, LEDS2, BPP2) time.pause(500)The jm_rgbx_pixel.spin driver seems to cover all bases, so I dumped the others.I got back to this tonight, thanks for the explanation. I see how the buffers in the new driver work.
I've attached a schematic for driving pixel chains.
I see they have been replaced with a 5mm version.
After 1 stroke and 3 stop/restarts on my heart, I am trying to get back into the propeller world and needed a driver for the WS2812s. Your great documentation is helping me immensely rebuilding my memory on the Propeller.
I went line by line in your assembly routine and it was very clear what you had done.
Now to the SPIN portion which was never my strong suit. Again, your documentation will be invaluable.
I had a bunch of these WS2811s left over from a MegaTree project 3 years back and want to place about 10 feet of them behind a bunch of small buildings in a Christmas scene display and want to create two scenes.
1) Just a solid back light, dim-able, with the ability to alter the apparent color temperature. Static display. [baby steps]
2) An Aurora Borealis like display behind the buildings with some movement to simulate an Aurora Borealis. [after the baby steps]
Not looking for any assistance at this point but just wanted you to know about another use of your driver.
Thanks!
I always try to write simple, straightforward code. Like many, I have benefited from good ideas and the council of others in these forums.
Have fun with the driver. I was just working with it on a client project this morning.
Have you posted this as yet on the OBEX?
I've been following along and am very interested.
I'm more of a lurker on this type of subject, because my skills are not good enough to make intelligent comments.
I have a small project I'm working on using the old driver you had placed on the OBEX, but am having troubles getting the colors I want consistently.
When this driver is in good shape to place on OBEX, I would like to try it.
..
Thanks
Gary
The driver is in good shape now; no need to wait for me to move to ObEx.
I'll give it a spin over the next few days.
Gary
I was never really happy with the white color I got from mixing RGB and there seamed to always be weird RGB shadows. The warm white gives me very usable task lighting for my project. I haven't done a lot color mixing with white yet but it supposed to be able to create nice pastel colors.
.okay() is GREAT!
I'm doing a few more multi strip tests this weekend. Wrapping my brain around the colorwipe and rainbow routines in a multi strip project. Almost got it I think.
I'm glad the driver is working for you.
And exactly decisions like that is what makes your code so easy to read. I am programming most of my life but bow deep to you every time I go thru your examples. You are truly a artist, making listings of code beautiful to read and to learn from.
thank you for this.
Mike
Again, thank you for your kindness.
Edit: Would this be better for this project than a breadboard? https://www.parallax.com/product/32999
The Overlay Board is a better way to go. My friend Matt had me create a stand-lone TC4427 board for him so that he could deploy them anywhere he needs. It's tiny, and useful.
I just created a PAB shield for a client -- no surprise, it has my two favorite interface circuits:1) TC4427, and 2) bi-directional level shifter with FETs for a secondary I2C buss.
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.