Open side-bar Menu
 Embedded Software
Colin Walls
Colin Walls
Colin Walls has over thirty years experience in the electronics industry, largely dedicated to embedded software. A frequent presenter at conferences and seminars and author of numerous technical articles and two books on embedded software, Colin is an embedded software technologist with Mentor … More »

OS migration

 
January 16th, 2017 by Colin Walls

I have often talked about the process that might be applied to the selection of an embedded operating system and I hope that I can provide some guidance. However, developers tend to stick with a specific OS [or, at least, with a particular OS vendor] – recent research suggested that only about 20% of developers anticipated a change of OS for their next project.

I started thinking about why there is this apparently high degree of loyalty …

I do not think that there is a single, simple reason why embedded software engineers choose to use the same OS time and again. One motivation is that embedded guys have a pragmatic conservatism: “if it ain’t broke, don’t fix it”. Although that attitude is quite reasonable, I think that we can identify two specific reasons not to change OS:

  1. Vendor satisfaction. If the level of support and quality of documentation is very good or excellent, that is definitely a reason to stick with a particular OS vendor [as it is with almost any product].
  2. Skills and IP lock-in. The technical characteristics of a given OS permeate the application code and the skill set of the team. This has primarily two manifestations:
  • Drivers and middleware are often very specific to a specific OS. Moving to a new OS implies the acquisition of new skills and rewriting of a lot of code.
  • The application program interface [API] ties the application code to the OS and also represents part of the team’s skill set. It is true that many RTOS products have a proprietary API. Moving to another OS would require changes to the application code. Alternatively, many developers us an OS abstraction layer to protect themselves from such a change – only the layer needs to be modified to accommodate a change in OS. Another approach is to embrace a standard and the common API standard is POSIX. Although this is the native API for Linux, it is also supported by many RTOS products and its use provides a degree of code portability.

If you are sticking with a specific OS for other reasons, I would be interested to hear about your motivations and experiences.

Logged in as . Log out »




© 2024 Internet Business Systems, Inc.
670 Aberdeen Way, Milpitas, CA 95035
+1 (408) 882-6554 — Contact Us, or visit our other sites:
TechJobsCafe - Technical Jobs and Resumes EDACafe - Electronic Design Automation GISCafe - Geographical Information Services  MCADCafe - Mechanical Design and Engineering ShareCG - Share Computer Graphic (CG) Animation, 3D Art and 3D Models
  Privacy PolicyAdvertise