ChibiOS Free Embedded RTOS

Hi,

A small update about recent developments (not visible in truck, it is all done in a branch).

The tickless mode in the ChibiOS/RT 3.0 development kernel appears to be working, the test suite is executed correctly but there are some limitations:

1) Preemptive round-robin is not supported in tickless mode. Threads at equal priority can yield cooperatively, this is almost never a problem.
2) Thread profiling debug option is not functional in tickless mode. It will be reimplemented when the kernel will receive the RT timer handling currently in the HAL.

This will enable ChibiOS to run in very deep power modes AND to increase the timer resolution to values like 20-50uS without saturating the bandwidth with useless interrupts.

Of course this branch contains very preliminary code, only the STM32F3xx is functional because it is being used as development platform.

Giovanni

That is awesome Giovanni.

So will the kernel be able to put the MCU into a deep sleep mode where the system clock is stopped. When all threads are sleeping then the kernel will automatically put the MCU into deep sleep?

How are peripherals affected by this? For instance, an SPI block transfer might have been initiated by a user thread before it sleeps. Will the kernel know that the SPI driver is working and so the kernel can't enter a mode of sleep too deep yet? (But a "core-only sleep" would be good and ideal still, so there are multiple power modes that should be utilized.)

The kernel does nothing by itself except generating just the interrupts strictly needed.

Now there are two hooks that are called when entering the idle thread and when leaving it, the behavior depends on what you do in the hooks. You may check the peripherals status before deciding the sleep mode for example.

Giovanni

While you're thinking about Tickless, could you also think about whether it's possible to do suspend to SRAM?

It'd be a very low power mode (deeper than WAIT/Tickless) where only the timers and/or RTC and/or external interrupts (pins or serial port or USB port or ethernet) are enabled. When the interrupt (timer or external) comes in, it wakes the CPU which restores everything to the right state before coming out of Idle.

Most Cortex chips support this mode of operation, but of course don't provide anything to help (like save system/peripheral config to memory location and restore from memory location)-:

Hi,

What the kernel can do (and it does) is to offer hooks for entering/leaving the idle thread. The configuration of deep sleep modes is so dependent of the machine configuration and status that cannot be realistically handled in a simple way.

What we could do is to define a new driver model dedicated to the sleep modes.

Giovanni

Giovanni wrote:What we could do is to define a new driver model dedicated to the sleep modes.

That's what I was wondering. If each driver had APIs for pause, save state to RAM location, load state from RAM location, continue, that might be enough for sleeping drivers.

Then people can use the idle API for the rest of the system that the driver API doesn't handle...

Very complex to implement and test. The application can already stop the unnecessary drivers before entering the sleep state and start them again exiting.

Giovanni

Giovanni,

wow, tickless!

It will probably open new cans of worms, but I think there may be added value to a tickless RTOS. Or do you think RT is contradictionary to tickless?

Random thoughts:

Do you know of any processors that can be waken from deep sleep from the internal RTC? (Instead of an GPIO pin)?

Typically waking up the system has a (latency, energy, ...) cost. In some of the timer systems there is an accuracy involved with the time-out. Some time-outs do not need to be accurate and can be coallesced.
It introduces step 3:
1) Wake-up
2) do any timing-critical work
3) do any non-timing critical work (that is within the accuracy of the time-out)
4) Sleep

In Linux the kernel tells the drivers to go to sleep.
In Android the drivers can tell the kernel to stay awake. Maybe in ChibiOS drivers should be able to keep the CPU from going deep sleep.

Regards,

Leon 'likewise' Woestenberg.

Hi Leon,

Long time this thing was first suggested by you in 2010 I think, we are getting there finally.

About the sleep states, it is up to the application to chose the right sleep state, there are hooks for entering/leaving the idle thread where decisions can be taken. The kernel itself just minimizes interrupts and provides the hooks.

Most processors can be waken by the RTC but this is not necessarily related to the tickless mode, very deep sleep modes require a system reinitialization because the system state is not retained.

The tickless mode is more about energy savings while the system is active (short sleeps, suppression of unnecessary interrupts), deep sleep modes are for "long" intervals.

Nothing forbids to mix the two things, for example, in the idle-enter hook you can look at the next event in the VT list and decide that it is far enough in time to deserve a real shutdown, at that point you can put the system to sleep and enable an RTC alarm for the wakeup. This would allow to do automatically a real shut down for intervals longer than N seconds.

Much higher timers resolution is a bonus on top of the tickless mode.

Giovanni

Hi Giovanni,

again, long time but I see you have been carefully coding the 3.x kernel with tickless and high-resolution modes. Great timing, giving the STM32L parts but also SAML21 parts, or maybe even the nRF52xx part, all claiming around 37 uW/MHz. I was about to start playing with these parts when I checked the ChibiOS site and learned about 3.x.

When and where is the release party?

I was thinking as a challenge for me to test, is to deeply power down the microcontroller and program the alarm of an external (ultra-low-power) RTC to wake-up the microcontroller from deep power down when the next ChibiOS timer event should occur. ChibiOS could upon (re)start reload the timer from the external RTC.

[If someone has done this, let me know.]

Cheers,

Leon