LuatOS 的設計核心在于高度模塊化與松耦合架構。系統將硬件驅動、通信協議、定時任務等封裝為獨立模塊，通過統一的注冊與回調機制接入主事件循環。這種設計不僅提升了代碼復用率，也使得開發者可以按需裁剪功能，適應不同規模的嵌入式項目需求。

一、LuatOS框架中的概念

在LuatOS中，有三個核心概念和一個調度器：

1、三個核心概念：任務（task），消息（message），定時器（timer）

2、一個調度器：sys.run()函數；

1.1 LuatOS任務（task）

1.1.1 FreeRTOS task和LuatOS task

從上面這張圖中我們可以看到，有兩種任務：

1、第一種是LuatOS內核固件中的任務，也就是FreeRTOS創建的任務；這種任務我們把它命名為FreeRTOS task；

2、第二種是LuatOS項目應用腳本中的任務，也就是用戶腳本代碼中調用sys.taskInit和sys.taskInitEx兩個API創建的任務，這種任務我們把它命名為LuatOS task；嚴格意義上說，LuatOS task并不是真正的task，而是利用了Lua中的協程（coroutine）概念，來等價實現的一種task效果，因為task的受眾面比協程的受眾面要廣的很多，所以我們在LuatOS中，將協程（coroutine）包裝成了task的概念，這樣更容易理解和使用；關于協程（coroutine）的知識，在本文接下來的內容中，我們會接觸到。

在這里我使用一個形象的比喻，爭取可以讓大家更加直觀的理解這兩種任務的聯系和區別：

1、有一個森林，這個森林就是FreeRTOS；

2、森林里生長了很多棵大樹，每一棵大樹都是FreeRTOS創建的一個任務，就是FreeRTOS task；

這些大樹分成了兩種：

a. 一種是長出了樹干，樹干上還有很多樹枝，這一種大樹只有一棵，就是Lua虛擬機任務

b. 一種是只長了光禿禿的樹干，樹干上沒有樹枝，這種大樹有很多，除Lua虛擬機之外，其余所有任務都是這種大樹

Lua虛擬機任務這棵大樹的樹干上長出的所有樹枝，就是一個個的LuatOS task

根據以上描述畫一張簡圖如下：

1.1.2 兩種LuatOS task（基礎task和高級task）

怎么創建一個task，在sys核心庫中提供了兩個api：

sys.taskInit(task_func, ...)

sys.taskInitEx(task_func, task_name, non_targeted_msg_cbfunc, ...)

這兩個api分別創建兩種task，首先我們給這兩種task起個名字，一種叫基礎task，一種叫高級task；

sys.taskInit(task_func, ...)創建的task是基礎task；

sys.taskInitEx(task_func, task_name, non_targeted_msg_cbfunc, ...)創建的task是高級task；

從設計原理的角度來看，基礎task和高級task的區別是：

(1) 所有的基礎task共享一個全局消息隊列；

(2) 每個高級task都有自己獨立的定向消息隊列，同時又能使用全局消息隊列；

1.1.3 LuatOS task內部運行環境和外部運行環境

在LuatOS應用腳本開發過程中，我們所編寫的應用腳本代碼，存在兩種業務運行的邏輯環境：

1、一種是在task的任務處理函數內部的業務邏輯環境中運行，我們簡稱為：在task內部運行；

2、一種是在task的任務處理函數外部的業務邏輯環境中運行，我們簡稱為：在task外部運行；

怎么理解這兩種業務邏輯運行環境？我們看下面這張圖

看右邊生長出分支的這棵大樹，這棵大樹就是FreeRTOS創建的Lua虛擬機task，是一個FreeRTOS task；

在這個Lua虛擬機FreeRTOS task上，這棵大樹再分為兩部分：

1、樹干部分：樹干部分運行的業務邏輯環境就是LuatOS task外部運行環境；

2、樹枝部分：每個樹枝都是一個獨立的LuatOS task，樹枝部分運行的業務邏輯環境就是LuatOS task內部運行環境；

在這里，大家只要知道有task內部運行和task外部運行兩種環境即可，接下來我們下面講解內部設計原理時，會進一步去學習理解；

1.1.4 LuatOS task狀態切換

1.2 LuatOS消息（message）

LuatOS 的消息機制是LuatOS task協作和事件驅動編程的核心部分，消息機制包括消息的發布和訂閱處理、消息的發送和接收處理；

