High-Precision Timer

[zzm634]

I am working on a new feature for the Movement framework that will help simplify faces and features that that need to measure elapsed time or trigger events in the future after short durations. I'm calling it the "high-precision timer", or HPT, and I'm working on it over at https://github.com/zzm634/Sensor-Watch/tree/hpt

Features:

• Measure elapsed time using a numeric timestamp that is not tied to the current calendar time, nor is it affected by changes to the RTC
• Schedule background tasks to be triggered in the future at a resolution greater than 1hz

New Faces:

• hpt_lapsplit_chrono : a lap/split chronograph face using the high-precision timer to measure elapsed time
• hpt_countdown_timer: a countdown timer that is more responsive to button presses and immune to RTC changes

Possible Refactors:

• Use HPT scheduled callbacks to implement LED timeout, buzzer control, and button long-press timing.
• Remove use of "fast ticks" 128hz callback in movement.c and open it up to faces (which currently are limited to 64hz)

Outstanding questions

• Timer frequency: 128hz or 1024hz?
  ** 128hz: can use the 32-bit timer register directly without having to worry about overflows. Running at 128hz, a 32-bit counter will overflow in 1.06 years, by which time the battery will probably have died. The counter will be reset to zero and powered off when no faces are using it, so unless someone is continuously running a stopwatch for more than a year, this is unlikely to be a problem.
  ** 1024hz: will need a combination of the 32-bit timer and an overflow interrupt to manually store a separate count of overflows. Timestamp would be 64-bit (though probably actually only 40 bits), and scheduling tasks will be more complicated. However, faces would never have to worry about encountering an overflow. 2^40 ticks at 1024hz is 34 years, and the battery will definitely be dead by then.

Concerns:

• If interrupt handling takes too long, it's possible for the timer value to change in the background while we're handling scheduled events. If events are scheduled too close together or too close in the future, it might be possible that by the time we set the timestamp value for the new interrupt, the counter has already passed it and the interrupt won't trigger. Now, if the counter is running at 128hz and the cpu is running at 4mhz, that gives us about 31,000 clock cycles to finish up whatever we were doing and check the timer again. Plenty of time... unless a face calls _delay_ms() or has to wait to activate a peripheral. Not a deal-breaking problem, but something we need to be aware of.

Benefits:

• Simpler logic for keeping track of durations. Much less math to do compared to converting an RTC time to a unix timestamp.
• Less active CPU time for background tasks. The LED, buzzer, and button-press timing is done right now by waking up the CPU and manually incrementing a value in "fast ticks" mode. By moving this stuff onto the HPT, we only have to wake up the CPU at specific important moments, like when the LED needs to be turned off or the tone of the buzzer changed. Fewer cpu wakeups plus less stuff for the CPU to do means better battery life.

TODO:

• I have the APIs written out (watch_hpt.h and additions to movement.h) and an implementation of the movement.c side that is mostly complete, but I have not written the low-level timer code yet (watch_hpt.c)
• Add this capability to the simulator so it can be used to test new faces without hardware

[matheusmoreira]

I'm working on it over at https://github.com/zzm634/Sensor-Watch/tree/hpt

Please create a draft pull request rather than a discussion. This will allow us to comment on and review the code in addition to discussing the new feature.

** 1024hz: will need a combination of the 32-bit timer and an overflow interrupt to manually store a separate count of overflows. Timestamp would be 64-bit (though probably actually only 40 bits), and scheduling tasks will be more complicated. However, faces would never have to worry about encountering an overflow. 2^40 ticks at 1024hz is 34 years, and the battery will definitely be dead by then.

I think this is the more robust option. The code to handle overflows should exist and be routinely exercised, and this accomplishes that and has the added benefit of higher timer resolution.

If events are scheduled too close together or too close in the future, it might be possible that by the time we set the timestamp value for the new interrupt, the counter has already passed it and the interrupt won't trigger.

I assume interrupts will be disabled for the duration of the handler callback then. Can we keep them enabled and use interrupt prioritization instead? That way high priority interrupts will interrupt the lower priority ones.

If this does get used to manage movement internals such as the buzzer and LED timings, they should be higher priority than watch face updates.

