Driving NeoPixel 144 with Teensy 3

Status
Not open for further replies.
G

greg

Well-known member
Hi,

I am trying to drive adafruit's 144LED strip with T3, and it seems to work fine if only a small portion of pixels are used, but as I increase the number of addressable pixels - below simple code crashes (Windows reports "device malfunctioned", etc, the usual stuff):

I am using NeoPixel library with Paul's latest changes for T3 and T3.1: https://github.com/adafruit/Adafruit_NeoPixel
T3 is connected on RawHid, running at 48MHz

Was wondering if anyone else has seen a similar issue.

Here is the full sketch:


#include <Adafruit_NeoPixel.h>

#define PIN 9

int count = 140; // numbers over 70 always seem to crash. Numbers below 20 never do

Adafruit_NeoPixel strip = Adafruit_NeoPixel(count, PIN, NEO_GRB + NEO_KHZ800);

void setup()
{
strip.begin();
strip.show(); // <-- this line appears to be crashing the firmware
}

void loop()
{
// does not matter
}

Thanks,
Greg
 
Greg, how are you powering the strip, what is the external power source? Many people have found that pixel and controller behaviour can be erratic when juice is low, so it might be worth checking that this source is a good one.
 
Not really a direct solution to your problem, but why not drive the strip with the OctoWS2811 library instead? It may seem like overkill since it's written to drive 8 channels, but it will drive one channel just fine and you'll have the option of cutting up your strip into multiple channels to get much higher refresh rates.
 
Thanks, Tetsuo, this might just do it. My understanding is that neopixel is Ws2812, is that still compatible with Octo2811 library?
Not a huge fan of Adafruit library anyway, as it is incompatible with Servo library (though I have not looked deep, maybe OctoWS2811 also disables interrupts, and I still will have to switch to a different servo lib).
I saw something interesting on OctoWS2811 page:
> Usually Teensy 3.0 should be powered by the same +5 volt power supply as the WS2811 LEDs. By default, Teensy 3.0 has VUSB connected to VIN. They can be separated by cutting apart pads on the bottom side of the board ... <
Currently, I only have the ground from my power supply connected to teensy's GND, but T3 is still powered by USB. Might that be a problem?
 
greg said:
I am trying to drive adafruit's 144LED strip with T3, and it seems to work fine if only a small portion of pixels are used, but as I increase the number of addressable pixels - below simple code crashes (Windows reports "device malfunctioned", etc, the usual stuff):
Click to expand...

USB only provides enough power for about 8 to 10 NeoPixel LEDs at full brightness. 15 or 20 might work on the test patterns. But 144 is certainly far too many for USB power.

The NeoPixel library doesn't "know" if pixels are actually connected. It sends exactly the same data, even if nothing is actually connected to the pin. Does the code still crash if the LEDs aren't connected at all?

Regarding the library, can you give my copy a try. It's here:
https://github.com/PaulStoffregen/Adafruit_NeoPixel

Adafruit merged my changes from a few weeks ago, but they aren't the same. I haven't tested with their copy. If my copy works and their's doesn't, please let me know, so I can submit another pull request to them.
 
mortonkopf said:
it would be useful to run the octows2811 lib basictest, and just use pin 2 for the strip and see if issues persist.
Does the processor speed affect the use of the neopixel lib?
Click to expand...

Don't forget to bridge pins 15&16 on the teensy... it's an easy step to miss if you're switching from FastSPI or the adafruit library to OctoWS2811.
 
Great, thanks mortonkopf I'll try tonight.
To answer you question, T3 clock speed has no effect on the weird behavior.
 
PaulStoffregen said:
USB only provides enough power for about 8 to 10 NeoPixel LEDs at full brightness. 15 or 20 might work on the test patterns. But 144 is certainly far too many for USB power.
Click to expand...

Paul, I am using an external power source (12A 5 V). GND from that power source is connected to T3's GND, and the only thing connecting Teensy to LED array is the Pin 9 (configured with NeoPixel library)
PaulStoffregen said:
The NeoPixel library doesn't "know" if pixels are actually connected. It sends exactly the same data, even if nothing is actually connected to the pin. Does the code still crash if the LEDs aren't connected at all?
Click to expand...
I'm pretty sure it would, but I'll double check tonight.

