Category: Microcontrollers

I just released pico]OS 1.1.1. Tickless mode is now stable, I have been running  boards with it without any problems for long times. I added also some support for Nordic Semiconductor NRF51 chips (Cortex-M0 + BLE).

When working with NRF51 I added a way to selectively block Cortex-M0 interrupts by using NVIC, because it was the only way to get Nordic Semiconductor BLE Softdevices working with pico]OS. But it is a useful feature for all M0 chips because one doesn’t have to block all interrupts during critical sections. Only limitation is that SysTick cannot be used drive scheduler (as it cannot be blocked with NVIC).

To enable this feature add following lines to poscfg.h:

#define PORTCFG_NVIC_SCHED_LOCK 1
#define PORTCFG_NVIC_SCHED_LOCK_IRQS 0xffff
#define PORTCFG_TICK_SYSTICK 0

PORTCFG_NVIC_SCHED_LOCK_IRQS is a mask which should include all interrupts that are going to call pico]OS services (0xffff is only an example).

There is also some retro-work: pico]OS runs again on 6502 when compiled with latest cc65 compiler.

I did some rough measurements using my picoscope on EMW3165 (ie. STM32F411CE) module to find out how deep sleeping during tickless idle affects system scheduling latency. I connected logic analyzer to four GPIO signals to get timings for SysTick, RTC wakeup, HSE oscillator startup time and application task activity. GPIO pins are driven by a simple test application on STM32, which initializes a pico]OS timer to fire each 150 ms. To find out differences between normal and tickless mode it also toggles power saving mode each pass.

First timings for case where systick is always active and CPU does not sleep:

SysTick interrupt handler seems to execute under 5 microseconds and PendSV handler that does the context switch in this case takes 3.5 microseconds. So, after interrupt is raised it seems to take a little more than 8 microseconds to application task serving it to be activated.

Next the case with tickless mode. More latency is to be expected because HSE oscillator is stopped and must be restarted before application continues.

In the worst case latency is a lot bigger. It seems to take 80 µs for CPU to start up from sleep and 720 µs for HSE oscillator to restart. Context switch to application task takes 6.6 µs, which is a little bit longer than in previous case (this is because context switch is delayed after HSE startup, needing an extra SVCall interrupt to handle it). Summing all these up it seems that the worst case latency is about 807 µs, which is 100 times more than in previous case.

The extra scheduling latency doesn’t hurt timer operations much, because pico]OS uses “safety margin” for tickless sleep – it always wakes up a few ticks too early, giving HSE oscillator time to startup correctly before it is needed. But extra latency is present on other interrupts, because there is no way to predict them.

If application cannot tolerate bigger latency, it is advisable either to leave tickless mode disabled or use posPowerDisableSleep in critical places to enforce smaller latency.

 

I pushed last bits of pico]OS 1.1 branch to github today and created 1.1.0 prerelease version. It is a major improvent on energy efficiency, since timer ticks can now be suppressed when system is idle.

Continue reading “pico]OS 1.1.0: Tickless idle”