1.2.1 三種消息隊列

消息需要存儲到消息隊列中，消息隊列中的消息遵循先進先出（FIFO）原則；

內核消息隊列

FreeRTOS創建的每一個task都有一個消息隊列，這種消息隊列就叫做內核消息隊列；

內核消息隊列是FreeRTOS直接管理的，存儲每個FreeRTOS task內核消息的隊列；

LuatOS應用全局消息隊列

所有LuatOS task應用共享一個消息隊列，這個消息隊列就叫做LuatOS應用全局消息隊列；

LuatOS應用全局消息隊列是LuatOS虛擬機直接管理的；

LuatOS基礎task可以接收處理這個消息隊列中的消息，LuatOS高級task可以接收處理這個消息隊列中的消息；

LuatOS外部運行環境中的業務也可以接收處理這個消息隊列中的消息；

LuatOS應用定向消息隊列

每個LuatOS 高級task都有一個消息隊列，這個消息隊列就叫做LuatOS應用定向消息隊列；

LuatOS應用定向消息隊列是LuatOS虛擬機直接管理的；

每個定向消息隊列和一個LuatOS高級task存在唯一的綁定關系；

只有綁定的LuatOS高級task才可以接收處理這個消息隊列中的消息；（雖然從源碼設計上看，所有的LuatOS高級task都可以接收處理定向消息隊列中的消息，但是這樣使用的話，理解起來會比較混亂）

1.2.2 六種消息

根據消息存儲使用的消息隊列類型以及消息發送方的不同，可以把消息劃分為以下六類：

1.3 LuatOS定時器（timer）

對于LuatOS應用程序來說，定時器本質上也算是一種特殊的消息，因為定時器太常用了，所以把他單獨拎出來，單獨的一個章節進行講解；

定時器分類如下圖所示：

1.4 LuatOS調度器（sys.run()）

sys核心庫是LuatOS應用程序運行的核心大腦，sys.run()是sys核心庫的大腦，負責整個LuatOS應用腳本程序的調度和管理，是LuatOS應用程序的調度器；

sys.run()非常重要，但是sys.run()使用起來非常簡單，僅僅在main.lua的最后一行調用sys.run()即可。

雖然sys.run()使用起來非常簡單，但是如果大家對sys.run()的運行原理有一個總體性的理解和認識，對開發LuatOS應用項目來說，幫助很大。

所以在這里，我先對sys.run()內部的工作原理做一個簡化后的總體介紹，至于更詳細的原理介紹，我們會在下面進行詳細講解；

我們看上面這張圖：

1、LuatOS內核固件中的FreeRTOS會創建一個Lua虛擬機任務；

2、Lua虛擬機任務的處理函數中，首先進行初始化：

在內核固件的C代碼中，加載Lua標準庫和LuatOS核心庫；

從LuatOS的腳本分區找到main.lua

開始逐行嵌套解析執行main.lua中的腳本代碼（加載必要的擴展庫腳本文件和自己開發的應用腳本文件，并且運行這些腳本文件的初始化代碼）

3、運行main.lua的最后一行代碼sys.run()

4、sys.run()中的實現是一個while true循環，在這個循環內，不斷地從內核消息隊列和LuatOS應用消息隊列中讀取消息，并且分發消息給接收者進行處理。

二、sys.lua源碼分析方法

通過本文前三部分的描述，我們對LuatOS運行框架的基礎理論知識做了簡單的回顧；

接下來我們進入本講的重點內容：學習理解LuatOS運行框架的內部設計源碼；

sys核心庫是LuatOS運行框架庫，是LuatOS應用程序運行的核心大腦；

我們要深入學習LuatOS框架的內部設計原理，就是要深入學習sys核心庫的內部設計實現原理；

sys.lua源文件是sys核心庫的代碼實現，點擊這里可以看到sys.lua源碼；

所以本講課程中，我們接下來會重點分析sys.lua的源碼實現；通過分析sys.lua源碼，從而來學習理解LuatOS框架的設計原理；

sys.lua是sys核心庫的內部實現；

說到核心庫，我們再來回顧一下LuatOS軟件架構，如下圖所示：

之前我們講述LuatOS軟件架構時，當時有說，LuatOS核心庫是用C語言開發的，這個描述并不準確，在核心庫中，有一個特例，就是sys核心庫，這個核心庫是用Lua語言開發的，并且源碼也開放了；

