1. A survey of small real-time operating systems. Henrik Hoffström hhm00001@student.mdh.se

2. The purpose Part 1: Make an survey of the ”commercially available rtos:es for small embedded systems. Part 2: Use the results of the survey to adapt Symo (a small rtos) to support one of the existing ”standards”

3. The problems 1.What is a small rtos ? 2.Which rtos:es should be included in the report ? 3.There are many ways to design a rtos, how to compare rtos:es of different design ? 4.What should be done with Symo ?

4. The solutions part I A small rtos:es was arbitrarily defined as being at the most 30k in size for the minimum footprint. The report includes six rtos:es. These were chosen according to the following criteria.

5. To be considered for inclusion an rtos had to: Be reasonably well know/used. Have an interesting design Have comprehensive documentation available for free.

6. The rtos:es included in the report are OSEK-VDX QNX eCos VX-Works 5.4 VCB SYMO

7. The solutions part II To be able to compare the different rtos:es a number of api richness criteria were set up*. The criteria were then used to evaluate the functionality of each rtos in the following areas: * This idea was heavily inspired by a document called Evaluation report definition found on www.dedicated-systems.com

8. The richness criteria. Task management Application modes Synchronization Event flags. Intertask communication Memory management Interrupt handling Clocks Timers Overall

11. The solutions part III My proposition is that an OSEK-VDX layer should be implemented on top on the existing Symo API.

12. Why OSEK-VDX It’s a large well documented standard Most of it’s functionality can be built on top of the existing Symo API. Conformance to the standard is broken up in different levels. The basic conformance level contains a low amount of features meaning that a working OSEK-conformant system can be build quickly.

13. Conclusions. Few other surveys of this kind has been done and those that exist are several years old Free documentation on rtos:es are hard to find. And the documentation that exists are often incomplete In spite of this the api richness criteria seem to give a good overview of an rtos, The rtos:es that on beforehand were known to have a rich Api were also those that fulfilled the largest amount of richness criteria.

14. Future work. There where several standards, most notably realtime-posix and uITRON 4.02 that had to be left out of the report since they didn’t fulfill the inclusion criteria. As many of the examined rtoes:es to some extent support these standards An examination of them would be a useful future addition to this report.