Some of the recent discussions on this forum regarding “Tickless OS” support NuttX inspired me. So I implemented it! It really was not that difficult… About a day and a half of work with only a few spills and chills.
I did all of the testing on the NuttX simulator using the OS test. I built in a simulated interval timer for the simulator and ran the OS test against the tickless OS support. The OS test is probably more exhaustive than what the typical application does so I am fairly confident in the implementation. Of course the simulator can miss certain classes of bugs.
NuttX is a 32bit embedded realtime operating system, licensed as open source under the BSD license.
I have a TI Tiva board I’ll have to dig out and try this on, looks like a lot of fun!
Really, there is nothing “fascinating” about a tickless RTOS. Normally an RTOS needs the system timer only for time-outs not for scheduling.
So what’s all the fuss about this tickless-stuff?
Not in my experience. Almost all non-cooperative OS (regardless if they are real time or not) I have looked at use a system timer for scheduling at least certain types of tasks.
Going tickless means that the processor may be asleep for longer and potentially save much more power.
Clearly our experiences differ, but I would suggest that system timers are used more often than you might think
I make the difference between a GPOS like eCos, *nix, Windows et al and an RTOS.
I am not aware off a “real” RTOS, which needs a timer for scheduling.
Of course, many RTOS use a system timer in order to allow the application programmer to suspend tasks for an amount of time. But if the application does not need a regular timebase, it may run “tickless”.
Scheduling in an RTOS is kicked by external events.
I have never heard anyone call eCos a General Purpose OS. The eCos group themselves call it a real time OS.
By “real” do you mean Hard Real Time? If not, please explain what you mean.
There are Tasks and Scheduling (with the capital letter), and then there are tasks the kernel does on a (semi) regular basis which may have nothing to do with process scheduling. So even though the system timer may not be used by the Scheduler, that doesn’t mean it isn’t used.
Oh, yes I stand corrected.
I do not like to differ between “hard” and “soft” realtime. With “real” I wanted to make the difference to GPOS with realtime extensions.
This is a strange view. An OS does have a scheduler which is responsible to divide CPU time between all processes/tasks. If an OS does give some work to tasks inside the kernel these are still tasks.
In an GPOS like Linux or Windows, the scheduler is often based on a tick. This allows the tasks to be swapped out after some amount of time (user experience).
In an (embedded) RTOS, this makes no sense for most tasks. So an RTOS schedules tasks because of events such as a GPIO pin changing state.
In most cases, the developer expects a task to run until it has finished the current (event triggered) job.
But maybe I have to explain what I understand under the term RTOS by examples:
QNX – no RTSO
QNX/Neutriono – the RTOS on which QNX is based
OSE – RTOS
Linux – GPOS
MQX – RTOS
SCIOPTA – RTOS
FreeRTOS – RTOS
DeepThought,
“Tickless” is actually a bit of misnomer because all preemtive operating systems need timer interrupts to generate context switches to keep processes from monopolizing the CPU. Tickless merely refers to turning off those interrupts to stop useless transitions like when the CPU is idle (ie a useless sleep->sleep transition).
I wouldn’t say there’s much fuss, only that some operating systems haven’t done it yet. I still find it interesting to read about when they do.
Edited 2014-08-09 03:56 UTC
I double my comment: In an RTOS, the timer is not needed for scheduling.
In case a process occupies all CPU time the software is bad designed. At least there should always be a kind of supervisor task plus a low level task that feeds the watch-dog.
But sure, when you think of some hypervisors, they to time partitioning to separate task-groups. But this is a special kind of RTOS IMHO.
A GPOS without tick is a different story.
DeepThought
I know what you are saying about the scheduler, but the characteristic you are referring to is not a property of whether an OS is an RTOS or not, but whether the OS is preemptive versus cooperative. All cooperative OS schedulers will wait until the process returns control, there’s no concept of ending processes at the end of their timeslice, and therefor there’s no need for timer interrupts.
In principal there’s no reason an RTOS scheduler can’t use timer based scheduling. For example, some predetermined timeslices could be reserved for a realtime process, as described at the following link under “Scheduling Paradigms”. This approach is simple, deterministic, and effective.
Scheduling algorithms and operating systems support for real time systems:
http://citeseer.ist.psu.edu/viewdoc/download?doi=10.1.1.107.4879&re…
In any case I still find NuttX worthy of covering even if it’s been done before, but that’s just my opinion.
I did not want to diminish NuttX. I astonished what it all provides. It was just all about “tickless”.
Hi Thom,
please fix the post: NuttX is an 8, 16 and 32 bits Operating System.
@DeepTrough the advantage of an tickless RTOS is the low power consumption and higher context exchange frequency.
I wish I could vote you up, so instead I will second your request.
NuttX is an interesting embedded OS, memory efficient and resource efficient, and unlike many embedded operating systems it even has a graphics subsystem and widget toolkit; and it can run on 8 and 16 bit CPUs as well as 32 bit ones.
And this fact is called out on the front page of the NuttX website as well as the wikipedia entry…
I know this is now “old news” (as it is now 4 days old or so) but it would be nice if the description were fixed.
I doubt anybody from the staff is reading these comments…
I believe the only real staff is Thom, he isn’t likely reading anymore (he seems to stop after the first day in most cases); but that is a shame.
I don’t know what the statute of limitations on correcting mistakes is, but I think it should be more than a week (if that doesn’t make me sound too entitled)…
Well, you can always try writing to Thom an email
– address is in his profile.
Given that it has pascal support, I may need to take a look.
Hahaha, then you need to look it because it has Pascal since its version 0.3.6 (circa 2008):
0.3.6 2008-01-06 Gregory Nutt <[email protected]>
* Changes for use with SDCC compiler
* Added a simulated z80 target
* Fix deadlock errors when using stdio but with no buffering
* Add support for Pascal P-Code interpreter
______________^^^^^^^^^^^^^
NuttX is amazing!!!