雖然sys核心庫是用Lua語言開發的，但是它還是一個核心庫，在編譯內核固件的時候，會把sys.lua源文件集成到編譯好的內核固件中對外發布；

我們今天采用以下方式來學習sys.lua源碼設計：

1、在目前的sys.lua源文件中增加詳細的注釋和運行日志，分析代碼設計

2、使用LuatOS PC模擬器，運行demo代碼+第1步增加運行日志的sys.lua，通過分析運行日志，進一步理解sys.lua的設計原理

在模擬器上運行demo代碼的方法，

本講中使用的demo代碼參考luatos_framework；模擬器運行時的命令如下：

要深入理解LuatOS框架的設計原理，其實就是深入學習sys.lua中的以下幾個概念：

1、一個調度器：sys.run()

2、三個概念：任務（task），消息（message），定時器（timer）

3、五張表：

高級task任務列表（taskList）

全局消息訂閱表（subscribers），全局消息隊列（messageQueue）

定時器處理表（timerPool），定時器回調函數參數表（para）

三、LuatOS 調度器（sys.run()）內部設計

LuatOS調度器sys.run函數的主體處理邏輯參考下圖中黃色背景部分

從這張圖可以看出，在LuatOS內核固件中有一個FreeRTOS，FreeRTOS運行起來之后，創建了很多任務，有軟件定時器任務，TCP/IP協議棧任務，文件系統任務，Lua虛擬機任務等。

其中Lua虛擬機任務和LuatOS項目的應用軟件關系最為密切；

Lua虛擬機任務運行起來之后，經過必要的初始化動作，就會去尋找main.lua腳本文件，找到之后，從main.lua的第一行代碼開始解析執行，main.lua會執行必要的初始化動作并且加載運行其他的Lua腳本應用功能模塊，main.lua的最后一行代碼為sys.run()，sys.run()是一個while true的循環函數，實際上也是Lua虛擬機任務的處理函數；

在這個while循環里面，不斷的分發處理各種消息，調度LuatOS項目應用軟件的正常運行。

現在，我們一起看下剛才描述的這個過程的源碼，在閱讀源碼之前，我們先看下面這張框圖，描述了主要源碼函數和代碼段的調用過程：

四、LuatOS 任務（task）內部設計

4.1 sys.taskInit（創建并且運行基礎task）

4.1.1 源碼分析

我們接下來再看sys.coresume(co, ...)的源碼

通過分析sys.taskInit這個api的源碼，我們可以看出，LuatOS的task概念，實際上是對Lua語言的協程（coroutine）概念的一層封裝，因為task的受眾面比協程的受眾面要廣的很多，所以我們在LuatOS中，將協程（coroutine）包裝成了task的概念，這樣更容易理解和使用；

4.1.2 Lua語言中協程（coroutine）概念的理解

在LuatOS的sys.lua中，把Lua中的協程概念包裝成了task概念，來實現多任務的編程效果；

所以我們要想深入理解sys.lua中的內部設計，勢必要對Lua語言中的協程概念有一個基本的認識；

在 Lua 語言中，協程（coroutine）是一種用戶態的輕量級線程，它允許程序在執行過程中暫停和恢復，從而實現協作式的多任務處理。與操作系統的線程不同，協程的調度完全由程序自身控制，而非由操作系統內核調度；

1、在LuatOS的sys.lua中，僅僅關注協程的三種狀態：

掛起（suspended）狀態，以下兩種情況，協程處于掛起狀態：

coroutine.create(f)創建協程后，未主動運行這個協程；

協程運行過程中，被本協程內部調用coroutine.yield(...)暫停；

運行（running）狀態：

處于掛起狀態的協程co，在此協程外執行coroutine.resume(co[, ...])則恢復為運行狀態；

死亡（dead）狀態：以下兩種情況，協程處于死亡狀態：

協程正常運行結束；

協程運行過程中出現異常結束；

2、協程的核心特點

協作式：協程必須主動讓出執行權（通過調用coroutine.yield(...)），其他協程才有機會運行。

狀態保留：協程暫停掛起時會保存當前執行狀態（如變量、棧），恢復時從暫停處繼續。

4.1.3 應用示例

針對剛才對sys.taskInit源碼的分析，接下來我們一起在模擬上運行一個demo示例，加深一下對sys.taskInitapi內部設計的理解；

核心代碼片段如下（重點關注黃色背景的代碼）：

main.lua

scheduling.lua

