1 / 14

A survey of small real-time operating systems.

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.

shaunna
Download Presentation

A survey of small real-time operating systems.

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 • 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 ?

  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. OSEK-VDX QNX eCos VX-Works 5.4 VCB SYMO The rtos:es included in the report are

  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. Task management Application modes Synchronization Eventflags. Intertask communication Memory management Interrupt handling Clocks Timers Overall The richness criteria.

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

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

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

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

More Related