The timer driver creates two devices: one that indicates the output state of the timer and another that triggers it. It would be nice to have a third device which indicates the remaining time that the timer will be active.
This issue proposes we add a remaining device which is an integer and is read-only. It indicates how many seconds are left before the timer expires.
If the timer hasn't been activated or has expired, this device will read 0. When the timer is triggered, this device should immediately indicate the remaining time (to the nearest second.) This driver should not repeatedly send 0s to the back-end. The remaining time should be updated at 1 hz.
We could have the device count down at 20 hz -- DrMem should be able to handle it. But that would potentially trigger logic blocks at 20 hz. Plus, it would be writing hundreds of records to the back-end. For now, let's keep it at a 1 second resolution.
This is a bad idea. If you want to time the subperiod, just make another timer and trigger them a the same time. I don't like the idea of filling redis with countdown timers.
The
timer
driver creates two devices: one that indicates the output state of the timer and another that triggers it. It would be nice to have a third device which indicates the remaining time that the timer will be active.This issue proposes we add a
remaining
device which is an integer and is read-only. It indicates how many seconds are left before the timer expires.If the timer hasn't been activated or has expired, this device will read 0. When the timer is triggered, this device should immediately indicate the remaining time (to the nearest second.) This driver should not repeatedly send 0s to the back-end. The remaining time should be updated at 1 hz.
We could have the device count down at 20 hz -- DrMem should be able to handle it. But that would potentially trigger logic blocks at 20 hz. Plus, it would be writing hundreds of records to the back-end. For now, let's keep it at a 1 second resolution.