I’m seeing weird behavior with EVERY_N_MILLISECONDS. I have the following code in my loop():
if (autoOn) {
EVERY_N_MILLISECONDS(25000) {
Serial.println(“foo”);
}
}
If I run a static pattern, it works as expected in terms of the “foo” printing every 25 seconds. However, I have several other “EVERY_N_MILLIS_I” timers as well, that control animations like chase, strobe, etc. They run much faster (e.g. every 100 ms). If I turn on one of those, then the “foo” printout happens every 100ms. It’s like it’s ignoring this 25s timer entirely.
I also tried replacing EVERY_N_MILLISECONDS with EVERY_N_MILLIS_I but that didn’t make any difference.
Are you not able to have multiple EVERY_N_MILLIS* timers running at the same time?
A bit more info. If the other function I run is this – and patternDelay is 100ms:
if (doChase) {
EVERY_N_MILLIS_I(chaseTimer, patternDelay) {
chaseTimer.setPeriod(patternDelay);
chase();
}
}
Then it behaves as I stated above – it prints “foo” every 100ms.
But if, in doChase(), I comment out the call to the chase() function and just replace it with Serial.println (“Chase”); then everything works as expected. I get “Chase” every 100ms, and I get “foo” every 25 seconds.
So it seems to be related to the time it takes the chase() function to run.
@marmil that worked! Very strange. The other weird thing is, I have an autoOff function that’s pretty much identical to autoOn, and it wasn’t exhibiting the weird behavior.
@marmil I spoke too soon – it didn’t work. And another piece of data… if I remove the “foo” printout from my autoOn function, then it causes the nearly-identical autoOff function to run on every timer delay instead.
e.g. if I put Serial.println(“bar”) in autoOff, then it only prints “bar” if I remove the “foo” printout from autoOn! So maybe there’s some interplay between Serial output and the EVERY_N_* functions?
Instead of a print statement, which is kind of slow compared to other stuff, what if you toggle an extra pin high or low (and read that with a multimeter) as a different sort of test?
Even weirder yet … One of my other timer functions is doRainbowCycle(). If I run that with a >3ms timer, then it runs my (completely unrelated) autoON function on that timing. If I run it with a <=3ms timer, then it runs my autoOFF function on that timing.
I will try a different test, as you suggest. I’m super curious why different timers like this would cause OTHER timers to misfire, in a consistent and repeatable way. Maybe indeed the print function is so slow that it’s mucking things up.
Ok, I replaced the print statements with calling the following function that just blinks a specified LED. leds[1] just refers to a second channel of lights, separate from the one where I’m changing patterns.
// Toggle a pixel between a specified color and Black.
void blink(CRGB color, int pixel) {
if (leds[1][pixel] == color) {
leds[1][pixel] = CRGB::Black;
}
else {
leds[1][pixel] = color;
}
FastLED.show();
}
Now my functions look like this – they each have a separate LED and separate color:
if (autoOn) {
EVERY_N_SECONDS(5) {
blink(CRGB::Green, 0);
}
}
if (autoOff) {
EVERY_N_SECONDS(5) {
blink(CRGB::Blue, 1);
}
}
And the problem is still happening. A timer >3ms causes led 0 to flicker green (autoOn) whereas led 1 blinks every 5 seconds as expected. (I changed it from 25 to 5 secs for faster testing). It even does this if I run a timer as long as 1000ms.
A timer <= 3ms causes led 1 to flicker blue (autoOff) whereas led 0 blinks every 5 seconds as expected.
@Ryan_Cush , While I’m not sure this is really that helpfully of a test, but I was playing around with setPeriod(), getPeriod(), getRemaining(), and reset(). Perhaps using these somewhere specific with your timer(s) might help solve something.
What if you try switching your checks around and have the timers on the outside and if statements on the inside of a timer? That way the timer would be running continuously and never get skipped because it’s inside an if statement that doesn’t get run.