做嵌入式開發(fā)的朋友十有八九都被網(wǎng)絡(luò)模塊這塊硬骨頭卡過。板子上的傳感器數(shù)據(jù)、跑起來的RTOS調(diào)度、邏輯復(fù)雜的業(yè)務(wù)代碼一切都調(diào)得服服帖帖結(jié)果一碰網(wǎng)絡(luò)突然就開始懷疑人生連不上服務(wù)器、收發(fā)數(shù)據(jù)一包丟一半、內(nèi)存池莫名被吃光、死機(jī)不知道死在哪個(gè)回調(diào)里。我自己的經(jīng)歷也差不多從第一次在裸機(jī)工程里裸奔著調(diào)協(xié)議棧到后來在多個(gè)項(xiàng)目里反復(fù)踩坑、重構(gòu)、穩(wěn)定上線用了挺長(zhǎng)時(shí)間才把這套網(wǎng)絡(luò)模塊的“通關(guān)之路”走通。今天這篇就圍繞嵌入式C語(yǔ)言網(wǎng)絡(luò)模塊講講從零到一到底要準(zhǔn)備什么、先做什么后做什么以及那些文檔里從來不會(huì)寫的細(xì)節(jié)。這個(gè)主題適合兩類朋友。一類是剛接觸嵌入式網(wǎng)絡(luò)的初學(xué)者你的目標(biāo)是在板子上跑通TCP/IP通信能穩(wěn)定收發(fā)數(shù)據(jù)不要求你對(duì)協(xié)議棧源碼倒背如流另一類是有一定基礎(chǔ)但正在做產(chǎn)品化的開發(fā)者你的板子要7x24小時(shí)聯(lián)網(wǎng)運(yùn)行要考慮斷線重連、內(nèi)存占用、傳輸性能你要的是能把活兒干利索的那一套實(shí)操方案。這篇文章會(huì)從方案選型、驅(qū)動(dòng)層移植、內(nèi)核配置、socket編程、調(diào)試排障這幾個(gè)維度走一遍完整流程所有內(nèi)容都基于我在實(shí)際項(xiàng)目中驗(yàn)證過的做法。1. 網(wǎng)絡(luò)模塊整體設(shè)計(jì)與方案選型1.1 先想清楚你的設(shè)備是什么角色嵌入式產(chǎn)品接入網(wǎng)絡(luò)第一件事不是寫代碼是先想清楚這個(gè)設(shè)備在網(wǎng)絡(luò)里到底扮演什么角色。這個(gè)決定會(huì)影響后續(xù)全部的硬件選型、軟件架構(gòu)、協(xié)議選擇甚至?xí)苯雨P(guān)系到MCU主頻和Flash容量夠不夠用。常見的角色大致分三種網(wǎng)絡(luò)客戶端設(shè)備主動(dòng)連接服務(wù)器或網(wǎng)關(guān)上報(bào)數(shù)據(jù)、接收指令。比如智能電表、環(huán)境監(jiān)測(cè)終端、遠(yuǎn)程IO模塊。網(wǎng)絡(luò)服務(wù)器設(shè)備作為TCP服務(wù)器接受上位機(jī)或手機(jī)App的主動(dòng)連接。比如Wi-Fi插座、局域網(wǎng)內(nèi)控制的熱水器、某些調(diào)試工具。被動(dòng)受控節(jié)點(diǎn)設(shè)備本身不主動(dòng)建鏈但需要響應(yīng)來自局域網(wǎng)或云端的查詢和控制。這種角色往往會(huì)結(jié)合UDP組播或自定義應(yīng)用層協(xié)議。角色定義清楚之后很多參數(shù)就跟著出來了。如果設(shè)備是客戶端重點(diǎn)考慮斷線重連、DNS解析、證書校驗(yàn)如果走TLS這些如果是服務(wù)器重點(diǎn)考慮并發(fā)連接數(shù)、監(jiān)聽隊(duì)列長(zhǎng)度、數(shù)據(jù)接收緩沖區(qū)大小如果是被動(dòng)節(jié)點(diǎn)往往要決定用什么協(xié)議來保證低功耗監(jiān)聽和快速喚醒。在我的一個(gè)實(shí)際項(xiàng)目里最初需求只寫了“設(shè)備需要通過以太網(wǎng)上傳數(shù)據(jù)到后臺(tái)”結(jié)果我直接按客戶端開發(fā)忙活了兩周才被產(chǎn)品告知設(shè)備還要能被運(yùn)維人員從現(xiàn)場(chǎng)臨時(shí)連接查看狀態(tài)。這下好了不僅要會(huì)主動(dòng)連服務(wù)器還要能作為服務(wù)器接受運(yùn)維工具的連接整個(gè)協(xié)議棧的內(nèi)存規(guī)劃和socket管理策略全部重來。所以項(xiàng)目啟動(dòng)時(shí)寧可多花半天把角色和周邊交互方式捋清楚也不要寫了兩千行代碼再返工。1.2 協(xié)議棧選擇從零寫、lwIP、還是RTOS自帶嵌入式網(wǎng)絡(luò)模塊的核心是TCP/IP協(xié)議棧。關(guān)于協(xié)議棧真實(shí)可選路徑其實(shí)就三條第一條路從零手寫協(xié)議棧。這個(gè)方案教學(xué)意義遠(yuǎn)大于工程意義。要寫一層ARP、一層IP、一層ICMP、一層TCP還要保證狀態(tài)機(jī)、重傳、擁塞控制這些機(jī)制在資源受限的MCU上正常工作工作量巨大單是TCP超時(shí)重傳和滑動(dòng)窗口的管理就是一片沼澤。雖然極客精神可嘉但我建議除非你是在做一個(gè)操作系統(tǒng)的教學(xué)項(xiàng)目或者要跑在某種特殊到無法用現(xiàn)成協(xié)議棧的芯片上否則真的沒必要從零編寫。第二條路移植lwIP。這是嵌入式界應(yīng)用最廣泛的開源TCP/IP協(xié)議棧麻雀雖小五臟俱全支持TCP、UDP、DNS、DHCP、SNMP、IGMP還能裁剪開關(guān)。它最吃香的點(diǎn)就是專門為嵌入式設(shè)計(jì)沒有復(fù)制Linux協(xié)議棧那一大堆重型機(jī)制內(nèi)存占用可以針對(duì)產(chǎn)品需求配置。我自己絕大多數(shù)網(wǎng)絡(luò)模塊項(xiàng)目都是基于lwIP做的哪怕是在RTOS上跑任務(wù)網(wǎng)絡(luò)層還是用它。它那套netconn和socket API寫起來跟PC環(huán)境下的socket編程很像上手門檻低。第三條路直接用RTOS的協(xié)議棧組件。很多商用RTOS已經(jīng)把TCP/IP協(xié)議棧、TLS、MQTT這些組件封裝好你只需要勾選配置然后調(diào)用API。這條路集成度最高穩(wěn)定性也不錯(cuò)但有個(gè)問題就是可定制性相對(duì)較弱而且收費(fèi)商業(yè)產(chǎn)品里部分組件按授權(quán)收費(fèi)。如果公司的項(xiàng)目允許用成熟的商業(yè)組件確實(shí)能省心很多。我做方案對(duì)比時(shí)習(xí)慣列一張表方便團(tuán)隊(duì)溝通方案上手難度可控性資源占用典型場(chǎng)景手寫協(xié)議棧極高完全掌控可做到極小教學(xué)、研究、特種硬件lwIP移植中等較高視配置而定絕大多數(shù)MCU聯(lián)網(wǎng)產(chǎn)品RTOS自帶網(wǎng)絡(luò)組件低較低中高商業(yè)快速交付、免開發(fā)適配說實(shí)話我自己的項(xiàng)目90%都落在lwIP這條路上。原因很簡(jiǎn)單它的社區(qū)足夠大遇到問題搜索引擎能找到答案代碼結(jié)構(gòu)清晰你能看到“內(nèi)部實(shí)現(xiàn)的一切數(shù)據(jù)包是如何流轉(zhuǎn)的”這一點(diǎn)在定位疑難雜癥時(shí)是救命稻草。有一次遇到的問題就是收包不完整最后從那行判斷協(xié)議類型、解析幀頭直接定位到驅(qū)動(dòng)的字節(jié)對(duì)齊問題——這種能力只有剖析過協(xié)議棧源碼才能獲得。1.3 硬件平臺(tái)與底層驅(qū)動(dòng)的前期確認(rèn)協(xié)議棧定下來之后硬件平臺(tái)是繞不開的話題。需要確認(rèn)的底層驅(qū)動(dòng)主要有三塊MAC控制器、PHY芯片、中斷與DMA通道。MAC控制器一般內(nèi)嵌在MCU里負(fù)責(zé)鏈路層的幀收發(fā)控制、CRC校驗(yàn)、地址過濾。你寫驅(qū)動(dòng)時(shí)主要就是初始化它的寄存器配置發(fā)送接收描述符通過DMA把數(shù)據(jù)包搬運(yùn)到內(nèi)存。PHY芯片則是外掛的物理層芯片負(fù)責(zé)把數(shù)字信號(hào)轉(zhuǎn)成差分信號(hào)跑在網(wǎng)線上它和MAC之間多是通過MII或RMII接口通信。底層驅(qū)動(dòng)這塊最容易出的坑是PHY地址和復(fù)位時(shí)序。PHY芯片的地址通常由硬件引腳上下拉決定不同型號(hào)默認(rèn)地址還不一樣比如很多常見PHY芯片的默認(rèn)地址是0x01但設(shè)置不同引腳也可能變成其他值。你以為代碼寫對(duì)了結(jié)果讀寄存器全是0xFF大概率就是PHY地址沒對(duì)上或者是復(fù)位時(shí)間不夠——PHY上電后需要等待一段時(shí)間某些芯片的復(fù)位時(shí)序苛刻一些要嚴(yán)格看數(shù)據(jù)手冊(cè)的延時(shí)要求。我常犯的錯(cuò)誤是把復(fù)位延時(shí)寫成“大概100毫秒”結(jié)果換了一顆PHY芯片之后發(fā)現(xiàn)偶爾初始化失敗查了手冊(cè)才發(fā)現(xiàn)這顆芯片要求復(fù)位后至少等待特定時(shí)間才能開始訪問寄存器否則第一次讀回來的狀態(tài)就是亂的。2. 底層驅(qū)動(dòng)與協(xié)議棧移植2.1 MAC驅(qū)動(dòng)移植從零到能收發(fā)包lwIP本身不包含具體芯片的驅(qū)動(dòng)它留給你的只是一個(gè)函數(shù)指針結(jié)構(gòu)體netif你要做的就是實(shí)現(xiàn)這個(gè)接口背后的實(shí)際收包發(fā)包函數(shù)。對(duì)這個(gè)結(jié)構(gòu)體里的幾個(gè)關(guān)鍵點(diǎn)必須心里有數(shù)low_level_init初始化MAC控制器、配置DMA描述符、申請(qǐng)內(nèi)存池、注冊(cè)MAC地址。low_level_output把協(xié)議棧要發(fā)送的數(shù)據(jù)幀寫到DMA描述符指向的緩沖區(qū)然后觸發(fā)發(fā)送。low_level_input從DMA接收描述符鏈上取回一幀數(shù)據(jù)交給協(xié)議棧處理然后重新掛載空緩沖區(qū)。初次接觸這塊代碼的人很容易被一個(gè)細(xì)節(jié)繞暈網(wǎng)絡(luò)字節(jié)序。ETH頭里的目的MAC、源MAC、類型字段IP頭里的版本/首部長(zhǎng)度、總長(zhǎng)度、校驗(yàn)和TCP頭里的序號(hào)、確認(rèn)號(hào)幾乎全部是網(wǎng)絡(luò)字節(jié)序也就是大端模式。而很多MCU尤其是ARM Cortex-M系列默認(rèn)是字節(jié)序無關(guān)的但你的調(diào)試工具、PC端的抓包工具顯示出來的值是經(jīng)過轉(zhuǎn)化的。如果你在設(shè)備端疊加協(xié)議頭時(shí)用了主機(jī)字節(jié)序傳出去的包抓包一看就是亂的對(duì)方收到報(bào)文會(huì)直接丟棄。正確做法是所有協(xié)議頭的構(gòu)造都按照RFC定義走多用htons、htonl這類字節(jié)序轉(zhuǎn)換函數(shù)。不要覺得性能有損失現(xiàn)代的MCU處理幾條字節(jié)序轉(zhuǎn)換指令幾乎不消耗什么時(shí)間但省下的調(diào)試時(shí)間是實(shí)實(shí)在在的。DMA描述符這塊還要注意緩沖區(qū)大小。通用做法是每個(gè)接收描述符掛一個(gè)MTU大小加上以太網(wǎng)頭部的完整緩沖區(qū)比如1500字節(jié)或1518字節(jié)。如果你的設(shè)備還要支持VLAN Tag就得考慮把緩沖區(qū)加大到1522字節(jié)甚至更大。緩沖區(qū)太小會(huì)直接導(dǎo)致大包被截?cái)嗷騺G失連上之后應(yīng)用層看到的現(xiàn)象就是發(fā)送大數(shù)據(jù)塊時(shí)直接假死。發(fā)一個(gè)簡(jiǎn)單的發(fā)送函數(shù)框架static err_t low_level_output(struct netif *netif, struct pbuf *p) { struct pbuf *q; u8_t *buffer; // 確保待發(fā)送數(shù)據(jù)放入DMA發(fā)送緩沖區(qū) buffer (u8_t *)tx_desc-buf_addr; for (q p; q ! NULL; q q-next) { memcpy(buffer, q-payload, q-len); buffer q-len; } // 配置描述符控制字并觸發(fā)發(fā)送 tx_desc-ctrl (p-tot_len DESC_CTRL_SIZE_MASK) | DESC_CTRL_TX_ENABLE; while (!(tx_desc-status DESC_STATUS_TX_COMPLETE)) { // 等待發(fā)送完成超時(shí)要處理 } netif-output(netif, p); return ERR_OK; }這段代碼把pBuf鏈表里的數(shù)據(jù)復(fù)制到DMA緩沖區(qū)然后觸發(fā)發(fā)送。注意那里用了一個(gè)while循環(huán)等待發(fā)送完成在實(shí)際項(xiàng)目中這種寫法在大流量下會(huì)阻塞協(xié)議棧更好的做法是用發(fā)送完成中斷或者在利用多個(gè)描述符做乒乓操作時(shí)輪詢狀態(tài)位。初學(xué)者可以先短平快跑起來后面再優(yōu)化性能。2.2 lwIP配置裁剪內(nèi)存決定一切l(wèi)wIP的裁剪基本上都集中在lwipopts.h文件里這個(gè)文件里每一項(xiàng)配置背后都是性能和內(nèi)存的取舍。我整理過一份自己在項(xiàng)目中反復(fù)用的配置清單可以直接當(dāng)起點(diǎn)配置項(xiàng)推薦值說明MEM_SIZE16000字節(jié)以上協(xié)議棧內(nèi)部的堆內(nèi)存池大小用于pBuf、連接塊等MEMP_NUM_PBUF32同時(shí)允許的PBUF數(shù)量影響收發(fā)緩沖能力MEMP_NUM_TCP_PCB8同時(shí)存在的TCP控制塊數(shù)量一個(gè)連接一個(gè)PCBMEMP_NUM_TCP_SEG32TCP待發(fā)送段的數(shù)量影響發(fā)送窗口能力PBUF_POOL_SIZE24接收用的PBUF池大小太少了扛不住突發(fā)流量TCP_WND4096或更大TCP接收窗口窗口太小會(huì)嚴(yán)重拉低吞吐TCP_SND_BUF4096TCP發(fā)送緩沖區(qū)應(yīng)用層send時(shí)超過會(huì)阻塞或報(bào)錯(cuò)CHECKSUM_GEN_IP / CHECKSUM_GEN_TCP1IP和TCP校驗(yàn)和生成必須開啟CHECKSUM_CHECK_IP / CHECKSUM_CHECK_TCP1包校驗(yàn)必須開啟否則出錯(cuò)時(shí)你完全無從察覺LWIP_NETCONN1開啟API接口一般linux風(fēng)格的應(yīng)用需要LWIP_SOCKET1開啟socket API支持這些配置之間是相互關(guān)聯(lián)的比如TCP_WND設(shè)得很大那么接收側(cè)需要的緩沖區(qū)也要相應(yīng)放大否則窗口開了但緩沖區(qū)不足數(shù)據(jù)來了只能丟棄。有個(gè)我當(dāng)年忽略的配置是socket API與netconn API互斥編譯還是共存編譯的問題LWIP_SOCKET開啟后系統(tǒng)會(huì)用更多內(nèi)存做socket層的封裝如果Flash和RAM都很緊張可以考慮只用netconnAPI代碼結(jié)構(gòu)調(diào)整一下就行。內(nèi)存池大小常規(guī)估算方式一個(gè)TCP PCB大約幾百字節(jié)一個(gè)PBUF結(jié)構(gòu)加數(shù)據(jù)空間取決于池大小如果一個(gè)PBUF池的緩沖區(qū)是1280字節(jié)那么24個(gè)就差不多占用40KB以上RAM。所以在配置之前先看你的MCU有多少RAM反過來倒推各項(xiàng)參數(shù)才合理。很多板子默認(rèn)RAM就64KB你還得跑業(yè)務(wù)邏輯、RTOS線程棧能留給協(xié)議棧的空間本來就有限這時(shí)候非要把發(fā)送緩沖區(qū)設(shè)成16KB出來的效果就是系統(tǒng)內(nèi)存耗盡、頻繁分配失敗。2.3 DHCP、網(wǎng)卡狀態(tài)與鏈路檢測(cè)嵌入式網(wǎng)絡(luò)設(shè)備通常還要處理兩個(gè)和業(yè)務(wù)一樣重要的問題動(dòng)態(tài)獲取IP和網(wǎng)線插拔檢測(cè)。對(duì)于需要即插即用的設(shè)備DHCP客戶端幾乎是標(biāo)配。lwIP里啟用DHCP很簡(jiǎn)單連上網(wǎng)絡(luò)后調(diào)用dhcp_start即可。但要注意在沒有DHCP服務(wù)器的環(huán)境里很多產(chǎn)品會(huì)自動(dòng)回退到固定的靜態(tài)IP這個(gè)邏輯需要自己寫。否則設(shè)備一直卡在等待IP的狀態(tài)用戶會(huì)以為死機(jī)了。我一般會(huì)在DHCP啟動(dòng)前就把靜態(tài)IP寫好超時(shí)多長(zhǎng)都沒獲取到IP就自動(dòng)切換到靜態(tài)IP模式。網(wǎng)線插拔檢測(cè)往往被初學(xué)者忽略。默認(rèn)情況下lwIP不會(huì)主動(dòng)告訴你物理鏈路斷了——它的底層驅(qū)動(dòng)只有在收到數(shù)據(jù)或嘗試發(fā)送時(shí)才會(huì)意識(shí)到鏈路有問題。所以你要在驅(qū)動(dòng)里周期性檢查PHY的鏈路狀態(tài)寄存器。有幾個(gè)PHY鏈路狀態(tài)檢測(cè)都比較規(guī)范比如讀取PHY的狀態(tài)寄存器或使用中斷引腳。這里給你一個(gè)實(shí)戰(zhàn)建議鏈路檢測(cè)的周期不要設(shè)太短否則會(huì)高頻訪問MDIO總線干擾其他I2C或SPI設(shè)備也不要設(shè)太長(zhǎng)不然斷線之后業(yè)務(wù)層的重連機(jī)制要等很久才觸發(fā)。我個(gè)人習(xí)慣是在線程里每500毫秒查一次PHY狀態(tài)鏈路狀態(tài)變化時(shí)才通知上層平時(shí)不做沒必要的動(dòng)作。3. 網(wǎng)絡(luò)應(yīng)用層的設(shè)計(jì)與實(shí)現(xiàn)3.1 TCP客戶端連接、發(fā)送、斷線重連網(wǎng)絡(luò)模塊跑通底層后真正的業(yè)務(wù)邏輯才開始。絕大多數(shù)嵌入式設(shè)備工作的核心動(dòng)作就是“連服務(wù)器發(fā)數(shù)據(jù)”。TCP客戶端代碼看起來簡(jiǎn)單真正寫穩(wěn)了卻不容易。一個(gè)完整的TCP客戶端至少包含這幾個(gè)環(huán)節(jié)建立一個(gè)socket、配置服務(wù)器地址和端口。建立連接。連接過程要設(shè)置超時(shí)因?yàn)榍度胧骄W(wǎng)絡(luò)環(huán)境可能很復(fù)雜目標(biāo)服務(wù)器不一定隨時(shí)可達(dá)。發(fā)送數(shù)據(jù)。發(fā)送時(shí)要處理部分寫入的情況socket發(fā)送緩沖區(qū)滿了怎么辦。接收數(shù)據(jù)。數(shù)據(jù)接收要考慮粘包和半包問題在TCP這種字節(jié)流協(xié)議上應(yīng)用層必須自己定義幀邊界。斷線重連。這是嵌入式產(chǎn)品設(shè)計(jì)中最基礎(chǔ)、也必須存在的機(jī)制。服務(wù)器重啟、路由器切換、網(wǎng)線被拔掉都要能自動(dòng)恢復(fù)。斷線重連機(jī)制的寫法有很多我自己常用的手段是設(shè)置一個(gè)“心跳包”和“業(yè)務(wù)重連”雙輪機(jī)制。心跳包負(fù)責(zé)確認(rèn)這條連接是否還活著典型做法是每幾秒發(fā)一次應(yīng)用層心跳超過N次沒有收到對(duì)端響應(yīng)就判定為斷線。而業(yè)務(wù)重連則是不依賴業(yè)務(wù)數(shù)據(jù)的自動(dòng)嘗試不論上次連接是什么原因斷開只要不是主動(dòng)關(guān)閉就按照退避策略自動(dòng)重連。這里提供一份連接重試的偽代碼邏輯static void tcp_client_task(void *arg) { while (1) { if (!connected) { if (socket_create_and_connect()) { connected 1; } else { // 退避重連指數(shù)退避從2秒起最大到30秒 vTaskDelay(get_backoff_delay() / portTICK_PERIOD_MS); continue; } } if (recv_timeout_ms(data, 1000) TIMEOUT) { if (GET_SYSTEM_MS() - last_heartbeat_sent HEARTBEAT_INTERVAL_MS) { send_heartbeat(last_heartbeat_sent); vTaskDelay(100); continue; } continue; } // 處理業(yè)務(wù)數(shù)據(jù) process_packet(data); } }關(guān)鍵是那個(gè)recv_timeout_ms無論收沒收到數(shù)據(jù)都能按時(shí)返回這樣心跳邏輯才能按計(jì)劃執(zhí)行。很多初學(xué)者直接在recv里阻塞著等一等等半天心跳發(fā)不出去連接斷了自己也不知道這是最常見的問題。3.2 TCP服務(wù)器多連接管理與常用架構(gòu)如果設(shè)備做TCP服務(wù)器問題就變成主動(dòng)連接設(shè)備的“客戶端們”可能隨時(shí)來、隨時(shí)走。嵌入式設(shè)備資源有限做多連接管理更需要講究。lwIP的socket API在服務(wù)器場(chǎng)景下可選的工作模式有兩種阻塞式多線程或者非阻塞式單線程事件輪詢。在資源緊張的MCU上我更推薦后者——單線程配合select函數(shù)來管理多個(gè)連接。原因是每個(gè)阻塞連接都占用一個(gè)線程棧棧內(nèi)存開銷大而且線程多了調(diào)度、上下文切換的負(fù)擔(dān)也不小。用select管理的核心思路是維護(hù)一個(gè)文件描述符集合每次循環(huán)調(diào)用select把有可讀事件的socket挑出來逐一處理。這樣不管有多少連接處理循環(huán)只需要一個(gè)線程。代碼骨架如下FD_ZERO(readfds); FD_SET(listen_fd, readfds); max_fd listen_fd; // 把所有已連接socket也加入集合 for (i 0; i client_count; i) { FD_SET(client_fds[i], readfds); if (client_fds[i] max_fd) max_fd client_fds[i]; } ret select(max_fd 1, readfds, NULL, NULL, timeout); if (ret 0) { if (FD_ISSET(listen_fd, readfds)) { new_fd accept(listen_fd, NULL, NULL); // 檢查連接數(shù)量上限不夠則接受并加入列表 } for (i 0; i client_count; i) { if (FD_ISSET(client_fds[i], readfds)) { n recv(client_fds[i], buffer, sizeof(buffer), 0); if (n 0) { // 連接關(guān)閉或異常剔除 } else { // 處理數(shù)據(jù) } } } }這個(gè)模式里要考慮幾個(gè)問題。連接數(shù)上限必須提前定義超過上限時(shí)要拒絕新的連接或者踢掉最老的連接客戶端長(zhǎng)時(shí)間不活動(dòng)需要一個(gè)超時(shí)機(jī)制主動(dòng)關(guān)閉它同時(shí)accept出來的新socket要加入管理列表關(guān)閉的幾個(gè)要從列表中移除。這些邏輯寫多了代碼就有點(diǎn)亂所以在實(shí)際項(xiàng)目里我會(huì)把整個(gè)服務(wù)器封裝成一個(gè)模塊對(duì)外只暴露注冊(cè)回調(diào)函數(shù)void server_init(u16_t port, server_data_handler handler); void server_poll(void); void server_on_connect(server_conn_handler handler);這樣業(yè)務(wù)代碼不需要關(guān)心底層是select還是多線程只需要往模塊里注冊(cè)處理函數(shù)。模塊內(nèi)部維護(hù)連接列表和活躍度整個(gè)代碼的耦合度會(huì)大幅降低后續(xù)排查問題也更方便。3.3 UDP與廣播低開銷但要想清楚丟包很多場(chǎng)景不需要可靠的TCP連接比如局域網(wǎng)內(nèi)的設(shè)備發(fā)現(xiàn)、狀態(tài)廣播、傳感器數(shù)據(jù)采集等。UDP的開銷遠(yuǎn)小于TCP它的數(shù)據(jù)發(fā)送可能一條語(yǔ)句就完成。但工程上使用UDP必須接受“丟包是正常的”這一事實(shí)并且要在應(yīng)用層做相應(yīng)的容錯(cuò)。UDP的使用場(chǎng)景里我覺得最典型的設(shè)備發(fā)現(xiàn)協(xié)議值得講一下。在一個(gè)局域網(wǎng)里新上電的設(shè)備需要讓上位機(jī)找到它通常做法是設(shè)備加入組播地址或者周期性地向子網(wǎng)廣播地址發(fā)送自己的設(shè)備信息。這里涉及到綁定哪個(gè)端口、組播地址怎么選、以及如何在收到響應(yīng)后選擇正確的通信方式。使用lwIP做組播時(shí)有一個(gè)坑我之前記憶猶新組播包的發(fā)送和接收一定要確保網(wǎng)卡的netif配置開啟了組播接收某些驅(qū)動(dòng)的MAC層需要顯式設(shè)置multicast filter字節(jié)上不同的MAC過濾方式也不一樣。不加設(shè)置的話設(shè)備往外發(fā)組播正常但收不到別人發(fā)來的組播包排查起來特別隱蔽。因?yàn)樽グぞ咴赑C上看到的報(bào)文是發(fā)出了但是進(jìn)不了MCU板子怎么調(diào)試都像是沒收到。如果你做UDP協(xié)議還要考慮一個(gè)問題最大接收緩沖。UDP數(shù)據(jù)報(bào)不會(huì)像TCP一樣自動(dòng)分片重傳應(yīng)用層接收buffer不夠就只能丟棄。所以以我的經(jīng)驗(yàn)UDP接收緩沖最好直接設(shè)成應(yīng)用層協(xié)議里定義的最大報(bào)文長(zhǎng)度避免半包、亂序解析帶來的業(yè)務(wù)bug。4. 性能優(yōu)化與調(diào)試經(jīng)驗(yàn)4.1 吞吐量上不去從窗口到CPU占用一路查設(shè)備剛跑通網(wǎng)絡(luò)功能時(shí)通常很興奮但接下來就是“為什么傳輸速率這么慢”的拷問。一塊64KB RAM的MCU千兆網(wǎng)口肯定是別想了但百兆網(wǎng)口跑滿打?qū)φ垡矐?yīng)該還有余量。吞吐量上不去排查重點(diǎn)有這幾點(diǎn)接收窗口太小TCP_WND設(shè)置的是對(duì)端允許給本機(jī)發(fā)送的數(shù)據(jù)量。如果只有2KB對(duì)方一次可能只發(fā)2KB等待你確認(rèn)后再發(fā)下一批這種往返等待直接限制吞吐。發(fā)送緩沖區(qū)太小發(fā)送側(cè)如果TCP_SND_BUF只有幾KB發(fā)送大文件時(shí)應(yīng)用層每次只能寫一小段要頻繁等待內(nèi)核緩沖區(qū)騰出來。DMA描述符不足網(wǎng)絡(luò)高速傳輸時(shí)DMA描述符數(shù)量不夠直接表現(xiàn)為“丟包”?？梢栽诎l(fā)送和接收方向上多配置描述符但注意這也會(huì)增加RAM開銷。中斷處理過于頻繁每個(gè)包都觸發(fā)一次中斷主循環(huán)忙不過來系統(tǒng)響應(yīng)變慢。可以考慮做中斷聚合比如每次中斷把所有收下來的包都取完再出ISR減少上下文切換的次數(shù)。還有一個(gè)容易被忽略的點(diǎn)lwIP的中斷收包路徑和下層的TCP校驗(yàn)和計(jì)算。如果芯片有硬件校驗(yàn)和加速功能一定要開啟如果沒有純軟件計(jì)算校驗(yàn)和在某些主頻不高的MCU上會(huì)占不少CPU負(fù)載。有一次測(cè)試項(xiàng)目同一個(gè)板子跑同樣的功能開啟硬件校驗(yàn)和之后CPU占用直接從80%降到30%吞吐量也上了一個(gè)大臺(tái)階。4.2 內(nèi)存管理協(xié)議棧內(nèi)存與RTOS堆棧如何平衡嵌入式網(wǎng)絡(luò)模塊的性能瓶頸往往不在CPU主頻而在內(nèi)存管理。lwIP有自己獨(dú)立的內(nèi)存池RTOS任務(wù)也有自己的棧空間怎么平衡是個(gè)經(jīng)驗(yàn)活。先說lwIP內(nèi)部。MEM_SIZE控制的是堆內(nèi)存用于一些動(dòng)態(tài)分配MEMP_NUM_*系列控制的是各種內(nèi)存池。常見的是MEMP_NUM_TCP_SEG太小導(dǎo)致發(fā)送數(shù)據(jù)時(shí)頻繁報(bào)內(nèi)存不足進(jìn)而觸發(fā)“TCP重傳”。從應(yīng)用層看起來就是偶爾卡住過一會(huì)又恢復(fù)實(shí)際上內(nèi)核一直在重傳隊(duì)列里掙扎。RTOS這邊每個(gè)網(wǎng)絡(luò)任務(wù)的棧大小要合理評(píng)估。socket API的send/receive調(diào)用鏈會(huì)在任務(wù)棧里創(chuàng)建臨時(shí)緩沖區(qū)、結(jié)構(gòu)體等棧給得小系統(tǒng)直接崩。常規(guī)經(jīng)驗(yàn)是把網(wǎng)絡(luò)任務(wù)棧設(shè)成2KB起步帶TLS的設(shè)到4KB以上。如果任務(wù)里使用了printf對(duì)網(wǎng)絡(luò)日志做格式化輸出那棧還要加大因?yàn)閜rintf本身是很吃棧的。內(nèi)存問題排查時(shí)我給個(gè)最簡(jiǎn)單的技巧統(tǒng)計(jì)一段時(shí)間內(nèi)lwIP關(guān)鍵內(nèi)存池的可用值。lwIP提供了mem_free_count、memp_free_count這類統(tǒng)計(jì)接口可以周期性地抓出來打日志。如果發(fā)現(xiàn)某個(gè)池的數(shù)量一直往下掉、不見回升那就是內(nèi)存在泄漏重點(diǎn)檢查有沒有在發(fā)送失敗或連接關(guān)閉的路徑上忘記釋放pBuf、連接控制塊這類問題十有八九是異常分支沒有走到釋放邏輯。extern struct memp_desc memp_pbuf; extern sys_mem_t mem_free_count; void dump_mem_stats(void) { u32_t free_pbuf memp_free_count; u32_t free_heap mem_free_count; printf(PBUF free: %u, heap free: %u\n, free_pbuf, free_heap); }用這套工具把各個(gè)內(nèi)存池的循環(huán)打印出來觀察正常情況下數(shù)值的波動(dòng)范圍。一旦出現(xiàn)持續(xù)下降或不為零的異常增長(zhǎng)基本上就能鎖死問題區(qū)域。4.3 抓包與日志定位問題別靠猜嵌入式網(wǎng)絡(luò)模塊出現(xiàn)問題調(diào)試技巧決定效率。這一步既是工具問題也是方法論問題。物理層抓包推薦在設(shè)備端網(wǎng)口串聯(lián)一個(gè)抓包工具或者直接把PC當(dāng)成客戶端/服務(wù)器來抓包。抓包工具能告訴你三件事設(shè)備到底有沒有把包發(fā)出去、發(fā)的包格式對(duì)不對(duì)、遠(yuǎn)端有沒有回應(yīng)。很多時(shí)候硬件工程師和軟件工程師爭(zhēng)論“到底有沒有發(fā)數(shù)據(jù)”抓包一看一錘定音。代碼層打點(diǎn)日志在協(xié)議棧的關(guān)鍵路徑上加日志。lwIP有可選的LWIP_DEBUG選項(xiàng)打開debug輸出后能打印連接狀態(tài)、接收事件、錯(cuò)誤碼等。但注意生產(chǎn)環(huán)境開著debug會(huì)明顯影響性能所以正式版本肯定要把debug關(guān)掉。調(diào)試時(shí)打開、發(fā)布時(shí)關(guān)閉這是常規(guī)操作。我自己用過一個(gè)方法把實(shí)時(shí)日志分成三個(gè)等級(jí)。等級(jí)一只記錄連接狀態(tài)變化和不可恢復(fù)的錯(cuò)誤等級(jí)二記錄收到和發(fā)送的業(yè)務(wù)包摘要比如源地址、目的地址、長(zhǎng)度、類型等級(jí)三記錄每一幀原始數(shù)據(jù)這通常配合抓包對(duì)照。日常調(diào)試開二、三級(jí)正常驗(yàn)證開一級(jí)。這套分級(jí)機(jī)制幫我節(jié)省了大量排查時(shí)間尤其在很多嵌入式環(huán)境中串口日志只有那么小的緩沖區(qū)你不可能把所有信息都打出來。常見定位流程如果設(shè)備連不上服務(wù)器先抓包看在內(nèi)網(wǎng)內(nèi)是否能跟PC通信。如果內(nèi)網(wǎng)通信正常再檢查本機(jī)到服務(wù)器的路由、網(wǎng)關(guān)設(shè)置、DNS解析如果本機(jī)到服務(wù)器之間不通把服務(wù)器端tcpdump抓到看SYN包有沒有到達(dá)。一層層縮小范圍比在代碼里瞎猜有效得多。5. 常見問題排查與避坑實(shí)錄我把這些年經(jīng)歷過的網(wǎng)絡(luò)模塊“靈異事件”整理成了一份問題清單基本每一條都能在真實(shí)項(xiàng)目中找到對(duì)應(yīng)?，F(xiàn)象根因解決方案設(shè)備能連上服務(wù)器但數(shù)據(jù)發(fā)不出去TCP發(fā)送緩沖區(qū)耗盡或滑動(dòng)窗口為0檢查TCP_SND_BUF、窗口是否被對(duì)端聲明為0檢查應(yīng)用層是否阻塞了發(fā)送設(shè)備收到數(shù)據(jù)但校驗(yàn)失敗丟包字節(jié)序處理錯(cuò)誤、或驅(qū)動(dòng)沒有開啟硬件校驗(yàn)和統(tǒng)一使用htons/htonl確認(rèn)校驗(yàn)和由誰(shuí)負(fù)責(zé)驅(qū)動(dòng)還是協(xié)議棧DHCP獲取不到IPDHCP超時(shí)配置過短或UDP廣播數(shù)據(jù)被網(wǎng)卡過濾延長(zhǎng)DHCP請(qǐng)求超時(shí)確認(rèn)MAC地址配置無誤、PHY接收正常網(wǎng)絡(luò)連接斷開了但設(shè)備不知道沒有心跳包或者PHY鏈路檢測(cè)未開啟設(shè)計(jì)心跳機(jī)制周期性檢查鏈路狀態(tài)服務(wù)端連接滿了新用戶連不上MEMP_NUM_TCP_PCB數(shù)量偏小或業(yè)務(wù)層連接列表滿按實(shí)際并發(fā)數(shù)調(diào)整PCB池及時(shí)關(guān)閉不活躍連接收發(fā)大數(shù)據(jù)包時(shí)死機(jī)DMA緩沖區(qū)太小、緩沖區(qū)地址未對(duì)齊按MTU計(jì)算描述符緩沖區(qū)為buffer做cache line對(duì)齊RTOS下網(wǎng)絡(luò)任務(wù)棧溢出socket API或printf消耗大量棧空間加大任務(wù)?；蛘呤褂脤ｉT的日志輸出接口替代printf第一條值得單獨(dú)說說服務(wù)器端聲明窗口為0在TCP里意味著對(duì)端應(yīng)用程序一段時(shí)間內(nèi)沒有讀取數(shù)據(jù)導(dǎo)致接收緩沖區(qū)滿。設(shè)備端如果是發(fā)送方看到對(duì)方窗口為0發(fā)送端要主動(dòng)停止發(fā)送并等待窗口更新。如果設(shè)備端持續(xù)發(fā)送就會(huì)白白消耗帶寬和CPU。所以接收方應(yīng)用層要盡早從socket緩沖區(qū)取走數(shù)據(jù)發(fā)送方也要對(duì)send返回值做判斷不要“發(fā)出去就算成功”。還有一部分問題出在連接剛建好的那一刻。TCP三次握手剛完成服務(wù)器端可能就立刻下發(fā)數(shù)據(jù)你的設(shè)備如果還沒有準(zhǔn)備好接收線程這個(gè)數(shù)據(jù)很可能被丟棄。不過因?yàn)橛谐瑫r(shí)重傳機(jī)制問題不會(huì)立刻暴露但會(huì)出現(xiàn)“偶發(fā)性的第一條消息丟失”很讓人困惑。解決方式是服務(wù)端或者客戶端協(xié)議里加一個(gè)“握手完成確認(rèn)”的機(jī)制比如客戶端主動(dòng)發(fā)送一條應(yīng)用層hello服務(wù)器在收到hello之后再開始業(yè)務(wù)下發(fā)這樣就把競(jìng)態(tài)問題規(guī)避掉了。一個(gè)我踩過多次的坑是關(guān)于PHY寄存器的復(fù)位異常。設(shè)備復(fù)位后百分百連不上或者連接速率變成10Mbps原因往往是PHY配置寄存器沒有在每次上電時(shí)重新寫入PHY內(nèi)部保持的上一次配置是異常狀態(tài)。建議每次系統(tǒng)啟動(dòng)時(shí)都對(duì)PHY執(zhí)行一次完整的軟件復(fù)位加全量配置流程而不是依賴PHY自身的默認(rèn)狀態(tài)。這個(gè)問題起初看起來像硬件問題實(shí)際是軟件初始化不徹底。網(wǎng)絡(luò)模塊還有一個(gè)隱藏坑客戶現(xiàn)場(chǎng)的網(wǎng)絡(luò)環(huán)境遠(yuǎn)比實(shí)驗(yàn)室復(fù)雜會(huì)碰到路由器設(shè)置了MAC白名單、交換機(jī)端口隔離、交換機(jī)緩存區(qū)很小導(dǎo)致丟包等情況。所以產(chǎn)品出廠前盡量多做幾輪現(xiàn)場(chǎng)環(huán)境測(cè)試不只是同事辦公室里的Wi-Fi還要拿到真實(shí)的園區(qū)網(wǎng)絡(luò)、工業(yè)交換機(jī)上跑。6. 寫在最后我的個(gè)人體會(huì)如果一定要給做嵌入式網(wǎng)絡(luò)模塊的朋友提煉幾條核心經(jīng)驗(yàn)我的體會(huì)是這樣的第一盡量選擇維護(hù)充分的開源協(xié)議棧比如lwIP它幫你解決的是TCP/IP最復(fù)雜的細(xì)節(jié)你要做的是把外設(shè)驅(qū)動(dòng)和業(yè)務(wù)邏輯寫扎實(shí)。手寫一個(gè)玩具級(jí)協(xié)議?？梢宰龅珓e在產(chǎn)品里冒這個(gè)險(xiǎn)。第二網(wǎng)絡(luò)模塊編程里“通信協(xié)議設(shè)計(jì)”和“業(yè)務(wù)程序框架”同等重要。很多設(shè)備出問題不是TCP不行而是應(yīng)用層沒有處理好分包、粘包、重連、認(rèn)證這些內(nèi)容。把應(yīng)用層協(xié)議設(shè)計(jì)得足夠完備能夠把“網(wǎng)絡(luò)請(qǐng)求-響應(yīng)-超時(shí)-重試”這個(gè)循環(huán)打穩(wěn)了整個(gè)系統(tǒng)的穩(wěn)定性自然就上來了。第三調(diào)試網(wǎng)絡(luò)問題一定要抓包不要盯著代碼發(fā)愁。網(wǎng)絡(luò)通信是兩端的交互只在一端看代碼很難找到真相。抓包能直接告訴你對(duì)方有沒有收到、回復(fù)了什么省掉至少一半的排查時(shí)間。第四內(nèi)存配置是嵌入式網(wǎng)絡(luò)的隱形關(guān)鍵點(diǎn)。無論你在業(yè)務(wù)邏輯上寫過多少精美的狀態(tài)機(jī)內(nèi)存耗盡了都一樣死給你看。建議把內(nèi)存池統(tǒng)計(jì)做成一個(gè)內(nèi)部調(diào)試接口在產(chǎn)品驗(yàn)證階段多觀察運(yùn)行伏態(tài)才能在正式投入現(xiàn)場(chǎng)之前把隱患清掉。最后再分享一個(gè)小技巧在交付前把網(wǎng)絡(luò)模塊單獨(dú)拎出來做一套故障注入測(cè)試。模擬斷網(wǎng)、斷電重啟、服務(wù)器端主動(dòng)斷開、網(wǎng)絡(luò)風(fēng)暴等異常情況看設(shè)備能不能自動(dòng)恢復(fù)。這一套測(cè)試跑過之后你對(duì)接網(wǎng)絡(luò)模塊的信心會(huì)完全不一樣。畢竟網(wǎng)絡(luò)環(huán)境再差設(shè)備也要能爬起來繼續(xù)干活這才是嵌入式網(wǎng)絡(luò)模塊真正必備的“耐造”能力。