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