Summary of μC/OS Real-Time RTOS Technology Online Seminar Q&A

μC/OS-II & μC/OS-III currently support more than 40 processor architectures, and example projects can be downloaded from here.

The required stack size for each task is application-dependent and can be obtained through manual calculation considering the memory required for function call nesting, register context, and interrupt handling. For detailed information, refer to How to Set the Stack Size for Application Tasks?

Task stacks can utilize processor features such as MPU/MMU and hardware stack limit registers for stack overflow detection. On the software side, uC/OS-II & uC/OS-III provide software stack checking functions. For specific implementations, refer to: https://micrium.atlassian.net/wiki/spaces/osiidoc/pages/163900/Task+Management and https://micrium.atlassian.net/wiki/spaces/osiiidoc/pages/132411/Detecting+Task+Stack+Overflows

The μC/OS kernel provides a fixed block size storage management mechanism for kernel objects and task stack space, implemented based on static allocation.

By default, the stack address for each task is determined by the linker during the linking stage.

In SMP systems, various strategies can be used to allocate task execution. By using the RTOS affinity feature, a task can be set to run on a specific CPU. In SMP systems, the RTOS knows all ready-to-run tasks and aims to run tasks on all cores whenever possible, unless a specific CPU affinity has been set for that task, which would prevent it from running. This is how priority is set. The same principle applies to multi-core CPUs, where tasks are prioritized just like in single-core systems. In a four-core system, the four most important tasks will run simultaneously.

All tasks are managed by the μC/OS kernel, and the occurrence of communication will change the state of the task. μC/OS uses a preemptive scheduling strategy to wake up the highest priority ready task for execution.

Based on μC/OS applications, the kernel provides a queue mechanism for asynchronous data interaction between interrupts and tasks or between tasks. Through the context switching mechanism provided by μC/OS, the execution context of the preempted task is correctly maintained, allowing the task to resume execution from the preempted position when it is run again.

Event groups are kernel objects created by the application and managed by the RTOS. Tasks or ISRs can set or clear bits in the event group. Only tasks can wait for bits to be set or cleared.

μC/OS-III supports preemptive scheduling and time-slicing algorithms, allowing multiple tasks to set the same priority level, with each task’s time slice length configurable individually. μC/OS-II only supports preemptive scheduling, and each task’s priority must be unique.

If the system does not have an independent interrupt stack, the context will be saved to the interrupted task’s stack when an interrupt occurs. If insufficient RAM space is allocated for the task stack, a stack overflow will occur. Therefore, when allocating task stacks, possible interrupt nesting should be considered, and sufficient stack space should be allocated.

Many RTOS provide APIs to change task priorities, such as OSTaskChangePrio() in uC/OS-III, which sets the new task priority level. If the priority only needs to be elevated above certain tasks, it is not necessary to use interrupt disabling. If the task needs to be at the highest priority and the time is very short, disabling interrupts can be used, but the interrupt handling time must be very short to avoid affecting the overall system response time.

When a task calls a delay function, it will be blocked, and the CPU will look for the next highest priority ready task to execute. The delay function does not block the CPU; it only stops the current task’s execution. The system uses a timer to count down, and when the delay time is up, the task is woken up again.

Many techniques can help applications meet their deadline requirements, such as Rate Monotonic Scheduling (RMS) and Rate Monotonic Analysis (RMA). RMS requires a preemptive scheduler like uC/OS-III, and not all tasks have strict deadlines; some tasks may not complete before their deadlines but will not cause system issues.

The choice of RTOS depends on the requirements:

1. Use open-source version or commercial solution?

2. Is software quality a concern?

3. Does the RTOS support the CPU architecture in use?

4. Is the quality of RTOS documentation a concern?

A hard real-time system is one that cannot miss any (hard) deadlines; otherwise, catastrophic consequences will occur. Soft real-time means missing deadlines does not lead to severe consequences. Most systems are a combination of hard and soft requirements. Usually, only a few tasks have strict deadlines, and the highest priority should be assigned to those tasks in applications.

From the application’s perspective, the behavior of mutexes on single-core or multi-core CPUs is the same. However, depending on the implementation of the multi-core RTOS, if the owner of the mutex needs to elevate priority, it may lead to a “kernel change”. However, this is transparent to the application code.

From the application’s perspective, the behavior of mutexes on single-core or multi-core CPUs is the same. However, depending on the implementation of the multi-core RTOS, if the owner of the mutex needs to elevate priority, it may lead to a “kernel change”. However, this is transparent to the application code.