I'm having issues timing things with millis() — is there anything in the FastLED

I’m having issues timing things with millis() — is there anything in the FastLED code that (interrupts etc?) that would potentially mess with the timing?


(In the future - give more information - what led chipset, what platform)

The ws2811/neopixel families require disabling the interrupts in order to get the timing right. This can interfere with the the counters used for millis because they are incremented in an interrupt handler.

I finally have a fix for this - but it is on a currently unsupported platform that I’m using for a contract gig. Once that is finished I will port the fix to all the platforms.

(That said, even when not disabling interrupts, I’ve found that millis can easily drift by seconds, if not minutes over the course of a day)

Sorry Daniel — Neopixels and Teensy.

So that’s why I have an issue — can’t see a way around it.

Dan — without wanting to sound like an impatient sod — what kind of timeframe for the fix? Also — any idea how long the code disables interrupts? (I’m writing to about 60 LEDs) I guess I can partially fix it by updating less rather than every loop like I am at the moment.

No time frame right now - depends heavily
on when this contract finishes. Right now, interrupts are disabled for (30us * number of leds). Also, there is code that does attempt to re-adjust (though it isn’t the most accurate).

Thanks Dan — 30us for 60 LED means 1.8ms for me. That’s good to know.

I might be better off if it didn’t try to adjust—

@Daniel_Garcia playing some more this evening with my LED clock that uses a 1Hz signal to sync millis with the RTC — the Teensy is pretty damned accurate (to microseconds) when it’s just timing the second and doing nothing else.

I have a feeling that FastLED is over compensating because it reports that the second is taking 1070ms or so. I have 60 LEDs being updated 60 times a second — so I reckon it should be about 108ms? So if turned off it should give me 890ms or thereabouts.

Is there any way to turn off the compensation?

It is possible there is some slop in both possible directions with the timing - it’s meant to be rough, and not exact. 1070ms is closer to accurate than 890ms :slight_smile:

I’m not in front of the code right now, but you can go into clockless_arm_k20.h and you should be able to see where it’s attempting to adjust the millis counter. I suspect the reason you are seeing it as 1070ms instead of 1010ms actually is because the code tries to always increment by at least 1ms (to account for frame updates that take less than 1ms, otherwise, millis() would never advance).

This should become a non-issue entirely in the next month or so.

Thanks Daniel — really looking forward to the update!