1. The Birth of uC/OS-II: From Open Source Experiment to Industry Benchmark

Background and Origin uC/OS-II (Micro-Controller Operating System Version II) was born in 1992, developed by embedded systems pioneer Jean J. Labrosse. Its predecessor, uC/OS (1991), was initially released as a teaching tool in the magazine “Embedded Systems Programming,” and later evolved into a commercial-grade Real-Time Operating System (RTOS) due to user demand. The design goal of uC/OS-II is to provide high reliability, portability, and deterministic real-time response for resource-constrained embedded devices, filling the gap in the small RTOS market at that time.

Core Design Philosophy:

1. Labrosse emphasized code transparency and configurability; uC/OS-II is known for its simplicity and verifiability:
2. The kernel code size is only about 6,000 lines (in C), making it easy for developers to understand and customize;
3. It adopts priority preemptive scheduling to ensure the determinism of hard real-time tasks;
4. Open source, with code certified by MISRA C standards, suitable for safety-critical scenarios.

From the uC/OS Official Website

1. µC/OS-II and µC/OS-III are preemptive, highly portable, and scalable real-time kernels.

   uC/OS is a preemptive, highly portable, and scalable real-time kernel.

2. Designed for ease of use on a huge number of CPU architectures, these kernels are a key component of the µC/OS real-time operating system.

   The uC/OS kernel is easy to use on many CPU architectures, making it a key component of the uC/OS real-time operating system.

3. µC/OS-II and µC/OS-III are preemptive, highly portable, and scalable real-time kernels.

   uC/OS is a preemptive, highly portable, and scalable real-time kernel.

4. Preemptive multitasking real-time kernel with optional round-robin scheduling.

   Preemptive multitasking real-time kernel, with optional round-robin scheduling.

5. Delivered with complete, clean, consistent source code with in-depth documentation.

   Provides complete, clean, consistent source code with in-depth documentation.

6. Highly scalable: Unlimited number of tasks, priorities, and kernel objects.

   Highly scalable: Unlimited tasks, priorities, and kernel objects.

7. Resource-efficient: 6K to 24K bytes code space, 2K+ bytes data space.

   Resource-efficient: 6-24KB code space and 2KB data space.

8. Very low interrupt disable time.

   Very low interrupt disable time.

9. Extensive performance measurement metrics (configurable).

   Provides various performance measurement mechanisms.

10. Certifiable for safety-critical applications.

    Can be certified for safety-critical applications.

uC/OS-II vs uC/OS-III

2. Industry Applications and Certifications: The Trusted Choice in High-Reliability Fields

uC/OS-II, with its deterministic response and auditability, is widely used in fields with stringent reliability requirements:

Medical Devices

FDA 510(k) certified cases: Used in life-sustaining devices such as cardiac pacemakers and infusion pumps, its task scheduling mechanism ensures zero-latency execution of critical tasks (e.g., heartbeat signal processing).

Advantages: Code traceability meets IEC 62304 medical software safety standards.

Aerospace

Complies with DO-178B/C aviation standards: Used in flight control subsystems (e.g., drone navigation modules), ensuring code free of deadlocks and priority inversion risks through formal verification tools (e.g., LDRA).

Case: NASA’s ground testing systems for some low Earth orbit satellites use uC/OS-II.

Industrial and Automotive Electronics

Complies with IEC 61508 (industrial safety) and ISO 26262 (automotive functional safety) standards, used in PLC controllers, in-vehicle ECUs, etc.

For example: Bosch’s early engine control units (ECUs) use uC/OS-II to manage multitasking timing.

3. Task Scheduling Algorithms: The Core Guarantee of Hard Real-Time

1. Priority Preemptive Scheduling

uC/OS-II adopts a static priority preemptive model:

Each task is assigned a unique priority (0 is the highest, usually reserved for system tasks);

The scheduler always runs the highest priority ready task, and lower priority tasks are preempted;

Interrupt Service Routines (ISR) can trigger task switching, ensuring very low latency.

2. Scheduler Implementation Mechanism

Ready List:

Manages task states through bitmap and linked lists, with a time complexity of O(1) for finding the highest priority task.

Critical section protection:

Ensures data consistency by disabling interrupts or using scheduler locks.

Task switching time:

Typical value < 5μs (ARM Cortex-M3 @72MHz).

Ready List:

The secret to efficient management – Ready List is the core data structure for task scheduling, consisting of two parts:

OSRdyGrp (8-bit group flag): marks which task groups (each group has 8 priorities) contain ready tasks.

OSRdyTbl[] (8-element array): each element corresponds to a priority group, with each bit indicating whether a specific priority task is ready.

1. Task Ready Update Logic When a task enters the ready state, the system updates the ready list using bitwise operations:

OSRdyGrp |=  OSMapTbl[prio >> 3];  // Mark group
OSRdyTbl[prio >> 3] |= OSMapTbl[prio & 0x07]; // Mark specific bit

1. Quickly Find the Highest Priority Task uC/OS-II usesTable Lookup Method (OSUnMapTbl) to quickly locate the highest priority task, requiring only 3 lookup operations:

y = OSUnMapTbl[OSRdyGrp];          // Find the highest priority group
x = OSUnMapTbl[OSRdyTbl[y]];       // Find the highest priority bit within the group
highest_prio = (y << 3) + x;       // Calculate global priority

This algorithm has a time complexity of O(1), far better than traversal search, ensuring scheduling efficiency.

3. Code Comments and Diagrams for Task Scheduling Algorithm

Task Running -> OSQPend -> Task Waiting -> OSQPost -> Task Ready -> Task Ready ProcessOSQPend: Task with priority 45 is suspended waiting for resources