首先我們分析一下，在這個demo示例中，使用sys.taskInit(task1_func)創建的任務，任務處理函數的task1_func()的源碼+sys.lua源碼，分析下代碼是如何調度運行的；

接下來我們使用模擬器，針對以下幾種場景，實際跑一下這個demo示例看看運行效果：

模擬器運行指令如下：

1、打開 scheduling.lua中的count = count + "hdjks"

最終運行的核心日志為

2、打開 scheduling.lua中的count = count + "hdjks"

sys.lua中的return wrapper(arg[1], coroutine.resume(...))修改為return coroutine.resume(...)

最終運行的核心日志為

3、打開 scheduling.lua中的count = count + "hdjks"

打開main.lua中的

_G.COROUTINE_ERROR_ROLL_BACK = false

_G.COROUTINE_ERROR_RESTART = false

最終運行的核心日志為

4.2 sys.taskInitEx（創建并且運行高級task）

4.2.1 數據結構（taskList）

4.2.2 源碼分析

從上面這段代碼可以看到，使用sys.taskInitEx創建一個高級task，和使用sys.taskInit創建一個基礎task相比，最核心的區別是多申請了一個高級task全局信息表{msgQueue={}, To=false, cb=cbFun}，這個全局信息表是高級task處理定時器消息和定向消息的關鍵；下圖中高級task指向的定向消息隊列，對應的就是高級task全局表中的msgQueue={}

4.2.3 應用示例

使用sys.taskInitEx創建一個高級task，和使用sys.taskInit創建一個基礎task相比，最核心的區別是多申請了一個高級task全局信息表{msgQueue={}, To=false, cb=cbFun}，其余實現原理和sys.taskInit完全相同，所以此處不再對sys.taskInitEx結合實際的demo示例來進一步理解了；

在后續的消息和定時器章節會進一步深入演示學習。

4.3 sys.taskDel（清除高級task的內存資源）

4.3.1 源碼分析

4.3.2 應用示例

針對剛才對sys.taskDel源碼的分析，接下來我們一起在模擬上運行一個demo示例，加深一下對sys.taskDelapi內部設計的理解；

核心代碼片段如下（重點關注黃色背景的代碼）：

main.lua

memory_task_delete.lua

接下來我們使用模擬器，針對以下三種場景，實際跑一下這個demo示例看看運行效果：

1、打開 memory_task_delete.lua中的sys.taskDel("led_task")

關閉 memory_task_delete.lua中的dhjsk = las + 2

關閉main.lua中的

_G.COROUTINE_ERROR_ROLL_BACK = false

_G.COROUTINE_ERROR_RESTART = false

最終運行的核心日志為

2、關閉 memory_task_delete.lua中的sys.taskDel("led_task")

關閉 memory_task_delete.lua中的dhjsk = las + 2

關閉main.lua中的

_G.COROUTINE_ERROR_ROLL_BACK = false

_G.COROUTINE_ERROR_RESTART = false

最終運行的核心日志為

3、打開 memory_task_delete.lua中的sys.taskDel("led_task")

打開 memory_task_delete.lua中的dhjsk = las + 2

打開main.lua中的

_G.COROUTINE_ERROR_ROLL_BACK = false

_G.COROUTINE_ERROR_RESTART = false

最終運行的核心日志為

4、打開 memory_task_delete.lua中的sys.taskDel("led_task")

打開 memory_task_delete.lua中的dhjsk = las + 2

關閉main.lua中的

_G.COROUTINE_ERROR_ROLL_BACK = false

_G.COROUTINE_ERROR_RESTART = false

最終運行的核心日志為

通過這個demo示例，我們可以看出sys.taskDel函數對于內存釋放的作用，目前的LuatOS設計，只需要記住一點就行了：

高級task的任務處理函數中，在調用return語句返回前，或者任務處理函數的最后一行代碼，調用sys.taskDel即可；

五、LuatOS 定時器（timer）內部設計

5.1 數據結構（timerPool和para）

5.2 api源碼分析

現在，我在vscode上打開已經添加了詳細注釋的sys.lua，對以下每個api的源碼進行分析（僅分析和定時器有關的源碼部分），為了讓大家對定時器的使用有一個更全局的認識，所以也會分析一部分LuatOS倉庫中開源的內核C代碼：

下面列舉的函數調用棧，供分析源碼時參考使用：