Now, if the counter is running at 128hz and the cpu is running at 4mhz, that gives us about 31,000 clock cycles to finish up whatever we were doing and check the timer again. Plenty of time...

I haven't profiled the code yet so I don't know if we're missing or hitting that deadline. We should get some worst case cycle counts for the current version of the firmware in order to know where we're at right now and what we need to change to accomodate that real time requirement.

I assume that watch faces are soft real time while watch hardware management is hard real time. Is this a reasonable assumption? Should watch faces be hard real time?

unless a face calls _delay_ms() or has to wait to activate a peripheral

I think we should get rid of that function. The watch faces should not be blocking on the event loop like that. The code should be as asynchronous as possible.

The face has access to a high precision timer, if it needs to wait some number of N Hz ticks, it should just count them and return if the deadline hasn't been reached yet. When the requisite amount of time has passed, it will know and then it can spring into action. Existing faces such as the pulsometer already count ticks that way.

• Less active CPU time for background tasks. The LED, buzzer, and button-press timing is done right now by waking up the CPU and manually incrementing a value in "fast ticks" mode. By moving this stuff onto the HPT, we only have to wake up the CPU at specific important moments, like when the LED needs to be turned off or the tone of the buzzer changed. Fewer cpu wakeups plus less stuff for the CPU to do means better battery life.

And this will be completely independent of the RTC which will be running concurrently?

We need power profiling to confirm that this does indeed consume less power.

• I have the APIs written out (watch_hpt.h and additions to movement.h) and an implementation of the movement.c side that is mostly complete, but I have not written the low-level timer code yet (watch_hpt.c)

Which peripheral is providing this high precision timer? I need to look it up in the data sheet. Are you using the RTC's COUNT32 mode?

• Add this capability to the simulator so it can be used to test new faces without hardware

I think we should invest time into getting the sensor watch hardware implemented in QEMU instead of hacking up the emscripten emulator any further. I ran into massive issues trying to test sleep modes in the latter, it would just freeze. I can't imagine it will be too reliable for developing timing sensitive firmware.

---

I have reviewed the SAM L22 datasheet and I assume you are going to use the TC = Timer/Counter in COUNT32 mode with a 1024 Hz prescaler configuration, concurrently with the RTC = Real Time Clock's 1 Hz signal.

So the movement timer facility will feature two timers:

1. The always-on 1 Hz RTC tick
2. The on-demand high resolution TC timer

Is it possible to merge these two somehow? PR #345 discusses switching the RTC itself to COUNT32 mode and using it in a similar way to what you are propsing. That way we can use only the RTC peripheral, which is also designed to remain powered even in BACKUP mode.

I suggest multiplexing access to this RTC's comparator register by dynamically organizing the timers so that the timer nearest to completion can be efficiently dequeued and scheduled for interrupt. This management should happen every time a timer is started, stopped or fired.

@joeycastillo's concerns over the reliability of the watch must be taken into consideration. We have to ensure that the watch will not freeze or remain unresponsive in sleep mode indefinitely.

[zzm634]

All good feedback.

Please create a draft pull request rather than a discussion. This will allow us to comment on and review the code in addition to discussing the new feature.

I didn't want to make a PR until I had the code working, but I can see the benefit of a "work in progress" PR.

I think this is the more robust option. The code to handle overflows should exist and be routinely exercised, and this accomplishes that and has the added benefit of higher timer resolution.

I will go with the 1024hz option and change the APIs in watch_hpt.h accordingly.

I assume interrupts will be disabled for the duration of the handler callback then. Can we keep them enabled and use interrupt prioritization instead? That way high priority interrupts will interrupt the lower priority ones.

Not entirely sure how interrupt prioritization works. I can at least try to update the code such that it does the necessary "next interrupt" scheduling stuff in a short critical section, then enables interrupts while running the actual tasks and faces.

And this will be completely independent of the RTC which will be running concurrently?

Yes. The RTC will still be counting seconds and keeping track of the time and date. This would be a separate timer that just counts upwards. As TC0/1 are used for USB stuff, I am going to use TC2/3 for this timer.

