140 likes | 419 Views
A survey of small real-time operating systems. Henrik Hoffström hhm00001@student.mdh.se. The purpose. Part 1: Make an survey of the ”commercially available rtos:es for small embedded systems.
E N D
A survey of small real-time operating systems. Henrik Hoffström hhm00001@student.mdh.se
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”
The problems • What is a small rtos ? • Which rtos:es should be included in the report ? • There are many ways to design a rtos, how to compare rtos:es of different design ? • What should be done with Symo ?
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.
To be considered for inclusion an rtos had to: • Be reasonably well know/used. • Have an interesting design • Have comprehensive documentation available for free.
OSEK-VDX QNX eCos VX-Works 5.4 VCB SYMO The rtos:es included in the report are
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
Task management Application modes Synchronization Eventflags. Intertask communication Memory management Interrupt handling Clocks Timers Overall The richness criteria.
The solutions part III • My proposition is that an OSEK-VDX layer should be implemented on top on the existing Symo API.
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.
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.
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.