mµOS - My micro OS

a small operating system for microcontrollers

Concept and Goals

mµOS is supposed to be a general purpose Operating-System for small Microcontrollers. With proper configuration it scales down to be useable on AVR ATtiny MPUs. The main focus is on getting Projects efficently and robustly done in short time.

The core of mµOS is a Scheduler which serves function calls from a few queues (Timer and 2 Priorities by default). This approach was choosen to minimize resource demands. Everything is served only by one Stack. There are no threads or context switches, but there are some facilities to call the Scheduler recursively.

Users code always runs synchronously from these queues which are scheduled by the mainloop provided by mµOS. Interrupts are handled by drivers and do the bare minimum necessary to serve the request, postpone any further processing themself onto the work queues.

This means that there are less possiblities of race conditions and in many cases a user doesn’t need to care for synchronization (unless writing drivers).

Still any resource which is not managed by mµOS is available to the user and can be freely accessed and configured. This is a deliberate design decision to put mµOS between bare-metal programming and some more complete OS.

Whenever reasonable mµOS reuses existing Platform and C libraries, but also adds its own concepts and API’s breaking history with POSIX and other common API’s whenever there are some reasons to do so.

Features

  • Most things in mµOS are configurable in very small detail. The build system only links parts which are referenced into the resulting firmware, thus it hard to tell what size mµOS has, because it depends on the application build on top. When slimmed down then sizes smaller than 1kByte and RAM usage of only few bytes are possible.

  • The mainloop pops functions from work queues, executing them and puts the µC to sleep when nothing needs to be done. Any Interrupt wakes the mainloop, the Interupt handler may put work onto the queues which in turn get called as soon the interrupt handler finishes. Scheduling latency is typically 20µs on a 8MHz AVR with the code yet unoptimized.

  • muos_yield() and muos_wait() calls can be used to suspend the current job and call the mainloop recursively.

  • mµOS uses one Hardware counter as main-timer, any timer, 8 or 16 bit can be used for this. The prescaler of this timer is configureable to give a lot freedom on the desired clock granularity and interrupt load. The overflow interrupt is used to increment a global counter and one of the output compare units is used to schedule wakeups of the mainloop.

  • There are (configureable) queues:

    • clpq the timer queue, using a sliding window priority-queue implementation to schedule work within near future, attainable timespans depend on the timer prescaler and shortclock type. clpq jobs are executed with the highest priority.

    • hpq and bgq are simple queues for high and low priority jobs. The scheduler executes from the front of this queues, first all jobs in the hpq and then all jobs in the bgq. One can push new jobs to then end or to the front of these queues, giving roughly 4 different priority levels. One should split work to be done into reasonable small parts and queue them to either work queue. Drivers are also supposed to do most of the work outside of Interrupts by pushing them to the queues.

  • Errors can happen asynchronously in interrupt handlers. Any error has a correspondending bit in a bit-array which flags its occurence. When any errors happened in interrupt handlers are not handled there, then the mainloop first calls a user-defined error handling function.

Documentation

You can read the online documentation here or download a PDF book here.

Note: The website and Documentation often reflect a development version.

Download

The git repository is available at

git://git.pipapo.org/muos

and can be browsed online at http://git.pipapo.org/?p=muos

Development is mainly done in feature branches, use git branch -r to see which ones are available. Development is done on the devel branch, the master branch is tried to be kept stable but often a bit behind. Later on, releases will get their own branches and tags.

Issues

Instead a bug-tracking, mµOS tags and documents bugs right inside its code and documentation. The documentation system then generates a list of known issues which can be viewed here.

License

mµOS - a small operating system for microcontrollers
Copyright (C) 2015, 2016   Christian Thäter <ct@pipapo.org>

This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.

You should have received a copy of the GNU General Public License
along with this program.  If not, see <http://www.gnu.org/licenses/>.