RTOS on 施星宇

常見 Real-Time OS 介紹與比較

Mon, 06 Jan 2025 15:32:31 +0800

介紹

即時作業系統（Real-Time Operating System, RTOS）是一種專門為即時（real-time）應用而設計的作業系統，強調「在特定時間限制內（deadline）對事件進行回應」，試想一個情境在工業的領域若機器某部分突然產生故障，需要在極短的時間內停止所有馬達的運作，若此時使用的是傳統的作業系統如Linux，依OS內核的調度策略，最終馬達停止的動作會有些許延遲，相較之下RTOS則可以有較彈性的執行緒搶佔，讓緊急情況的處理可以更快被執行

本質上來說RTOS的內核使用起來的效果是大同小異的，基本上能做到多個執行緒的建立、輪詢執行、優先序搶佔、互斥鎖、內核級的中斷等功能，進階一點的則有可以動態記憶體管理、多核心的支援，這些RTOS主要的差異大多是在外圍模組的支援、周邊的開發生態系等，以下就分別介紹目前主流常見的幾種RTOS:

FreeRTOS

FreeRTOS 是由 Real Time Engineers Ltd. 及 Amazon 維護，完全開源並且在全球廣受使用，FreeRTOS 可以說是最最最常見的一種RTOS，成功之道大概在於早早就開源，早早就被各家IDE整合，各家晶片的SDK也都可以看到他的影子，我最早接觸他是在Arduino IDE，FreeRTOS早早就出現在Arduino library list中，使用起來也夠簡單，沒有什麼複雜的設定，加一兩行code就可以實現多執行緒，讓初學者很容易就可以踏入RTOS的世界。他背後的金主爸爸是 Amazon，後來也整合了不少 AWS 上IoT相關的功能，由於早早就開源，周圍的模組也不少。

AzureRTOS (Threadx)

ThreadX 是由 Express Logic 開發的即時作業系統（RTOS），後續被 Microsoft 收購並推出更名版本 AzureRTOS 並開源，從名字就可以看出來未來應該是要跟微軟的 Azure 搭配做一些IoT的功能，但目前好像還沒看到什麼殺手級的應用。由於開源的時間比較晚，周圍的套件比較少，像BLE、Wifi這類的Stack能用的東西好像比較少，但相信有微軟原生的支援應該可以成長的很快，我會碰到 AzureRTOS 是因為 STM32 官方原生支援 AzureRTOS，很有趣的是 STM32 的開發環境也有支援 FreeRTOS，但支援度是遠遜於 AzureRTOS 的。

Zephyr

Zephyr 是由 Linux 基金會（Linux Foundation）主導的開源即時作業系統（RTOS），Zephyr雖然出現很久了，但算是這幾年才突然紅起來，主打一個跨平台的相容性和完整的開發工具鏈，有像是West這種很好用的工具、也有像是DeviceTree者種為跨平台設計的架構，可以說要用Zephyr就要連著這一整串工具鏈一起用才會好用，不過好像也是因為綁著工具鏈跟相容性的原因，好像各家晶片雖然說有支援，但好像又支援的沒那麼好，特別是牽涉到很底層的硬體設定(像時鐘樹設定)就會變的特別麻煩，如果沒有這種需求就蠻好用的，很多設定、初始化都幫你省略了。會碰到Zephyr是因為使用 Nordic 的藍牙 SoC，最新的的 nrf connect SDK 基本上是建立在 Zephyr 上的，而 Zephyr 通訊相關的套件也很完整，很適合給 Nordic 的晶片用。

RT-Thread

RT-Thread 是一款由中國團隊主導開發的開源即時作業系統（RTOS），在中國的嵌入式系統開源社群算蠻熱門的，對中國製MCU(特別是一些RISC-V的晶片)支援度很好，但其他地方就比較少看到有人在用，跟Zephyr一樣也有蠻多工具可以使用，我自己還沒有用過，但讓我印象深刻的是RT-Thread社群有一個可以一鍵生成 STM32 bootloader 的工具，不過要使用要註冊帳號，而且還限定用中國的電話才能註冊…，就對中國以外的開發者不是很友好。

比較

幾種RTOS的差別

