Overview

Round Robin Scheduling	Every task in the each priority gets an equal amount of time.
Preemptive and cooperative	Choose between preemptive or cooperative on a task by task basis.
Register Compression	Save only the registers that are used on the stack at taskswitch.
Separate OS/ISR Stack Space	The OS (ISR) has its own stack space
Power save on Idle	The idle task can be used to save power.
Honest Time Slicing	Every task gets the same amount of execution time, so no starvation.
High Resolution Load Monitor	Check how many subticks a task really runs.
Stack Overflow Protection	Before a task overflows the stack it is shut down, others keep running.
Rendez Vous, Mutexes, Queues	Everything you need to communicate between tasks.
Priority Lifting	Tasks get the priority of the most important blocked task.
Timed Power down	If all tasks are delayed sufficiently long, the OS may sleep.
Nested Critical Sections	Seperated nesting for tick and general interrupt critical sections.
OS interruptible	Large parts of the OS can be made interruptable.
Error Callback	System errors are reported through a customable method.
Precision Delays	The time between the different wakeups of a task can be set precisely.
Minimal Footprint	Only things realy needed are compiled into the kernel.
Watchdog per Task	Revive tasks that have crashed with a watchdog.
Heavily Documented	Lines in the core file: 43% code, 50% comments, 7% blanks.
Trace facility	Produces a trace of most actions taken inside the OS.
Configuration Checking	Your configuration is checked by preprocessor code for typos.
Lots of Example code	More than a dozen examples illustrate how to use the api.
Script code analyzer	Some scripts help you to optimize your code further.
Source available and free	As it should be.
Integrated file system	File system for onboard eeprom managed by the OS.
High speed events	Events for reviving tasks with for some special action.

Detailled descriptions

Round Robin Scheduling per Priority

The scheduler runs through all tasks in the highest priority. The task which has not yet run, but is able to, gets the turn. If no task is able to run, a low priority is examened. If no task can be stared, the idle task is started. The idle task does not consume resources.

Preemptive and cooperative

Per task it can be specified if the task should be preemptible or not. Tasks which are run on a cooperative basis do not need to save any registers.

Register Compression

Registers which are not used in a specific tasks, or registers only used in area's where no context switch is possible do not need to be saved. Especially in the AVR architecture which has 32 registers, this can save a lot of stack space. Often it is enough to save only 12 registers or even less. This also makes the context switch quicker.

Separate OS Stack Space

Regular operating systems have no special stack for the OS. The code for save/restore context is simple, but on every task stack a copy of variables used in the OS appear. This is such a waste! Thus, in the Femto OS a separate stack is used for the OS. Of course this implies an extra change of stack on every save context. Something similar applies to the interupt service routines. You may give it its own space of let it make use of the OS stack.

Power save on Idle

The idle task is a portable method, in which you can call a power save mode of the device. Of course this is implemented in the port for the ATtiny861.

Honest Time Slicing

Most OS have a tick interrupt with a fixed time interval. Most of the times this is just fine. There are situations however where this may starve particular tasks, that are just at the end of the cycle. With Honest Time Slicing you can ensure every task has at most a given number of sub ticks to run. The sub tick timer is reset at every task switch. Since this time slice can be set per application and can also be extended, this is particularly useful for implementing communication tasks. If you know some communication can be completed in say 5 ms, just set the time slice for that task to 5 ms. Per default, the Femto OS uses equidistant tick interrupts however.

High Resolution Load Monitor

Using the sub tick timer it is possible to monitor the time spent in every task, the OS and the ISR. This functionality can be compared with the well known windows taskmanager. It also keeps track of the use of the registers and stack using a watermark technique.

Stack Overflow Protection

When living on the edge, you must have tools to rescue when you fall over. On every context switch the system calculates if the context will actually fit on the remaining stack. If not, the context is not saved, to prevent overflow, and an error message is generated. Of course, when your code goes into production this can be switched off.

Rendez Vous, Mutexes, Queues

Several synchronization primitives are available. You can let tasks (any number) wait for each other, you can define a (reentrant) mutex, and you can make use of queues. Queues are locked by stating the number of bytes involved. A lock is obtained if the queue is ready for reading or writing. At task can hold several locks simultaneously. It is also possible to request the possesion of two mutexes, queus or a combination simultaneously. The task blocked until both resources become available.

Priority Lifting

Also called priority inheritance. If a high priority task blocks on a low priority task, the low priority task is increased in priority. If the synchronization is over, the low priority task is set to its original priority. What differs from the standard implementation is that the low priority task gets its the priority stored in flash, instead of the priority it had before the block occurred. This is done to save ram.

Timed Power down

If all processes are sleeping or are sufficiently long in delay, the device may be brought to a low power state in which the tick interrupt is halted. After wake up, the timer counter is restored, and operations continue as if no sleep occurred. The OS tries to incorporate sleep periods as much as possible, time calculations are done by the OS.

