What is the difference between RTOS and Embedded Linux?
RTOS and Embedded Linux are used for embedded systems programming. Is Embedded Linux itself an RTOS ? Can anyone list the comparison or difference please?
Answers
Linux is a general-purpose OS (GPOS); its application to embedded systems is usually motivated by the availability of device support, file-systems, network connectivity, and UI support. All these things can be available in an RTOS, but often with less broad support, or at additional cost or integration effort.
Many RTOS are not full OS in the sense that Linux is, in that they comprise of a static link library providing only task scheduling, IPC, synchronisation timing and interrupt services and little more — essentially the scheduling kernel only. Such a library is linked with your application code to produce a single executable that your system boots directly (or via a bootloader). Most RTOS do not directly support the loading and unloading of code dynamically from a file system as you would with Linux — it is all there at start-up and runs until power down.
Critically Linux is not real-time capable. An RTOS provides scheduling guarantees to ensure deterministic behaviour and timely response events and interrupts. In most cases this is through a priority based pre-emptive scheduling algorithm, where the highest priority task ready to run always runs — immediately — pre-empting any lower priority task without a specific yield or relinquishing of the CPU, or completion of a time-slice.
Linux has a number of scheduling options, including a real-time scheduler, but this is at best «soft» real-time — a term I dislike since it is ill-defined, and essentially means real-time, most of the time, but sometimes not. If your application has no need of «hard» real-time, that’s fine, but typical latencies in real-time Linux will be in the order of tens or hundreds of microseconds, whereas a typical RTOS real-time kernel can achieve latencies from zero to a few microseconds.
Another issue with embedded Linux is that it needs significant CPU resources, perhaps >200MIPS, 32bit processor, ideally with an MMU, 4Mb of ROM and 16MB of RAM to just about boot (which may take several seconds). An RTOS on the other hand can be up in milliseconds, run in less than 10Kb, on microcontrollers from 8-bit up. This can have a significant impact on system cost for volume production despite being ostensibly «free».
There are larger RTOS products that exhibit some of the features of a GPOS such as dynamic loading, filesystems, networking, GUI (for example, in QNX), and many RTOS provide a POSIX API (usually secondary to their native real-time API) for example VxWorks and again QNX, so that a great deal of code developed for Linux and Unix can be ported relatively easily. These larger more comprehensive RTOS products remain scalable, so that functionality not required is not included. Linux in comparison has far more limited scalability.
Can we ignore the second sentence in your question? It is meaningless, and perhaps points to a misunderstanding of design patterns. The first part is interesting however. That said, I would generalise it to cover real-time systems rather than RTOS.
Many of the most familiar patterns are mechanistic, but in real-time systems higher-level architectural patterns are also important.
Bruce Powell Douglass is probably the foremost author on the subject of patterns for real time systems. If you want a flavour of what he has to say on the subject then read this article on Embedded.com (it is part three of a series of three; be sure to read the first two as well, since they also touch on the subject, (1) (2)). You could also do worst than to visit Embedded.com and enter «design patterns» into the search box, there are a number of articles on specific patterns and general articles on the subject.
While I think you are being far to specific in requesting patterns for «RTOS(VxWorks)», patterns I have used specifically with VxWorks are the Facade and Adapter patterns. Partly to provide an OO API, and also to provide a level of RTOS agnostic abstraction. The resulting classes were then implemented for Segger emBOS (to allow us to run a smaller, lower cost, royalty free RTOS), and both Windows and Linux to allow test, debug and simulation of the code in a richer environment with more powerful tools.
A non-exhaustive list of many patterns is provided on Wikipedia, many of which will be applicable to real-time systems. The listed concurrency patterns are most obviously relevant.
RTOS vs embedded linux
There was a discussion here that is now closed: https://stackoverflow.com/questions/25871579/what-is-the-difference-between-rtos-and-embedded-linux#:~:text=Many%20RTOS%20are%20not%20full,essentially%20the%20scheduling%20kernel%20only.&text=Critically%20Linux%20is%20not%20real%2Dtime%20capable The accepted answer could be summarised as «Critically Linux is not real-time capable». However, I think this is misleading. When it comes to an OS like linux, you have to distinguish between applications, the kernel, and device drivers. According to my understanding (having written many Unix device drivers and worked on the Unix kernel decades ago), the device drivers and the kernel are real-time capable. Device drivers respond to hardware events (interrupts) and the kernel, in turn, can perform actions based on these events. So, yes, while it’s true that certain real-time features are not available to applications, if you have the capability of writing a device driver, you can circumvent this limitation by moving your application logic into a specialised device driver or kernel module. (Of course it has to make logical sense to do that. ) Have I missed something? Does anyone disagree with this?
Your argument seems to be: handle the event in the kernel instead of userspace, and then you have a «realtime system». «Have I missed something?» — Yes, try defining «realtime system» that is accurate. «Does anyone disagree with this?» — Yes, but am I qualified to disagree with you? FWIW I have also «written Unix device (& nexus) drivers and worked on the Unix kernel decades ago», SunOS to be specific, as well microkernels.
Try again. Thanks for your comment. «try defining «realtime system» that is accurate». Do you agree with this definition? «A Real Time OS provides fixed time guarantees to applications, without buffering delays». If you agree, then clearly Linux is not a Real Time OS. So my point is that if you’re happy to move some of your logic into a kernel module (or device driver) then you can definitely use Linux for your real time requirements. Agreed?
(1) «Guarantees» for what, anything? What is «buffering delays»? (2) No, I don’t agree. Maybe some trivial response action can be incorporated into the kernel, but that will not always be practical for a more general case. If floating point unit or file access is needed, then you’re advocating overburdening the kernel. Just because you can come up with one simplistic scenario to use Linux like a RTOS does not make Linux suitable as a RTOS in a more general sense.
What is the difference between RTOS and Embedded Linux? [closed]
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
RTOS and Embedded Linux are used for embedded systems programming. Is Embedded Linux itself an RTOS ? Can anyone list the comparison or difference please?
An RTOS (real time operating system) is software that has deterministic behavior. Events are handled within a time constraint. Embedded Linux is not an RTOS as events/interrupts are typically handled by deferred procedures or ‘bottom half’ code which can not guarantee latency. However, there have been RTOS implementations of Linux for embedded Linux. I think Wind River (Intel) ships a version of this.
«Real time Linux kernel is used. Kernel response is in real time or is deterministic.» embeddedcraft.org/embedlinuxdesktoplinux.html
1 Answer 1
Linux is a general-purpose OS (GPOS); its application to embedded systems is usually motivated by the availability of device support, file-systems, network connectivity, and UI support. All these things can be available in an RTOS, but often with less broad support, or at additional cost or integration effort.
Many RTOS are not full OS in the sense that Linux is, in that they comprise of a static link library providing only task scheduling, IPC, synchronisation timing and interrupt services and little more — essentially the scheduling kernel only. Such a library is linked with your application code to produce a single executable that your system boots directly (or via a bootloader). Most RTOS do not directly support the loading and unloading of code dynamically from a file system as you would with Linux — it is all there at start-up and runs until power down.
Critically Linux is not real-time capable. An RTOS provides scheduling guarantees to ensure deterministic behaviour and timely response to events and interrupts. In most cases this is through a priority based pre-emptive scheduling algorithm, where the highest priority task ready to run always runs — immediately — pre-empting any lower priority task without a specific yield or relinquishing of the CPU, or completion of a time-slice.
Linux has a number of scheduling options, including a real-time scheduler, but this is at best «soft» real-time — a term I dislike since it is ill-defined, and essentially means real-time, most of the time, but sometimes not. If your application has no need of «hard» real-time, that’s fine, but typical latencies in real-time Linux will be in the order of tens or hundreds of microseconds, whereas a typical RTOS real-time kernel can achieve latencies from zero to a few microseconds — even at much lower CPU clock rates.
Another issue with embedded Linux is that it needs significant CPU resources, perhaps >200MIPS, 32bit processor, ideally with an MMU, 4Mb of ROM and 16MB of RAM to just about boot (which may take several seconds). An RTOS on the other hand can be up in milliseconds, run in less than 10Kb, on microcontrollers from 8-bit up. This can have a significant impact on system cost for volume production despite being ostensibly «free».
There are larger RTOS products that exhibit some of the features of a GPOS such as dynamic loading, filesystems, networking, GUI (for example, in QNX), and many RTOS provide a POSIX API (usually secondary to their native real-time API) for example VxWorks and again QNX, so that a great deal of code developed for Linux and Unix can be ported relatively easily. These larger more comprehensive RTOS products remain scalable, so that functionality not required is not included. Linux in comparison has far more limited scalability.