名稱	AzureRTOS (ThreadX)	FreeRTOS	Zephyr	RT-Thread
維護者	- 原為 Express Logic 開發，現由 Azure (Microsoft) 管理 - 被微軟購買後開源	- AWS（Amazon）及大社群共同維護 - 開源專案，有廣大社群支援	- 由 Linux Foundation 托管 - 眾多主要產業贊助商與貢獻者（如 Intel、Nordic 等）	- 中國嵌入式廠商與RT-Thread 社群
授權	- MIT 授權 (開源版本)	- MIT 授權 - 完全開源、商業可使用	- Apache 2.0 授權 - 完全開源	- LGPL 授權 - 可商業使用，但需遵守 LGPL 條款
主要特色	- 小巧的記憶體佔用 - 高效能可搶先式多工 - 整合除錯功能、其他外設控制模組	- 模組化設計，可高度客製化內核 - 協同式及可搶先式多工 - 詳細文件與巨大社群，支援度高	- 跨平台相容性好 - 追蹤與分析工具完善 - 與 Percepio Tracealyzer 整合	- 輕量化設計與微核心架構 - 效率高，啟動速度快 - 著重模組化與易用性
使用門檻	- 門檻中 - 提供專門的 API 與工具鏈 - 原生支援STM32，其他晶片支援則較少	- 門檻低 - 文件全面且社群龐大 - 新手上手相對容易，維護成本低	- 門檻高 - 須熟悉成套的開發工具鏈 - 社群與企業資源豐富，難度取決於應用深度	- 門檻中 - 設計較為精簡易懂 - 模組化讓功能可彈性擴充，但仍需對 RTOS 原理有基礎理解
社群與生態	- 因 Microsoft Azure 加持，工業界支持度高 - 開源時間較晚，社群支援相較少	- 擁有極為廣泛的使用者社群 - 豐富的第三方套件與論壇資源	- 企業和開源社群雙管齊下 - 大型廠商投入資源開發並提供硬體支援 - 文件與套件工具逐漸成熟	- 亞洲市場擁有極大用戶基礎 - 社群不斷壯大，第三方資源也逐年提升
適用範圍	- 消費電子、工業設備 - 高度資源受限或需要高效能的應用	- 廣泛用於各類微控制器與嵌入式裝置 - 適合中小型專案或原型開發	- 高度跨平台相容性的產品 - 需要整合多種通訊協定的裝置	- 小型物聯網裝置、家電產品、工業控制等 - 適合資源有限且需高即時性的情境
範例	- 高度整合 SoC 平台 - 網路裝置、醫療器械、消費性電子設備 - 資源特別有限但需穩定度的系統	- 物聯網邊緣設備 - 小型感測器、可攜式產品 - 工業自動化控制	- 高速通訊設備 - 需要完整追蹤與調試能力的工業設備 - 精密儀器及高可靠度應用	- 嵌入式微控制器 - 智能家居與可穿戴式裝置 - 需要快速啟動、高效率排程的場景

內核功能層面的差異

