neopixel timing test

The program below demonstrates some odd timings of neopixel calls. On some regular basis the call takes twice as long. There is odd non-monotonicity to the time it takes depending on the NUMPIXELS. 64 is weird, 57 is different and more weird &c. And the time taken does not seem to go up very rapidly with an increasing number of pixels, like if y = mx + b, m seems way too small even if we ignore that sometimes a larger number of pixels takes significantly less time.

Something else is going on, something obvious that you will kindly remind me about, or tell me what I never knew.

IDE 1.8.7, UNO, tried several. Does it matter - that I don’t really have a strip hooked up? I tell you I do not think so.

// warp core animation timing investigation

# define NUMPIXELS     64

# include <Adafruit_NeoPixel.h>

# define PIN 6

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

void setup() {
	Serial.println("minimum example");


unsigned char limit = 50;
unsigned long usTimer;

void loop()
	usTimer = micros();;

	Serial.println(micros() - usTimer);

	if (limit--) return;

	for (; ; );



You can't really use millis() or micros() to do timing when using Adafruit_NeoPixel, because interrupts are disabled while writing to the LED strip, and both those functions rely on interrupts. FastLED attempts to make an adjustment to millis() to compensate, but the Adafruit library does no such compensation.

Oh, that makes perfect sense.

Since millis/micros is also the basis for my personal low-rent “RTOS”, I now understand a few other oddities that troubled (but did not stop) me.

I’ll look to other resources for both timing and time sharing. I shouldn’t need more than a free running counter at some known frequency.

Time to learn what timers can do and what they are already tasked with doing.

This also looks like a good time to start figuring out that cheap logic analyser I got…