OSQPost: Releases resources to wake up the suspended task with priority 45

Task Scheduling Related Variable and Constant Definitions

Variables related to the task with priority 45 are initialized when the task is created

Ready Group Variable Definitions

Set the suspended task with priority 45 to Ready state

OS_Sched finds the Ready task (priority 45) and executes scheduling

Variables related to the task with priority 10 are initialized when the task is created

Set the suspended task with priority 10 to Ready state

OS_Sched finds the Ready task (priority 10) and executes scheduling

4. Real-Time Performance Enhancement Design

Zero interrupt delay: ISR directly calls the scheduler without waiting for the kernel to exit;

Priority ceiling protocol: Optional configuration to prevent priority inversion;

Deterministic behavior: No dynamic memory allocation, predictable task state transition times.

5. Real-Time Assurance

1. Deterministic Analysis

1. Priority Inversion Prevention Although uC/OS-II does not have a built-in priority inheritance mechanism, it can be avoided by:

• Reasonable task priority design
• Controlling critical section execution time
• Using semaphore strategies for optimization

4. Performance Comparison: uC/OS-II vs Mainstream RTOS

The following is a typical performance data comparison based on the ARM Cortex-M4 platform (unit: clock cycles):

Conclusion:

uC/OS-II performs excellently in low-resource scenarios (such as MCU), with task switching efficiency close to hardware-level RTOS (such as VxWorks);

Compared to FreeRTOS, it has stronger determinism, suitable for hard real-time systems;

Limitations: Lack of dynamic task creation, multi-core support, and other modern features.

5. Detailed Explanation of uC/OS-II Commercial Use Authorization

1. Historical Evolution of Authorization Models Open Source Phase (1998-2000): uC/OS-II was initially released as open source under the GPLv2 license, allowing free use and modification, but requiring derivative works to also be open source. This limited its application in commercial closed-source products.

Commercial Authorization Phase (2000-Present): To meet the needs of enterprises for closed source, developer Jean Labrosse founded Micrium, converting uC/OS-II to a commercial licensing model. Users must purchase a license, exempting them from open-source obligations and allowing embedding in proprietary products.

1. Current Authorization Types and Terms The commercial authorization of uC/OS-II is managed by Silicon Labs (which acquired Micrium in 2016), providing flexible licensing options:

Single Product License

Fee: One-time payment (approximately 3,000 – 10,000, specific amount negotiated based on product sales and usage).

Scope: License tied to a single product model, allowing unlimited production.

Terms: No need to disclose source code, royalty-free.

Multi-Product/Enterprise License

Fee: Annual subscription or customized quotation, suitable for multi-product line enterprises.

Scope: Covers all products of the company, including technical support and update services.

Additional Services: Priority technical support, code customization, safety certification assistance (e.g., IEC 61508, DO-178C).

Educational and Non-Profit License

Fee: Free or heavily discounted, proof of institution required.

Restrictions: Limited to teaching or research, commercial use prohibited.

1. Core Terms and Restrictions of Authorization Code Ownership: Users gain the right to use uC/OS-II, not ownership. Resale, reverse engineering, or unauthorized distribution is prohibited.

Hardware Binding: Authorization is usually tied to specific processor architectures (e.g., ARM Cortex-M); changing hardware requires re-authorization.

Geographic and Temporal Scope: Valid globally, permanent use (unless terms are violated).

1. Technical Support and Additional Services After purchasing a commercial license, users can enjoy:

Technical Support: Resolve technical issues through a ticket system or dedicated account manager.

Code Updates: Receive security patches and functional enhancements (e.g., new processor adaptations).

Certification Support: Assistance in passing industry certifications (e.g., medical (FDA), aviation (DO-178C)), providing necessary documentation and test cases.

1. Free Evaluation and Trial Evaluation Kit

Function: Complete code, but commercial use is restricted (usually 30-90 days trial period).

Purpose: For developers to verify uC/OS-II’s compatibility with target hardware.

1. Comparison of Authorizations with Other RTOS

1. Frequently Asked Questions and Considerations Q: Do I need to purchase separate authorization for each product? A: Yes. If the same company launches multiple product models (e.g., different hardware versions), separate authorization is required for each model.

Q: Does the authorization support multi-core processors? A: uC/OS-II only supports single-core; multi-core needs to upgrade to uC/OS-III (requires additional authorization).

Q: Can the open-source version be used for commercial products? A: No. The GPLv2 version requires products to be open source, and violations may lead to legal risks.

1. Process for Migrating to Commercial Authorization Contact the Silicon Labs sales team, providing product information and expected sales.

Sign the Commercial License Agreement (CLA), clarifying the scope and fees of authorization.

Obtain access to the official code repository and technical support account.

1. Update on uC/OS-II Commercial Authorization Model

After Silicon Labs acquired the uC/OS-II development company, it decided in 2020 to host the uC/OS-II source code on GitHub and change the authorization license to Apache 2.0, attracting more users to use uC/OS-II.

6. Conclusion: The Enduring Vitality of Classic RTOS

uC/OS-II, with its transparent architecture and verifiability, still holds a place in safety-critical fields such as medical and aerospace. Although modern RTOS (like Zephyr, Azure RTOS) excel in functional extensibility, uC/OS-II’s minimalist design and hard real-time guarantees make it a classic choice in resource-constrained systems. For developers, understanding its scheduling mechanism is an excellent starting point for mastering real-time system design.

Chart Explanation: Performance data is based on public benchmark tests (such as EMF Benchmark Suite), and actual values may fluctuate due to compiler optimizations and hardware differences.