名稱	AzureRTOS (ThreadX)	FreeRTOS	Zephyr	RT-Thread
內核架構	- 輕量級、模組化設計 - 單核心即時系統 - 提供 preemption-threshold	- 單核心設計 - 透過設定檔自由啟用/停用功能 - 針對 MCU 移植方便	- 類微核心（microkernel）概念 - Kconfig 編譯時可裁剪/擴充 - 可支援多核心 (SMP)	- 微核心 + 模組化 - 通過 Packages 擴充 - 預設核心輕量、啟動速度快
排程機制	- 可搶先式多工 - 優先順序排程 - preemption-threshold 降低不必要的搶先	- 可搶先式或協同式多工 - 時間片 (time slicing) 可選 - 任務通知提高效能	- 可搶先式/協同式混合 - 支援多核心下的任務搬移 - 彈性設定時間片與搶先策略	- 以優先順序為基礎的可搶先式 - 切換開銷低 - 適合時限嚴苛的應用
中斷管理	- 提供快速中斷響應 - ISR 中可使用 IPC 原語 - 建議複雜邏輯放在 Thread	- 有完整的中斷優先級設定規範 - 提供「FromISR」API 與核心互動 - 避免高優先級中斷封鎖 RTOS 服務	- 針對不同架構有對應方法 - 允許在 ISR 後半段做較複雜處理 - 支援 `irq_offload`	- 中斷入口/出口簡潔 - 可在 ISR 裡做任務喚醒或 IPC - 建議將重任務放在中斷後處理或 Task
任務通訊與同步	- 提供 Semaphore、Mutex、Event Flags、Message Queue - Block Pool / Byte Pool 作為底層資源	- 有 Queue、Semaphore、Mutex、Event Group、Task Notification - Queue 是核心溝通管道	- 提供 Queue、FIFO、LIFO、Pipe、Mailbox、Semaphore、Mutex 等多樣化機制 - 信號（Signals）/事件等高階通訊	- 提供 Semaphore、Mutex、Event、Mailbox、Message Queue - 模組化 API，易於擴充
記憶體管理	- Block Pool（固定大小） - Byte Pool（彈性分配） - 適合小型系統	- 多種 heap 實作 (heap1~heap5) - 依需求選擇靜態或動態配置 - 須注意配置 Semaphore / Mutex 以確保多任務安全	- slab、mempool、heap 等多種分配策略 - Kconfig 可細調 - 需在編譯階段做良好配置	- mempool、heap 二分法 - 預設輕量動態分配算法 - 可搭配自訂或高階 alloc 演算法
除錯與追蹤	- 可使用 TraceX 等工具 - 整合度高，針對 Thread、Event、IPC 做可視化	- FreeRTOS+Trace、第三方 IDE 追蹤工具多 - 與 Percepio Tracealyzer 深度整合	- 統一的 Tracing 子系統 - 可連接 Tracealyzer、LTTng、SystemView 等 - 追蹤支援度豐富	- RT-Thread Studio 或其他插件 - 提供簡單 log 系統與線上除錯機制 - 社群亦有類似 FreeRTOS Trace 的追蹤方案
可移植性與擴充性	- 官方主要支援多數 ARM、RISC-V、MIPS - Microsoft 收購後社群逐漸擴大	- 幾乎所有 MCU 都有移植 - 大量第三方套件與驅動 - 可透過 AWS FreeRTOS 延伸雲端功能	- 原生支援多家大廠硬體 (Intel、NXP、Nordic…) - Kconfig + Devicetree 與 Linux 類似 - 企業支援與社群並重	- 在亞洲（特別是中國）用得廣泛 - 與國產 MCU、RISC-V 平台整合度高 - Packages 方式讓功能彈性擴充

總結

總結一下前面提到的四種RTOS：

AzureRTOS (ThreadX)：以高效能與小巧佔用聞名，擅長在嚴苛的資源受限環境中執行，另有良好的除錯工具與商業案例，對STM32的支援度好。
FreeRTOS：擁有巨大開源社群與靈活的擴充性，適用於廣泛的微控制器與嵌入式應用，在學術或商業專案皆常見，初學者適合。
Zephyr：受到 Linux 基金會與多家企業的大力推動，硬體支援廣泛，並有強大的追蹤與分析工具，適合需要高可靠度及詳細監控的中大型嵌入式應用
RT-Thread：架構輕量化、模組化明確，啟動速度快，適合物聯網及其他對即時性與資源效率要求高的場景。

Zephyr RTOS 兩種建立Thread的方式

Sun, 05 Jan 2025 22:20:31 +0800

Zephyr RTOS 兩種建立Thread的方式

Thread (執行緒)

在 Zephyr OS中，每個獨立的功能或任務可以放在不同的執行緒中執行，內部使用了輕量級的排程器，可以根據不同執行緒的優先級，以及執行緒本身的狀態（ready, running, pending 等），來決定哪一個執行緒能夠先被 CPU 執行，執行緒可以有以下幾個性質：

執行緒優先級（Priority）：數值越小表示優先級越高（Preemptive scheduling 的情況下）。
堆疊大小（Stack Size）：每個執行緒必須設定自己的堆疊空間，Zephyr 會在執行緒切換時儲存或恢復執行緒的上下文。
執行緒生命週期（Lifecycle）：可以在編譯期就被預先配置好，或在執行期動態配置與建立。

Zephyr 建立執行緒的兩種常見方法

在編譯期間（Compile Time）建立執行緒

Zephyr 提供了一個巨集 K_THREAD_DEFINE() 用於在編譯期就宣告並建立執行緒。只要程式一開啟並初始化 RTOS 後，這些執行緒就會自動被建立並進入排程器的管理。

K_THREAD_DEFINE()

1
2


#define K_THREAD_DEFINE(name, stack_size, entry_fn, p1, p2, p3, \
 prio, options, delay)