PaulStoffregen said:
Regarding the library, can you give my copy a try. It's here:
https://github.com/PaulStoffregen/Adafruit_NeoPixel
https://github.com/PaulStoffregen/Adafruit_NeoPixel
Adafruit merged my changes from a few weeks ago, but they aren't the same. I haven't tested with their copy. If my copy works and their's doesn't, please let me know, so I can submit another pull request to them.
Click to expand...
I actually tried your's too. Same effect, but I think the threshold for crashing has gotten higher (i.e. I believe could never get to 30 LED's with Adafruit's version, and with your's I could occasionally go as far as 79)
 
If it crashes without any LEDs connected, please post the complete and exact code, and I'll give it a try on a board here.
 
Confirmed.
Does crash w/o LEDs being powered if the number of LEDs is high. See the very first post in the thread for full code.
 
out of curiosity, have you tried moving the show() call into the loop() function? Perhaps there's some race condition you're bumping in to.. under real-world conditions, it would normally be:

void setup()
{
strip.begin();
}

void loop()
{
/*
various setPixelColor() calls would go here or in some called function
*/
strip.show();
}

. I still think using OctoWS2811 is your better option though :D
 
Last edited:
Yep. show() crashes in the loop as well. I tried it all. Its intermittent too, i.e. it might succeed 10 times in a row and crap out on 11th call.
Anyway, I took your advise, integrated OctoWs2811 and it worked beautifully. Rock solid.

My servos connected to Pins 5 and 6 were still rattling badly as LED strip was being driven, but I moved them to pins 9 and 10 and stock Servo library works fine while LED strip is being driven (same power source).

Thank you all for great help.
 
Glad to hear you've got everything working! What are you building that combines a servo w/ LEDs? I built a giant radial gauge from an 11" wall clock and integrated it with a commercial NMS (ScienceLogic EM7). It was just for giggles to show off the next-generation dashboards: when you click on a roll-up performance metric in a leaderboard widget, it drives the last-polled value for that roll-up to the gauge. The gauge mirrors an on-screen widget that has configurable severity bands (e.g. healthy, warning, critical) and the screen version and physical version update concurrently. It was a fun project, shown here:

http://www.youtube.com/watch?v=dvQFq7wMsVA&feature=youtu.be <-- shows coordination of stepper motor timing with LED activity
http://www.youtube.com/watch?v=p6uZZelEAo4&feature=youtu.be <-- shows integration w/ ScienceLogic EM7 dashboards
 
Nice clips, tetsuo. Its a Teensy investigation project masqueraded as a silly Christmas project that I've been doing with kids (way past the deadline by now :)). As person walks by the tree - it shakes its limbs and lights up. Just wanted to play with full stack sensing->PC->actuation->lights. Using RawHid to communicate with the T3. Implemented servo acceleration and speed control on top of standard arduino Servo library.
Only wish this sort of stuff existed 20 years ago when I could devote more time to it.
 
TL;DR: You can work around this problem by adding "delay(4)" at the beginning of setup(). You'll find it also works if you power cycle your Teensy, so it reboots from powerup instead of an reboot initiated by reprogramming the flash.

I've added a 4 ms delay in Teensyduino's internal initialization, which runs before setup(), so when 1.18 is released this workaround will no longer be necessary.

This was a really tough problem to investigate. It turns out the Mini54 chip is actually causing this problem. Well, that and the fact I wrote this update to Neopixel using a timer that's technically part of the debug watchpoint unit. When rebooting after an upload, about 1.5 ms after bootup, the Mini54 configures part of the debug hardware so it can monitor if Teensy has entered a sleep mode or a halt mode, which is how the USB stack sends the auto-reboot request to the Mini54 chip. This configuration process stops that watchpoint unit timer. If that configuration of the hardware, which normally should have no effect on a program running on Teensy, happens to fall on a fairly narrow window where the NeoPixel library is updating and depending upon that timer, Neopixel stalls forever in an infinite loop with interrupts disabled.

Just adding a small delay in the startup solves this problem. It turns out early versions of Teensyduino had a 100 ms delay that was removed because it didn't seem necessary. Hindsight....

Sorry this caused so much trouble. If anyone is still following this thread, hopefully this helps.
 
Status
Not open for further replies.
Back
Top