簡介本資源是面向嵌入式開發(fā)工程師與TI單片機進階學(xué)習(xí)者的FreeRTOSLwIP雙棧移植實踐工程聚焦TM4C1294XL微控制器平臺解決RTOS與TCP/IP協(xié)議棧協(xié)同運行的核心技術(shù)難點。壓縮包含502個文件以203個頭文件h和149個源文件c為主體涵蓋FreeRTOS內(nèi)核配置、LwIP網(wǎng)絡(luò)驅(qū)動如enet_s2e.c、emac.c、USB與以太網(wǎng)外設(shè)適配代碼另有32個IAR工程配置文件xcl、24個編譯目標(biāo)文件o及多個調(diào)試腳本bat/ps1和工程文件ewp/uvproj整體9.89MB結(jié)構(gòu)完整、可直接構(gòu)建調(diào)試。已有271人學(xué)習(xí)下載資源提供可運行的完整工程框架包含driverlib.a庫支持、多任務(wù)調(diào)度示例、LwIP與FreeRTOS同步機制信號量/隊列、EMAC硬件抽象層實現(xiàn)及詳細(xì)browse/pbd調(diào)試信息顯著降低網(wǎng)絡(luò)化嵌入式系統(tǒng)開發(fā)門檻。 幾個月前我拿到一塊新的 EK-TM4C1294XL LaunchPad準(zhǔn)備做一個基于 FreeRTOS 多線程架構(gòu)的采集網(wǎng)關(guān)。應(yīng)用場景很直接現(xiàn)場 CAN 總線的數(shù)據(jù)、模擬量傳感器信號統(tǒng)一采集之后通過 10/100M 以太網(wǎng)接入后臺。工程代號我起了一個比較隨意的名字repeatxdn。整套軟件棧選型也很常規(guī)——RTOS 用 FreeRTOS網(wǎng)絡(luò)協(xié)議棧用 LwIP芯片用 TM4C1294XL。真正折騰人的不是單個組件怎么跑而是三個東西組合在一起之后線程、中斷、協(xié)議棧、驅(qū)動之間的資源爭用和時序問題。這個組合在嵌入式圈子里非常經(jīng)典TM4C1294 自帶以太網(wǎng) MAC 和內(nèi)部 PHY省掉外掛 PHY 的物料成本和布線麻煩FreeRTOS 提供搶占式多任務(wù)調(diào)度適合把采集、處理、網(wǎng)絡(luò)上報拆成多個職責(zé)獨立的線程LwIP 則是嵌入式中最常用的輕量級 TCP/IP 協(xié)議棧。對于做工業(yè)數(shù)據(jù)采集、邊緣網(wǎng)關(guān)、物聯(lián)網(wǎng)設(shè)備的開發(fā)者來說這套方案完全可以當(dāng)成一個可復(fù)用的參考模板。下面我把從零搭建到穩(wěn)定性調(diào)優(yōu)的完整過程寫出來包括移植配置、任務(wù)劃分、LwIP 對接以及我在線程死鎖和堆棧溢出上踩過的具體坑。無論你是剛接觸 FreeRTOS 的學(xué)生還是在評估 TM4C1294 方案的工程師這篇文章應(yīng)該都能提供一些實在的參考。1. 項目背景與方案選型為什么是這三樣組合1.1 項目原型和需求邊界項目原型是一臺工業(yè)數(shù)據(jù)采集網(wǎng)關(guān)?，F(xiàn)場設(shè)備通過 CAN 總線對外發(fā)送狀態(tài)信息規(guī)劃波特率 500kbps峰值報文量大約 1000 幀/秒另外一路模擬量采樣模塊負(fù)責(zé)采集溫度和電壓采樣周期 100ms板子還保留了一路 UART 作為本地調(diào)試配置口。所有數(shù)據(jù)最終通過以太網(wǎng)上報給上位機要求 TCP 長連接可配置上報周期最低到 10ms。這些需求合在一起光靠一個裸機大循環(huán)已經(jīng)很難寫。原因很簡單CAN 接收是中斷驅(qū)動的中斷來了必須及時讀走 FIFO否則會丟幀模擬量采樣需要周期性觸發(fā)TCP 數(shù)據(jù)發(fā)送又是另一套時序底層網(wǎng)卡還會連續(xù)產(chǎn)生收發(fā)中斷。如果全部擠在同一個循環(huán)里任何一個環(huán)節(jié)處理慢了其他環(huán)節(jié)都會跟著抖。所以這個項目從一開始就需要一個 RTOS 做任務(wù)調(diào)度。這也是標(biāo)題里基于線程這個說法的來源把不同工作拆成獨立線程用優(yōu)先級解決實時性用隊列和信號量解決協(xié)作。1.2 芯片選型TM4C1294XL 能扛住什么TM4C1294XL 這個名字實際上包含兩層意思如果買的是原廠 LaunchPad全稱是 EK-TM4C1294XL板上那顆主控芯片的完整型號是 TM4C1294NCPDT。它基于 ARM Cortex-M4F 內(nèi)核主頻 120MHz帶硬件浮點單元內(nèi)置 256KB SRAM 和 1MB Flash。對于這個量級的采集網(wǎng)關(guān)來說CPU 算力足夠內(nèi)存也不算緊張。真正讓它在我這兒勝出的原因是網(wǎng)絡(luò)接口。TM4C1294 的以太網(wǎng)控制器在芯片內(nèi)部集成了 MAC 和 PHY意味著 MCU 可以直接用 RMII/MII 接口信號外接一個帶隔離變壓器的 RJ45 座子或者使用板載 PHY 方案。而當(dāng)時對比過的其他 M4 方案大多只集成 MAC需要外掛 PHY 芯片BOM 里多一顆物料PCB 布線也多一塊成本其實沒有優(yōu)勢。TivaWare 驅(qū)動庫對這塊芯片的覆蓋也比較完整外設(shè)驅(qū)動、例程、甚至 LwIP 的移植參考都能在官方包里找到。這對快速起步幫助很大很多底層寄存器細(xì)節(jié)不用自己去啃數(shù)據(jù)手冊。1.3 RTOS 和協(xié)議棧選型FreeRTOS 是我這邊唯一考慮過的 RTOS。它開源免費商業(yè)使用沒有授權(quán)費用在工業(yè)設(shè)備里不會有合規(guī)風(fēng)險內(nèi)核本身很小占用幾 KB Flash 就夠社區(qū)資料非常多碰到問題基本都能搜到。任務(wù)調(diào)度、隊列、互斥量、信號量、任務(wù)通知這些基礎(chǔ)件都提供文檔也寫得很清楚。LwIP 是嵌入式領(lǐng)域用得最廣的 TCP/IP 協(xié)議棧之一。它最大的特點是對資源要求控制得比較好支持無操作系統(tǒng)模式和帶操作系統(tǒng)模式。在帶操作系統(tǒng)模式下LwIP 依賴外部提供的互斥量、信號量和郵箱機制來做線程同步這正好能和 FreeRTOS 對應(yīng)上——互斥量對應(yīng) mutex信號量對應(yīng) semaphore郵箱對應(yīng)隊列。后面第 4 章我會詳細(xì)講這條對接鏈路。選型階段也考慮過直接跑 uIP但那個協(xié)議棧功能上比 LwIP 弱不少TCP 會話管理也不夠靈活項目要做 TCP server、UDP 組播設(shè)備發(fā)現(xiàn)還是 LwIP 更合適。2. 內(nèi)核移植配置先把 FreeRTOS 在 TM4C1294XL 上跑穩(wěn)2.1 源碼和工程結(jié)構(gòu)FreeRTOS 當(dāng)前的版本可以從官方 GitHub 倉庫獲取核心源碼集中在 FreeRTOS/Source 目錄下。一個最小可用的內(nèi)核工程至少需要以下文件FreeRTOS/Source/ ├── tasks.c ├── list.c ├── queue.c ├── timers.c ├── event_groups.c ├── croutine.c ├── stream_buffer.c └── portable/ ├── GCC/ARM_CM4F/ # GCC 工具鏈時用 ├── RVDS/ARM_CM4F/ # Keil MDK 時用 └── MemMang/heap_4.c我用的 IDE 是 Keil MDKportable 層選的是 RVDS/ARM_CM4F后來為了調(diào)試方便也切過 GCC 工具鏈。heap 實現(xiàn)我推薦 heap_4.c它支持合并相鄰空閑塊可以比較有效地減少內(nèi)存碎片。當(dāng)然如果你們團隊對內(nèi)存碎片有更嚴(yán)格的把控要求heap_5.c 可以把堆分散到多個不連續(xù)內(nèi)存區(qū)域TM4C1294 的大 SRAM 也能這么玩。最簡單的驗證方式其實是用 TivaWare 自帶的 FreeRTOS 例程起步。TivaWare 安裝目錄下有 examples/boards/ek-tm4c1294xl/freertos_demo 這個工程它已經(jīng)把啟動文件、中斷處理函數(shù)和 FreeRTOSConfig.h 都配置好了在這個基礎(chǔ)上改成自己的工程框架要快很多。但如果你不想用 TivaWare 的舊版 FreeRTOS而是想換成新版內(nèi)核那就需要自己把 portable 層文件替換上去并核對中斷向量表。2.2 FreeRTOSConfig.h 關(guān)鍵配置FreeRTOSConfig.h 是整個內(nèi)核行為的開關(guān)集中地。我給 TM4C1294XL 做配置的時候主要關(guān)注下面這些宏配置宏取值說明configCPU_CLOCK_HZ120000000必須和實際 PLL 輸出主頻一致configTICK_RATE_HZ10001ms 一個系統(tǒng)節(jié)拍任務(wù)調(diào)度和延時更精細(xì)configMAX_PRIORITIES8最多 8 個任務(wù)優(yōu)先級configTOTAL_HEAP_SIZE32 * 1024FreeRTOS 內(nèi)核堆大小單位字節(jié)configUSE_MUTEXES1啟用互斥量帶優(yōu)先級繼承configUSE_COUNTING_SEMAPHORES1啟用計數(shù)信號量configCHECK_FOR_STACK_OVERFLOW2使能棧溢出檢測方式二configUSE_IDLE_HOOK1空閑任務(wù)鉤子用來做低功耗或監(jiān)控configUSE_TICK_HOOK0系統(tǒng)節(jié)拍鉤子需要時再開configMINIMAL_STACK_SIZE128空閑任務(wù)棧大小單位是字WordconfigMAX_SYSCALL_INTERRUPT_PRIORITY5允許調(diào)用 FromISR 系列 API 的最大中斷優(yōu)先級這里有兩個特別容易踩的坑。第一configCPU_CLOCK_HZ 必須和 SysCtlClockFreqSet 得到的系統(tǒng)時鐘一致否則 vTaskDelay 的時間會按錯誤的時鐘頻率計算系統(tǒng)節(jié)拍就漂了。第二TM4C1294 的 NVIC 中斷優(yōu)先級只有高 3 位有效優(yōu)先級實際范圍是 0 到 7數(shù)值越大優(yōu)先級越低。FreeRTOS 要求內(nèi)核使用的 SysTick 和 PendSV 中斷優(yōu)先級必須是最低的所以 configKERNEL_INTERRUPT_PRIORITY 可以配成 255而 configMAX_SYSCALL_INTERRUPT_PRIORITY 配成 5意思是優(yōu)先級數(shù)值大于等于 5 的中斷不能直接調(diào)用 FreeRTOS 的 FromISR 接口。這個規(guī)則直接關(guān)系到后面中斷和線程的數(shù)據(jù)交互需要仔細(xì)核對。2.3 中斷向量和啟動文件Cortex-M4 內(nèi)核有兩個中斷和 FreeRTOS 強相關(guān)PendSV 負(fù)責(zé)上下文切換SysTick 負(fù)責(zé)系統(tǒng)節(jié)拍還有一個 SVC 用于第一任務(wù)啟動。這三個中斷處理函數(shù)必須由 FreeRTOS 的 port 層提供不能被啟動文件里的同名弱定義占用。具體做法是如果使用 Keil需要在 startup_keil.s 或者對應(yīng)的啟動文件里把 SVC_Handler、PendSV_Handler、SysTick_Handler 這三個名字注釋掉或者確認(rèn)它們沒有被定義。FreeRTOS 源碼里的 port 層會重新定義這幾個函數(shù)名如果兩邊重名鏈接時會產(chǎn)生 multiple definition 錯誤。TivaWare 的 freertos_demo 工程里這一點已經(jīng)處理好了可以直接參考它的中斷向量表寫法。2.4 時鐘和外設(shè)初始化TM4C1294 板載晶體是 25MHz和 TM4C123 那類的 16MHz 晶體不一樣初始化 PLL 的時候要特別注意。我使用的是 TivaWare 的 APISysCtlClockFreqSet(SYSCTL_USE_PLL | SYSCTL_OSC_MAIN | SYSCTL_XTAL_25MHZ | SYSCTL_CFG_VCO_480, 120000000);這樣配置之后系統(tǒng)主頻、外設(shè)總線時鐘都會以 120MHz 為基準(zhǔn)后續(xù)配置 UART 波特率、PWM 頻率、定時器周期時都要基于這個值計算。2.5 第一個線程驗證內(nèi)核工程搭建好之后我習(xí)慣先寫一個最小任務(wù)驗證調(diào)度器是否正常工作。最簡單的方式是讓板載 LED 以 500ms 周期翻轉(zhuǎn)void vTaskLed(void *pvParameters) { for (;;) { GPIOPinWrite(GPIO_PORTN_BASE, GPIO_PIN_0, 0); vTaskDelay(pdMS_TO_TICKS(500)); GPIOPinWrite(GPIO_PORTN_BASE, GPIO_PIN_0, GPIO_PIN_0); vTaskDelay(pdMS_TO_TICKS(500)); } }如果 LED 以穩(wěn)定節(jié)奏閃爍說明 SysTick 調(diào)度、上下文切換、PendSV 中斷路徑都正常工作了。這個時候再繼續(xù)往上疊加外設(shè)驅(qū)動和協(xié)議棧排查問題的范圍就會小很多。3. 基于線程的應(yīng)用層設(shè)計任務(wù)劃分與優(yōu)先級調(diào)度3.1 任務(wù)清單標(biāo)題里的基于線程不是單純指系統(tǒng)用了 FreeRTOS而是應(yīng)用層真的按并行思路去拆任務(wù)。我在 repeatxdn 工程里的任務(wù)劃分如下任務(wù)名優(yōu)先級觸發(fā)方式建議棧字職責(zé)can_collect_task4CAN 接收中斷 周期查詢512CAN 報文接收、解析、入隊sensor_task350ms 周期256模擬量采樣、濾波、本地數(shù)據(jù)更新data_proc_task3消息隊列觸發(fā)512融合 CAN 與傳感器數(shù)據(jù)封裝上報幀tcp_server_task2阻塞于 netconn_accept1024TCP 長連接管理、命令接收、數(shù)據(jù)發(fā)送udp_notify_task2500ms 周期512UDP 組播設(shè)備發(fā)現(xiàn)與心跳廣播led_task1500ms 周期128運行狀態(tài)指示燈monitor_task01s 周期256統(tǒng)計任務(wù)棧余量、CPU 占用率我當(dāng)時特意把 can_collect_task 放在最高優(yōu)先級因為 CAN 報文實時性最強晚一點處理就可能被 FIFO 溢出沖掉。tcp_server_task 的棧給到了 1024 字因為 netconn API 調(diào)用路徑的棧深度加上 LwIP 內(nèi)部調(diào)用鏈確實比普通采集任務(wù)深不少如果給太小網(wǎng)絡(luò)任務(wù)容易在調(diào)用 send 的時候莫名崩潰。3.2 優(yōu)先級分配的核心邏輯任務(wù)優(yōu)先級不是隨意定的。我的分配思路是三條線第一離數(shù)據(jù)源頭越近優(yōu)先級越高。CAN 中斷只是把報文從 FIFO 搬到隊列真正的解析工作由 can_collect_task 做這個任務(wù)直接決定數(shù)據(jù)采集的完整性所以優(yōu)先級最高。第二網(wǎng)絡(luò)上報任務(wù)放在中優(yōu)先級。tcpip_thread 和 tcp_server_task 不能開太高否則高頻網(wǎng)絡(luò)中斷和數(shù)據(jù)發(fā)送會擠壓 CAN 的采集時間但也不能太低否則上位機指令響應(yīng)延遲會明顯變大。我把它放在 2 級和 UDP 組播任務(wù)同級靠隊列和信號量保證先后順序。第三監(jiān)控類任務(wù)永遠(yuǎn)放最低優(yōu)先級。monitor_task 只做統(tǒng)計慢一點沒有任何影響?？臻e任務(wù)鉤子里也做了一個輕量級的 CPU 空閑計數(shù)值結(jié)合運行時間統(tǒng)計功能可以算出 CPU 占用率這個在后面第 6 章會提到。3.3 任務(wù)間通信的選型FreeRTOS 里任務(wù)間通信方式有好幾種我根據(jù)自己的場景做了簡單分類隊列適合數(shù)據(jù)流傳遞。CAN 原始報文從采集任務(wù)發(fā)給數(shù)據(jù)處理任務(wù)我用的是一個長度為 64 的隊列上報數(shù)據(jù)從 data_proc_task 發(fā)往 tcp_server_task用的是另一個隊列。二值信號量適合中斷喚醒任務(wù)。ETH 收包中斷里只做一個信號量 give網(wǎng)絡(luò)線程等待這個信號量然后調(diào)用 LwIP 的收包接口?；コ饬窟m合保護共享資源。比如調(diào)試串口、Flash 讀寫這類一個時刻只能一個任務(wù)使用的資源我用互斥量保護還帶優(yōu)先級繼承特性。任務(wù)通知適合簡單的喚醒場景。任務(wù)通知比信號量更輕量不占用獨立的內(nèi)核對象在只喚醒單個任務(wù)并且不需要計數(shù)的情況下我用任務(wù)通知替代信號量。一個比較實用的選擇經(jīng)驗是如果傳遞的是連續(xù)數(shù)據(jù)流優(yōu)先隊列如果只是某個事件發(fā)生了這種標(biāo)志優(yōu)先任務(wù)通知或二值信號量如果多個任務(wù)都要訪問同一份資源再考慮互斥量。不要什么場景都用隊列硬套。3.4 中斷與線程的數(shù)據(jù)接力中斷服務(wù)程序里絕對不做復(fù)雜業(yè)務(wù)處理。這是多線程系統(tǒng)設(shè)計里最基礎(chǔ)也最重要的一條原則。以 CAN0 接收中斷為例。我在中斷里做的最多的事情就是讀 FIFO、構(gòu)造消息結(jié)構(gòu)體、調(diào)用 FromISR 后綴的隊列發(fā)送函數(shù)把數(shù)據(jù)交給 can_collect_task然后清理中斷標(biāo)志void CAN0IntHandler(void) { uint32_t ui32Status; tCANMsgObject sMsg; uint8_t pui8Data[8]; BaseType_t xHigherPriorityTaskWoken pdFALSE; ui32Status CANIntStatus(CAN0_BASE, CAN_INT_STS_CAUSE); if (ui32Status CAN_INT_INTID_STATUS) { CANIntClear(CAN0_BASE, CAN_INT_INTID_STATUS); return; } sMsg.pui8MsgData pui8Data; CANMessageGet(CAN0_BASE, ui32Status, sMsg, 0); if (sMsg.ui32MsgID 0x100u) { xQueueSendFromISR(xCanQueue, sMsg, xHigherPriorityTaskWoken); } portYIELD_FROM_ISR(xHigherPriorityTaskWoken); }注意最后一行如果 xHigherPriorityTaskWoken 被置為 pdTRUE表示隊列發(fā)送喚醒了一個高優(yōu)先級任務(wù)這時需要主動觸發(fā)一次上下文切換讓喚醒后的任務(wù)立刻執(zhí)行。這個細(xì)節(jié)很多人會漏掉導(dǎo)致中斷退出了但任務(wù)沒有及時調(diào)度。3.5 端到端數(shù)據(jù)鏈路整個數(shù)據(jù)流從物理信號到網(wǎng)絡(luò)報文我梳理成了一條清晰的鏈路CAN 總線 - CAN 控制器 FIFO - CAN0 中斷 - can_collect_task - CAN 報文隊列 - data_proc_task 數(shù)據(jù)融合 - 上報隊列 - tcp_server_task - LwIP netconn_write - EMAC 驅(qū)動 - 內(nèi)部 PHY - RJ45 以太網(wǎng)每條數(shù)據(jù)通路都對應(yīng)一組隊列和信號量。實際調(diào)試時如果某個環(huán)節(jié)丟了數(shù)據(jù)我只需要在隊列的出入口打點就能快速定位是采集慢、處理慢還是發(fā)送慢。這個數(shù)據(jù)流可視化的思路對排查線程問題幫助很大。4. LwIP 移植照這條路把網(wǎng)絡(luò)棧接進 FreeRTOS4.1 移植前必須明白的分層網(wǎng)上很多資料把 LwIP 移植講得像玄學(xué)其實看透分層之后就清晰了。LwIP 在你需要關(guān)注的層面可以分為五層驅(qū)動層操作具體的 MAC 控制器負(fù)責(zé)收發(fā)以太網(wǎng)幀。網(wǎng)卡接口層通過 struct netif 描述一個網(wǎng)口LwIP 通過 netif 的 input/output/linkoutput 回調(diào)函數(shù)驅(qū)動網(wǎng)卡。協(xié)議核心層IP、TCP、UDP、ICMP 等協(xié)議實現(xiàn)這部分是協(xié)議棧本身不需要改。OS 封裝層LwIP 設(shè)計為可以在裸機或 RTOS 上跑所以需要一個 sys_arch 層把互斥量、信號量、郵箱、任務(wù)創(chuàng)建等能力映射到 FreeRTOS 上。API 層給用戶提供 netconn API 或 socket API。對 TM4C1294 來說驅(qū)動層 TI 官方已經(jīng)提供了 EMAC 驅(qū)動代碼我要做的主要是 netif 初始化、注冊回調(diào)以及補全 sys_arch。協(xié)議核心層和 API 層直接編譯進工程即可。4.2 EMAC 與內(nèi)部 PHY 初始化要點TM4C1294 的以太網(wǎng) MAC 很特別它支持內(nèi)部 PHY默認(rèn) PHY 地址是 0。使用內(nèi)部 PHY 時不需要提供外部 MDIO 引腳連接。初始化過程大概包括使能以太網(wǎng)外設(shè)時鐘、設(shè)置內(nèi)部 PHY 模式、配置 MAC、打開 DMA 中斷、初始化收發(fā)描述符。TivaWare 的 third_party/lwip-1.4.1 目錄下有一個現(xiàn)成的移植例程其中 tivaif.c 和 tivaif.h 把 EMAC 初始化和收包處理都封裝好了。我一開始是直接照搬它的后來為了適配新版 LwIP把里面幾個過時的函數(shù)調(diào)用做了調(diào)整核心邏輯沒動。讀取 PHY 狀態(tài)也是必須的通過 MDIO 接口讀 PHY 的 BMSR 和 PHYSTS 寄存器判斷連接是否建立、當(dāng)前速率是 10M 還是 100M、雙工模式是全雙工還是半雙工。我在項目里做了一個 link 狀態(tài)監(jiān)控任務(wù)每 500ms 讀一次檢測到網(wǎng)線斷開或恢復(fù)時立即向應(yīng)用層上報事件。4.3 netif 注冊與底層收發(fā)回調(diào)LwIP 的主入口配置通常是這樣的struct netif gNetIf; struct ip4_addr xIpAddr, xNetMask, xGateway; IP4_ADDR(xIpAddr, 192, 168, 1, 100); IP4_ADDR(xNetMask, 255, 255, 255, 0); IP4_ADDR(xGateway, 192, 168, 1, 1); netif_add(gNetIf, xIpAddr, xNetMask, xGateway, NULL, tivaif_init, tcpip_input); netif_set_default(gNetIf); netif_set_up(gNetIf);這里最關(guān)鍵的是 netif_add 的第二個函數(shù)指針參數(shù) tivaif_init 和第三個參數(shù) tcpip_input。tivaif_init 負(fù)責(zé)初始化硬件并填充 netif 的 output/linkoutput 回調(diào)tcpip_input 是 LwIP 在帶操作系統(tǒng)模式下推薦的收包入口它會把收到的以太網(wǎng)幀放入一個消息隊列由 tcpip_thread 統(tǒng)一處理。這種設(shè)計保證協(xié)議棧核心是單線程訪問的避免多線程并發(fā)調(diào)用協(xié)議函數(shù)造成的數(shù)據(jù)競爭。4.4 sys_arch 層用 FreeRTOS 實現(xiàn)如果手動寫 sys_arch需要實現(xiàn)的東西很少但每一樣都得對應(yīng)到 FreeRTOS 的機制LwIP 抽象FreeRTOS 實現(xiàn)說明sys_mutex_new/lock/unlock/freexSemaphoreCreateMutex / xSemaphoreTake / xSemaphoreGive保護共享數(shù)據(jù)sys_sem_new/signal/waitxSemaphoreCreateBinary / xSemaphoreGive / xSemaphoreTake事件同步sys_mbox_new/post/fetchxQueueCreate / xQueueSend / xQueueReceive傳遞指針消息sys_thread_newxTaskCreate創(chuàng)建 tcpip_thread 等sys_nowxTaskGetTickCount返回當(dāng)前時間戳我建議直接使用社區(qū)里成熟的 sys_arch.c 文件做適量修改。一個容易忽視的細(xì)節(jié)是郵箱mbox隊列長度。如果隊列長度太小網(wǎng)絡(luò)收包高峰期 sys_mbox_trypost 會失敗直接導(dǎo)致丟包。我把 mbox 隊列長度配置成 32配合 PBUF_POOL_SIZE 32實測小包高速收發(fā)時丟包率明顯下降。4.5 兩種 API 的取舍LwIP 用戶態(tài) API 有兩種raw API 和 netconn API也包含基于 netconn 的 socket API。raw API 性能最高所有協(xié)議處理都在回調(diào)函數(shù)里完成但代碼邏輯分散多線程之間要格外小心共享數(shù)據(jù)。netconn API 是面向連接的 API編程方式接近 socket每個連接可以獨占一個線程阻塞等待數(shù)據(jù)這在多線程系統(tǒng)里寫起來非常順手。我這邊的 tcp_server_task 就是標(biāo)準(zhǔn) netconn 編程。主循環(huán)里 netconn_accept 等待客戶端連接收到連接后進入一個子狀態(tài)循環(huán)由任務(wù)棧上的局部變量保存連接句柄。每個客戶端連接對應(yīng)一個獨立任務(wù)實例的話會更清晰但會增加線程數(shù)量我在這個項目里用的還是單任務(wù)管理多個連接輪詢的方式。4.6 lwipopts.h 中的關(guān)鍵調(diào)校lwipopts.h 決定了 LwIP 的內(nèi)存占用和行為特征。我在 repeatxdn 工程里做的關(guān)鍵配置如下宏取值說明NO_SYS0帶操作系統(tǒng)模式LWIP_NETCONN1啟用 netconn APILWIP_SOCKET0不使用 POSIX socket節(jié)省 ROMMEM_SIZE30 * 1024協(xié)議棧堆大小單位字節(jié)MEMP_NUM_NETCONN4同時打開的 netconn 數(shù)量PBUF_POOL_SIZE32PBUF 池數(shù)量影響收包吞吐TCP_MSS1460以太網(wǎng)最大報文段長度TCP_WND8 * TCP_MSSTCP 接收窗口提高吞吐LWIP_DHCP1啟用 DHCP 客戶端LWIP_IGMP1啟用 IGMPUDP 組播需要TCP 接收窗口直接決定單連接吞吐上限。如果 TCP_WND 太小發(fā)送方的窗口受限吞吐就上不去。但窗口調(diào)大也會占用更多內(nèi)存項目里 SRAM 有 256KB我給它留的余量是夠的。實際使用中如果吞吐一直上不來可以優(yōu)先檢查 TCP_WND 和 PBUF_POOL_SIZE 這兩個值。4.7 收發(fā)鏈路實測效果調(diào)試完協(xié)議棧之后我用兩個方式做了驗證。一是 UDP 高速小包測試通過上位機向開發(fā)板發(fā)送 200 字節(jié)的 UDP 包統(tǒng)計接收端收到的包數(shù)和校驗錯誤數(shù)1000 包/秒的速率下基本無丟失。二是 TCP 單向吞吐測試用 iperf 工具跑板卡做 TCP server上位機做 client 發(fā)送 TCP 流實測吞吐穩(wěn)定在 27Mbps 附近CPU 占用約 45%這個數(shù)值對 M4 內(nèi)核跑 LwIP 來說是一個比較合理的水平。此時如果還想進一步提高吞吐通常的方向是加大 TCP_MSS、TCP_WND、PBUF 池數(shù)量同時降低中斷處理延遲但實時性采集任務(wù)會受影響需要做平衡。5. 線程踩坑實錄死鎖、優(yōu)先級反轉(zhuǎn)、堆棧溢出5.1 案例一互斥量保護區(qū)內(nèi)調(diào)用 netconn_write 導(dǎo)致死鎖這個坑我印象很深。系統(tǒng)剛跑通網(wǎng)絡(luò)功能時我總喜歡在任務(wù)里用一個共享互斥量保護一個全局緩沖區(qū)用來臨時拼接多幀數(shù)據(jù)然后再調(diào)用 netconn_write 發(fā)送。結(jié)果板子運行幾十秒后 TCP 連接必然斷流tcp_server_task 卡死在發(fā)送路徑上。后面用調(diào)試器掛上去看任務(wù)狀態(tài)發(fā)現(xiàn) tcp_server_task 阻塞在 netconn_write 調(diào)用里而 tcpip_thread 一直拿不到某個信號量。再結(jié)合?；厮莞蚴堑湫偷慕徊娴却业娜蝿?wù)拿著互斥量 A同時請求 LwIP 內(nèi)部核心鎖 Btcpip_thread 拿到了核心鎖 B又需要訪問由互斥量 A 保護的共享緩沖區(qū)。誰都不讓誰死鎖就出現(xiàn)了。解決方法很簡單把所有需要拼接的臨時數(shù)據(jù)在互斥量保護范圍內(nèi)拷貝到私有的發(fā)送緩沖區(qū)先釋放互斥量 A再調(diào)用 netconn_write。原則就是不要在持有自己鎖的時候去調(diào)用可能阻塞的協(xié)議棧 API。5.2 案例二兩個任務(wù)互相等待的經(jīng)典死鎖另一個死鎖發(fā)生在兩個任務(wù)各持有一把互斥量后又去等待對方持有的資源。任務(wù) A 拿 mutexA 后等待隊列 queueB任務(wù) B 拿 mutexB 后等待隊列 queueA。兩個隊列都有數(shù)據(jù)但都同時被對方阻塞系統(tǒng)整體進入僵死狀態(tài)。這種死鎖排查起來并不輕松。我養(yǎng)成的一個習(xí)慣是所有 xSemaphoreTake 和 xQueueReceive 的地方一律加超時時間絕不使用無限等待。比如if (xQueueReceive(xCmdQueue, cmd, pdMS_TO_TICKS(100)) pdTRUE) { // 處理指令 }超時返回之后即使邏輯上沒有完全處理完也好過整個任務(wù)卡死。系統(tǒng)設(shè)計上保證主流程在一個超時周期內(nèi)還能繼續(xù)跑監(jiān)控任務(wù)就能發(fā)現(xiàn)問題。5.3 優(yōu)先級反轉(zhuǎn)低優(yōu)先級任務(wù)拖慢高優(yōu)先級任務(wù)優(yōu)先級反轉(zhuǎn)是嵌入式多線程系統(tǒng)里一個繞不開的話題?，F(xiàn)象是高優(yōu)先級任務(wù)在等一把被低優(yōu)先級任務(wù)持有的互斥量而中等優(yōu)先級任務(wù)搶占了低優(yōu)先級任務(wù)的 CPU導(dǎo)致低優(yōu)先級任務(wù)遲遲釋放不了鎖高優(yōu)先級任務(wù)實際等待時間遠(yuǎn)大于預(yù)期。FreeRTOS 互斥量默認(rèn)實現(xiàn)了優(yōu)先級繼承機制當(dāng)高優(yōu)先級任務(wù)等待一把互斥量時當(dāng)前持有該互斥量的任務(wù)會被臨時提升到高優(yōu)先級從而加快釋放。這個機制能解決大部分場景。但這里有個使用提醒共享臨界區(qū)要盡量短不能把一個耗時很長的操作放在互斥量里面。否則即使有優(yōu)先級繼承等待鎖的任務(wù)依然會被長時間拖住。5.4 堆棧溢出檢測讓問題在上線前現(xiàn)形任務(wù)棧配小是嵌入式開發(fā)最常見的內(nèi)存事故來源之一。癥狀千奇百怪可能是某個變量的值突然被改寫可能是函數(shù)返回地址被覆蓋后跑飛也可能是在不同優(yōu)化級別下表現(xiàn)完全不同。FreeRTOS 提供了兩級棧溢出檢測。configCHECK_FOR_STACK_OVERFLOW 設(shè)為 1只在任務(wù)切換時檢查任務(wù)棧指針本文還有配套的精品資源點擊獲取