Is it possible to merge these two somehow?

I think it is reasonable to have both the RTC running all the time to keep track of clock time for faces that need it, and this TC running intermittently when faces need short background tasks. While it may be possible to use a single hardware peripheral to handle all of the timekeeping requirements of the watch, the extra logic involved means the CPU spends more time awake, and the complexity of the code itself can lead to more bugs.

I think we should invest time into getting the sensor watch hardware implemented in QEMU instead of hacking up the emscripten emulator any further.

Disagree here. That web-based simulator is critically important for contributors who may be interested in hacking away at this project. The quick turnaround time between making a change and being able to play with it right away in a web browser is awesome. It's certainly not perfect, and I was caught out by the whole "TCC doesn't run in standby mode" thing, which the web simulator doesn't seem to care about, but I think we need to keep the emscripten emulator updated and working until the QEMU version achieves feature parity.

---

The two main challenges I was facing when trying to use the RTC for duration measurement purposes were:

• Changing the RTC time (such as when the user adjusts time manually, or for DST, or to change time zones) interferes with timestamp tracking in other faces. I wrote a chronograph face based on saving timestamps from the RTC, and it totally blows up if you change the RTC value underneath it. Faces would need a way to be notified when the RTC clock is modified so they can update their saved timestamps accordingly.
• Alarms and background tasks based on the RTC must be aligned to the nearest second. This is fine for alarms, but for something like a countdown timer, it will feel "laggy", as it will take between zero and one seconds for the user's button press to be aligned with a tick from the RTC. I know, it's not a game-breaking bug for a 10 minute countdown timer to take up to one whole extra second before it beeps, but Casio pulled this off with their crackerjack ASIC, and we've gotta at least do better than they did.

I was also working on some major changes to try to understand and simplify the LED and buzzer code, and I think using a duration-based timer like this will make that code much more straightforward. In general, even though we're going to be using another peripheral on the chip, I think it will save power overall by letting the CPU stay in sleep mode more often (vs waking up at 128hz for "fast ticks" code).

Also, Totally agree about _delay_ms(). It should be forbidden to use in this project, but I have seen some faces that use it. There are other reasons a face might busy-wait though, such as if it is waiting for a sample from the ADC or talking with a sensor over I2C or SPI. Ideally, those operations would be set up to use interrupts as well so they could be fired off and forgotten about, but that might be asking too much of a watch face.

[matheusmoreira]

Not entirely sure how interrupt prioritization works.

The currently executing code can only be preempted by an interrupt of higher priority than the currently executing code. So we can set internal movement tasks to high priorities and be confident that they won't be interrupted by watch faces.

The NVIC supports setting the priority for every interrupt. Details:

• ARMv6-M Architecture Reference Manual
  • B1.3.2 Exceptions
    • Priority levels, execution priority, exception entry, and execution preemption
  • B3.4.7
    • Interrupt Priority Registers
      • NVIC_IPR0 - NVIC_IPR7

I can at least try to update the code such that it does the necessary "next interrupt" scheduling stuff in a short critical section, then enables interrupts while running the actual tasks and faces.

Yes, this is critical in order to address reliability concerns. The next interrupt must be guaranteed, especially the time keeping functionality of the watch. There must be no risk of the watch ever getting stuck in sleep mode.

I think it is reasonable to have both the RTC running all the time to keep track of clock time for faces that need it, and this TC running intermittently when faces need short background tasks.

I think so too. The datasheet says they even have a one-shot mode which automatically turns off their clocks after they expire. It could be made efficient.

I'm just wondering if it wouldn't be better to rely on the RTC instead. It's the only peripheral that remains powered in the BACKUP mode. There's some silicon bugs that apparently prevented its use in the sensor watch but it might see some use in the future.

While it may be possible to use a single hardware peripheral to handle all of the timekeeping requirements of the watch, the extra logic involved means the CPU spends more time awake, and the complexity of the code itself can lead to more bugs.

The extra logic amounts to finding the next expiring timer and then scheduling it on the RTC's comparator. If the radix timers suggested by @theAlexes proves efficient, it could even reduce the overall time the CPU spends awake since all the loops which handle background and scheduled tasks will be eliminated.

