Is there a timer/clock that can be used to calculate elapsed time between a Start Time and End Time that is not affected by changes to the Real-Time Clock and System Time?
It would seem to me that using DateTime.Now isn’t an option if the system time can be changed either by the user or by a network time check. Am I wrong? Is there another solution that I am missing?
Can you just track and compensate?
can you just increment a counter after power up (with option we can reset this counter) incremented every sec in fw ? 
That is what I am working on now. Any changes to DateTime creates a new TickOffset. Instead of using DateTime.Now, I will use create a new datetime that uses the TickOffset.
Before I went through the work I wanted to be sure I wasn’t overlooking anything.
1 Like
@Austrian_Dude I am looking for millisecond accuracy but in either case I don’t think an interrupt in TinyCLR is accurate enough to properly increment a counter based on time. In other words, it might hit the interrupt 60 times a minute or maybe 58, there is no guarantee.
with in fw i meant firmware = ghi in firmware you mostly have guarantee of trustful incrementations
@Austrian_Dude, yes ideally there would be a system millisecond counter that starts at 0 at boot-up.
1 Like
Yeah we can very easily do that but do we really want to waste a timer on something silly like that instead of something like signal generator?
1 Like
Second to this one. Having something similar to the old netMF PowerState.Uptime would be helpful.
Is it possible to get a hardware register to automatically increment?
Same as previous answer, very easy to do but you lose a precious timer. Was on issues already
Make it optional trough tinyclr config?
Then you can choose if you want to use a timer for it or not based on the project.
There are 101 small things we want to make available like this one. This will create a confusing list of small additional unnecessary things. We will continue to focus on the big features and we can always return to the “nice to have but not necessary” features when all the “must have” features are out of the way. Please visit GitHub to see the list.
4 Likes
Thank you @Gus_Issa. I agree, there are bigger issues on that list that I would like to see finished first. I have created a workaround for now. As I stated earlier I just wanted to be sure I wasn’t overlooking something before I created the workaround.
2 Likes
Perhaps you can share what you have made? In case someone needs it now.
I ran into a similar problem with a task-scheduler. If the user changes the time (or an NTP packet does), then the schedule would get thrown off causing agents to never run again, or run way ahead of schedule.
My solution was to wrap all calls to the time setting functions on the RTC. By convention, any part of my app that wanted to set the time went through that wrapper interface. The wrapper would send out an event if the time basis changed. The event contained the delta that was applied to the clock and each consumer of the event would adjust appropriately. For instance, the scheduler would adjust all the next-run times. Locks ensured that changes to the RTC happened one at a time and were reported in order.
@skeller - in your case, you could just build a list of the deltas and apply them when computing the difference. One could even create an elapsed-time class that would do all that for you under the covers. For your scenario, not as easy as an uptime counter, because you don’t need an absolute timebase, but it will work until such a thing is available.