Teensy 3.2 millis() going 2.5x faster than actual time?

I am attempting to run some FastLED animations on WS2812 panels. I had my code running on an Adafruit Trinket Pro (a 16MHz avr/arduino-alike) and recently moved to running on a Teensy in order to do more sophisticated animation. Unfortunately now all the animations are running much faster than real-time because an increment of 1000 in millis() occurs every ~425ms of actual time.

Some code to minimally demonstrate this (not really related to my fastled animations, but still based off of millis()) is:

Inspecting the serial console and timing how long it takes for 100 numbers to be printed, I find that it takes about 42 seconds when it should be 100. I'm sure I could write some code to get accurate counts wrt my laptop's clock if I needed to but I'm just watching the serial console with a stopwatch right now. I get similar numbers for printing ten numbers and so on. The millisecond counter is definitely substantially fast. How do I fix this?

Still no luck here. I have manually forced FastLED to receive millisecond values that are scaled appropriately but it'd be nice if there were a better fix.

Does showCurrentPattern() do something to cause loop() to delay() or sync to the systick clock?

If not, then loop() will run as fast as showCurrentPattern() and Serial.println() permit.

I'm not really following? The code, which directly queries millis(), prints too fast, not too slow. That is, "curr-prev > 1000" happens *substantially* before 1000ms have actually passed (closer to 425ms).

I think what stevech is asking you to do is comment out the call to showCurrentPattern() to see if it's doing something to the clock. I can assure you that I've used mills() many times for delays of 1 second and haven't had this problem.

If commenting out showCurrentPattern() doesn't help then please post your setup routine. Something somewhere is dinking with the clock.

I recall reading on the FastLED Google Plus group that FastLED tries to adjust the millis() count after it's updated WS2812 with the interrupts turned off. This is almost certainly a bug in FastLED. Best to report it on their Google Plus group.

The very best thing you can do is use FastLED together with OctoWS2811. FastLED can use OctoWS2811 as a driver. That's far more efficient. It's also possibly overkill, since OctoWS2811 is meant for huge LED projects. But it has a design that keeps interrupts enabled and uses almost no CPU time to drive the LEDs, which means millis() won't be impacted, and it also gives you nearly all the CPU time to draw your next frame while the previous is still transferring to the LEDs.

You could also use OctoWS2811 without FastLED, if it will meet your needs. But OctoWS2811 lacks the many very optimized drawing functions of FastLED, so if you're using those, you get the very best of both by configuring FastLED to use OctoWS2811 as a driver.