RTOS項(xiàng)目中踩過的10個(gè)致命坑（上篇）

點(diǎn)擊上方藍(lán)色字體，關(guān)注我們

RTOS 憑借搶占式調(diào)度、多任務(wù)并行、精簡(jiǎn)的內(nèi)核，成為嵌入式開發(fā)的標(biāo)配。但它的便利背后，藏著無數(shù)個(gè)足以讓整個(gè)項(xiàng)目翻車的致命陷阱。這些坑往往不會(huì)在編譯階段報(bào)錯(cuò)，甚至實(shí)驗(yàn)室測(cè)試都很難復(fù)現(xiàn)，一旦到了復(fù)雜的量產(chǎn)現(xiàn)場(chǎng)，就會(huì)集中爆發(fā)，排查起來更是難如登天。

今天，我把這些年在項(xiàng)目里親身踩過、親眼見過的 10 個(gè)最致命的 RTOS 坑整理出來，每一個(gè)都帶著量產(chǎn)故障的血淚教訓(xùn)。

早年做工業(yè)采集項(xiàng)目時(shí)，同事在串口接收中斷里直接調(diào)用了printf打印日志、pvPortMalloc申請(qǐng)緩存，還調(diào)用了不帶FromISR后綴的消息隊(duì)列發(fā)送函數(shù)。

結(jié)果設(shè)備上電后隨機(jī)出現(xiàn)內(nèi)核調(diào)度錯(cuò)亂、任務(wù)卡死，甚至直接 HardFault，實(shí)驗(yàn)室復(fù)現(xiàn)概率極低，到了現(xiàn)場(chǎng)干擾大、中斷頻繁的環(huán)境，半小時(shí)就必崩。

這是 RTOS 開發(fā)中最常見也最致命的坑，核心根源在于對(duì)中斷上下文與任務(wù)上下文的本質(zhì)區(qū)別、OS API 的中斷安全機(jī)制完全不了解。

RTOS 的絕大多數(shù)常規(guī) API（比如不帶FromISR的函數(shù)），是為任務(wù)上下文設(shè)計(jì)的，內(nèi)部會(huì)通過關(guān)調(diào)度、掛起任務(wù)等方式實(shí)現(xiàn)同步，而這些機(jī)制在中斷上下文里完全失效，中斷不能被調(diào)度器掛起，強(qiáng)行調(diào)用會(huì)直接破壞內(nèi)核的任務(wù)鏈表、就緒隊(duì)列等核心數(shù)據(jù)結(jié)構(gòu)。

即便是 C 標(biāo)準(zhǔn)庫的printf、malloc這類函數(shù)，絕大多數(shù)實(shí)現(xiàn)都是不可重入、非中斷安全的，內(nèi)部有全局鎖或靜態(tài)變量，中斷里調(diào)用會(huì)導(dǎo)致重入，破壞內(nèi)存堆結(jié)構(gòu)、IO 狀態(tài)，直接引發(fā)死鎖或 HardFault。

中斷上下文的執(zhí)行時(shí)間必須極短，任何耗時(shí)操作都會(huì)拉長(zhǎng)中斷關(guān)閉窗口，導(dǎo)致其他中斷丟失、實(shí)時(shí)性徹底崩盤。

ISR 里只做最精簡(jiǎn)的中斷標(biāo)志清除、硬件寄存器操作，絕對(duì)不做任何業(yè)務(wù)邏輯、耗時(shí)操作。

錯(cuò)誤示例：

// 致命錯(cuò)誤：串口ISR里調(diào)用非中斷安全APIvoid USART1_IRQHandler(void){    if(USART_GetITStatus(USART1, USART_IT_RXNE) != RESET)    {        uint8_t data = USART_ReceiveData(USART1);        xQueueSend(uart_rx_queue, &data, portMAX_DELAY); // 錯(cuò)誤：用了非FromISR的API        printf("recv data: %02X\r\n", data); // 致命錯(cuò)誤：ISR里調(diào)用printf        uint8_t *buf = pvPortMalloc(64); // 致命錯(cuò)誤：ISR里動(dòng)態(tài)申請(qǐng)內(nèi)存    }}

正確示例：

