开头先聊点实在的很多玩STM32F407的朋友跑通了裸机点灯、串口收发之后下一步大概率就想折腾以太网。F407这颗片子自带MAC控制器配一颗外部PHY芯片就能上网但不少人卡在“MAC初始化成功、PHY也读到了ID可就是ping不通”这个阶段然后就开始怀疑人生。其实问题多半不在硬件而是lwIP协议栈的移植细节没处理好或者HTTPD服务器的资源分配没到位。这篇文章是系列第二篇重点放在两件事上一是基于STM32CubeMX图形化配置把lwIP协议栈完整跑起来讲清楚几个关键参数为什么这样设二是在lwIP之上搭建HTTPD网页服务器实现浏览器访问开发板、读取传感器数据、控制LED这类常用功能。适合手里有F407开发板、想从“点灯”进阶到“联网”的嵌入式开发者也适合在产品里需要快速集成Web管理界面的工程师参考。1. 移植前的工程规划与CubeMX配置里最容易踩的坑先说结论如果还在手写lwIP移植文件、手动拷贝源码进工程我建议立刻停掉。STM32CubeMX对lwIP的集成已经非常成熟它能自动生成网卡驱动接口eth.c/h、lwIP内核配置lwipopts.h、内存配置等一整套文件省去大量手工移植的麻烦。F407的MAC是内核自带的不需要外部MAC芯片CubeMX只需要配置RMI接口和PHY芯片型号即可。1.1 硬件连线与PHY芯片选型F407支持MIIMedia Independent Interface介质无关接口和RMIIReduced Media Independent Interface简化的介质无关接口两种模式。强烈建议用RMII它只需要9根信号线而MII需要16根。RMII模式要求PHY芯片的时钟由外部50MHz提供常见做法是让STM32的MCO1引脚PA8输出50MHz给PHY芯片的XI时钟脚。市面上最常见的PHY是LAN8720A支持RMII带自协商功能价格便宜而且CubeMX里有现成的LAN8742A选项可以选这两者引脚兼容配置基本通用。接线一般是PA8MCO1接PHY的XI/CLKIN提供50MHz参考时钟PC1ETH_MDC、PA2ETH_MDIO接PHY的MDC/MDIO配置口PA1ETH_RMII_REF_CLK接PHY的REF_CLKPA7ETH_RMII_CRS_DV、PC4ETH_RMII_RXD0、PC5ETH_RMII_RXD1PB13ETH_RMII_TXD0、PG14ETH_RMII_TXD1、PB11ETH_RMII_TX_EN一个必须注意的细节PHY地址配置。LAN8720A的PHY地址由引脚RXER/PHYAD0的电平决定大多数模块默认接地地址为0x00所以CubeMX里PHY Address填写0。如果你的板子接了上拉电阻就要改成1否则读不到PHY的ID后续网络会莫名其妙地不稳定。1.2 时钟树里被忽略的50MHz配置许多朋友在CubeMX里配置完ETH外设生成代码后编译下载发现PHY芯片没有被正确初始化检查寄存器返回值全是0xFF。原因多半是MCO1脚没有配置成50MHz输出或者RCC时钟树的HSE、PLL参数不对。F407的系统时钟最高168MHz但MCO1输出50MHz需要从PLL的Q分频取得并不是简单的“选个50MHz”就行。正确做法是把HSE配置为外部晶振开发板一般是8MHz或25MHzPLL源选择HSE然后在RCC的MCO输出配置里选择PLLCLK并手动填上/4分频确保输出恰好是50MHz。整个过程在CubeMX的Clock Configuration页里可以直接看到图形化的结果调试时特别直观。1.3 RMII模式与ETH外设参数建议在CubeMX的ETH选项卡里有以下几个重点参数PHY Address改成交互式排查后的实际地址默认0最省事PHY ClockRMII模式选External外部50MHz输入MAC Address可以随便编一个但要注意别跟局域网内其他设备冲突MDC Clock Range2.4MHz到2.52MHz之间选择生成代码之前建议把ETH的高级参数Advanced parameters展开看一眼保持默认即可一般不需要改。如果后面遇到网络速度异常再回来把“ETH_DMA_RX_MODE”从Polling改成Interrupt或者调整TX/RX描述符数量。2. lwIP关键配置与内存分配的取舍逻辑CubeMX生成工程后lwIP的配置集中在lwipopts.h和lwip.c里。很多新手在这里容易犯一个错误看到能通过编译就以为配置没问题结果运行起来要么ping丢包严重要么HTTPD访问极慢。下面几个参数是被验证过最值得花心思调整的。2.1 MEM_SIZE与内存堆大小lwIP运行需要两类内存内存堆heap用于核心数据结构的动态分配内存池memp用于固定大小的数据包缓冲。F407的片上RAM是192KB其中64KB位于CCM不能直接被以太网DMA使用所以可用的普通RAM约128KB左右。CubeMX默认给MEM_SIZE1600字节这明显偏小。假如你的HTTPD要同时处理几个连接、还要缓存网页文件内存不够就会导致连接被丢弃、网页加载一半就断了。我实测把MEM_SIZE改到10KB~12KBDHCP和TCP并发能力才有明显改善。但也不能无限大因为PBUF、TCP_WND、UDP等还要单独占用内存留个10KB左右给RTOS任务栈和用户代码比较稳妥。2.2 PBUF池与TCP窗口PBUF池的数量直接影响数据包接收能力。数值太小网络高频数据涌入时缓冲区耗尽丢包重传导致速度雪崩。默认15个PBUF只能满足基本的ping和网页访问如果要做数据传输或TCP长连接建议调到25~30个。TCP_WND窗口大小决定发送端填充速度。CubeMX默认TCP_WND4096这个数值配合每包1460字节的MSS最大分段大小刚好能支持3个包同时在途。如果网站页面超过4KB浏览器就要等确认才能继续发请求会感觉卡顿。可以改成8192但要注意每增加1字节窗口内存占用也同步增加。2.3 关于CCM内存的使用误区F407有一块特殊的64KB CCM RAM0x10000000起始只能被内核访问不能被DMA外设访问。lwIP的PBUF和DMA描述符如果分配在CCM以太网控制器无法正常读取表现就是“永远收不到数据包”。CubeMX生成的ETH描述符默认放在普通RAM一般不会出问题。但如果你手动优化了内存布局把.ccm段用起来就一定要确认lwIP的缓冲区、描述符、DMA相关变量都在普通RAM区域。我见过一个案例有人把整个.bss段搬进CCM结果MDIO能读到PHY寄存器但RMII收包永远失败查了两天才定位到内存归属问题。3. HTTPD服务器的实现不仅仅是把网页丢进去很多人误以为HTTPD服务器就是把一个HTML文件放在Flash里、系统自动提供访问其实在嵌入式场景下页面往往是动态的需要实时反映设备状态。lwIP的HTTPD模块为我们提供了一套完整的解决方案静态页面预编译、CGI调用、SSI标签替换。3.1 静态页面设计就是从C数组里读HTMLlwIP的HTTPD默认从fsdata.c读取网页内容。CubeMX生成的工程里fsdata.c是空的。要把一个HTML文件放进去需要两步准备一个index.html文件内容可以是带CSS样式、简单的JavaScript的网页注意编码用UTF-8。用makefsdata工具把HTML转成C数组生成fsdata.c替换工程里的模板文件。这个工具默认不生成在工程里需要去找lwIP源码目录下的contrib文件夹找到后编译运行把HTML文件拖进去即可生成。如果觉得麻烦也可以直接手写一个简单的网页结构体但一旦更新网页内容还要重新转很繁琐强烈建议用工具。网页文件本身要控制体积。F407的Flash有1MB放一个几十KB的页面完全没问题但不建议塞大型图片或gif一方面浪费Flash另一方面HTTPD服务器是单线程处理的大文件会阻塞其他设备的访问。3.2 CGI机制让网页与MCU交互CGICommon Gateway Interface通用网关接口是HTTPD服务器一个非常实用的功能。它的原理是当浏览器请求某个带?cmdxxx的URL时服务器调用用户注册的CGI处理函数处理这个请求然后把响应返回给浏览器。举个实际例子控制LED在HTML里写一个链接a href/cgi-bin/led?state1打开LED/a在main.c里注册CGI处理器#include lwip/apps/httpd.h static const tCGI cgi_handlers[] { {/led, tcp_led_cgi_handler}, }; static const char *tcp_led_cgi_handler(int iIndex, int iNumParams, char *pcParam[], char *pcValue[]) { if (iNumParams 1 strcmp(pcParam[0], state) 0) { if (strcmp(pcValue[0], 1) 0) { HAL_GPIO_WritePin(LED_GPIO_Port, LED_Pin, GPIO_PIN_RESET); return /led_on.html; } } return /led_off.html; }主函数里注册表httpd_init(); http_set_cgi_handlers(cgi_handlers);这里有个容易被忽略的细节返回值必须是预编译在fsdata.c里的网页文件路径。也就是说你需要提前准备一个led_on.html和led_off.htmlCGI处理后跳转到对应页面哪怕页面内容就一行字也必须存在。否则服务器会返回404。3.3 SSI机制网页中直接插入实时数据SSIServer Side Include服务器端嵌入是比CGI更轻量级的动态页面方案。原理是在HTML里写特殊标记服务器解析到标记时调用函数获取值替换后再发给浏览器。比如在index.html里写温度!--#echo vartemp --然后在代码里#include lwip/apps/httpd.h static const char *ssi_handler(int iIndex, char *pcInsert, int iInsertLen) { float temp read_temperature(); // 假设函数 snprintf(pcInsert, iInsertLen, %.2f, temp); return pcInsert; } ... htd_ssi_set_handler(ssi_handler);还有一步关键操作让HTTPD把.shtml文件当作SSI文件处理。如果你的网页文件后缀是.html服务器默认不做SSI替换。确保网页文件名是.shtml或者修改HTTPD配置。3.4 GET请求与POST请求的处理差异很多初学者在嵌入式HTTPD里纠结“POST请求怎么处理”实际上lwIP提供了两种方式GET请求拼接URL参数走CGI机制适合控制类操作如开关LED。POST请求lwIP的CGI不支持POST需要用户自己注册回调函数处理HTTP请求体。如果项目里必须处理POST比如提交表单数据可以用httpd_cgi_handler的变体altcp_httpd_post_begin函数。但我的经验是嵌入式设备尽量用GET SSI组合。POST的场景往往可以重构成JSON WebSocket方案后面会细说。4. 网络连接不稳定时的排查清单辛辛苦苦配置完网页也加载出来了但动不动就掉线、ping一顿一顿的这种问题最能消磨耐心。以下是我实际调试过程中验证过有效的一套排查顺序。4.1 第一步确认PHY地址与自协商结果先用逻辑分析仪或调试器读PHY寄存器LAN8720A的寄存器1是BCSR0x100表示自协商完成且连接正常。如果读不到这个值多半是PHY地址不对或者RMII时钟没起来。调试器里读寄存器的方法uint32_t phy_id 0; HAL_ETH_ReadPHYRegister(heth, PHY_ADDRESS, PHY_BCR, tmp); HAL_ETH_ReadPHYRegister(heth, PHY_ADDRESS, PHY_BSR, tmp);如果你的PHY地址配置错误读出来的寄存器要么全1、要么全0这时去检查CubeMX里的PHY Address同时在硬件上确认PHYAD引脚的拉电阻。4.2 第二步检查RMII参考时钟相位RMII标准下STM32的RMII_REF_CLKPA1和PHY的REF_CLK输出是同相位的50MHz。如果PCB布线走了很长的线相位偏移可能导致采样错误。排查方法用示波器量PA1引脚和PHY的REF_CLK引脚确认频率稳定在50MHz且没有大幅抖动。再检查MCO1配置是否被外设抢占某些工程开启SDIO后MCO1会被复用导致PHY时钟丢失。4.3 第三步lwIP任务优先级与RTOS调度如果使用了FreeRTOS lwIP的组合网络线程tcpip_thread优先级设置不当会导致网络卡顿。tcpip_thread要高于ethernet_input_thread如果单独开了收包线程但通常建议把所有网络相关线程统一定在较高优先级并在defaultTask里只做低负载的周期性任务。实际操作中我习惯把tcpip_thread优先级设为6默认值ethernet_input_thread设为5DHCP线程设为4。用户任务优先级低一些不影响网络反而因为网络线程优先级高ping响应总能快速处理。4.4 第四步网线连接状态与自动协商RMII模式对网线质量敏感尤其是100Mbps全双工模式。如果开发板与路由器之间用的是劣质网线或者距离过长自协商失败会导致速率变慢或闪断。处理方法在PHY初始化后强制将速度/双工设置为100M/Full绕过自协商。LAN8720A的寄存器0BCR的bit13写1、bit8写0即可关闭自协商强制百兆全双工。提示调试前期建议强制固定速度排除自协商干扰功能跑通后再恢复成自适应确保兼容各类交换机。5. 从HTTPD到WebSocket页面实时刷新的另一种思路如果只是监控温度、传感器数据HTTPD SSI足够但页面要频繁刷新每次都重新加载整个HTML显得很浪费而且体验不佳。一个更好的方案是把HTTPD作为页面加载入口页面内的JavaScript通过WebSocket或Ajax请求从MCU获取数据实现局部刷新。5.1 用Ajax轮询实现秒级数据刷新最简单的方法是借助XMLHttpRequest定时请求一个数据接口比如让CGI处理函数返回JSON字符串static const char *get_data_cgi(int iIndex, int iNumParams, char *pcParam[], char *pcValue[]) { snprintf(json_buf, sizeof(json_buf), {\temp\:%.2f,\humi\:%.2f}, temp, humi); return json_buf; }页面端用JavaScript每隔500毫秒请求一次/cgi-bin/get_data数据更新及时页面不用刷新内存占用也不高。这种方式对F407来说非常轻松实测CPU占用不到5%。5.2 WebSocket的引入时机与硬件条件如果数据频率要超过10Hz比如需要实时绘制波形、远程遥控小车Ajax轮询的开销就不划算了此时WebSocket才是正解。但F407跑WebSocket需要额外移植lwIP的WebSocket库lwIP的contrib里自带了一个实现内存消耗也更大达到几十KB量级。所以我的建议是先评估项目对时延和频率的需求。一般的环境监测、设备状态页Ajax轮询足够只有涉及音频、视频流、高频控制信号时才值得上WebSocket。6. HTTPD服务器与FreeRTOS共存时的时间切片策略CubeMX在生成lwIP工程时可以在Middleware and Software Packs里把FreeRTOS配置上并与lwIP同时启用。这种组合在生产环境很常见但需要处理一个调度问题HTTPD服务器和用户任务的执行时间如何划分。6.1 任务栈大小与堆栈溢出监控tcpip_thread和httpd相关任务默认栈大小是1024字节到2048字节。如果网页文件比较大、SSI处理比较复杂栈可能溢出表现是运行十几分钟后死机。建议把tcpip_thread栈调到2048字节以上httpd_thread栈调到4096字节。同时开启FreeRTOS的栈溢出钩子函数日常开发阶段打印日志定位void vApplicationStackOverflowHook(TaskHandle_t xTask, char *pcTaskName) { // 在这里打印任务名方便定位 }6.2 时间片分配与周期任务HTTPD本身是被动响应型任务只要有请求进来才处理不会一直占用CPU。所以时间片冲突主要发生在你自己写的周期性用户任务大量占用CPU时间时比如软件算法循环。要避免网络响应卡顿需要给网络任务足够的运行窗口。简单粗暴的方法是降低用户任务的频率比如温度采集从1ms周期改成10ms周期。还有一招是主动让出CPU用户任务运行完后主动调用一次osDelay(1)让出时间片给高优先级网络任务。7. 一个完整的HTTPD应用示例LED控制 传感器数据展示理论讲多了容易虚这里手把手搭一个最小可用示例把前面所有点串起来。7.1 网页文件设计准备一个index.shtml后缀必须带s否则SSI不生效包含!DOCTYPE html html headtitleSTM32F407 控制台/title/head body h3传感器数据/h3 温度!--#echo vartemp -- ℃br 湿度!--#echo varhumi -- %br h3LED控制/h3 a href/cgi-bin/led?state1打开LED1/a | a href/cgi-bin/led?state0关闭LED1/a /body /html用makefsdata工具生成fsdata.c替换工程内文件。7.2 主程序框架static void ssi_handler(int iIndex, char *pcInsert, int iInsertLen) { switch (iIndex) { case 0: snprintf(pcInsert, iInsertLen, %.2f, read_temp()); break; case 1: snprintf(pcInsert, iInsertLen, %.2f, read_humi()); break; } } static const char *led_cgi_handler(int iIndex, int iNumParams, char *pcParam[], char *pcValue[]) { if (strcmp(pcValue[0], 1) 0) { HAL_GPIO_WritePin(LED_GPIO_Port, LED_Pin, GPIO_PIN_RESET); } else { HAL_GPIO_WritePin(LED_GPIO_Port, LED_Pin, GPIO_PIN_SET); } return /index.shtml; } int main(void) { HAL_Init(); SystemClock_Config(); MX_GPIO_Init(); MX_ETH_Init(); MX_LWIP_Init(); httpd_init(); // 注册SSI标签处理函数 htd_ssi_handler(ssi_handler); // 注册CGI处理函数 static const tCGI cgi_handlers[] { {/led, led_cgi_handler}, }; http_set_cgi_handlers(cgi_handlers); while (1) { MX_LWIP_Process(); // 其他用户代码 } }7.3 验证过程开发板接到路由器串口打印DHCP获取到的IP。浏览器输入该IP刷新页面温度湿度能实时变化点击LED链接CGI回调里控制GPIO翻转页面跳回数据页。整个过程不需要外部网络完全局域网内跑通。如果DHCP分配失败可以查一下路由器的DHCP服务是否正常或者恢复静态IP测试。这时要注意静态IP必须和路由器同一网段网关、掩码填对否则依旧不通。8. 性能优化与稳定性加固的几条经验功能跑通之后如果准备把代码放进产品里下面几条优化建议值得考虑。8.1 提升HTTPD并发能力默认HTTPD是单线程模型同一时间只能处理一个连接。如果页面引用了CSS、JS、图片等多个资源浏览器会同时发起多个TCP连接服务器只能一个一个处理一次页面加载可能耗时好几秒。优化方法开启HTTPD多线程支持CubeMX里的lwIP配置有HTTPD_MAX_CONNECTIONS参数调到4或8同时在FreeRTOS里给httpd_thread增加独立任务。代价是内存占用增加典型情况每个连接需要额外2KB~4KB。F407的RAM不大所以页面资源能合并就合并CSS内联JS内联图片用base64编码或直接不要。8.2 使能TCP心跳保活嵌入式设备接入局域网如果不做数据交互TCP连接可能会被中间路由器老化回收。HTTPD场景下浏览器每次访问是新建连接问题不大但如果你在设备上了WebSocket就要在TCP层开启keepalive。配置方法lwIP的LWIP_TCP_KEEPALIVE置1然后初始化TCP PCB时设置pcb-so_options | SOF_KEEPALIVE; pcb-keep_idle 5000; // 5秒无数据后开始探活 pcb-keep_intvl 1000; // 探活间隔 pcb-keep_cnt 3; // 连续3次失败判定连接断开8.3 网页资源的Flash存储布局把网页放在内部Flash能省事但单片机程序升级时会遇到一个问题如果使用IAP在应用编程方案升级固件升级过程中网页不能更新否则会导致页面损坏。比较成熟的方案是页面文件单独放一个Flash分区升级程序只更新代码区页面区单独管理或者干脆把页面文件放到外部SPI Flash。F407 1MB的Flash内部布局建议Bootloader 64KBApp 512KB页面区256KB剩余存配置和日志。页面区固定地址用链接脚本const变量指向Flash地址HTTPD直接从这个地址读取网页数据而不是通过标准文件系统。提示这种方案要注意Flash字节对齐和擦除页大小否则页面区被误格式化会导致设备失去Web管理页面只能拆机重刷。9. 常见问题的快速对照表这里把我调试过程中遇到的高频问题整理成一张表方便你排查时直接对照。现象可能原因排查方向DHCP获取不到IPPHY地址错、RMII时钟缺失、网线读PHY寄存器量50MHz时钟ping通则网页打不开HTTPD未初始化、页面文件未生成检查routing表、CGI返回的路径是否正确网页能打开但图片不全内存不足、HTTPD并发太低增大MEM_SIZE、HTTPD_MAX_CONNECTIONS长时间运行后死机内存碎片、栈溢出监控task栈调大MEM_SIZE开启堆栈溢出检测LAN8720A读不到IDPHY地址不匹配、MCO1时钟不准检查PHYAD0引脚电平确认CubeMX时钟树收发数据丢包严重PBUF池太小、DMA描述符不足调大PBUF池数量查看ETH DMA状态寄存器10. 这个系列后续还可以怎么玩这篇文章做完了lwIP的移植和HTTPD的搭建只是以太网应用的第一步。F407的以太网能力远超“开个网页”这么简单后续可以扩展的方向很多基于MQTT协议做云平台对接、用TFTP实现远程固件升级、跑Modbus TCP实现工业设备通信、甚至用UDP组播做设备发现。每一个方向都是lwIP的进阶玩法后面有空再逐个拆开写。最后说一个我在实际项目中经常用的技巧开发阶段把HTTPD的调试日志开关打开让每个请求的处理路径和耗时都能打印出来。具体是lwipopts.h里把LWIP_DEBUG和HTTPD_DEBUG都设为LWIP_DBG_ON这样能直接看到SSI标签是否被正确替换、CGI是否被正确调用。上线前再统一关掉性能和代码体积都能受益。这个习惯帮我省了大量在黑盒子里猜问题的时间建议你也养成。