FreeRTOS and Real-Time Software

The most important information in brief

What is FreeRTOS?

FreeRTOS is a real-time operating system for microcontrollers and embedded systems. It provides fundamental mechanisms for organizing multiple software tasks on a microcontroller. These include tasks, schedulers, queues, semaphores, timers, and synchronization mechanisms between program components. A microcontroller continues to execute only the instructions permitted by its hardware. However, FreeRTOS ensures that this execution does not have to be organized as a single unstructured program flow, but can be divided into separate task areas.

In a typical embedded system, multiple parallel requirements quickly arise. A sensor must be read at fixed intervals. Communication via UART, SPI, I²C, CAN, Ethernet, or another interface must receive and send data. Control logic must evaluate states and set outputs. A user interface or diagnostic function must respond to user input or external requests. Without an operating system, such functions are often combined in a main loop, interrupt service routines, and state machines. This can be sufficient for small programs. However, as the number of functions grows, it becomes more difficult to understand which task is executed when and which function blocks another.

FreeRTOS creates a technical structure for this. Each task can be modeled as a task. For example, one task can acquire measurement values, another task can process communication data, and yet another task can perform a control or decision-making process. The scheduler decides which task receives CPU time based on the priorities and states of the tasks. This divides the software into units that can be functionally and technically separated more effectively.

For projects, this doesn't mean FreeRTOS automatically solves every timing problem. The correct division into tasks, the choice of priorities, the handling of interrupts, and the memory planning must be suitable for the system. An incorrectly prioritized task can delay time-critical processes. A blocking function can prevent other components from executing. Unclear data transfer between tasks can create errors that only occur under specific load conditions. PICKPLACE therefore views FreeRTOS not just as a library to be integrated, but as an architectural decision for the embedded system.

Working with FreeRTOS also involves the distinction between interrupt context and task context. Interrupts are often used to react quickly to hardware events, such as a received data block, a timer expiration, or an external input. However, the actual processing should often be deferred to tasks so that interrupts remain short and system behavior remains predictable. FreeRTOS provides mechanisms for this, allowing interrupts to notify tasks or pass data to queues.

Memory also plays a central role. Microcontrollers often have limited RAM and Flash memory. Each task requires stack memory. Queues, buffers, and other data structures also require memory. Therefore, in FreeRTOS projects, it is necessary to clarify which tasks are truly necessary, what stack sizes should be set, and how dynamic or static memory allocation will be handled. These questions are not just implementation details but influence the debugging and maintainability of the software.

When does a microcontroller need a real-time operating system?

A microcontroller does not need a real-time operating system like FreeRTOS in every project. If a device only performs a simple function, queries few inputs, and does not process time-critical communication, a main loop with clear state machines can be sufficient. A real-time operating system becomes relevant when multiple tasks with different temporal requirements need to be coordinated and the software becomes unclear or error-prone without clear separation.

Typical cases include systems with sensors, controls, communication, and measurement functions. For example, a measuring device can regularly collect data, simultaneously update a display, and respond to external communication requests. A controller can monitor inputs, control actuators, and provide diagnostic data. In such systems, it is often not enough to execute tasks sequentially in a loop if individual functions take longer or wait for external events. FreeRTOS allows blocking waiting tasks and giving CPU time to other tasks.

Another reason is defined reaction behavior. Real-time does not mean that a system has to be particularly fast. The crucial factor is that certain reactions occur within defined time limits. If an input must be evaluated within a few milliseconds, if a communication protocol specifies time windows, or if a control system is to work periodically with a fixed clock, the software must take this time behavior into account. FreeRTOS offers timers, task priorities, and synchronization mechanisms with which such requirements can be met.

The project size can also justify the use of FreeRTOS. When multiple developers work on different software components, a task structure helps to separate responsibilities. A communication task can be developed independently of a measurement task, as long as interfaces and data transfers are clearly defined. This does not replace architectural work, but it creates a basis for describing, testing, and expanding functions separately.

In industrial electronics, machinery, vehicles, marine equipment, and military systems, requirements for clear states, verifiable communication, and defined response times often arise. In such environments, unplanned blockages, race conditions, or memory issues can be difficult to find. FreeRTOS can help address these issues systematically when used appropriately. Each project must clarify which functions are time-critical, which run only periodically, which events must be handled immediately, and what data is exchanged between tasks.

A real-time operating system is also advisable when communication interfaces are operated alongside control or measurement tasks. Communication frequently generates asynchronous events: data arrives, transmissions end, timeouts expire, and protocol states change. If these processes are mixed directly with measurement or control functions, the software can become difficult to read. With FreeRTOS, communication processes can be organized into their own tasks or event structures. Careful decisions must be made regarding how buffers are managed, how long tasks may block, and how error states are reported.

Using it is inadvisable if the additional mechanisms create more complexity than they organize. FreeRTOS comes with a scheduler, configuration parameters, and runtime behavior that must be understood. Therefore, a project should not rely on FreeRTOS solely because multiple functions are available. It should be examined whether the tasks really need to be coordinated in parallel, whether there are hard or soft time limits, and whether the development structure supports a task-based architecture.

Why not write it yourself?

An in-house scheduler or a self-developed mini-operating system often appears manageable in the early stages of a project. A main loop, a few timers, some flags, and interrupts are initially sufficient to demonstrate initial functions. However, complexity increases as soon as waiting states, priorities, data transfers, timeouts, mutual exclusions, and error conditions are added. Many in-house developments begin as simple control flows and later become difficult-to-test systems of special cases.