Nested Critical Sections

Critical sections (mutex or queues) can be nested. Furthermore there are separate Enter/Exit global critical sections and similar tick critical sections. These can be nested up to 4 or 16 levels deep, depending on the setting of the configuration parameters.

OS interruptible

Interrupts can never occur at places where the stack is changed. Apart from this, the OS can be made interruptible if needed. However, it is also possible to work in a OS protected mode. Thus, depending on your needs the system can be quite responsive.

Error Callback

The port file contains a method that is called in case of an error. The current implementation is to present that information on PORTA by blinking the leds. It shows an error code, and subsequently which task or slot caused the problem. If the error is not fatal, Femto OS will terminate the offending task and resume operations. The Femto OS also contains a method for recreating the particular context of a task and restart it.

Precision Delays

Femto OS is driven by a 16 bit timer, and the system is quick enough to run a 1000Hz timer interrupt on a ATtiny861. You have the possibility to wake every task a fixed number of ticks after its last wake, which makes precision timing possible.

Minimal Footprint

Only those parts you really need are compiled into the Femto OS, this not only applies to the methods implementing the API but also to the core of the system itself. This can all be fine tuned with a number of configuration parameters. First you develop with all guards on alert. This makes your code larger, but can be done on an architecture with more flash/ram. This is needed, since you want to be certain your application is correct. When all is well, simply switch off the checks and the code size will reduce up to 40%.

Watchdog per Task

For every task a watchdog can be defined which keeps track of the activity of your task. (This is not related to the device watchdog itself) If your task gets stuck, it will bark and give you the opportunity to act in a particular way. This is most convenient when implementing communication busses. In this way you don't have to check on every spot if the timeout has passed, simply let the watchdog take care of that.

Heavily Documented

The Femto OS core code and port file is heavily documented. The overall design is pretty straightforward OS system design, so anyone with some knowledge in that area should find it easy to understand and modify. The core file contains 43% of lines with code, 50% with comments, 7% of blank lines. Or, if you count the characters, 62% of them is devoted to comments.

Trace facility

All actions inside the Femto OS are traced upon request. The trace information is sent to an method in the port file. The current implementation uses the USI to get the information to the outside world. Included in the download is a Delphi program (under windows) to read the trace information. You can use this facility also to trace your own applications.

Configuration Checking

Since there are numerous options that must be configured, a mistake is easily made. That in itself is not a problem, but it becomes a problem when the code still compiles and runs. Therefore there is a special configuration check facility (all standard preprocessor code) which checks the typo's made most often.

Lots of Example code

At this moment we have 11 demo applications demonstrating what this system is capable of. At the same time you can learn from it, how the functions should be used. It is often a lot quicker to modify already working code than start from scratch.

One of the application examples contains a shell and a homebred bus communication protocol. In order to get that running, a delphi program is included, and the device must be coupled to the parallel pinter port. Through the shell you can communicate with the device and give instructions. Use this as a starter for your own applications.

Script code analyzer

Two scripts are delivered (based on awk) which can help you to analyze your code. First, extract_regs, analyses the assembly code and tries to calculate the use of stack and registers. It does its job reasonable well, but the results depend on the quality of the disassembly comments in the elf code. If labels are misinterpreted (which happens more than often) the script cannot calculate the function target correctly and may miss some registers.

A second script checks if the indirect addressing has been correctly used by the gcc compiler. Sometimes the compiler still makes use of the framepointer, when there is no real need. Since most functions are naked, this can be dangerous, so you will be warned if this happens. At that point you can switch of the use of the naked attribute.

Source available and free

Whether this is a reason to choose for the Femto OS is a matter of taste. In any case, you can easily modify the code if something is not to your liking. And if you are willing to publish your code and embedded upgrade instructions it may be suited for commercial applications as well. If not, well, there still is the commercial license.

Integrated file system

Most AVR chips have an onboard EEPROM available. You can activate a file system on (part of) this eeprom. Files have fixed maximal sizes, but a 'FAT' table keeps track of the filling of each file. While the files are beeing written, that task is locked and other tasks may continue to run. File operations are single write - multiple read synchronized. This synchronization mechanism works independently of the other synchronizers. Writing is organized in such a way that at power failure the integrity of the files is protected. (Requires brown out detection.) If the device is put to sleep, all tasks queued up for writing to the file system are allowed to complete. To extend the life of the EEPROM the write byte methode can make use of split byte programming.

High speed events

You can generate events in tasks and interrupts. These events can be used to wake one or more tasks waiting for events. Using this mechanism you can build very efficient (i.e. low overhead) ways to handle i/o. The mechanism even works when the OS is set to be interruptable.

Contact: info@femtoos.org