Every N Seconds ...

Every N Seconds …
For the extremely brave, some experimental new FastLED additions… Just added to the v3.1 branch on github: some helpers to perform tasks periodically, e.g., every ten seconds. The simplest way to use the new functionality is with the new “EVERY_N_SECONDS” macro, that acts a bit like an “if” statement:

void loop() {
EVERY_N_SECONDS(10) { chooseNewPalette(); }

}

This mechanism does not use interrupts, and has to be executed periodically to work, i.e. as shown in the “loop” function above. It uses 4 bytes of RAM for each independent ‘Every N Seconds’ timer; you can have as many different ones as you wish.

You can also use these periodic triggers like this, without the helper macros. You have to declare a static instance of the ‘Every N Seconds’ class, initialize it with the period you want, and then you can just test it with an “if” statement to see if the period has come around again:

void loop() {
static CEveryNSeconds newPatternTime(10);

if( newPatternTime ) {
changePattern();
}
}

The nice thing about that is that you can integrate it with other triggers, as in:

if( newPatternTime || buttonPushed ) {
  changePattern();
}

There are a few variations, including EVERY_N_MILLISECONDS.
The underlying time base is the Arduino millis clock, which drifts a fair amount, so don’t use these timers for rocket science, but they work nicely for making periodic changes to an LED animation.

There’s no sample code yet (other than this, above), but it’ll come in the next few days, along with whatever bug fixes are needed.

Enjoy, and let us know what you find. So far from my testing, it looks like this is going to simplify things a bit.

That is seriously a major step foreward! Great work, thanks! I´m sure people will love it. I do.

Works like a charm. I just miss the possibility to do thinks like

void loop() {
EVERY_N_MILLISECONDS(200) { doSomething(); }

}

That example should actually just work! Let me know if so (or not).

Update: sorry, try EVERY_N_MILLIS.

…which means I should add the other :slight_smile:

That does the job! Now I call the new add-on “perfect”.

One more idea: if the user could specify a timebase for the EVERY_N functions too, it would be easy to implement things like a pause button affecting beatsin88 and everything timing related. Do I make sense? If I am right, then it would be trivial to sync a complete animation to whatever only by manipulating the timebase.

So… I think there is a way you can do that-- but it’s not an argument, it’s a whole different mechanism. Grep the code for GET_MILLISECOND_TIMER…

It is awesome to realize the modular and universal way you guys constructed the lib.

This was actually out of necessity; “millis” is an Arduino-provided function and we continue to move toward being totally non-dependent on the Arduino APIs and libraries. So, we had to provide a way to access a timebase with “millis”; hence the code you see there.

Field report: I have a thousand-line (18K compiled code) animation program that uses three different periodic timers. I upgraded the timers from the pre-existing “longhand” code to use this new mechanism.

  • reduced size of source code by 25 lines (and increased readability)
  • reduced program flash size by 60 bytes
  • reduced RAM usage by 12 bytes
  • eliminated one lingering ‘rollover’ bug in the hand-written timer code
    So far, so good.

I just tried this new feature myself. It took me a while to figure out that the new macros need to go inside the main loop() function but once that was done they worked like a charm! I was able to remove my SimpleTimer.h dependency and the related calls and it saved about ~500 bytes I think.

It’s being used in my APA102 spiral Christmas tree right now. Currently trying to figure out a good way to make it so that instead of the entire tree changing colors when the palette changes it will gracefully flow from one palette to the next.

Thanks for the feedback on the new timers.

As for palette fading, here’s what I’ve done so far: you keep the current palette, and also a target palette, and every so-often you morph the current palette a little bit toward the target.

This will probably make its way into an example within a week or so, but the idea isn’t too hard to write from scratch.

Yeah, I figured that’s how it would have to work. I’m going to see if I can write that up right now…

Just in case you have an example for the palette fading by hand I´d appreciate to have a look on it, @Mark_Kriegsman . I think it would seriously improve the electric mandala.

Example is on the way… once I get back to an actual computer later today…

Color Palette Crossfade example and video: https://plus.google.com/112916219338292742137/posts/FvLgYPF52Ma

There is another idea in my head, Mark: I think many people (including you and me) have written many times something like FOR_N_SECONDS(seconds). If it would be part of the lib it could be the first step towards a basic scripting / timeline functionality allowing basic show composing. What do you think?

Interesting. And I think I know what you mean. Let me think about it a bit; this one has more open questions about expected behavior, if there’s an implied loop, etc. I like the idea; I’ll noodle on it a bit.

I’d love to play with this, but I’m having a hell of a time cloning this branch using git, and then actually getting it work on my Gemma board. Am I asking too much?

It should work fine on Gemma, Trinket, and Flora boards as well as the more mainstream AVR suspects. What problem are you having? Compiling? Runtime issue?