Lua->C：sys.timerStart，sys.timerLoopStart，sys.wait，sys.waitUntil，sys.waitMsg->rtos.timer_start

C： l_rtos_timer_start->luat_timer_start->xTimer接口

C：luat_timer_callback->luat_msgbus_put

Lua->C->Lua：sys.run->rtos.receive->luat_msgbus_get->l_timer_handler(返回rtos.MSG_TIMER，timer_id， repeat三個參數)

5.3 完整業務處理過程

5.4 應用示例

剛才我們已經分析了和定時器操作有關的sys.lua源碼，在本講的最后一章，我會基于一個實際的MQTT demo項目，逐行分析項目中應用腳本源碼和sys.lua源碼，讓大家在實際的項目中深刻理解LuatOS運行框架中的消息設計原理；

六、LuatOS 消息（message）內部設計

6.1 數據結構（subscribers和messageQueue）

下圖中的全局消息隊列，對應的就是messageQueue ={}

6.2 api源碼分析

現在，我在vscode上打開已經添加了詳細注釋的sys.lua，對以下每個api的源碼進行分析（僅分析和消息處理有關的源碼部分），為了讓大家對消息的使用有一個更全局的認識，所以也會分析一部分LuatOS倉庫中開源的內核C代碼：

在這些api中，消息的發送和接收api容易混用，組合使用關系參考下表（每一行的兩個單元格所表示的api必須組合使用）：

下面列舉五種消息應用場景的完整業務處理過程：

6.3 內核非定時器消息完整業務處理過程（以 串口接收到新數據消息 為例）

1、uart.on(1, "receive", recv_cb)->l_uart_on

2、luat_irq_uart_cb->luat_msgbus_put

3、sys.run()->rtos.receive->luat_msgbus_get->l_uart_handler(在這里執行執行uart.on注冊的回調函數recv_cb，然后返回空數據，sys.lua中的rtos.receive返回值為nil)

6.4 系統應用全局消息完整處理過程（以"IP_READY"為例）

在用戶腳本代碼中，根據具體的業務邏輯，訂閱全局消息"IP_READY"

當某一種網卡網絡環境準備就緒時，在內核固件的netif_ip_event_cb中，主動調用sys.lua中定義的_G.sys_pub = sys.publish，實際上就是調用sys.publish發布一條全局消息"IP_READY"，存儲到sys.lua中的全局消息表messageQueue中

在sys.lua中，消息分發處理：sys.run->dispatch

6.5 用戶應用全局消息完整處理過程

在用戶腳本代碼中，根據具體的業務邏輯，訂閱全局消息

在用戶腳本的代碼，調用sys.publish發布全局消息

在sys.lua中，通過sys.run調度器，執行dispatch分發處理全局消息

6.6 系統應用定向消息完整處理過程（以socket.EVENT為例）

l_socket_callback，當內核固件中的某一個socket產生異步事件時（例如socke接收到新數據），主動調用sys.lua中定義的_G.sys_send = sys.sendMsg，實際上就是調用sys.sendMsg給指定Lua腳本中的高級task發送一條定向消息，存儲到此高級task對應的定向消息隊列taskList[task_name].msgQueue中

在用戶腳本代碼中，通過sys.waitMsg去處理定向消息

6.7 用戶應用定向消息完整處理過程

1、在用戶腳本代碼中，調用sys.sendMsg發送定向消息

2、在用戶腳本代碼中，調用sys.waitMsg處理定向消息

6.8 應用示例

剛才我們已經分析了和消息操作有關的sys.lua源碼，在本講的最后一章，我會基于一個實際的MQTT demo項目，逐行分析項目中應用腳本源碼和sys.lua源碼，讓大家在實際的項目中深刻理解LuatOS運行框架中的消息設計原理；

七、基于MQTT demo項目，再次全面理解LuatOS框架的內部設計運行原理

講到最后，我會基于一個實際的MQTT demo項目，逐行分析項目中應用腳本源碼和sys.lua源碼，讓大家在實際的項目中深刻理解LuatOS運行框架的內部設計原理；

7.1 demo項目總體設計框圖

demo項目的總體設計框圖如下：

7.2 demo項目源碼+sys.lua源碼綜合分析

這個mqtt demo代碼中的注釋比較詳細，sys.lua代碼注釋也比較詳細，接下來我用vscode直接打開這份demo項目和sys.lua，和大家一起分析下源碼設計；

今天的內容就分享到這里了~

審核編輯 黃宇