IoT applications choose RTOS or Linux
Linux VS RTOS, which should I choose?
introduction
When developing a device or system, one of the earliest and most critical decisions you need to make is deciding what type of operating system it will run on.
The operating system is a large-scale system-level software based on specific hardware. It is a collection of components including resource management, thread\process scheduling, thread\interprocess communication and synchronization.
Linux is often the default operating system of choice for many devices and projects, ranging from Android smartphones and smart TVs to game consoles and cars. Many devices use Linux systems.
RTOS (Real-time operating system, RTOS) is also very common. Some small gateways, smart watches, medical devices or toys will choose RTOS as the operating system of the device.
Linux
Linux is a general purpose operating system (General Purpose Operating System, GPOS); its application in embedded systems usually includes peripheral driver support, file system, network connection and UI support. All of these things can be provided in the RTOS (or cut out this part of the function), but usually the support is not wide, or requires additional cost or integration work.
Of course, these functions of Linux require the support of a large amount of hardware and software resources, while RTOS requires much less resources, which also corresponds to the amount of money needed.
Another important factor is that Linux is not real-time. RTOSs provide scheduling guarantees to ensure deterministic behavior and timely response to events and interrupts.
RTOS
RTOS is different from traditional operating systems such as Linux because it provides deterministic hard real-time responses to external events (high-priority tasks must be executed within a specified small time, otherwise they will explode). On the other hand, traditional operating systems provide non-deterministic soft real-time responses. In practice, this means that RTOS software can provide highly responsive processing (much faster than traditional operating systems) for a limited number of scheduled tasks , while traditional Linux operating systems are more efficient at handling a large number of different tasks.
Compare
| Linux | RTOS | |
|---|---|---|
| real-time | Soft real-time, Linux has many scheduling options, including a real-time scheduler, but this is "soft" real-time at best, typical latencies in real-time Linux will be on the order of tens or hundreds of microseconds, a general-purpose operating system (GPOS) like Linux Usually a priority time-sharing scheduler such as round robin is used to distribute time "fairly" among many processes. So the more processes are running, the busier they are (using more of the available time slices), the slower it will be to respond. | Hard real-time, a typical RTOS real-time kernel can achieve latency from zero to a few microseconds (worst case, not average time). RTOSs usually have a preemption priority based scheduler, so the highest priority ready task will run immediately anyway, and will keep running until it suspends itself or a higher priority task becomes ready. Note that putting a program in an RTOS does not automatically make it real-time, the developer must assign priorities appropriately to ensure that all tasks run on time every time. In general, the task with the shortest and most deterministic runtime should have the highest priority. |
| resource requirements | Originally Linux was developed for desktop PCs (based on the x86 processor architecture). Requires a lot of CPU resources, probably >200MIPS, 32-bit processor, ideally with MMU, 4Mb of ROM and 16MB of RAM to boot (may take a few seconds), it usually doesn't work on 8- or 16-bit MCUs , and requires more onboard RAM for the Linux kernel. For example, MCUs based on the ARM Cortex-M architecture usually have only a few hundred kilobytes of RAM, and Linux cannot run on these chips. | RTOS can start in milliseconds and run in less than 10Kb on microcontrollers above 8 bits. A very simple setup, running two tasks, a scheduler, a communication queue and a semaphore on an 8-bit architecture, would probably require around 200 bytes of RAM |
| safety | High, Linux uses proper process separation, where applications cannot access memory used by other processes or the kernel itself. | higher |
| Development friendliness | The code abstraction is done well, which is convenient for porting. Support many software and hardware drivers, more and more perfect debugging and performance analysis tools | Debug tools that support limited performance analysis, code compatibility is average |
| Difficulty developing understanding | The boot loader, kernel, and root file system in a Linux-based system are at least orders of magnitude more complex than in an RTOS-based design. | Low |
| Equipment volume | bigger | smaller |
| low power consumption | Higher power consumption. And it is difficult to understand its power consumption control method | Low power consumption, providing a simple and effective power consumption control method |
| cost | Bill of materials (BOM) for Linux systems start at around $20 | The BOM for a single-chip microcontroller might only be around $3 |
| hardware driver | Linux is the ruler of off-the-shelf hardware drivers, and many chip vendors these days only offer Linux drivers. If you're working with complex hardware drivers, using off-the-shelf Linux drivers can speed things up considerably | Supported hardware drivers are limited |
| Selection suggestion | Insufficient at the fine-grained level of real-time performance. However, in terms of developer friendliness, the development environment is much friendlier, especially for those who don't have a deep understanding of the low-level code. If you need a lot of memory for the task at hand, such as a large database required by a GPS system, then Linux's extra memory won't be a problem. If your response times are based on human perception (latencies over 100ms are fine), then relatively low real-time performance is not an issue. | RTOS can only run a small number of tasks at the same time, especially a small number of tasks with high real-time requirements. There is far less code, much less complexity, and far less potential for error, so you have more control over how your entire system works. Inexpensive hardware, fast responsiveness, and a willingness to do the hard work of development are where RTOS ends, and the complementary aspects point to Linux. |
Summarize
1) When it comes to choosing Linux or RTOS for IoT applications, the simple answer starts with: if you have real-time needs, you should use (as the name suggests) an RTOS.
2) Other than that, everything depends on your actual requirements (cost, features). It also really depends on what the developer is used to. Configuring Linux can be quite challenging, sometimes a simple RTOS is easier.
(Thank you for liking or collecting)