In embedded development, the argument of “using RTOS to improve efficiency” is often mentioned, but in actual projects, there is often a counterintuitive phenomenon of “the system becoming slower.” This article clarifies the core differences between RTOS and bare metal from a technical perspective, providing direct decision-making advice in just three minutes.
1. Analysis of the RTOS Efficiency Paradox
1. Task Scheduling Overhead
Context switch cost: FreeRTOS task switching requires 84 CPU cycles, while μC/OS-III requires 150 cycles.
Interrupt latency: The time interrupts are disabled in RTOS directly affects real-time performance, while bare metal interrupts execute directly.
Memory consumption: The RTOS kernel occupies 5-10KB of ROM, and task stack space needs to be allocated separately.
2. Performance Advantage Scenarios for Bare Metal
Single-task systems: For simple sensor data collection, the interrupt response time in bare metal can be reduced to the microsecond level.
Resource-limited scenarios: The STM32F0 series (8KB RAM) can run bare metal code with only 1.2KB of RAM required.
Hard real-time requirements: Scenarios sensitive to timing, such as motor control and PWM modulation.
2. Decision Tree for RTOS Application Scenarios
1. Scenarios that Must Use RTOS
Multi-tasking parallelism: Simultaneously handling communication, display, and control (e.g., drone flight control).
Priority management: Medical devices need to ensure that life-support tasks are executed with priority.
Complex interactions: Industrial HMI devices need to coordinate touch screens, networks, and data storage.
Maintainability requirements: Team development requires modular isolation (e.g., automotive electronic ECU development).
2. Scenarios to Use RTOS with Caution
Low-end MCUs: Running RTOS on 8-bit chips (e.g., AVR) may lead to sluggish performance.
Ultra-low power: Bare metal can quickly enter sleep mode (e.g., IoT sensor nodes).
Simple logic: LED chaser lights, single sensor data collection, etc.
Extremely cost-sensitive: Each additional 1KB of RAM requires a reevaluation of costs.
3. Compromise Solution: Lightweight Scheduler
1. Coroutine Solution
Implementation principle: Simulating multitasking through state machines (e.g., Protothreads library).
Advantages: Zero memory allocation, suitable for resource-constrained scenarios like STM8.
Limitations: No true parallelism, complex tasks can easily block.
2. Event-driven Architecture
Core mechanism: Interrupt-triggered task processing (e.g., MQTT message parsing).
Case study: Smart locks achieve low-power operation through event-driven design.
Toolchain: Combined with state machine generators (e.g., YAKINDU).
4. Key Decision Metrics
This article is an original piece by Wanyi Education, please indicate the source when reprinting!