// 正確用法：ISR僅做事件上報(bào)，業(yè)務(wù)交給任務(wù)void USART1_IRQHandler(void){    BaseType_t xHigherPriorityTaskWoken = pdFALSE;    if(USART_GetITStatus(USART1, USART_IT_RXNE) != RESET)    {        uint8_t data = USART_ReceiveData(USART1);        // 僅用中斷安全API發(fā)送數(shù)據(jù)，觸發(fā)任務(wù)調(diào)度        xQueueSendFromISR(uart_rx_queue, &data, &xHigherPriorityTaskWoken);        portYIELD_FROM_ISR(xHigherPriorityTaskWoken); // 觸發(fā)必要的上下文切換    }}// 專門的串口處理任務(wù)，在任務(wù)上下文做業(yè)務(wù)邏輯void uart_rx_task(void *arg){    uint8_t data;    while(1)    {        // 阻塞等待中斷上報(bào)的數(shù)據(jù)        if(xQueueReceive(uart_rx_queue, &data, portMAX_DELAY) == pdPASS)        {            // 所有業(yè)務(wù)邏輯、打印、內(nèi)存操作都在任務(wù)里執(zhí)行            uart_data_parse(data);        }    }}

做車規(guī)車身控制項(xiàng)目時(shí)，一個(gè)優(yōu)先級(jí)最高的剎車信號(hào)處理任務(wù)，偶爾出現(xiàn)響應(yīng)超時(shí)，導(dǎo)致剎車邏輯執(zhí)行延遲。排查了半個(gè)月，最終定位到：低優(yōu)先級(jí)的 Flash 讀寫任務(wù)持有了互斥鎖，被中等優(yōu)先級(jí)的傳感器采集任務(wù)搶占，導(dǎo)致高優(yōu)先級(jí)的剎車任務(wù)被阻塞了上百毫秒，完全違背了硬實(shí)時(shí)要求。

這就是經(jīng)典的無界優(yōu)先級(jí)反轉(zhuǎn)問題，也是搶占式 RTOS 里最容易被忽略的致命問題。

搶占式調(diào)度的核心規(guī)則是，CPU 永遠(yuǎn)執(zhí)行就緒態(tài)中優(yōu)先級(jí)最高的任務(wù)。

當(dāng)高優(yōu)先級(jí)任務(wù)（H）需要訪問被低優(yōu)先級(jí)任務(wù)（L）持有的共享資源時(shí)，H 會(huì)被阻塞，等待 L 釋放鎖。

此時(shí)如果有中等優(yōu)先級(jí)的任務(wù)（M）就緒，會(huì)搶占低優(yōu)先級(jí)任務(wù) L 的 CPU，導(dǎo)致 L 遲遲無法釋放鎖，高優(yōu)先級(jí)任務(wù) H 就會(huì)被無限期阻塞。相當(dāng)于中等優(yōu)先級(jí)任務(wù)，反而搶占了最高優(yōu)先級(jí)任務(wù)的執(zhí)行權(quán)，實(shí)時(shí)性徹底失效。

很多工程師的致命誤區(qū)，把二進(jìn)制信號(hào)量當(dāng)成互斥鎖用，而信號(hào)量完全沒有優(yōu)先級(jí)保護(hù)機(jī)制，是優(yōu)先級(jí)反轉(zhuǎn)的重災(zāi)區(qū)。

互斥訪問場(chǎng)景，必須用帶優(yōu)先級(jí)繼承機(jī)制的互斥鎖，絕對(duì)不能用二進(jìn)制信號(hào)量替代。優(yōu)先級(jí)繼承會(huì)臨時(shí)把持有鎖的低優(yōu)先級(jí)任務(wù)的優(yōu)先級(jí)，提升到等待該鎖的最高優(yōu)先級(jí)任務(wù)的級(jí)別，避免被中等優(yōu)先級(jí)任務(wù)搶占，從根源上抑制優(yōu)先級(jí)反轉(zhuǎn)。

做物聯(lián)網(wǎng)網(wǎng)關(guān)項(xiàng)目時(shí)，設(shè)備運(yùn)行幾天就會(huì)隨機(jī)出現(xiàn) HardFault，有時(shí)候是數(shù)據(jù)校驗(yàn)全錯(cuò)，有時(shí)候是任務(wù)直接卡死，現(xiàn)象完全無規(guī)律。最終定位是兩個(gè)問題：一是 TCP 協(xié)議解析任務(wù)的棧大小給少了，大報(bào)文解析時(shí)函數(shù)嵌套太深導(dǎo)致棧溢出；二是開啟了 FPU 硬件浮點(diǎn)運(yùn)算，任務(wù)切換時(shí) FPU 寄存器入棧占用了額外棧空間，預(yù)留不足直接溢出，破壞了相鄰的內(nèi)存數(shù)據(jù)。

RTOS 中每個(gè)任務(wù)都有獨(dú)立的棧空間，棧溢出是嵌入式開發(fā)的頭號(hào)隱形殺手，它的致命之處在于，溢出的破壞是靜默的、隨機(jī)的，不會(huì)立刻觸發(fā)故障，等到異常發(fā)生時(shí)，現(xiàn)場(chǎng)早已被破壞，排查難度極大。

常見的棧溢出根源：

常見解決辦法：