FreeRTOS offers proven basic mechanisms for exactly these tasks. Tasks can block without stopping the entire application. Queues can transfer data between tasks. Semaphores and mutexes can coordinate access to shared resources. Software timers can trigger recurring or delayed actions. While it's possible to write these functions yourself, it requires a thorough understanding of scheduling, interrupt behavior, stack usage, memory access, and concurrency.

Handling concurrency is particularly critical. When two program components use the same resource, such as a communication bus, a memory buffer, or a state variable, errors can occur that are not visible in every test run. They depend on which task is interrupted at what time. Such errors are difficult to pinpoint without clear synchronization mechanisms. FreeRTOS provides tools to structure these accesses. However, the tools must be used correctly. A mutex in the wrong place can cause deadlocks, a queue with the wrong size can lose data, and a priority that is too high can displace other tasks.

Timing issues also argue against an uncontrolled custom solution. A self-written scheduler must decide which task runs when. It must handle interrupts, map waiting times, and prevent slow functions from blocking time-critical processes. In simple systems, a cooperative approach can work, where each function returns regularly. However, as soon as a function waits for external data or performs a long calculation, its behavior becomes harder to predict. FreeRTOS is designed for such scenarios, provided the architecture is designed accordingly.

Another point is troubleshooting. With an in-house development, not only the application but also the process control itself must be checked. If an error occurs, it is unclear whether the cause lies in the business logic, in the self-written scheduler, in an interrupt, or in memory management. With FreeRTOS, the application still needs to be checked, but the basic mechanisms are clearly described and widely used in many microcontroller environments. This makes it easier to narrow down the problem if project participants understand the concepts and configuration options.

PICKPLACE views the question „FreeRTOS or custom solution?“ as a technical consideration. For very small systems, a custom, simple structure can be beneficial. For systems with multiple time-dependent tasks, communication, sensor technology, and limited memory, FreeRTOS or a comparable real-time operating system is often more suitable. The decisive factor is not the use of a specific tool, but the manageability of the software throughout the project's lifecycle.

Typical technical questions in FreeRTOS projects

When working with FreeRTOS and real-time software, many projects begin with the question of how to divide existing functions into tasks. Not every function should become its own task. Too many tasks increase memory requirements and make prioritization difficult. Too few tasks can lead to independent processes being mixed together again. A sensible division is guided by timing behavior, data flows, interfaces, and responsibilities.

Task prioritization is another work item. Time-critical tasks require appropriate priority but must not permanently displace other tasks. Communication tasks must be able to react to events without burdening the system with polling. Diagnostic or background functions should run when no higher-priority tasks are active. These priorities cannot be set in isolation but must be considered in conjunction with interrupts, timers, and blocking behavior.

Interrupts must be designed to capture hardware events but not perform extensive processing. In many cases, it makes sense to only save data or notify a task within the interrupt. Processing then occurs in the task context. This keeps interrupt runtimes short and makes system behavior more predictable.

Memory analysis is also part of project work. Each task requires a stack. Stacks that are too small lead to hard-to-detect errors. Stacks that are too large waste RAM, which can be limited on microcontrollers. Additionally, buffers for communication, measurement data, or status information must be planned. In FreeRTOS projects, therefore, checks are made to determine which memory areas can be statically allocated, where dynamic allocation should be avoided or controlled, and how memory errors can be detected.

Typical Technologies and Stacks

• RTOS FreeRTOS
• Microcontroller STM32F407VG
• IDE STM32CubeIDE
• Debugger SEGGER J-Link
• Protocol Stack lwIP

Our Services

PICKPLACE supports projects involving FreeRTOS and real-time software through software development, FreeRTOS setup, and the elaboration of task and thread management. This goes beyond just the technical integration of the operating system, also focusing on the appropriate structure for the respective embedded application.

Our services include the analysis of existing microcontroller software. We examine which tasks are time-critical, which processes can cause blocks, which interrupts are present, and how data is exchanged between program parts. Based on this, we can decide whether FreeRTOS is suitable, which architecture fits, or if an existing structure should be adapted.

When setting up FreeRTOS, we handle the basic integration into the embedded software. This includes configuring the scheduler, creating initial tasks, incorporating timers, and defining communication mechanisms between tasks. The specific implementation depends on the microcontroller, peripherals, memory limitations, and existing software base.

In task and thread management, we structure functions according to responsibilities and temporal behavior. We define which tasks run as separate tasks, which events are transferred via queues or notifications, and where synchronization is necessary. We also consider which functions remain in the interrupt context and which should be moved to tasks.

PICKPLACE also undertakes development work on FreeRTOS-based applications. This can include sensor querying, communication processing, control logic, measurement sequences, or diagnostic functions, as far as they arise from the project context. Existing software can be further developed, converted to a task-based structure, or examined for errors in the interaction of tasks, interrupts, and memory.

In error analysis and debugging, we consider typical causes in real-time software: blocking tasks, incorrect priorities, stack problems, unclear synchronization, timing deviations, or data loss in communication paths. The goal of the work is a traceable localization of the cause and a modification that fits the system architecture.

For the handover to further implementation, we document the relevant architectural decisions. These include task partitioning, priorities, data paths, synchronization points, storage assumptions, and known limitations. This documentation helps to carry out later extensions or troubleshooting on a clear technical basis.