That web-based simulator is critically important for contributors who may be interested in hacking away at this project.

No disagreement here.

The quick turnaround time between making a change and being able to play with it right away in a web browser is awesome.

QEMU would provide an equally fast turnaround time, if not faster.

It's certainly not perfect, and I was caught out by the whole "TCC doesn't run in standby mode" thing, which the web simulator doesn't seem to care about

It doesn't seem to care about a lot of things, unfortunately. Accuracy seems to be low, especially where lower level functionality is concerned. QEMU can address this. It would also be able to run the actual compiled firmware instead of a special emscripten compiled version, eliminating a huge dependency and simplifying the build system.

I think we need to keep the emscripten emulator updated and working until the QEMU version achieves feature parity.

That's reasonable.

The two main challenges I was facing when trying to use the RTC for duration measurement purposes were:

What do you think of my proposal in PR #345?

Let's make the current time independent of the RTC. We can make it part of movement's state and have a high priority 1 Hz task keep the current time every second.

Would this simplify these challenges?

In general, even though we're going to be using another peripheral on the chip, I think it will save power overall by letting the CPU stay in sleep mode more often (vs waking up at 128hz for "fast ticks" code).

I agree with you about the fast ticks code.

How significant is the power cost of enabling the extra timers? Let's say the timer is clocked and simply running in the background, is it reasonable to assume any additional power consumption will be negligible? In other words, only the time the CPU spends awake counts?

If that's the case then there should be no problem with using an additional timer. Maybe we can even enable all of the timers at once and multiplex access to all of them, including the RTC. That way the CPU will spend most of its time sleeping and will only wake up when a timer has expired or when the ALARM button is pressed.

This would make it possible for timers to interrupt each other though. We must ensure that the interrupt priorities are correct. We're already seeing problems due to button presses interrupting ticks. For example, issue #377.

I think from the timer scheduling facility makes sense no matter what we choose. Whether we keep relying on the RTC or enable one or all other timers, we'll benefit by being able to multiplex access to them.

but that might be asking too much of a watch face

We might be able to provide a nice API for it. The actual interrupts just need to call movement first. The framework can then organize the data into nice structures and call the appropriate watch face functions, passing them everything they need.

[zzm634]

I'm just wondering if it wouldn't be better to rely on the RTC instead. It's the only peripheral that remains powered in the BACKUP mode. There's some silicon bugs that apparently prevented its use in the sensor watch but it might see some use in the future.

I was going to bring that up, that we never go into BACKUP mode anyway because of that silicon bug, but TBH, even without that bug, I don't think we'd ever want to go into BACKUP mode on this watch, since that would mean shutting the display off too. We're already getting more than a year of battery life out of the watch without BACKUP mode, and that's perfectly adequate. For a device like this, I'd rather have a watch that always shows something on the display, even if it means I have to change the battery every 12 months vs a watch that lasts 18 months, but I have to press a button sometimes just to see the time.

If we ever do decide to support "super low energy" BACKUP mode, I'd imagine we would only do it after a long timeout, like a week or a month. At that point, it's more likely that someone has left the watch in a drawer and probably doesn't care about any running stopwatches or countdown timers, and it would be safe to halt or reset the HPT. Alternatively, we could just prevent going to BACKUP mode and stay in STANDBY if the HPT is running. and we'd still get great battery life out of it.

The extra logic amounts to finding the next expiring timer and then scheduling it on the RTC's comparator.

I mean, there's a little more to it than that. Unless I'm mistaken, the RTC can still only schedule interrupts on whole-second boundaries, meaning it wouldn't be suitable for chronographs, buzzer tones, or long-press timing, both of which require sub-second precision.

And regarding PR #345 and switching the RTC to COUNT32 mode at higher frequency: I am generally against this. It seems silly to me for us to use the RTC peripheral as a generic 32-bit timer and give up its calendar and alarm features when there are two other 32-bit timers we could use. We would have to emulate all of the hardware features it provides in software now including:

• ticking specifically at 1hz for clock faces
• doing all the calendar math to go from unix seconds to calendar time

