Simple (Yet Useful) Timer Object
JonnyMac
Posts: 8,941
In the process of porting my P1 libraries to the P2, some changed because we have better features and language elements in Spin2. In the P1 I had an object called jm_time that handled delays and simple timing. That has been updated to jm_timer.spin2 which provides elapsed milliseconds since the call to its start() method, a free-running countdown timer (resolution is milliseconds), and the ability to call another method at a specific interval. Of course, the timer's update() method must be called more frequently than any interval your code is using for timing or calling other methods.
In the attached demo I show the elapsed time, a countdown timer, and a running RTC. The RTC registers are updated every 100ms by a call established in the timer.
To run a method at a specific interval:
tmr1.set_task(@update_rtc, 100)
This will schedule the update_rtc() method t run every 100ms. The update() method should be called very frequently so that timing wobble is minimized.
Comments
Thanks Jon! I appreciate all of your contributions!
I've been away from the fun lately with work and such; looking forward to catching up again.
Paul
Super Jon!! I love you RTC routines.
In another thread, someone was asking about using the P2 timebase to run a RTC and correcting for the Crystal offsets.
ie there are some cases where P2 is always-on anyway, and the battery savings of a external RTC do not help, so it can make sense to just use the P2 Crystal.
At a glance I cannot see a means to trim/correct the RTC for at least a initial offset effect ? Is that easy to add ?
I guess you could adjust the global CLK_FREQ = 200_000_000 to (say) CLK_FREQ = 200_002_000 for a +10ppm compile-time offset, but it is less clear if that gets truncated elsewhere ?
I created a simple demo to illustrate the use of the timer object's set_task() method, not to create an RTC that exceeds the accuracy of the P2 system clock, which it can't, because the timer object uses the Spin2 getms() function at its core. I suppose if one decided the time was off by two seconds per day that one could adjust the time manually at/near the midnight change-over.
That doesn't work. Try it for yourself. Set CLK_FREQ to 200_002_000 and then run this line of code:
The value is, indeed, getting truncated due to the internal mechanisms of multipliers/dividers that drive timing.
Ah, yes. I guess there are two CLK_FREQ actually in play.
The nominal one, that drives the PLL, which has low-integer controls, and is coarse, so PLL_CLK is 10 * Crystal.
The actual crystal however is not == 20.00000MHz, which is what we want to try and correct for.
At 200MHz there is 200000 ticks per ms, which is 5ppm granular, or get10ms() could be 0.5ppm granular, and get100ms() could be 50ppb granular.
Understood. Given the speed of the P2, if one really wanted to tune system ticks/millisecond timing for an RTC, it would be best to write the RTC code in PASM2.