Tick-less mode support for NilRTOS

[Giovanni]

Hi,

Starting from revision 5828 Nil supports a tick-less mode. This means that there is no more a periodic interrupt and the system time is calculated using an HW counter.

I implemented it in the CM0 port only so far and the result are very interesting. On the STM32F0 at 48MHz the demo is running with a timer resolution of 20uS in tickless mode. This means you can call nilThdSleepMicroseconds() and expect an accuracy of 20uS plus the jitter caused by interrupts servicing.

The tick-less mode will allow for huge power savings because the CPU is not waken from the deep sleep modes by the system tick interrupt, it only exits the sleep mode when there is some actual work to do.

Of course the classic mode is still supported.

Giovanni

[Giovanni]

Also added hook macros for entering/leaving the idle thread, this way it is easy to add code to enter or leave low power modes.

Together with the tick-less mode and the small size this should make Nil about ideal for low power applications on tiny devices.

Giovanni

[chrylis]

What properties does the "HW counter" need to have? For example, on AVR the main timers are shut down in power-saving modes, and you'd have to use Timer2 with an external crystal to keep accurate time while the processor is asleep. For one application I'm working on, it would be fine for the system clock to lose time while asleep (the watchdog timer with its ±15% is accurate enough to wake from deep sleep), but the AVR can't go any deeper asleep than Idle with Timer0/1 running.

[Giovanni]

It is required a 16/32 bits up-counter with a comparator register. A down counter could be used too with extra math.

Giovanni

[chrylis]

What Bad Things would happen if the system clock lost time during sleep? I would like to put an AVR into Power-Save mode (only Timer2 running, but waking up on Timer2 or other interrupt), and it's OK if threads don't get scheduled until the MCU wakes up (the tasks that need to respond promptly will set their own interrupts). Would Nil just resume scheduling when the processor wakes up (and returns from the ISR), or would there be problems?

[Giovanni]

Hi,

Rescheduling only happens on interrupts when the OS is in the idle thread.

You need to use a deep sleep state that still allows for interrupt servicing at it will be fine (except possible problems with added ISR latency caused by the sleep state).

Giovanni

[chrylis]

Unfortunately, the AVR's deep sleep states turn off the timer that Nil uses for the system clock, so it's impossible to go into deep sleep and still have the timer run correctly. What I am trying to determine is whether the rest of the system would still work properly if the system clock gets paused during sleep (like how old VM software sometimes made guest OSes lose time, but everything else worked). All of the wakeup interrupts from deep sleep can be managed specifically by threads, and the clock timer would get restarted on wakeup.

[Giovanni]

Is there some other timer not stopped in deep sleep?

Giovanni

[chrylis]

Timer2 can be run in deep sleep, but it has the disadvantages of drawing power and only having 8-bit resolution. My plan was to use the watchdog timer (8s overflow time) when my device is idle to see whether it should scan for events (every half-hour or so; an ISR can track 30 minutes with a single-byte counter in about 4 cycles) and Timer2 when running a program to wake on an interval of 10-250ms while active. The deep sleep would be interrupted by either the watchdog interrupt or pin-change (for physical buttons or incoming serial data) and would not need a system tick. My system is almost entirely event-driven, but I would like to use Nil to run string parsing and I2C on non-interrupt threads and then go to sleep if there's no work to do; since a cooperative model with interrupts will work, I don't need a correct system timer, but I haven't been able to figure out from the source whether putting that timer to sleep (or, ideally, eliminating it) would cause problems.

[chrylis]

(To clarify: It does appear that the STM port with tickless support does work by setting a hardware timer for the next known event timeout, which is the general approach I'm taking with Timer2, but that implementation at least appears to be limited to the overflow time of the hardware timer, and it doesn't support using multiple timers, such as the extremely slow watchdog on the AVR. I'm still not quite sure how the scheduler is intended to work but would be happy to help document and clarify it when it reaches a semi-stable point.)