With the Internet of Things, RTOS’s have been gaining a great deal of popularity lately. After all, they’re much better-suited for use in embedded systems than GPOS’s, and far easier to work with in many cases, as well. If the previous two sentences sounded like Greek to you, then don’t worry – you aren’t alone.
It can be easy to forget that not everyone understands all the buzzphrases and insider terminology that’s bandied about around a particular technological development. Today, I’d like to demystify things a bit. Let’s talk about some of the most important terms in embedded computing.
They actually aren’t as complex as you might think.
You probably already know what a General Purpose Operating System is and does. We’re talking about platforms like Linux, Windows, Mac OS, and so on. An essential component of any mobile device, server, or computer system, a GPOS is responsible for running all the applications in an installation.
Thing is, it’s not really made for real-time use – that’s where RTOS’s come in.
RTOS stands for Real Time Operating System. These software platforms are designed for use cases where time is of the essence – for example, in connected cars. Processing time must be far shorter than in a GPOS, and the execution pattern for applications and processes needs to be predictable. Generally, they also run on smaller, more lightweight hardware than GPOS’s, as larger hardware configurations tend to have issues with agility.
They vary in a few other ways, as well:
- In a GPOS, task scheduling is not always based on which application or process has priority. They typically use a ‘fairness’ policy to dispatch threads and processes. An RTOS, on the other hand, always has priority-based scheduling.
- The more threads that are running in a GPOS, the longer it will take to schedule and start executing a thread.
- In a GPOS, a high-priority thread cannot pre-empt a kernel call. In an RTOS, a low-priority task will be pre-empted by a high-priority one if necessary, even if it’s executing a kernel call.
- Where development is concerned, GPOS code generally isn’t modular in nature. RTOS Kernel Code, on the other hand, is designed to be scalable, so that developers can pick and choose Kernel objects selectively.
Mind you, there’s a bit more to this whole discussion than what I’ve laid out above. That said, this piece should serve as something of a primer for you, giving you a general idea of the two terms. If you’d like to learn more, you can go here, and be sure to subscribe to our blog below.