name：此執行緒的識別名稱，同時會生成一個 k_tid_t 型態的變數。
stack_size：此執行緒的堆疊大小（以 byte 為單位）。
entry_fn：此執行緒進入點函式（thread function），開始執行時要跑哪個函式。
p1, p2, p3：最多可傳入三個參數給進入點函式使用（都為 void* 型態）。
prio：優先級（數值越小，優先級越高）。
options：執行緒選項，通常先給 0 表示沒有特別的額外設定。
delay：執行緒開始之前的延遲時間（ticks 或毫秒），若填 0 表示不延遲，立即就緒。

在執行期間（Run Time）建立執行緒

另一種是在程式運行期間建立執行緒，使用 API 函數k_thread_create() 建立執行緒。這種方法在有些情況下會更具彈性，例如依據狀態或條件，動態啟動或終止執行緒，以免靜態建立過多浪費資源。

k_thread_create()

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


k_tid_t k_thread_create(
 struct k_thread *new_thread,
 k_thread_stack_t *stack,
 size_t stack_size,
 k_thread_entry_t entry,
 void *p1,
 void *p2,
 void *p3,
 int prio,
 uint32_t options,
 k_timeout_t delay
);

new_thread：指向使用者自行宣告的 struct k_thread 物件，用來儲存此執行緒的控制區塊。
stack：指向此執行緒對應的堆疊空間（需先以 K_THREAD_STACK_DEFINE() 靜態或動態配置）。
stack_size：此堆疊的大小。
entry：執行緒執行的進入點函式。
p1, p2, p3：最多可傳入三個參數到執行緒函式。
prio：優先級。
options：執行緒選項，常用為 0。
delay：執行緒開始前是否要延遲。

範例

以下兩段程式碼，分別示範用 K_THREAD_DEFINE()（在編譯期間）或 k_thread_create()（在執行期間）建立兩個執行緒，分別執行 LED 漸亮漸暗（fade_led）與 LED 閃爍（toggle_led）的功能 github repo 以下是在Nucleo-F303K8的執行結果，左邊LED執行toggle，右邊執行fading

在編譯期間（Compile Time）動態建立執行緒範例

K_THREAD_DEFINE(fade_tid, 512, fade_led, NULL, NULL, NULL, 5, 0, 0);
- 建立一個名為 fade_tid 的執行緒，堆疊大小 512 bytes，執行函式為 fade_led，優先級 5。
- p1, p2, p3 都填 NULL，表示不需要傳遞參數。
K_THREAD_DEFINE(toggle_tid, 512, toggle_led, NULL, NULL, NULL, 5, 0, 0);
- 同樣建立名為 toggle_tid 的執行緒，stack大小、優先級參數與上面一致，執行函式為 toggle_led。

這些執行緒在編譯的時候就已經被「靜態配置」了，所以當系統啟動並執行到 main() 時，它們也就由排程器自動啟動並不斷執行。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76


#include <stdio.h>
#include <zephyr/kernel.h>
#include <zephyr/sys/printk.h>
#include <zephyr/device.h>
#include <zephyr/drivers/pwm.h>
#include <zephyr/drivers/gpio.h>

void fade_led(void *p1, void *p2, void *p3);
void toggle_led(void *p1, void *p2, void *p3);

// 利用 DT_ALIAS(pwm_led0) 與 DT_ALIAS(led1) 取得裝置樹中的設備訊息
static const struct pwm_dt_spec pwm_led0 = PWM_DT_SPEC_GET(DT_ALIAS(pwm_led0));
static const struct gpio_dt_spec led1 = GPIO_DT_SPEC_GET(DT_ALIAS(led1), gpios);

// 這裡定義一些常數用於控制漸亮漸暗的速度或節拍
#define NUM_STEPS 256U
#define SLEEP_MSEC 5U
#define SLEEP_TIME_MS 500

// 在編譯期間靜態建立兩個執行緒
K_THREAD_DEFINE(fade_tid, 512, fade_led, NULL, NULL, NULL, 5, 0, 0);
K_THREAD_DEFINE(toggle_tid, 512, toggle_led, NULL, NULL, NULL, 5, 0, 0);

// fade_led 會透過 PWM 設定脈寬來控制 LED 的亮度，製造 "呼吸燈" 效果
void fade_led(void *p1, void *p2, void *p3)
{
 uint32_t pulse_width = 0U;
 uint32_t step = pwm_led0.period / NUM_STEPS;
 uint8_t dir = 1U;

 while (1) {
 // 設定當前的脈寬
 pwm_set_pulse_dt(&pwm_led0, pulse_width);

 // 調整脈寬，控制 LED 往漸亮或漸暗方向
 if (dir) {
 pulse_width += step;
 if (pulse_width >= pwm_led0.period) {
 pulse_width = pwm_led0.period - step;
 dir = 0U;
 }
 } else {
 if (pulse_width >= step) {
 pulse_width -= step;
 } else {
 pulse_width = step;
 dir = 1U;
 }
 }
 k_sleep(K_MSEC(SLEEP_MSEC));
 }
}