---

I know that us software engineers love to do more with less. (I mean, otherwise we'd just be using smart watches) Ultimately, the question here comes down to CPU wakeups and power consumption. I could implement a reasonable alternative to this version of the HPT by commandeering the 128hz tick from the RTC and using it to keep track of a continuously incrementing timestamp, then checking to see if the timestamp matches any scheduled events manually. But that means waking up the whole CPU to mostly just increment a variable in memory and occasionally do some extra work. I have to imagine that using a hardware timer to do this will be much more power efficient. For example, if we want to illuminate the LED for 3 seconds, we have to wake up the CPU 384 times just to increment a value and say "nope, not time to turn off the LED yet." Using a separate timer for this would mean we only have to wake the CPU up once when it is time to turn the LED off.

[matheusmoreira]

the RTC can still only schedule interrupts on whole-second boundaries

That's only because movement has configured the prescaler all the way down to 1 Hz.

The 10-bit programmable prescaler can scale down the clock source. By this, a wide range of resolutions and time-out periods can be configured. With a 32.768 kHz clock source, the minimum counter tick interval is 30.5 µs, and time-out periods can range up to 36 hours. For a counter tick interval of 1s, the maximum time-out period is more than 136 years.

There's quite a bit of freedom in the tick periods we can choose.

It seems silly to me for us to use the RTC peripheral as a generic 32-bit timer and give up its calendar and alarm features when there are two other 32-bit timers we could use.

I don't disagree with you. Wouldn't enabling the additional timers consume more power though? I suppose that's all it comes down to.

We would have to emulate all of the hardware features it provides in software now

Does this require more power than keeping the additional peripherals active? It's difficult for me to say. I think @joeycastillo is the only one who's done any power profiling on the watch, I wonder what his intuition is on this matter.

ticking specifically at 1hz for clock faces

This isn't a big problem though. If it was just the RTC keeping track of time all on its own, that would make sense since the CPU is sleeping in that case. However, it does wake up the CPU every second in order for movement to deliver tick events to the foreground watch face so it can update the screen. So the CPU is going to be woken up and do expensive computations regardless of what we do.

This would be a problem in low energy mode but we could simply switch the time period to one minute timer in that case.

doing all the calendar math to go from unix seconds to calendar time

We can avoid all that computation by storing this data in movement's state. We could have a structured time and date and a timestamp at the same time. Movement's time keeping function would then simply increment those every second. In low energy mode, it would simply add 60 seconds every minute.

then checking to see if the timestamp matches any scheduled events manually

We don't need to do that. We can find the nearest event and schedule that on the RTC's comparator instead. Then the CPU sleeps until it fires. This scheduling must be done every time timers are started, stopped or expired.

For example, if we want to illuminate the LED for 3 seconds, we have to wake up the CPU 384 times just to increment a value and say "nope, not time to turn off the LED yet."

That's not what I had in mind. The way I imagined it, the LED would be illuminated and then a timer would be set for 3 seconds in the future. Then the CPU would sleep. When the timer fires, the LED would be turned off.

[Kimm0th]

Speaking of precision, aren't the standard digital watch button 'mechanisms' just absolutely awful?

At the cost of a great deal of time, frustration, and a Sensor Watch PCB I caused a short on, I hacked blister buttons into mine. It was extremely difficult and remains a tad sketchy, especially being a fiddle to disassemble and reassemble, because the blisters themselves are separate and held in place with a little strip of sticky tape, but the tactile buttons are nevertheless a vast improvement - aside from feeling a LOT fancier and being stupidly unique (as in, all the other watches seem stupid without tactile buttons), you know you've successfully pressed the button without watching the watch.

Here's a couple of pics: https://forum.core-electronics.com.au/t/watch-out-for-the-rabbit-holes/18882/14

What would be super awesome, is if there was a PCB option to include some little unitary tactile buttons instead of the standard contacts on the PCB edge - this would require the user to cut away some of the movement's chassis, and to break off the spring tabs from the battery cover as I've done, but there's no real need for the Sensor Watch to be a reversible mod, and this would kick so much arse.