Hey @Rakesh thanks! First question is which strip exactly do you have? If it’s like this one https://www.adafruit.com/products/2439 then it appears the whole strip is controlled all at once with high voltage and mosfets (driven via PWM). So you may not need a library to drive it, but just some good old PWM outputs. Check out Adafruit’s tutorial on how to wire and code these types of strips: https://learn.adafruit.com/rgb-led-strips
If I’m totally off about what you have, please point me to the datasheet for your LED strip and I can give you some better advice
Hi BDub,
The LEDs I have are similar to the link posted by Hootie81, just a lower pixel density(60/m)
They are like the adressable SMD5050 RGB LEDs. The RGBW LEDs I have work with the current Arduino neopixel library+Arduino, as there is support for RGBW there. I was looking through the code and the inline asm code is different from the neopixel library for the photon.
I am just trying to understand how the current neopixel library for photon works, and if I can do something simple to add a 4th pixel to the current code and have the setpixelcolor function accept 4 input values.
It looks like it’s as simple as adding a 4th byte for the white LED on all pixels. Currently there are only 24 bits sent per byte, and now there needs to be 32 bits. The timing may be different, I haven’t compared yet. The assembly part of the library is really simple, it’s just NOPs that add 1 cycle of delay time. It’s nearly impossible to calculate the number of NOPs required though. What I usually do when supporting a new type of strip is just hand calibrate the delays with an oscilloscope, and iterate until it’s as close as I can get it. Looks like I need to order one of these strips to make sure it’s working with the neopixel library Looks like you’ll be attempting something now, so good luck!
###Just updated the NeoPixel library to support the P1 and Electron
Important:
If you have an old app in Build that you are migrating to a Photon, P1, Electron or Core, please remove the NeoPixel library from your app and re-apply it to update the included library to v0.0.8. If you are creating a new app, simple add the NeoPixel library to your app and you will have the latest v0.0.8.
Has anyone checked the stability of this library over many hours? I am still experiencing many lockups of the photon when I am trying to run this for many hours. I am driving 21 LEDs that are daisy chained at around 20hz refresh rate (ideally I want to get this higher).
I have implemented a watchdog reset library and I am recording upwards of 20 reboots over 24 hours. From my print statement debugging, it seems like the code is freezing on the strip.show() command. Whenever it locks up, I am receiving the print statement before the strip.show() but never the one after. I am unable to debug deeper than this since any internal print statements disturb the Neopixel library’s time sensitive code.
Is it possible that the fast IRQ interrupt detaching and reattaching is causing issues? Any ideas on how I can explore this? I am running the photon with system thread enabled and have tried with both system mode in manual and automatic but neither removes the lock up issue.
Hey @sdinnu, I’m thinking there must be some series of things in your code that’s leading to this instability. I built a 24 pixel advent calendar that was hanging on my xmas tree for all of December and it was very consistantly connected. I just happened to have an IFTTT service hooked up to that Photon monitoring my online/offline status and it was only down when it was deep sleeping from 1am to 7am (power save mode), or if my internet was down (due to Comcast or my router needing a kick in the pants).
I’m sure I’m not doing the same things you are though… are you using attachInterrupt()? The Neopixel library disables all interrupts in the show() routine to keep 100% focus on bitbanging the output pin. If you are using Multi-threading with this, there are bound to be other issues. First try disabling multi-threading and go from there. If that’s the issue I bet there’s a way to fix things in the Neopixel library to play well with system threads.
I had not altered the Neopixel library but I did recently add the Photon-WDGS timer library since I was getting system lockups and I needed the Photon to reset automatically. I know that the WDGS library is attaching interrupts to check if the photon is locked up. In the next couple days I will completely strip down the code until I can figure out whats causing the issue.
I understand that in the show() routine, all interrupts are disabled, but should that impact the system thread? I assumed it would only impact the user thread and the interrupts involved in that. Ill try going into single thread mode, but I really would like to have a separate user thread as the code polls from many sensors and writes to the flash-EEPROM and I dont want it hanging because of Wifi commands.
In terms of general code instability, are there things I should look for while debugging to figure out lock ups? I checked the system free memory and it doesnt seem to be changing so I dont think its a memory leak. I guess best thing is to just comment stuff out until it stops locking up. I unfortunately cannot replicate the lockup nor is the frequency happening at a fixed rate so its a fairly long debug process per change.
Yeah intermittent lock ups are quite fun You could run your application via GDB debugger via JTAG and Particle Programmer Shield, and when it locks up it’s most likely in a tight loop somewhere… so then just break and step debug to see what the issue is.
Is there any debugger shield for the P1? My project uses all the pins of the Photon and its going to be hard to add JTAG pins without not being able to utilize all my pins.
I would like to know the same thing, jamesarm97. I purchased a spool of the RGBW Neopixels but I am not advanced enough to determine what needs to be changed to allow it to work with the Photon. I currently have an Arduino Uno with a Bluetooth module controlling them for under cabinet lighting in my kitchen, but it’s a pain to control. Would love to get one of my Photons running the lights.
Hi @timb !
Hope you did not try to eat these M&Ms yet…
I also want to use the APA106 LEDs (Neopixels) with built-in WS2811 control IC for “status boards”, setting each LED to a specific colour depending on the applicable status.
I wonder if I can omit the level shifter, mentioned in the library text.
You are obviously not using any 3.3v => 5V level shifter with these “PIXELBIT” LEDs.
Are they 3.3V types? (I could not find them and your above link is broken)
Did you try the “neopixels” also without level shifter?
Has anyone else had issues with too-short delay times on Photons? Various functions take ms as ints, and I’m finding them executing much faster than specified, e.g.:
int flash_delay = 2000;
int flashes = 10;
int final_delay = 20000;
for (int n=0; n<flashes; n++) {
next_time_red = red(next_time_red, flash_delay);
}
red(true, final_delay);
colorAll(OFF, 1);
The flashes are happening at about 2Hz, instead of 0.5Hz, and the final red call goes red and immediately turns off, though the comment for the function call is // Set all pixels in the strip to a solid color, then wait (ms)
I have a first-pass of the technobly library this is based off of running RGBWstrandtest.ino using the pinSetFast() and pinResetFast() changes recommended elsewhere. No guarantees that I got all the color ordering correct – this is a machete hack not anything ready for a pull request yet – but it should work.
###Just updated the NeoPixel library to support the RGBW NeoPixels
Important:
If you have an old app in Build that you are migrating to a Photon, P1, Electron or Core, please remove the NeoPixel library from your app and re-apply it to update the included library to v0.0.9. If you are creating a new app, simply add the NeoPixel library to your app and you will have the latest v0.0.9.
Looks like you’ll be attempting something now, so good luck!