• 棧大小的合理計(jì)算規(guī)則，任務(wù)棧最小尺寸 = （函數(shù)最大調(diào)用深度的棧占用 + 局部變量最大占用）* 120% + 額外預(yù)留（FPU / 上下文開銷）；主棧大小要根據(jù)最大中斷嵌套深度、中斷內(nèi)的棧使用量來設(shè)置。強(qiáng)制開啟
• FreeRTOS 開啟configCHECK_FOR_STACK_OVERFLOW，實(shí)現(xiàn)棧溢出鉤子函數(shù)，溢出時(shí)立刻觸發(fā)告警、停機(jī)，方便定位。
• 帶 MPU 的 MCU，直接用 MPU 給棧區(qū)域設(shè)置不可寫保護(hù)，溢出時(shí)直接觸發(fā)內(nèi)存訪問異常，精準(zhǔn)定位。
• 調(diào)試階段開啟棧水印檢測(cè)，RTOS 創(chuàng)建任務(wù)時(shí)會(huì)給棧空間填充固定的水印值（比如 0xA5），運(yùn)行時(shí)通過檢測(cè)水印的破壞程度，統(tǒng)計(jì)棧的峰值使用量，精準(zhǔn)調(diào)整棧大小。
• 禁止在任務(wù)中使用大尺寸局部數(shù)組 / 結(jié)構(gòu)體，改用靜態(tài)全局變量或動(dòng)態(tài)分配；絕對(duì)禁止使用遞歸函數(shù)。

做電機(jī)控制項(xiàng)目時(shí)，同事為了保護(hù)多任務(wù)共享的控制參數(shù)，直接用__disable_irq()關(guān)了全局中斷，然后在臨界區(qū)里做了參數(shù)濾波計(jì)算、甚至 SPI 讀寫操作，關(guān)中斷時(shí)長(zhǎng)最長(zhǎng)達(dá)到了 200us。結(jié)果導(dǎo)致電機(jī)編碼器的高速中斷丟失，位置采樣不準(zhǔn)，電機(jī)出現(xiàn)堵轉(zhuǎn)、飛車風(fēng)險(xiǎn)。

臨界區(qū)是保護(hù)共享資源的核心手段，但濫用臨界區(qū)，比不用臨界區(qū)的后果更嚴(yán)重：

常見解決辦法：

• 臨界區(qū)最小化原則，臨界區(qū)內(nèi)只做共享資源的讀寫操作，絕對(duì)不能放任何耗時(shí)運(yùn)算、外設(shè)訪問、阻塞式 API 調(diào)用，執(zhí)行時(shí)間控制在微秒級(jí)。
• 只有任務(wù)和中斷都會(huì)訪問的共享資源，才需要用關(guān)中斷的臨界區(qū)；僅多個(gè)任務(wù)之間訪問的共享資源，用互斥鎖即可，不要隨便關(guān)中斷、關(guān)調(diào)度。
• 必須使用 RTOS 內(nèi)核提供的標(biāo)準(zhǔn)臨界區(qū)宏（比如 FreeRTOS 的taskENTER_CRITICAL()/taskEXIT_CRITICAL()），不要自己手動(dòng)開關(guān)中斷，內(nèi)核宏會(huì)自動(dòng)處理臨界區(qū)嵌套問題，避免出錯(cuò)。
• 關(guān)中斷的臨界區(qū)，必須嚴(yán)格控制執(zhí)行時(shí)長(zhǎng)，對(duì)于車規(guī)、工業(yè)控制類產(chǎn)品，建議關(guān)中斷的最大時(shí)長(zhǎng)不超過 10us，絕對(duì)不能超過中斷的最小觸發(fā)周期。

早年做智能家居項(xiàng)目時(shí)，多個(gè)任務(wù)通過全局變量傳遞設(shè)備狀態(tài)，加了 volatile 關(guān)鍵字，結(jié)果出現(xiàn)了狀態(tài)邏輯錯(cuò)亂，明明任務(wù) A 已經(jīng)把狀態(tài)改成了運(yùn)行態(tài)，任務(wù) B 讀到的還是待機(jī)態(tài)，甚至出現(xiàn)了從未定義過的狀態(tài)值。排查發(fā)現(xiàn)，32 位 MCU 上對(duì) 64 位的時(shí)間戳變量的讀寫不是原子操作，任務(wù)切換發(fā)生在讀寫的中間，導(dǎo)致數(shù)據(jù)被撕成兩半，出現(xiàn)了臟數(shù)據(jù)。

這是嵌入式工程師最容易陷入的認(rèn)知誤區(qū)：volatile 根本不能解決多任務(wù)的線程安全問題，更不能用來做任務(wù)間同步。

點(diǎn)擊閱讀原文，更精彩~