如果說去年的項目教會了我什么那就是幾乎每一個嵌入式設備最終都會被人要求“能不能用網頁看看數據、改改參數”。前幾年我還覺得這只是個偽需求直到親眼看著客戶把筆記本電腦網線直接插到設備上打開瀏覽器輸入IP調參數我才意識到嵌入式Web服務器不是錦上添花而是很多產品從“能跑”走向“好用”的那道門檻。這篇文章是這個系列的開篇主角是很多人入坑嵌入式網絡的第一套經典組合STM32F407 lwIP。我打算用一整篇文章把“在單片機上跑Web服務器”這件事講透——它到底是什么、為什么是F407配lwIP、數據怎么從網線流進瀏覽器、裸機和FreeRTOS兩條路線怎么選、資源賬怎么算以及一條絕對不能碰的安全紅線。適合兩類讀者一是剛接觸lwIP的嵌入式新手二是想給現有產品加網絡能力的工程師。1. 為什么要在單片機里塞一個Web服務器1.1 嵌入式Web服務器是什么和云端服務器差在哪很多人一聽“Web服務器”腦子里蹦出來的是Nginx、Apache、云主機。這是慣性的誤解Web服務器本質就是個“通過HTTP協議響應請求的程序”跟跑在多大的硬件上沒有任何關系。把一套HTTP服務邏輯塞進一塊Cortex-M4單片機里它照樣是Web服務器只不過響應能力、并發(fā)能力跟云服務器完全不是一個量級。我用一個對比把這層關系說清楚對比項傳統(tǒng)Web服務器嵌入式Web服務器硬件資源多核CPU、GB級內存168MHz MCU、192KB SRAM并發(fā)能力幾千上萬個并發(fā)連接同時38個連接就很可觀內容生成動態(tài)語言數據庫字符串拼接、模板填充、靜態(tài)文件部署位置機房、云端設備內部、現場局域網、直連網線訪問規(guī)模全球公網用戶一個工程師或一臺上位機明白了這個定位你就能理解為什么嵌入式Web服務器從設計思路到代碼實現都和互聯網那套東西不一樣。它追求的不是高并發(fā)、高可用而是在極其有限的資源里把“現場可訪問”這條鏈路做通、做穩(wěn)。1.2 一個典型的應用場景現場調試與遠程維護你會問設備本來有串口、有按鍵、有屏幕為什么非要Web頁面我舉一個最常見的場景。設備部署在客戶現場運行一段時間后參數需要微調。傳統(tǒng)做法是工程師扛著筆記本去現場拆開機箱連串口線打開上位機改完參數再封裝回去。這套流程熟練的話也要半小時。而如果設備支持Web服務器工程師手機連上設備同一網段甚至有些設備支持WiFi直連瀏覽器輸一個IP打開配置頁改完點保存收工。從拆箱到改完五分鐘以內。更重要的場景是數據可視化。一臺設備采集溫度、壓力、振動信號傳統(tǒng)上位機要裝軟件、配驅動而Web頁面天生帶有圖表庫、表格渲染能力設備只需要吐出JSON或HTML片段瀏覽器就能畫出漂亮的趨勢曲線。這就是為什么現在越來越多的工業(yè)設備、醫(yī)療儀器、檢測裝置都在出廠時標配一個隱藏的Web管理頁面。1.3 靜態(tài)頁面與動態(tài)頁面嵌入式Web的靈魂在后者嵌入式Web服務器里有兩種頁面新手最容易混為一談。第一種是靜態(tài)頁面HTML、CSS、JS文件提前編譯好存放在Flash文件系統(tǒng)里LittleFS、SPIFFS或者干脆一個C數組用戶訪問時原樣下發(fā)。這種頁面的價值在于“展示”比如設備銘牌信息、說明書下載。第二種是動態(tài)頁面頁面里的實時數據是服務器“現場生成”的。比如溫度值不是存在Flash里的固定數字而是每次請求時從傳感器讀取、格式化成HTML片段再返回。動態(tài)頁面才是嵌入式Web服務器真正的價值所在沒有動態(tài)數據能力的Web頁面跟一個pdf說明書沒區(qū)別。實現動態(tài)頁面的經典套路有兩個CGI回調和SSI注入。CGI適合處理表單提交、URL操作指令這類“用戶主動觸發(fā)”的動作SSI適合頁面加載時自動填充實時值。這兩者的細節(jié)我會放在系列后續(xù)文章里展開這篇你只要記住一個結論設計頁面時先分清哪些內容靜態(tài)、哪些內容動態(tài)這會直接決定后續(xù)代碼是怎么組織的。2. F407 lwIP的組合到底贏在哪2.1 硬件底氣的關鍵F407內置以太網MAC很多人選型時會糾結STM32F407到底憑什么成為網絡應用的首選答案很直接它內置了10/100M以太網MAC控制器。這里要先給小白補一個概念。以太網物理接口分兩層MAC層負責數據封裝、地址過濾、差錯檢測是數字邏輯PHY層負責把數字信號轉換成網線上傳輸的模擬差分信號。STM32F407內部集成了MAC意味著它可以直接外接一顆便宜的PHY芯片最常見的是LAN8720、DP83848就能上網不需要用SPI轉以太網芯片。SPI轉以太網方案比如W5500雖然硬件上更省事但有幾個繞不開的痛點吞吐量受限于SPI總線速率協議棧跑在芯片內部不好定制數據包緩沖區(qū)太小遇到大流量、長連接時容易丟包。而STM32F407用RMII接口連接PHYDMA直接把網絡幀搬進內存吞吐量輕松跑滿100Mbps而且協議棧完全由自己掌控靈活性和性能都比SPI方案高一個檔次。對于要做Web服務器的項目這個差距是決定性的。2.2 CCM RAM的暗坑DMA碰不到的那塊內存提到F407的資源必然繞不開CCM RAM。F407有192KB普通SRAM加上64KB CCM RAM很多新手一算256KB內存呢跑lwIP綽綽有余。這個賬算錯了而且錯得隱蔽。CCM RAM是內核私有內存只有CPU能訪問DMA包括以太網DMA和外設總線碰不到。lwIP收發(fā)數據包主要靠以太網DMA搬運如果你圖省事把網絡緩沖區(qū)分配在CCM RAM里結果就是網卡根本收不到數據。這幾乎是每個移植lwIP的人都會踩一遍的坑。正確做法是協議棧的數據包緩沖區(qū)、DMA描述符必須放在0x20000000開頭的普通SRAM區(qū)域CCM RAM只放那些CPU直接處理的中間數據比如網頁內容拼接的臨時緩沖區(qū)、加密算法的工作區(qū)。我這里特意把普通SRAM和CCM RAM的區(qū)別列出來方便你后面自己寫鏈接腳本時對照檢查項目普通SRAMCCM RAM起始地址0x200000000x10000000容量192KB64KBCPU訪問支持支持DMA訪問支持不支持適用場景網絡緩沖區(qū)、DMA描述符、全局變量加解密工作區(qū)、CPU高頻計算的臨時數據2.3 軟件側的理由lwIP專為嵌入式而生硬件選對了軟件也得匹配。lwIPLightweight IP是瑞典計算機科學研究院開源的輕量級TCP/IP協議棧它就是為嵌入式設備設計的。跟Linux那種完整的協議棧不同lwIP從內存管理到協議實現都做了嵌入式適配。它支持IPv4/IPv6、TCP、UDP、ICMP、IGMP、DHCP、DNS這些常用協議代碼結構很清晰可控性強。更重要的是它有三種運行模式RAW API無操作系統(tǒng)、Netconn API帶RTOS的中間層、Socket API類BSD套接字。這意味著同一個lwIP既可以跑在裸機上做簡單應用也可以掛在FreeRTOS下做一個完整的網絡子系統(tǒng)。lwIP的內存管理也是一大亮點。它不用標準malloc而是用內存池memp和內存堆mem兩種策略組合避免嵌入式環(huán)境頻繁動態(tài)分配造成碎片。數據包使用pbuf機制通過引用計數避免數據拷貝一個數據包從網卡驅動一路傳到應用層全程零拷貝。這種設計思路對于只有一兩百KB內存的MCU來說非常關鍵。2.4 為什么不上Linux偏要在單片機上遭罪這是我在技術交流群里被問爛了的問題“F407都能跑網絡了直接上一塊ARM Linux不香嗎”香但要看前提。Linux方案一般要換A7/A9級別的處理器外圍電路復雜度、PCB面積、功耗、BOM成本同步上漲。對一個只做參數采集、定時上報、頁面配置的設備來說殺雞用牛刀。更重要的是很多設備的啟動時間要求在秒級甚至毫秒級Linux從boot到網絡服務就緒往往要好幾秒而F407的lwIP可以在上電后幾百毫秒內完成網絡初始化。我對這個問題的判斷是項目選型不是找“性能最強”的平臺而是找“剛好夠用”的平衡點。F407 lwIP適合的是中低資源、高實時性、成本敏感的工業(yè)控制類產品。如果你要跑數據庫、人工智能推理、大規(guī)模Web應用那自然要上Linux甚至服務器這不在本系列的討論范圍。3. 數據是怎樣從網線流進瀏覽器的3.1 把整條鏈路拆開看從MAC到協議棧寫代碼之前腦子里必須有一條完整的數據通路圖。瀏覽器地址欄敲下http://192.168.1.100到頁面顯示出來這段旅程在F407這邊是這樣的PHY芯片把網線上的模擬信號轉成數字比特流通過RMII接口傳到STM32的MAC控制器。MAC控制器按以太網幀格式校驗目標MAC地址、CRC校驗通過DMA把幀數據搬運到內存中預先分配好的接收緩沖區(qū)。以太網驅動HAL庫或標準庫的ETH驅動檢查DMA描述符發(fā)現新幀到達后構造一個pbuf結構把數據包掛到lwIP的netif接口上。lwIP協議棧逐層解析先剝開以太網頭交給IP層IP層判斷是本地數據包剝開IP頭交給TCP層TCP層按端口號找到對應的控制塊PCB把應用數據放到接收隊列里。應用層的HTTP服務器從TCP接收隊列里取出字節(jié)流解析出HTTP請求行GET路徑、HTTP版本、請求頭、請求體然后根據路由調用對應的處理邏輯。響應路徑反向走一遍構造HTTP響應頭和正文按TCP分段大小切割交給IP層封裝再交給MAC和DMA發(fā)送出去PHY把數字信號轉成模擬信號送上網線。這個鏈路里的每個節(jié)點都可能成為瓶頸。驅動層沒處理DMA描述符回收接收幾幀就卡死協議棧的中斷處理沒做好臨界區(qū)保護數據就出錯應用層處理太慢TCP窗口就會縮小吞吐量上不去。所以調試時永遠要用“分段驗證”的思路先讓Ping通再試TCP連接最后才調試HTTP內容。3.2 動態(tài)網頁的兩種經典機制CGI與SSI應用層與瀏覽器交互最常見的就是CGI和SSI這也是目前l(fā)wIP httpd里仍然主打的機制。CGICommon Gateway Interface在lwIP里的實現思路是當URL匹配某個路徑時協議棧調用你注冊的回調函數你在這個函數里解析參數、執(zhí)行動作、生成響應內容。舉個例子你點擊網頁上的“重啟設備”按鈕表單POST到/api/rebootCGI回調里識別到這個路徑執(zhí)行NVIC_SystemReset()然后返回一個“設備重啟中”的提示頁面。CGI適合做“動作型”請求。SSIServer Side Include則適合“采集型”需求。你在HTML模板里寫一個特殊標記比如p當前溫度!--#echo vartemperature -- ℃/plwIP httpd在發(fā)送這個頁面時會掃描這些標記每遇到一個就調用一個名為tcpip_callback的處理函數把temperature這個變量的實時值替換進去再繼續(xù)發(fā)送。瀏覽器看到的就是已經填充好的完整HTML整個過程對前端透明。選擇CGI還是SSI有個很實用的判斷標準頁面需要“主動拿數據”時用SSI頁面需要“觸發(fā)動作或提交配置”時用CGI。兩者經常配合使用一個頁面里用SSI顯示當前參數值用CGI處理修改請求。3.3 一封HTTP響應的最小實現對于剛開始跑通TCP、還沒引入httpd的開發(fā)者用原始socket API手動拼一個HTTP響應是理解協議本質的好辦法。下面這段代碼演示了收到HTTP請求后返回一個最簡單的HTML頁面static const char http_ok[] HTTP/1.1 200 OK\r\n Content-Type: text/html\r\n Content-Length: 62\r\n Connection: close\r\n \r\n htmlbodyh1HELLO STM32/h1/body/html; void http_send_response(struct tcp_pcb *pcb) { tcp_write(pcb, http_ok, strlen(http_ok), 1); tcp_output(pcb); }注意幾個細節(jié)Content-Length必須和正文長度嚴格一致不然瀏覽器會一直等后續(xù)數據Connection: close告訴瀏覽器響應發(fā)完就關連接省得管理長連接HTTP頭結束后的空行\(zhòng)r\n\r\n不能省否則犯規(guī)。這段代碼雖然簡單但把HTTP協議的本質暴露得一清二楚——它就是一堆文本協議按約定格式排版輸出就行。4. 裸機與RTOS兩條主流的lwIP運行路線4.1 裸機輪詢模型直觀但天花板低lwIP移植有兩個經典流派裸機和RTOS。新手從CubeMX生成工程時常常糾結選哪個我建議先理解區(qū)別再做決定。裸機模式下lwIP協議棧不是靠獨立線程驅動的而是在主循環(huán)里反復調用兩個函數ethernetif_check檢查是否有新數據到達有則處理和sys_check_timeouts處理TCP定時器、重傳等。整個協議棧和應用代碼共享同一個執(zhí)行上下文不允許阻塞。裸機模式的好處是省去了RTOS的開銷和任務切換的復雜性代碼執(zhí)行路徑非常清晰。但壞處同樣明顯如果在某個地方跑一個長循環(huán)比如驅動外設的延時等待網絡數據包就無法及時處理TCP重傳超時高一點的連接直接就斷掉了。在帶操作系統(tǒng)模型的對比下裸機項目一旦功能多起來幾乎必然碰到這種“顧此失彼”的尷尬。4.2 FreeRTOS多線程模型產品級項目的標配RTOS模式下lwIP以獨立的線程運行。最常見的做法是創(chuàng)建三個線程tcpip_thread處理TCP/IP協議棧、ethernetif_thread負責從網卡收包、交由tcpip線程解析、以及應用層自己的線程如web_server_thread監(jiān)聽80端口處理HTTP請求。應用線程與協議棧之間用netconn或socketAPI通信機制與PC上寫網絡程序很像。調用accept、recv時線程會主動休眠不會占著CPU死等。某一路連接卡住最多影響當前線程其他任務照常運行。這種模型下Web服務器狀態(tài)查詢、傳感器采集、邏輯控制可以并行才是產品級設備的正常形態(tài)。從裸機升級到RTOS后要注意lwIP線程的優(yōu)先級設計。以太網收包線程的優(yōu)先級要高于普通應用線程但低于系統(tǒng)滴答和硬件中斷。否則一旦應用線程忙于計算網絡線程搶不到CPU同樣會出現連接卡頓這就是很多人把FreeRTOS移植好后網速反而變慢的原因。4.3 兩種模型怎么選一張對比表對比維度裸機輪詢FreeRTOS多線程實時性差受主循環(huán)阻塞影響好任務獨立調度開發(fā)難度簡單直接需要理解同步機制資源開銷省去RTOS約2~4KB RAM每個任務棧約1~2KB多連接處理有限需要狀態(tài)機容易每個連接一個線程適用場景簡單Demo、小工具產品級、多外設并發(fā)項目擴展性加功能后急劇惡化良好模塊天然隔離如果你只是跑個Demo驗證流程裸機完全夠用但做真正的產品直接上FreeRTOS模型省得后面推倒重來。系列后面的文章里我會把兩種模型的CubeMX配置分別跑一遍到時會展示其中的關鍵差異。5. 功能上限與資源賬一張表看清能做什么5.1 典型功能矩陣與開銷估算很多人立項時最關心的是F407上到底能跑多“豪華”的Web應用我直接給一張基于實際工程經驗的功能矩陣表每項功能的實現方式和資源開銷都列清楚功能實現方式額外Flash開銷額外RAM開銷難度靜態(tài)產品頁LittleFS 網頁文件取決于網頁大小約2KB文件系統(tǒng)緩沖低實時數據曲線SSI注入 Chart.js前端網頁文件占用約1KB中參數配置CGI解析表單 Flash存儲約3KB代碼約1KB中日志查詢文件系統(tǒng)讀接口 Web列表頁約5KB代碼約4KB中高WebSocket推送lwIP 自實現WebSocket層約8KB代碼每個連接約2KB高Web OTA升級HTTP Post接收 Flash寫入約6KB代碼約8KB文件緩沖高HTTPS加密mbedTLS 證書預置約30~60KB代碼握手時約16KB很高注意表格里的RAM開銷是指“疊加項”實際工程中多個模塊同時啟用峰值內存還要看數據包緩沖區(qū)的并發(fā)占用。我見過一個功能暴多的項目RG到了192KB的邊緣最后只能把TCP窗口調小才勉強壓下來。5.2 lwIP裁剪把不用的協議都關掉lwIP的默認配置是“開著所有功能”的直接用會很浪費資源。配置文件lwipopts.h就是干這個事的我在實際項目中一般這么調關閉IPv6內部局域網環(huán)境根本用不上省下大量代碼和內存。限制TCP連接數MEMP_NUM_TCP_PCB從默認10降到4夠用就行。調整TCP窗口TCP_WND和TCP_SND_BUF可以設成4KB~8KB不要貪大。關閉不用的協議沒有組播需求就關IGMP不需要自動IP分配可以關LWIP_DHCP但大多數板子建議開著方便接入路由器。裁剪的原則是“按需開啟能關就關”。一次發(fā)布前把所有不用的模塊關掉代碼體積能縮小30%內存碎片也明顯減少。這塊的詳細配置我在系列的第八篇里會專門出一篇“l(fā)wIP配置項逐項拆解”。5.3 日志存儲與Web查詢的組合場景熱詞里有一條“基于STM32F407的日志存儲記錄方法”這確實是Web服務器一個非常實用的組合方向。設備運行日志原來都存在Flash里查詢只能通過串口一條條翻用戶體驗極差?，F在方案很簡單日志寫入Flash環(huán)形區(qū)或者LittleFS文件Web服務器加一個/log路由按時間倒序渲染成HTML表格。配合前端的模糊搜索、翻頁功能現場排查故障的效率能提升一個量級。這里要注意一個工程細節(jié)不要把日志寫入Web服務的文件系統(tǒng)同一個頻繁寫的文件。我見過有人把系統(tǒng)日志和網頁文件放在同一個分區(qū)日志頻繁擦寫最后把網頁文件也擦壞了。正確做法是按功能分區(qū)或者利用LittleFS的目錄功能把/www和/log分開并控制日志文件的最大尺寸寫滿后滾動覆蓋。6. Web服務器的安全底線別裸奔著上線6.1 嵌入式Web服務器的風險面有多大很多工程師覺得“我的設備只在內網跑不會有人攻擊”這是大錯特錯的。設備接入局域網后它就是一個暴露在網絡的節(jié)點任何在內網的主機、甚至通過漏洞進入內網的攻擊者都能直接對這個設備發(fā)起探測。而嵌入式設備恰恰是最容易淪陷的目標協議棧追求輕量、代碼審查不嚴格、默認不設防、上線后無人運維打補丁。常見的風險點就這么幾個默認無認證任何人都能打開頁面改參數甚至重啟設備。明文傳輸HTTP協議明文發(fā)送登錄密碼、設備數據在局域網里可以被抓包截獲這個風險我后面會花大篇幅講。緩沖區(qū)溢出如果CGI處理不校驗輸入長度惡意超長字符串可能直接打穿協議棧。固件升級漏洞OTA接口一旦被利用等于把設備完全交給攻擊者。6.2 分級防守從認證到TLS安全不能一刀切結合項目成本、設備算力我建議按下面的層級逐步加強第一級最基本的賬號密碼認證。lwIP httpd支持Basic Access Authentication在網頁根目錄里配置.htpasswd類似的文件瀏覽器訪問時彈出用戶名密碼框。這個實現的代碼量很小但要注意Basic認證的密碼是Base64編碼能防君子防不了小人只適合“防誤操作”不適合“防攻擊”。第二級加入會話管理。密碼驗證通過后服務器發(fā)一個帶時間戳的Token之后的請求都帶這個Token超過5分鐘無操作自動失效。前端配合一個登錄頁和axios攔截器這部分代碼量大概幾百行但能堵住明顯的匿名訪問通道。第三級上TLS做HTTPS。lwIP本身不帶TLS但可以配合mbedTLS實現。要注意的是F407沒有硬件加解密引擎RSA握手要消耗幾秒CPU時間證書校驗也吃內存。實際項目中我的做法是預置客戶端證書、使用ECC算法比RSA快很多、只啟用AES-128-GCM這樣的輕量TLS版本才能在F407上流暢跑。6.3 lwIP本身有哪些安全槽點要填lwIP作為嵌入式協議棧它的設計目標本來就是“輕量”不是“安全”有一些默認配置需要手動加固。一是關閉調試打印泄漏信息。開發(fā)階段開著LWIP_DEBUG沒問題release版本一定關掉否則協議棧內部的IP、端口、緩沖區(qū)狀態(tài)都從串口泄露出來等于給攻擊者遞地圖。二是嚴格校驗用戶輸入。CGI解析里所有來自URL的參數都要做長度和范圍檢查尤其是用于拼接字符串、文件路徑的參數絕對不能直接拼進去。字符串格式化時用snprintf代替sprintf避免緩沖區(qū)溢出。三是限流與超時。httpd服務器要設置連接超時空閑連接自動關閉對頻繁請求同一個URL的客戶端可以做簡單的頻率限制避免設備被一個腳本就打到資源耗盡。四是保持lwIP版本更新。lwIP社區(qū)會修復一些安全漏洞定期拉到最新穩(wěn)定版看著麻煩卻是最省心的安全措施。7. 系列路線圖與動手前的準備清單7.1 這個系列接下來會講什么標題里帶了“一”我得把后續(xù)的路數交代清楚免得追更的朋友不知道這條線怎么走。本篇目標是幫你建立整體認知下一篇開始進入硬核實操二CubeMX圖形化配置F407以太網與lwIP手把手搭建裸機版lwIP工程搞定PHY初始化、RMII引腳分配讓Ping通。三移植到FreeRTOS多線程模型下的httpd帶你配置CubeMX的OS選項創(chuàng)建tcpip線程讓Web服務器跑在RTOS上。四CGI應用實戰(zhàn)做一個表單頁面通過網頁修改設備參數并保存到Flash。五SSI動態(tài)頁面實戰(zhàn)做實時數據監(jiān)控面板溫度、電壓每秒刷新。六WebSocket讓數據主動推送解釋為什么輪詢效率低實現服務器主動推送。七Web OTA固件升級網頁上傳固件設備自動重啟升級同時講斷電保護的實現技巧。八lwIP配置項逐項拆解把lwipopts.h里的關鍵宏挨個講一遍讓你徹底告別“照抄配置”。九HTTPS安全加固mbedTLS與lwIP的集成實戰(zhàn)。寫這么多篇不是為了湊數而是這個知識體系確實一環(huán)套一環(huán)。你跟著走完基本能獨立給任何一款MCU做Web服務器方案了。7.2 你需要準備的硬件和軟件類別推薦工具/器件備注開發(fā)板正點原子、野火的STM32F407系列帶網口板帶LAN8720或DP83848 PHY配RJ45網口額外PHY板LAN8720模塊RMII如果自制板子參考Datasheet調50MHz時鐘軟件工具STM32CubeMX、Keil MDK / IAR器重力推CubeMX工程生成省心網絡工具Wireshark、PuTTY、瀏覽器開發(fā)者工具抓包調試是網絡開發(fā)的命根子輔助工具串口調試助手、邏輯分析儀用來調試驅動層時序其中Wireshark請你務必裝上它能把每一次HTTP請求、TCP握手、重傳都原原本本顯示出來。我調網絡問題這么多年90%的疑難雜癥最后都是靠抓包數據說話才定位到的。沒有它你只能靠猜。7.3 給新手的幾條建議這個系列內容量大我不希望你一開始就想著把所有東西都看懂。建議按下面的節(jié)奏來第一條先跑通再理解。不要上來就啃l(wèi)wIP源碼先用CubeMX生成一個能Ping通的工程找到“通了”的感覺再反過來研究為什么通。第二條抓包是你的眼睛。任何一次網絡連接異常先抓包看數據有沒有發(fā)出來、有沒有回包、協議棧有沒有報錯比盯著代碼發(fā)呆高效十倍。第三條先裸機再上RTOS。如果兩個模型都不懂先用裸機跑通整個Web Server鏈路再遷移到FreeRTOS這樣出問題時你知道是協議棧的問題還是任務調度的問題。第四條每次只改一個變量。調完PHY驅動測通PingPing通了再開TCP調試TCP通了再寫HTTP。跳著調只會讓問題疊加越查越亂。我在第一次調通整個Web服務器時站在接線的板子前愣了半天就這么個不起眼的芯片居然也能吐出一個完整的網頁。那種感覺到現在都還記得。所以你也別急跟著整個系列一步一步走這個組合的樂趣你很快就能體會到。