What millistimer library is this?

Projects Programming
1

timer.h

  class MillisTimer{
    public:
      MillisTimer(uint32_t time, functionPtr action, bool repeat);
      static void processTimers(void);
      void start(void);
      void start (bool repeat);
      void stop(void);
      void begin(void);
    private:
      enum TimerState{
        STOPPED,
        RUNNING,
      }state = STOPPED;
      functionPtr callback;
      uint32_t delay;
      uint32_t lastMillis = 0;
      bool repeats;
      static std::vector<MillisTimer*>timerArray;
  };

timer.cpp

// MillisTimer

std::vector<MillisTimer*> MillisTimer::timerArray;

MillisTimer::MillisTimer(uint32_t milliseconds, functionPtr action, bool repeat) {
  //timerArray.push_back(this);
  delay = milliseconds;
  callback = action;
  repeats = repeat;
}

void MillisTimer::begin(void) {
  timerArray.push_back(this);
  Serial << "Timer Added" << "\n";
}

void MillisTimer::processTimers(void) {
  uint32_t currentMillis = millis();
  int count = 0;
  for (auto& i : timerArray)
  {
    if(currentMillis - i->lastMillis >= i->delay)
    {
      if (i->state == RUNNING){

        if(i->callback){
          i->callback();
        }
        if (!i->repeats){
          i->state = STOPPED;
        }
        else {
          i->lastMillis = currentMillis;
        }
      }
    }
  }
}

void MillisTimer::start (void){
  lastMillis = millis();
  state = RUNNING;
  Serial << "Timer Start\n";
}

void MillisTimer::start (bool repeat){
  repeats = repeat;
  lastMillis = millis();
  state = RUNNING;
  Serial << "Timer Start\n";
}

void MillisTimer::stop(void){
  lastMillis = millis();
  state = STOPPED;
}

Anybody recognise what library it comes from? It's so good - example usage below

MillisTimer relayTimer(700, relaytimercallback, false);

relayTimer.begin();
relayTimer.start();

void relaytimercallback(void) {
  relayTimer.stop();
  relayPin0.off();
}

I've been using this library for the Particle Photon courtesy of (I think?!) @BulldogLowell but can't find the original which was probably for Arduino? I've tried recreating it by stripping back what is particle specific but am just tying myself in knots with compiler errors eg "can't find vector" etc. I have tried supplying a vector library but new errors just crop up.
Thanks

3

? did you think you had it, @slolrnr ?

4

ah, THINK I've found it again

5

Sorry, Iā€™m new to the Arduino forum, and it screwed up my reply.
I meant to say add ā€œ#include ā€ to include the std::vector class

6

Whoever wrote that almost understands non-blocking.
The process timers function that has to process ALL the timers before returning has the potential to make smooth stutter.

There should be no for-loop there, what if you used 100 timers or even 20?
Use instead an index updated at the top of void loop() to process a single timer per pass through loop() for all but always guaranteed very fast inner loops or things that HAVE to be done before next loop(). Void loop() should run 10's of times per millisec.

7

While it doesn't use callbacks, this millis (and/or micros) timer library is pretty useful if I do say so myself: FireTimer.h

1 Like
8

If you shape your own code to not block it will be smaller and faster with less latency than any library can get you. As long as you rely on the library you will not learn better oe how simple that gets.

Nick Gammon starts with this, do multiple things at once.

Nick Gammon, next level on reading text w/o blocking and intro to state machines.

With those 2 lessons and practice (use or lose!) covers about 95% of regular automation. Interrupts he also covers should be last resorts.

9

Seems to do that thing.

But this "overflow handling" it has

	// Handle overflow
	if (currentTime < timeBench)
		timeDiff = (UL_MAX - timeBench) + currentTime;
	else
		timeDiff = currentTime - timeBench;

is completely unnecessary. The expression

 (UL_MAX - timeBench) + currentTime;

is the same as

 currentTime - timeBench + UL_MAX;

Adding UL_MAX to an unsigned long integer is the same as subtracting... 1. So those two expressions that are carefully chosen between, for no reason, result in a 1 unit difference in timeDiff - not, as the comments and code might suggest, saving the whole thing from going south at the rollover point.

I've seen that same overflow handling, and some even more elaborate. There is just no problem that needs to be solved that way here.

a7

2 Likes
10

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.