ArduinoTime

[SterlingPeet]

I am planning to refactor the ArduinoTime component to be less awkwardly broken of a LinuxTime implementation. It turns out this is not as simple as I may have hoped. There are some concerns:

• micros() counts up forever like millis() and thus it is weird not to modulo that field to keep the value under 1 second
• On ATmega, the calls to millis() and micros() are kinda slow
• Disabling interrupts over the calls makes the progression of time inconsistent and slower than real time
• Calling millis/micros back to back without disabling interrupts has edge conditions that don't quite line up temporally

• I could build a special ATmega component that leverages the same timer as millis/micros and doesn't have weird caveats, but it wouldn't be Arduino generic, so maybe that should just be a separate component?

  For my own internal version, I added the modulo on micros, and noticed that some seconds had more than 1 second worth of microseconds in them. This idiosyncrasy can be corrected on the ground, but I don't like providing a component that does this.

@LeStarch Thoughts?

[LeStarch]

From the library perspective, we should have something that works out-of-the-box based on arduino framework calls. I like the module approach because that forces into a known box: seconds, mircoseconds [0, 1000000). I didn't quite follow what was meant by: "and noticed that some seconds had more than 1 second worth of microseconds in them. This idiosyncrasy can be corrected on the ground, but I don't like providing a component that does this." and thus this may not be the best opinion.

Likely for your project you'll need better timing. There are two options:

1. New component
2. HW conditional implementation file

I prefer option 1 in this case as the implementations will likely be so vastly different that it really makes sense to be a separate component.

[SterlingPeet]

OK, so the problem I ran into is that time progresses between the millis() and micros() calls. The original component that I forked from your Teensy example had a bug that never bounded the micros() call, so it incremented until the 32 bit number rolled over rather than rolling over at the second boundary.

While investigating the unbounded microsecond bug, I discovered that my fix resulted in different bugs, where a time like "165 seconds and 12 microseconds", could happen twice. Once at the beginning of the second, and again at the end of the second.

Switching the order of the calls resulted in the opposite error, where very low microsecond values couldn't occur, and the microsecond values above 1 million did occur.

The question about providing a reference time component with only Arduino library references is this: Should we provide a component that is known to be broken in this way, or should we try to do something different?

[LeStarch]

I'd prefer a "working" solution but I am not sure how easy it is to do better. Perhaps a good-enough solution would be to just provide millisecond resolution for the stock example?

U32 mills = millis();
time = Fw::Time(millis/1000, (millis % 1000) * 1000);

We could use a counter member variable, and count microseconds roll-over but this gets complicated.