// toggle_led 會透過 GPIO pin toggle 的方式，使 LED 閃爍
void toggle_led(void *p1, void *p2, void *p3)
{
 while (1) {
 gpio_pin_toggle_dt(&led1);
 k_sleep(K_MSEC(SLEEP_TIME_MS));
 }
}

int main(void)
{
 // 檢查 PWM 裝置是否 ready
 if (!pwm_is_ready_dt(&pwm_led0)) {
 printk("Error: PWM device %s is not ready\n", pwm_led0.dev->name);
 return 0;
 }

 // 設定 GPIO pin 為輸出
 gpio_pin_configure_dt(&led1, GPIO_OUTPUT_ACTIVE);

 // main 函式結束後，兩個 K_THREAD_DEFINE 建立的執行緒依然會持續執行
 return 0;
}

在執行期（Run Time）動態建立執行緒範例

若想要在程式執行的過程中（例如：由某個事件觸發）再建立執行緒，可以使用以下的做法： 1. 用 K_THREAD_STACK_DEFINE(my_stack_area, STACK_SIZE); 定義stack。 2. 定義一個 struct k_thread my_thread_data; 作為執行緒控制區塊（Thread Control Block, TCB）。 3. 呼叫 k_thread_create()，傳入上述的stack、控制區塊、進入點函式及其他參數來完成建立。

以下是一個範例，展示如何在 main() 函式中動態建立執行緒（此示例僅顯示與執行緒有關的部分，省略週邊初始化等重複程式碼）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52


\* 
前面的程式碼相同
*\

// 宣告執行緒stack size
static K_THREAD_STACK_DEFINE(fade_stack, 512);
static K_THREAD_STACK_DEFINE(toggle_stack, 512);

// 宣告執行緒控制區塊
static struct k_thread fade_thread_data;
static struct k_thread toggle_thread_data;

// 這兩個函式和之前範例雷同
void fade_led(void *p1, void *p2, void *p3)
{
 // ...
}

void toggle_led(void *p1, void *p2, void *p3)
{
 // ...
}

int main(void)
{
 // 在執行期動態建立 fade_led thread
 k_tid_t fade_tid = k_thread_create(
 &fade_thread_data,
 my_fade_stack,
 K_THREAD_STACK_SIZEOF(my_fade_stack),
 fade_led,
 NULL, NULL, NULL,
 5, 0,
 K_NO_WAIT
 );

 // 在執行期動態建立 toggle_led thread
 k_tid_t toggle_tid = k_thread_create(
 &toggle_thread_data,
 my_toggle_stack,
 K_THREAD_STACK_SIZEOF(my_toggle_stack),
 toggle_led,
 NULL, NULL, NULL,
 5, 0,
 K_NO_WAIT
 );

 // k_thread_create 回傳 k_tid_t，可用於後續管理 thread
 // 例如 k_thread_suspend(fade_tid), k_thread_resume(fade_tid), k_thread_abort(fade_tid)...

 return 0;
}

比較

建立方式	特點	典型使用時機
Compile Time 建立	`K_THREAD_DEFINE()`	一開始已知需要的執行緒，以及系統資源充足時
Run Time 動態建立	`k_thread_create()`，在程式執行時期再分配資源	不確定需要多少執行緒，或需要彈性創建／釋放

如果確定在整個系統的生命週期中，執行緒數量固定，或是系統比較單純（例如一個簡單的多任務控制），用編譯期方式能減少程式碼的複雜度，也能讓程式一啟動就快速就緒。
如果系統中會動態產生／取消某些任務（如：偵測到新裝置才開新任務等），就可以使用動態建立的方式，提高系統彈性。

總結

靜態（編譯期）建立執行緒：
- 使用 K_THREAD_DEFINE()
- 簡單、快速、程式架構清晰
- 適用於固定且少數的長期執行緒
動態（執行期）建立執行緒：
- 使用 k_thread_create()
- 需要自行管理堆疊、控制區塊等
- 適用於需要彈性創建和銷毀大量或不定數量執行緒的應用場景