Overview
| OS Design | |
| 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. |
| Shared Stacks for tasks | Possibility to save ram by letting tasks share their stack space. |
| 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. |
| OS interruptible | Large parts of the OS can be made interruptable. |
| Resource Tracking | Tasks that are terminated are managed to release all kernel resources. |
| | |
| Additional capabilities | |
| Nested Critical Sections | Seperated nesting for tick and general interrupt critical sections. |
| 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. |
| Precision Delays | The time between the different wakeups of a task can be set precisely. |
| Watchdog per Task | Revive tasks that have crashed with a watchdog. |
| High Resolution Load Monitor | Check how many subticks a task really runs. |
| Integrated file system | File system for onboard eeprom managed by the OS. |
| High speed events | Events for reviving tasks with for some special action. |
| | |
| Quality protection | |
| Parameter Checking | Parameters passed to the kernel can be checked for validity. |
| Stack Overflow Protection | Before a task overflows the stack it is shut down, others keep running. |
| Error Callback | System errors are reported through a customable method. |
| Trace facility | Produces a trace of most actions taken inside the OS. |
| Configuration Checking | Your configuration is checked by preprocessor code for typos. |
| Script code analyzer | Some scripts help you to optimize your code further. |
| | |
| Making live easy | |
| Lots of Example code | More than a dozen examples illustrate how to use the api. |
| Source available and free | You can inspect, modfiy and improve the code. |
| Minimal Footprint | Only things really needed are compiled into the kernel. |
| Heavily Documented | Lines in the core file: 43% code, 50% comments, 7% blanks. |
| Over 40 ports. | For the AVR, Femto OS has been ported to 44 devices. |
| X-platform toolchain builder | Use the toolchain builder on Mac, Windows or Linux. |
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.
| Contact: info@femtoos.org | CC-BY License: Ruud Vlaming. |