TimerTicker could run several times in a row

[jetremblay]

calsol-fw-libs/utils/LongTimer.cpp

Lines 42 to 45 in d184a60

	if (LongTimer::timePast(currentUs, tickerExpire_)) {
	tickerExpire_ += period_;
	return true;
	}

@ducky64 I know this was written to be long term stable, but if the main loop is slow, this might return true several times in a row. Should we keep adding period_ until tickerExpire_ is in the future?

[ducky64]

That's actually a pretty tricky question. One of the assumptions of this class is that it gets called regularly, so this probably isn't suitable in cases where that doesn't hold. In any case, for a less-stable class, I think it makes more sense to add period_ to the current time, than to keep the period but skip cycles.

I'd also argue that a main loop with such unpredictable loop rates should be refactored or otherwise re-examined.

[edwardcwang]

Out of curiosity, could it also be possible to use a hardware timer to trigger that loop more frequently if the main loop is slow?

[jetremblay]

That is definitely possible, and I agree with @ducky64's comment about writing better main loops. I guess the case where this would happen is for code that needs to run very frequently. Maybe we can add a mechanism to log these events in order to be able to improve the code timing if required?

[ducky64]

@edwardcwang So personally, I prefer the polling approach (because of dataflow spaghetti and threading synchronization issues associated with doing significant work in an interrupt - especially for newer programmers), which is what this provides. So while this makes it harder to shoot yourself in the foot in subtle ways, the user does have to be aware of timing. But hopefully at least it will be more obvious.

@jetremblay I think an error counting and logging infrastructure would be a great idea, though the implementation and API of that needs some thought.