StopWatch: add persistence #2141
Conversation
|
Build checks have not completed. Possible reasons for this are:
|
|
@FintasticMan Can you trigger CI? |
|
Added a fix for a minor issue: after exiting StopWatch in the |
codingjourney
force-pushed
the
stopwatch-persistence
branch
from
605cba9
to
5d97a2e
Compare
|
By the way, I've noticed this PR breaks InfiniSim. Does that have to be adapted before things get merged in InfiniTime? I don't mind looking into it, it's just that the build setup seems a bit more involved (I went with the Docker method for InfinTime and that's super smooth). |
|
Yeah it's good practice to get an InfiniSim PR up and waiting if a PR here will break it (annoyingly the CI has given up again so I can't easily see). I haven't used the docker method so I can't comment on that but provided you're on Linux getting a build environment up and running shouldn't be too bad. |
|
I've created PR #163 for InfiniSim. Necessary changes were trivial. Functionality in InfiniSim seems to work as intended. |
|
Great :) |
* more consistent function names * lapCapacity as constexpr * LastLap returns std::optional * simplified handling of TickType_t values * removed unused methods * minor fix in lap rendering
codingjourney
force-pushed
the
stopwatch-persistence
branch
from
f045b67
to
0195a1c
Compare
| const int timeElapsedCentis = timeElapsed * 100 / configTICK_RATE_HZ; | ||
|
|
||
| const int hundredths = (timeElapsedCentis % 100); | ||
| const int secs = (timeElapsedCentis / 100) % 60; | ||
| const int mins = ((timeElapsedCentis / 100) / 60) % 60; | ||
| const int hours = ((timeElapsedCentis / 100) / 60) / 60; | ||
| return TimeSeparated_t {hours, mins, secs, hundredths}; | ||
| return TimeSeparated {hours, mins, secs, hundredths}; |
There was a problem hiding this comment.
One thing I've noticed: if the stop watch is left running for a long time these calculations overflow. Could this be refactored to avoid anything exceeding a uint32? The actual tick count overflows every 2^32 / 2^10 = 2^22s ~= 48days, but dividing that by 100 gives just 11.65h (as currently the tick count is multiplied by 100, so overflow happens 100x earlier). I don't think we need to worry about a 48 day overflow, but more than 11h would be nice.
This PR solves Issue #303 and is based on previous work by @desttinghim (PR #783 ) and @pptime02 (PR #1410 ). Well, it's actually just a re-base of #1410 onto the current main branch. I did my best not to disrupt functionality implemented on main in the past 2 years. Any feedback is appreciated.