簡介面向嵌入式開發(fā)者的 S32K144 在 FreeRTOS 下串口輸出工程資源包重點(diǎn)解決實(shí)時(shí)操作系統(tǒng)環(huán)境中串口驅(qū)動(dòng)配置、任務(wù)間通信與中斷處理三者協(xié)同的問題適用于汽車電子、工業(yè)控制等對多任務(wù)響應(yīng)有要求的開發(fā)場景。壓縮包共 383 個(gè)文件大小 21.34MB除 C 與頭文件源碼外還包含 makefile 等構(gòu)建配置以及編譯生成的 elf、map 文件和 IDE 調(diào)試設(shè)置便于直接導(dǎo)入、重新構(gòu)建并燒錄驗(yàn)證。工程內(nèi)配置文件、串口驅(qū)動(dòng)、任務(wù)模塊、主入口劃分清晰配置了隊(duì)列傳遞機(jī)制和串口中斷服務(wù)程序并涉及 LPUART、EDMA、時(shí)鐘等外設(shè)參數(shù)示范了中斷服務(wù)程序保持精簡、快速將數(shù)據(jù)放入隊(duì)列、再由專門任務(wù)集中發(fā)送的典型寫法有助于理解實(shí)時(shí)系統(tǒng)中如何保證數(shù)據(jù)安全傳輸。目前已有 1033 人學(xué)習(xí)適合正在研究 S32K144 與 FreeRTOS 串口通信的嵌入式開發(fā)者參考和二次開發(fā)。 S32K144這顆芯片在車載電子和工業(yè)控制里出現(xiàn)的頻率非常高ARM Cortex-M4F內(nèi)核主頻最高可以跑到112MHz片上集成了LPUART、FlexIO、CAN、ADC這些常用外設(shè)還帶溫度等級高、安全特性齊的優(yōu)勢所以不少長期運(yùn)行的采集類、控制類產(chǎn)品都拿它做主控。而FreeRTOS又是“裸機(jī)轉(zhuǎn)系統(tǒng)”的第一站項(xiàng)目從輪詢轉(zhuǎn)向多任務(wù)之后我發(fā)現(xiàn)最基礎(chǔ)也最容易被坑的就是串口輸出裸機(jī)時(shí)往里寫寄存器就行上了系統(tǒng)之后事情就完全不一樣了串口要面對多任務(wù)并發(fā)、中斷搶占、堆棧消耗這些新問題。前陣子我正好在做一臺便攜式數(shù)據(jù)記錄儀主控就是S32K144FreeRTOS跑三個(gè)任務(wù)一個(gè)做CAN數(shù)據(jù)采集一個(gè)做按鍵和狀態(tài)管理還有一個(gè)專門管串口日志輸出。做的時(shí)候踩了不少坑從串口亂碼到任務(wù)堆棧爆掉再到中斷里調(diào)FreeRTOS API觸發(fā)硬錯(cuò)誤基本都遇到過。這篇文章就把整個(gè)實(shí)現(xiàn)過程從FreeRTOS移植到LPUART驅(qū)動(dòng)再到任務(wù)層設(shè)計(jì)、常見問題排查按實(shí)際開發(fā)順序整理出來希望對正在做S32K144FreeRTOS串口輸出的朋友有參考價(jià)值。1. 為什么S32K144FreeRTOS的串口輸出值得單獨(dú)寫一篇1.1 這個(gè)項(xiàng)目到底要解決什么這個(gè)項(xiàng)目的核心需求很直接S32K144上跑FreeRTOS把系統(tǒng)里的運(yùn)行狀態(tài)、調(diào)試日志、數(shù)據(jù)采樣結(jié)果通過串口穩(wěn)定輸出到上位機(jī)。聽起來就是個(gè)“printf移植”的活兒但你真的上手做就會發(fā)現(xiàn)問題被低估了。先說裸機(jī)和系統(tǒng)下的區(qū)別。裸機(jī)時(shí)代串口輸出是一個(gè)順序執(zhí)行的函數(shù)調(diào)用UART_SendBlocking數(shù)據(jù)發(fā)完再返回前后邏輯不會打架。但到了FreeRTOS里多個(gè)任務(wù)可能同時(shí)想打印日志如果每個(gè)任務(wù)都直接操作UART外設(shè)兩個(gè)任務(wù)互相打斷數(shù)據(jù)就會交叉錯(cuò)亂。再加上中斷服務(wù)程序里也可能有日志需求比如CAN接收中斷要把一幀報(bào)文轉(zhuǎn)發(fā)出來這時(shí)的并發(fā)性就更復(fù)雜了。再一個(gè)棘手的問題是實(shí)時(shí)性。數(shù)據(jù)采集任務(wù)的周期是毫秒級的如果日志輸出任務(wù)占著串口不放或者串口中斷優(yōu)先級設(shè)置不對就可能反過來拖累采集任務(wù)造成任務(wù)超時(shí)。所以這個(gè)項(xiàng)目本質(zhì)上是要解決三件事多任務(wù)并發(fā)下串口資源的互斥訪問、中斷安全的日志輸出路徑、以及不讓日志拖垮系統(tǒng)實(shí)時(shí)性的調(diào)度設(shè)計(jì)。1.2 整體架構(gòu)怎么分層我最終的方案是把串口輸出分成四層每一層只干一件事外設(shè)層LPUART1的初始化配置引腳、波特率、中斷、FIFO這層只和硬件寄存器打交道。驅(qū)動(dòng)層維護(hù)一個(gè)環(huán)形緩沖區(qū)負(fù)責(zé)中斷接收和發(fā)送提供最底層的字節(jié)讀寫接口。同步層利用FreeRTOS的隊(duì)列把“任務(wù)產(chǎn)生的日志數(shù)據(jù)”和“串口驅(qū)動(dòng)實(shí)際發(fā)送”解耦日志數(shù)據(jù)進(jìn)隊(duì)列發(fā)送任務(wù)從隊(duì)列取數(shù)據(jù)。應(yīng)用層不同的業(yè)務(wù)任務(wù)調(diào)用一個(gè)統(tǒng)一的日志接口比如LOG_INFO、LOG_ERR不需要關(guān)心串口怎么發(fā)出去的。這個(gè)分層思路來自一個(gè)樸素的經(jīng)驗(yàn)串口是一個(gè)共享慢速外設(shè)而日志產(chǎn)生是隨機(jī)的、多源的中間必須有一個(gè)緩沖和解耦的環(huán)節(jié)。如果不做分層直接在業(yè)務(wù)任務(wù)里操作UART寄存器代碼寫起來快但后續(xù)每加一個(gè)任務(wù)都要處理鎖和互斥遲早會出事。2. 把FreeRTOS跑起來比想象的麻煩一點(diǎn)2.1 移植方式選擇SDK集成還是手動(dòng)加入源碼S32K144移植FreeRTOS有兩條路可以走。一條是用NXP官方的S32 Design Studio配合S32 SDK直接生成帶FreeRTOS的工程模板另一條是手動(dòng)下載FreeRTOS源碼復(fù)制到自己的工程里配置編譯路徑。兩條路我都試過說一下各自的特點(diǎn)。官方SDK集成方式的優(yōu)勢是省事SDK里已經(jīng)把FreeRTOS的端口層代碼portable目錄下的GCC/ARM_CM4F都適配好了只需要在組件配置里勾選FreeRTOS然后重新生成代碼即可。S32 Design Studio的流程一般是新建S32DS工程時(shí)選擇FreeRTOS組件或者之后在SDK組件管理器里添加。它自動(dòng)會引入libFreeRTOS.a或者源碼文件同時(shí)把FreeRTOSConfig.h放到生成目錄里。手動(dòng)添加源碼的方式更透明適合需要精準(zhǔn)控制FreeRTOS版本、常量配置的場合。手動(dòng)添加時(shí)需要把FreeRTOS源碼里的這些目錄和文件加進(jìn)工程核心源碼tasks.c、queue.c、list.c、timers.c、event_groups.c、croutine.c用不到也可以不加內(nèi)存管理portable/MemMang/heap_4.c我推薦直接用heap_4支持合并碎片比heap_1靈活移植層portable/GCC/ARM_CM4F/port.c和portmacro.h頭文件路徑include/目錄和對應(yīng)的portable目錄如果你之前做過STM32的FreeRTOS移植會發(fā)現(xiàn)S32K144的流程很相似核心就是確認(rèn)好編譯器和架構(gòu)匹配的port層。2.2 解決“#include freertos/FreeRTOS.h 檢測到錯(cuò)誤”這個(gè)報(bào)錯(cuò)在開發(fā)時(shí)幾乎一定會遇到。我的經(jīng)驗(yàn)是分兩種情況處理。第一種是編譯錯(cuò)誤也就是編譯器真的找不到FreeRTOS.h。原因多半是頭文件路徑?jīng)]加全或者路徑寫錯(cuò)了。解決方法是把FreeRTOS源碼的include目錄、portable/GCC/ARM_CM4F目錄、以及包含F(xiàn)reeRTOSConfig.h的目錄全部加到工程的Include Paths里。注意S32K144的FreeRTOSConfig.h可能在多個(gè)地方比如config_files目錄或者根目錄別漏了放配置文件的那個(gè)路徑。第二種是IDE的IntelliSense報(bào)錯(cuò)實(shí)際編譯是過的。這在使用VS Code配合Eclipse插件、或者Keil的代碼分析功能時(shí)很常見。因?yàn)镮DE的代碼分析器依賴的是compile_commands.json或者工程的include路徑配置跟編譯器實(shí)際用的路徑可能不一致。處理方式也很直接要么耐心把IDE的include路徑配全要么直接以“實(shí)際編譯結(jié)果”為準(zhǔn)紅波浪線只要不影響編譯可以暫時(shí)忽略。真正要警惕的是“假報(bào)錯(cuò)”把真報(bào)錯(cuò)掩蓋了所以遇到紅波浪線先看是IntelliSense還是build窗口的輸出這個(gè)一定要區(qū)分清楚。另外FreeRTOS內(nèi)核頭文件的引用有兩種風(fēng)格一種是#include FreeRTOS.h一種是#include freertos/FreeRTOS.h取決于你把源碼放到工程里的目錄結(jié)構(gòu)。建議都統(tǒng)一用小寫freertos/子目錄的方式管理保持工程整潔也方便VS Code的智能提示。2.3 FreeRTOSConfig.h幾個(gè)必須改動(dòng)的參數(shù)FreeRTOS能跑起來幾個(gè)關(guān)鍵配置參數(shù)必須先和芯片時(shí)鐘匹配上。下面是針對S32K144典型80MHz主頻的配置參考#define configUSE_PREEMPTION 1 #define configUSE_IDLE_HOOK 1 #define configUSE_TICK_HOOK 0 #define configCPU_CLOCK_HZ ( ( unsigned long ) 80000000 ) #define configTICK_RATE_HZ ( ( TickType_t ) 1000 ) #define configMINIMAL_STACK_SIZE ( ( unsigned short ) 128 ) #define configTOTAL_HEAP_SIZE ( ( size_t ) ( 20 * 1024 ) ) #define configMAX_TASK_NAME_LEN ( 16 ) #define configUSE_16_BIT_TICKS 0 #define configIDLE_SHOULD_YIELD 1 #define configUSE_MUTEXES 1 #define configUSE_RECURSIVE_MUTEXES 0 #define configUSE_COUNTING_SEMAPHORES 1 #define configUSE_TRACE_FACILITY 1 #define configUSE_STACK_OVERFLOW_CHECK 2 #define configMAX_PRIORITIES ( 5 ) #define configMAX_SYSCALL_INTERRUPT_PRIORITY ( 5 )這里有幾個(gè)地方要專門解釋一下。configCPU_CLOCK_HZ必須和你實(shí)際配給S32K144核心的時(shí)鐘一致如果時(shí)鐘實(shí)際是80MHz但這里寫112MHz所有和時(shí)間相關(guān)的延時(shí)、超時(shí)邏輯都會偏掉。configTICK_RATE_HZ我習(xí)慣用1000Hz也就是1ms一個(gè)tick做日志時(shí)間戳精度夠用同時(shí)任務(wù)調(diào)度的開銷也合理。configTOTAL_HEAP_SIZE給到20KB對于我這個(gè)三個(gè)任務(wù)加隊(duì)列的規(guī)模綽綽有余但如果你后面要加lwIP或者FatFS建議提到40KB以上。還有configMAX_SYSCALL_INTERRUPT_PRIORITY這個(gè)值和中斷安全API密切相關(guān)后面第三節(jié)講UART中斷時(shí)會細(xì)說。我的經(jīng)驗(yàn)是在S32K144上如果這個(gè)優(yōu)先級配置不對FreeRTOS的API在中斷里調(diào)用時(shí)會在configASSERT處直接崩掉而且崩得毫無征兆。3. 串口驅(qū)動(dòng)層你的數(shù)據(jù)要走的路3.1 LPUART初始化與引腳復(fù)用S32K144上串口外設(shè)叫LPUART支持低功耗模式常用的有LPUART0和LPUART1。我這個(gè)項(xiàng)目用的是LPUART1引腳選PTB0和PTB1對應(yīng)的是UART1_TX和UART1_RX功能。引腳不是隨便選的要查S32K144參考手冊的Pin Mux表確認(rèn)復(fù)用功能編號。這里我選了ALT2功能。初始化的核心代碼如下簡化掉了一些狀態(tài)檢查和錯(cuò)誤處理void LPUART1_Init(uint32_t baudrate) { /* 1. 打開PORTB時(shí)鐘和LPUART1時(shí)鐘 */ PCC-PCCn[PCC_PORTB_INDEX] | PCC_PCCn_CGC_MASK; PCC-PCCn[PCC_LPUART1_INDEX] | PCC_PCCn_CGC_MASK; /* 2. 配置引腳復(fù)用為LPUART1 */ PORTB-PCR[0] | PORT_PCR_MUX(2); /* PTB0 - UART1_TX */ PORTB-PCR[1] | PORT_PCR_MUX(2); /* PTB1 - UART1_RX */ /* 3. 復(fù)位LPUART并配置 */ LPUART1-GLOBAL | LPUART_GLOBAL_RST_MASK; LPUART1-GLOBAL ~LPUART_GLOBAL_RST_MASK; /* 4. 8位數(shù)據(jù)、無校驗(yàn)、1位停止位 */ LPUART1-CTRL LPUART_CTRL_M_MASK; LPUART1-BAUD LPUART_BAUD_OSR(15) | LPUART_BAUD_SBR(baud_div); /* 5. 使能發(fā)送、接收和中斷 */ LPUART1-CTRL | LPUART_CTRL_RIE_MASK | LPUART_CTRL_TIE_MASK; LPUART1-CTRL | LPUART_CTRL_RE_MASK | LPUART_CTRL_TE_MASK; }波特率分頻值baud_div的計(jì)算有個(gè)公式分頻值 外設(shè)時(shí)鐘頻率 / (波特率 × 過采樣率)。我配置的LPUART1外設(shè)時(shí)鐘是8MHz過采樣率OSR選15波特率115200那么SBR 8000000 / (115200 × 16) ≈ 4.34向上取整到4實(shí)際波特率會有一點(diǎn)偏差但在允許范圍內(nèi)。如果你發(fā)現(xiàn)串口數(shù)據(jù)亂碼先別急著懷疑線接錯(cuò)了大概率是這個(gè)分頻值沒算對或者外設(shè)時(shí)鐘和你以為的不一致。3.2 環(huán)形緩沖區(qū)串口驅(qū)動(dòng)的靈魂串口驅(qū)動(dòng)層我強(qiáng)烈建議搞一個(gè)環(huán)形緩沖區(qū)不要用裸的數(shù)組加標(biāo)志位。環(huán)形緩沖區(qū)的好處是讀寫可以分離生產(chǎn)者和消費(fèi)者各自維護(hù)自己的索引在單生產(chǎn)者單消費(fèi)者的場景下甚至不需要關(guān)閉中斷就能安全操作。一個(gè)典型的串口環(huán)形緩沖結(jié)構(gòu)長這樣#define UART_RX_BUF_SIZE 512 #define UART_TX_BUF_SIZE 512 typedef struct { uint8_t buffer[UART_TX_BUF_SIZE]; volatile uint16_t head; volatile uint16_t tail; } ring_buffer_t; static ring_buffer_t g_txRing;head是寫入位置tail是讀出位置。寫入時(shí)往head處放數(shù)據(jù)然后head加一讀取時(shí)從tail處取數(shù)據(jù)tail加一。遇到末尾就回繞到0。判斷緩沖區(qū)滿不滿、空不空直接比較兩個(gè)索引就行。在我這個(gè)驅(qū)動(dòng)里業(yè)務(wù)任務(wù)不是直接調(diào)用底層寫函數(shù)而是調(diào)用一個(gè)帶超時(shí)的投遞接口bool UART_TransmitRing(uint8_t *data, uint16_t len, uint32_t timeout_ms) { /* 遍歷數(shù)據(jù)逐字節(jié)寫入環(huán)形緩沖 */ for (uint16_t i 0; i len; i) { uint32_t t0 xTaskGetTickCount(); while (Ring_IsFull(g_txRing)) { /* 如果TX中斷使能ISR會自動(dòng)取走數(shù)據(jù)并發(fā)送 */ if ((xTaskGetTickCount() - t0) pdMS_TO_TICKS(timeout_ms)) { return false; } } Ring_Write(g_txRing, data[i]); /* 觸發(fā)發(fā)送寫數(shù)據(jù)寄存器使能TX中斷 */ LPUART1-DATA data[i]; LPUART1-CTRL | LPUART_CTRL_TIE_MASK; } return true; }注意這里用到了xTaskGetTickCount來判斷超時(shí)所以這個(gè)函數(shù)只能在任務(wù)上下文調(diào)用不能在中斷里用中斷里要用另一個(gè)專用接口。3.3 中斷ISR與FreeRTOS安全API的邊界LPUART1的中斷服務(wù)函數(shù)里要做的事情很明確接收中斷就讀取數(shù)據(jù)寄存器把字節(jié)存進(jìn)RX環(huán)形緩沖并且可以用xStreamBufferSendFromISR或者xQueueSendFromISR把這個(gè)字節(jié)投遞給上層處理任務(wù)發(fā)送中斷就檢查TX環(huán)形緩沖是否有待發(fā)數(shù)據(jù)有就繼續(xù)發(fā)沒有就關(guān)閉發(fā)送中斷。這里有兩個(gè)非常關(guān)鍵的FreeRTOS規(guī)則要記住。第一ISR里調(diào)用的FreeRTOS API必須使用帶FromISR后綴的版本比如xQueueSendFromISR替代xQueueSend。第二ISR的優(yōu)先級不能高于configMAX_SYSCALL_INTERRUPT_PRIORITY對應(yīng)的值否則這些帶FromISR的API也白搭。在我這個(gè)S32K144工程里NVIC里設(shè)置LPUART1中斷優(yōu)先級為5而FreeRTOS的configMAX_SYSCALL_INTERRUPT_PRIORITY是5configPRIO_BITS是4這樣中斷優(yōu)先級數(shù)值大于等于5的都允許調(diào)用FreeRTOS API。如果LPUART中斷優(yōu)先級設(shè)成了0到4那ISR里絕對不能調(diào)用FreeRTOS函數(shù)否則進(jìn)入臨界區(qū)時(shí)會出問題表現(xiàn)就是程序卡死或者進(jìn)HardFault。4. 任務(wù)層設(shè)計(jì)串口輸出不要裸著寫4.1 基于隊(duì)列的串口輸出任務(wù)驅(qū)動(dòng)層就位之后應(yīng)用層要做的就不是直接調(diào)UART_TransmitRing了而是設(shè)計(jì)一個(gè)專門的串口輸出任務(wù)。這個(gè)任務(wù)的功能是從FreeRTOS隊(duì)列里取日志消息然后調(diào)用驅(qū)動(dòng)層接口發(fā)送。我的日志發(fā)送任務(wù)這樣寫的typedef struct { uint8_t data[128]; uint16_t len; } log_msg_t; static QueueHandle_t g_logQueue; void vUartOutputTask(void *pvParameters) { log_msg_t msg; for (;;) { if (xQueueReceive(g_logQueue, msg, portMAX_DELAY) pdTRUE) { UART_TransmitRing(msg.data, msg.len, 50); } } } void UART_Log(const char *fmt, ...) { log_msg_t msg; va_list args; va_start(args, fmt); msg.len vsnprintf((char *)msg.data, sizeof(msg.data), fmt, args); va_end(args); if (msg.len sizeof(msg.data)) { msg.len sizeof(msg.data); } xQueueSend(g_logQueue, msg, 0); }這個(gè)設(shè)計(jì)核心的好處是解耦。業(yè)務(wù)任務(wù)調(diào)用UART_Log只做兩件事格式化字符串、把數(shù)據(jù)塞進(jìn)隊(duì)列然后就返回了。真正的串口發(fā)送動(dòng)作由vUartOutputTask統(tǒng)一處理。這樣即使某個(gè)業(yè)務(wù)任務(wù)的優(yōu)先級很高也不會因?yàn)榇诎l(fā)送慢而長時(shí)間阻塞自己。隊(duì)列元素大小我定的是128字節(jié)如果你日志內(nèi)容經(jīng)常超過128字節(jié)記得加大否則vsnprintf會截?cái)?。?duì)列深度我設(shè)了8夠用。還要注意vsnprintf比較吃棧這個(gè)任務(wù)創(chuàng)建時(shí)的棧大小我給到了512字words低于這個(gè)值在格式化復(fù)雜字符串時(shí)可能會棧溢出。4.2 任務(wù)優(yōu)先級怎么排才穩(wěn)FreeRTOS里優(yōu)先級數(shù)值越大優(yōu)先級越高。我這個(gè)項(xiàng)目的任務(wù)優(yōu)先級分配是CAN采集任務(wù)優(yōu)先級3串口輸出任務(wù)優(yōu)先級2按鍵處理任務(wù)優(yōu)先級1空閑任務(wù)優(yōu)先級0。串口輸出任務(wù)優(yōu)先級不是越高越好。如果把它設(shè)得比CAN采集任務(wù)還高當(dāng)CAN總線報(bào)文量大時(shí)采集任務(wù)可能發(fā)現(xiàn)自己的發(fā)送隊(duì)列滿了但還沒被及時(shí)處理。反過來串口輸出任務(wù)又是日志通道優(yōu)先級太低會導(dǎo)致日志積壓緩沖區(qū)滿了以后新的日志會被丟棄。我的經(jīng)驗(yàn)是日志輸出任務(wù)比最高優(yōu)先級的業(yè)務(wù)任務(wù)低一級并且日志量再大也不能讓日志任務(wù)搶占關(guān)鍵采集任務(wù)的執(zhí)行。另外日志任務(wù)創(chuàng)建時(shí)的堆棧大小要專門注意。日志任務(wù)不僅要跑操作系統(tǒng)的調(diào)度邏輯還要跑vsnprintf這種重量級格式化函數(shù)。如果你在任務(wù)里調(diào)用UART_Log其實(shí)格式化是在業(yè)務(wù)任務(wù)里做的那業(yè)務(wù)任務(wù)的棧也要相應(yīng)加大。比如我的CAN采集任務(wù)棧設(shè)置的是512字就是因?yàn)槔锩嬗昧艘淮蜺ART_Log輸出一行十六進(jìn)制數(shù)據(jù)。4.3 堆池和?？臻g的規(guī)劃思路FreeRTOS的內(nèi)存管理我用的是heap_4方案configTOTAL_HEAP_SIZE配置了20KB。堆池大小規(guī)劃時(shí)要把任務(wù)棧、隊(duì)列、信號量、互斥量、事件組等等對象全算進(jìn)去。一個(gè)粗算公式是堆總需求 各任務(wù)棧大小之和 隊(duì)列存儲區(qū)大小之和 內(nèi)核對象大小之和。拿我這個(gè)項(xiàng)目舉例三個(gè)任務(wù)棧分別是512、512、256字1個(gè)字在CM4F上是4字節(jié)那就是(512512256)×4 5120字節(jié)。日志隊(duì)列8個(gè)元素每個(gè)128字節(jié)隊(duì)列存儲區(qū)就是8×128 1024字節(jié)。加上內(nèi)核對象和TLS、TCB的開銷20KB堆池完全夠用還留了不少余量。驗(yàn)證方法是在初始化完成后打印xPortGetFreeHeapSize()如果剩余空間過小說明堆池配得太緊。另外建議開啟configUSE_TRACE_FACILITY之后可以在調(diào)試時(shí)用uxTaskGetSystemState()查看各任務(wù)的棧高水位線這個(gè)數(shù)值能告訴你每個(gè)任務(wù)實(shí)際使用了多少?？臻g方便優(yōu)化。5. 穩(wěn)定性排查與實(shí)踐經(jīng)驗(yàn)匯總5.1 開啟棧溢出檢測別等崩潰才后悔FreeRTOS提供了兩種棧溢出檢測模式在configUSE_STACK_OVERFLOW_CHECK里配置為1或者2。模式1在任務(wù)切換時(shí)檢查棧指針是否越界模式2還會額外在任務(wù)棧底部寫入一個(gè)固定標(biāo)記每次切換時(shí)檢查這個(gè)標(biāo)記是否被覆蓋。模式2更嚴(yán)格能更早發(fā)現(xiàn)棧溢出但會稍微增加上下文切換開銷。我在調(diào)試階段用的是模式2上線前如果確認(rèn)棧余量充足可以改回模式1減少開銷。無論是哪個(gè)模式都要實(shí)現(xiàn)vApplicationStackOverflowHook函數(shù)棧溢出時(shí)系統(tǒng)會調(diào)用這個(gè)鉤子。這個(gè)函數(shù)里我習(xí)慣放一個(gè)串口緊急輸出和死循環(huán)方便接調(diào)試器看現(xiàn)場void vApplicationStackOverflowHook(TaskHandle_t xTask, char *pcTaskName) { UART_TransmitBlocking((uint8_t *)STACK OVERFLOW: , 16); UART_TransmitBlocking((uint8_t *)pcTaskName, strlen(pcTaskName)); for (;;); }實(shí)際使用中最容易棧溢出的兩個(gè)點(diǎn)任務(wù)里用大局部數(shù)組比如uint8_t buf[512]這種任務(wù)里調(diào)用printf系列函數(shù)特別是%f浮點(diǎn)格式化非常耗棧。如果你發(fā)現(xiàn)串口輸出偶爾亂碼、任務(wù)莫名消失、系統(tǒng)進(jìn)入HardFault優(yōu)先懷疑棧溢出。5.2 串口資源互斥互斥量比二值信號量更適合回到最開始說的多任務(wù)并發(fā)問題。如果兩個(gè)業(yè)務(wù)任務(wù)同時(shí)調(diào)用UART_Log即使有隊(duì)列緩沖也可能出現(xiàn)日志順序錯(cuò)亂的問題。其實(shí)隊(duì)列本身就是一種天然的消息互斥機(jī)制但如果你要在一個(gè)任務(wù)里連續(xù)輸出多行日志比如打印一個(gè)完整的數(shù)據(jù)幀不希望中間被其他任務(wù)插一腳那就需要互斥量來保護(hù)這次打印的原子性。FreeRTOS的互斥量Mutex和二值信號量的一個(gè)關(guān)鍵區(qū)別是互斥量支持優(yōu)先級繼承。當(dāng)?shù)蛢?yōu)先級任務(wù)持有互斥量時(shí)如果有高優(yōu)先級任務(wù)來等這個(gè)互斥量內(nèi)核會臨時(shí)把低優(yōu)先級任務(wù)的優(yōu)先級提升到等高優(yōu)先級同級等釋放互斥量后再降回來。這能有效避免優(yōu)先級反轉(zhuǎn)問題。舉一個(gè)我實(shí)際踩過的坑三個(gè)任務(wù)都往串口寫日志一開始我用的是二值信號量保護(hù)結(jié)果高優(yōu)先級的CAN任務(wù)經(jīng)常等很久才拿到信號量因?yàn)橹袃?yōu)先級的顯示任務(wù)一直在運(yùn)行它雖然沒有信號量但不斷搶占CPU導(dǎo)致低優(yōu)先級日志任務(wù)沒法釋放信號量。換成互斥量之后優(yōu)先級繼承機(jī)制讓低優(yōu)先級任務(wù)在CAN任務(wù)等待期間臨時(shí)獲得了更高的優(yōu)先級這個(gè)問題就消失了。所以在共享串口這類資源互斥場景下優(yōu)先選互斥量而不是二值信號量。5.3 常見問題速查表最后把這個(gè)項(xiàng)目里遇到過的典型問題和排查思路整理成一個(gè)速查表方便大家直接對應(yīng)排查?，F(xiàn)象最可能的原因排查和解決辦法串口完全無輸出LPUART時(shí)鐘沒開或引腳復(fù)用錯(cuò)檢查PCC時(shí)鐘門控、PORTx_PCR[n]的MUX值是否選對輸出亂碼波特率分頻值錯(cuò)誤或晶振/時(shí)鐘源不匹配核對SBR計(jì)算用邏輯分析儀測實(shí)際波特率輸出丟字節(jié)發(fā)送緩沖滿后業(yè)務(wù)任務(wù)超時(shí)放棄加大環(huán)形緩沖、加長超時(shí)時(shí)間或降低日志頻率任務(wù)跑著跑著消失任務(wù)堆棧溢出開棧溢出檢測模式2查看棧高水位線進(jìn)HardFault中斷里調(diào)用非FromISR的API或中斷優(yōu)先級過高ISR里只用帶FromISR后綴的API將中斷優(yōu)先級設(shè)為不低于configMAX_SYSCALL_INTERRUPT_PRIORITY#include freertos/FreeRTOS.h報(bào)錯(cuò)頭文件路徑?jīng)]配全確認(rèn)include目錄、portable目錄、FreeRTOSConfig.h目錄都在Include Paths里日志順序錯(cuò)亂多任務(wù)并發(fā)打印沒有互斥保護(hù)使用互斥量對關(guān)鍵日志段進(jìn)行原子保護(hù)堆內(nèi)存不足任務(wù)創(chuàng)建失敗configTOTAL_HEAP_SIZE偏小打印xPortGetFreeHeapSize確認(rèn)剩余量必要時(shí)加大堆池串口輸出影響采集實(shí)時(shí)性日志任務(wù)優(yōu)先級設(shè)置過高將日志任務(wù)優(yōu)先級設(shè)為比關(guān)鍵采集任務(wù)低一級還有兩個(gè)我特別想強(qiáng)調(diào)的實(shí)操細(xì)節(jié)。第一調(diào)試時(shí)不要把串口發(fā)送做成無限阻塞等待否則某個(gè)調(diào)試把日志打滿、TX FIFO滿的時(shí)候整個(gè)系統(tǒng)會被拖住。所有發(fā)送接口都要設(shè)計(jì)超時(shí)超時(shí)就應(yīng)該返回錯(cuò)誤。第二如果使用VS Code做代碼編輯編譯路徑里的compile_commands.json一定要記得在工程結(jié)構(gòu)變化后重新生成否則那種“代碼分析器和編譯器路徑不一致”的假報(bào)錯(cuò)會一直煩你真正的編譯錯(cuò)誤反而容易被忽略。說實(shí)話S32K144的LPUART和FreeRTOS的組合不算復(fù)雜但坑都是埋在細(xì)節(jié)里的。項(xiàng)目做完之后最大的感受是串口輸出這件事千萬不要把它當(dāng)作“printf移植”那么簡單來對待。它其實(shí)是整個(gè)系統(tǒng)調(diào)試的基石驅(qū)動(dòng)物理層做好環(huán)形緩沖系統(tǒng)層選好隊(duì)列和互斥機(jī)制任務(wù)層規(guī)劃好優(yōu)先級和棧空間這三個(gè)環(huán)節(jié)都做到位了后面的調(diào)試工作才會真正順起來。希望這篇整理能幫大家少走點(diǎn)彎路。本文還有配套的精品資源點(diǎn)擊獲取