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 lower priority is examened. If no task
can be started, 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.

Shared Stacks for tasks

Tasks that do not run very often, for example that are watching some switches,
can share their stack space. Among each other they run cooperatively, but with
the remaining tasks they still run preemtive.

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/ISR 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. A similar apprach is used for the
isr's, which may use the OS stack or a stack on their own.

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 on the avr's.

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.

OS interruptible

Interrupts can never occur in routines where the stack is changed, the context
save/restore for example, and in the event handlers. Apart from this,
the OS and kernel calls 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. Note that nested interrupts are not allowed per default.
Kernel calls are not preemptable. For calls that are handled in OS space, this makes
no real sense, and calls that are handles in OS space are usually very short.

Resource Tracking

Tasks can be terminated by the OS if an error occurs. Usually in the testing
phase because the stack overflows or not all used registers are saved on the context.
Tasks can also be terminated by an kernel call. The OS makes sure all hold locks
on for example the file system, mutexes etc are released when such an event takes
place.

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.

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.

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.

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.

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.

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.
Note: these events are not related to the event system on the xmega.

Parameter Checking

All methods that take parameters have optional parameter checking in place.
This protects you, for example, from passing non existent task numbers, priorities,
reading from empty queues and so on. Of course, when you go to production, you
switch these checks off.

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.

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.

Trace facility

All actions inside the Femto OS are traced upon request. The trace information
is sent to a method in the port file. The current implementation uses bitbanging
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.

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 frameprointers are used by the gcc compiler.
Sometimes the compiler still makes use of the framepointer, when there is
no real need.

Lots of Example code

At this moment we have 12 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.

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.

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%.

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.

Over 40 ports.

For the AVR, Femto OS has been ported to 44 devices. All
demo applications have been tested on the hardware, except in
those cases where the hardware does not accomodate the
application. Where possible, the preprocessor reduces
footprint by removal of the higher stackpointer etc. Also,
the ATmega256x is supported, albeit with the limitations
imposed by gcc. Adding a new port is easy since all device
information is contained within one file.

X-platform toolchain builder

Included in the package is a toolchain builder which
installs the latest versions of binutils, gcc, avr-libc
and avrdude on your system. It even solves the gmp and
mpfr library problem for you. It has been tested on
Gentoo Linux, Ubuntu Linux, Mac OSX, Windows 2000 and
Windows XP.