Electronics Weekly Electronics Design & Components Tech News
At a top level, the choice is between a full OS, such as Linux, with general purpose features and a wide range of drivers, middleware and applications or a more targeted system such as FreeRTOS. This is an embedded OS with tight deterministic real-time behaviour, but more restricted with features and support.
What is FreeRTOS?
FreeRTOS is one of the most popular real-time operating systems used on microcontrollers today. It is distributed under the MIT licence, which means it can be used without restriction and gives express permission for reuse of the code for any purpose.
FreeRTOS is a true real-time OS, meaning it has deterministic behaviour with timers and task scheduling. It has a very small footprint in terms of the kernel size and a broad ecosystem of options and community contributions.
No MMU (memory management system) is required, which means that generally the design will fit a lower cost CPU with internal RAM and flash (that is, microcontrollers, as opposed to application processors).
FreeRTOS has been developed over the past 18 years and has become the go-to RTOS for microcontrollers, thanks to semiconductor partners such as ARM, NXP, Microchip, Silicon Labs, ST and Texas Instruments.
What is Embedded Linux?
Embedded Linux has been around since the early days of the 1990s and is the most used OS – even platforms such as Android are based on Linux. It is open source; many of the packages range from MIT to GNU licences, although there are closed source packages and libraries.
Embedded Linux normally refers to Yocto or Debian distributions. Yocto is a toolchain rather than a distribution, with a set of build and configuration tools engineered to compile the kernel, drivers and packages based on a need-to-have or dependency-based inclusion. This results in a lightweight distribution, reducing the storage and the RAM required. Ubuntu/Debian and other set distributions are typically more of an all-in starting point. Users then strip out by hand the features that are not required, to reduce the size or security window.
Yocto is normally a better way to build a bespoke product. Because it includes only required features, it tends to be safer and more streamlined. The lower storage, RAM and CPU usage of a minimal build also means less hardware and, therefore, a cost saving.
Comparing RTOS
Embedded Linux can have real-time patches to enforce low latency, consistent response time and determinism when running tasks. There are actually several choices when it comes to the kernel build: deadline-based schedulers, round robin, FIFO and completely fair scheduler (the standard desktop scheduler). Using an embedded Linux OS does not necessarily mean real-time patches are needed.
FreeRTOS uses a simple scheduler. The system developer needs to design software with this in mind, using priorities to determine tasks that need to run before others. Low latency interrupt handling and hardware timers give very fine control for repetitive tasks that need to be performed at a high speed.
Linux, on the other hand, generally relies on features in hardware for these types of tasks.
For example, to sample a pin, which is going to be the input from an IR receiver, this can be done in a software or hardware timer at a frequency of 100Khz on FreeRTOS. But in Linux, if the CPU does not have a hardware feature to support this tight timing requirement, a software function with large time slices or variable interrupt latencies would need to be written.
Memory management
Linux requires a CPU with an MMU to give individual processes their own virtual space to run within, sandboxing applications so one application cannot write into the virtual memory of another by mistake.
Virtual memory can be used as a means of over-extending physical memory. Applications may allocate large amounts of RAM. Unless accessed this memory is, in effect, just a placeholder. If memory is accessed infrequently it may be swapped out to a slower medium (disk) to allow other active applications to run. Although it is not advisable to use a system to its limits, virtual memory may extend to mapping files into RAM, that is, sharing memory safely between processes and allowing the tracking of problems with applications writing outside their allocations.
FreeRTOS has a rudimentary allocation system that allocates physical memory. Tasks can write into any memory corrupting each other unless the memory protection unit (MPU) is enabled. The MPU prevents access of memory outside the current task’s stack.
Development effort
A pre-configured Linux distribution – Debian, for instance – is accessible to new developers. Creating applications on desktop machines (or the machine itself) can be straightforward. Debugging using tools, such as gdb, is well documented, as well as easy and free to access. There are a host of examples for Linux.
Taking a custom board and adapting the bootloader, kernel and drivers is a big development step, as is using Yocto to produce a stripped-down build with only the packages required for the product.
A custom platform may require patching of drivers to the kernel that are not mainstream. Many projects utilising a custom Linux platform will have dedicated Linux engineers for this task and other programmers for the application coding.
FreeRTOS can be daunting initially, but the environment is less expansive, allowing developers to quickly create custom applications on development kits. In many cases, this results in being able to move the bespoke application to a custom hardware platform in fewer steps.
These microcontrollers, typically, have their own inbuilt RAM and flash so even basic functions such as initialising memory and loading the initial bootloader may not need modifying on these custom boards, as this is all on-chip.
Flexibility
Linux is definitely the stronger here. When developing an embedded system, it is much simpler to find a driver or package for the hardware or application when looking in a larger pool of software.
Linux hardware is generally more powerful and has more RAM and storage than the microcontroller systems available. This gives the application engineer a much easier time to focus on the problem rather than all the restrictions of the system. There are also more tools and examples available to draw from than the equivalent FreeRTOS system.
The platform will most likely have an almost instant on time, very low standby current, be able to perform very deterministic tasks and offer cheaper cost too, due to less need for larger resources such as RAM/storage.
The pool of example drivers and application code is not as extensive, but it is still significant and customisation is easy to implement due to the lower overall complexity.
Debugging
Most FreeRTOS systems will have a real-time debugger. The microcontrollers or their development kits have built-in hardware programming/debugging features able to download, run and set breakpoints on running code using a cheap connection, such as USB or inbuilt JTAG to a desktop PC.
By contrast, Linux has tools such as gdb, Valgrind, OS features for monitoring I/O operations, files or handles in use and process handling.
The difference is that code is debugged on the FreeRTOS level at a driver or application logic level. On Linux, debugging the bootloader, kernel, or drivers is trickier and requires either very basic tools (logs and serial prints) or complex setups and hardware, such as JTAG, which could be expensive.
The FreeRTOS platform will most likely revolve around a low-cost CPU, internal RAM or flash, as the system will be less computationally powerful. The power supply components will have a lower requirement, making them cost-effective, too. Overall, microcontroller systems will be cheaper than Linux ones.
Support
Linux has a sizeable community of users and examples available to developers while FreeRTOS has strong backing from major chip manufacturers. For niche applications, however, many examples may rely on features from the chip and porting. These may require expert knowledge of how these can be translated to another chip architecture. The FreeRTOS systems will be more constrained in its available resources or CPU power, so generic examples may not be optimal to run between systems.
Porting of Linux application code between platforms is reasonably straightforward. Porting of drivers and other hardware specific code can be trickier and detailed knowledge of the chip architecture may be required.
On FreeRTOS, many low-level code examples may require a deep understanding of the chip it was intended for, and more application logic will like the Linux examples and move cleanly between systems.
Both FreeRTOS and Embedded Linux have distinctive differences. Linux systems lend themselves to complex products requiring fewer hard, real-time tasks. Any time-critical tasks are supported by the CPU hardware internally while additional microcontrollers or other devices, such as FPGAs, provide hard timing tools if needed. This increases hardware cost but gives great flexibility with upgradability.
FreeRTOS systems are generally simpler devices, controlling one job with tight constraints, for example, a motor controller. FreeRTOS can be used for complex systems but requires careful management of the resources available. The systems tend to be lower cost, but at the risk of less headroom for expansion.
Some products will fall between the two devices core areas. Choice should be evaluated against the project’s demands, development capability and cost, power consumption, response time, time-critical tasks, support and future expansion.
Newer application CPUs, such as the NXP i.MX8 series, join a number of A cores running Linux with M cores running FreeRTOS on the same chip. This eases firmware updating because one system controls firmware for both and means less hardware complexity.
