简介一份面向STM32F407开发者的以太网与LWIP协议栈实战资源包涵盖固件库驱动到网络协议栈的完整代码适合嵌入式初学者及希望在ARM平台实现联网功能的中级开发者。压缩包内共2000个文件包括1041个头文件、881个C源文件和78个文本说明头文件与C源文件构成HAL/LL驱动和LWIP主体文本文件辅助配置阅读整体大小28.86MB结构清晰便于导入工程。已有447人学习与浏览适用于工业控制、物联网设备及局域网通信等场景。资源重点展示硬件以太网MAC初始化流程指导开发者设置MAC地址、子网掩码等网络参数并基于LWIP建立TCP或UDP连接同时提供DHCP、DNS等上层服务及HTTP服务器示例。通过研读这些代码开发者可快速掌握在Cortex-M4平台上移植网络协议栈的方法减少底层驱动调试时间为毕业设计或产品原型验证提供完整参考。1. STM32F407固件库里的LWIP以太网究竟值不值得折腾做物联网网关或者工业数据采集时很多工程师第一反应是上Linux但有些现场只需要把几十个字节的报文稳定传出去单片机加一个以太网口就足够。STM32F407固件库里的ETH外设负责把MAC从芯片里拉起来LWIP负责把TCP/IP协议栈跑明白这份工程模板的价值在于它把标准外设库、ETH驱动和LWIP缝合成一个能直接打开的完整项目而不是让你从零对照数据手册拼寄存器。它不仅适合F407上需要联网的老项目迁移也适合新手在现有硬件上快速验证协议栈。一句话说清定位这是一条从寄存器配置到TCP通信都能复现的落地链路踩坑点主要集中在时钟、内存和中断三个地方提前知道能省掉一整周的排查时间。2. 先看清ETH外设固件库里以太网是怎么被拉起来的2.1 三层分工MAC、PHY、LWIP协议栈各管什么F407芯片内部集成的ETH外设本质上是一个以太网MAC控制器加上配套的DMA引擎它不包含物理层收发器。也就是说你必须在板子上外接一颗PHY芯片MAC通过MII或RMII接口和PHY连接。PHY负责把数字信号变成差分信号送上网线MAC负责组帧、校验、地址过滤而LWIP负责的是更上层的事IP分片重组、ARP缓存、TCP状态机、重传超时。这三层之间互相不认识全靠固件库把MAC初始化好再把LWIP收到的数据包交给DMA去收发。很多人在F407上首次跑以太网时容易犯一个错误把PHY和MAC混为一谈以为换一颗PHY只要改引脚就行。实际上PHY的寄存器地址、复位时序、时钟来源甚至自动协商行为都不同换PHY意味着驱动层要跟着改。固件库提供的ETH驱动只覆盖MAC本身对PHY的操作通常还是直接用MDIO总线读写PHY寄存器来完成很少能靠库函数一套通吃。固件库和HAL库在以太网初始化上差异也很大。HAL库把DMA描述符、发送接收缓冲区都封装成结构体你只需要调用HAL_ETH_Init。而固件库的做法是让你自己定义描述符数组和缓冲数组然后把这些数组的地址填进初始化结构体。第二步有个隐藏要求描述符必须放在DMA能访问的内存区域并且按4字节对齐否则传输一启动就是HardFault或者全乱码。2.2 RMII还是MII引脚减半但参考时钟必须算清STM32F407的ETH外设同时支持MII和RMII两种物理接口芯片通过复用的方式把两组引脚映射到GPIO上同一时间只能启用其中一种。MII需要16根信号线TXD[3:0]、RXD[3:0]、TX_EN、RX_DV、TX_CLK、RX_CLK、CRS、COL再加MDIO和MDCRMII把数据线砍到各2根总共只需要9根信号线。引脚数量差了一半对PCB布局和IO占用来说RMII优势明显所以绝大多数F407开发板和自研板都选了RMII。对比项MIIRMII信号线数量约16根约9根参考时钟TX_CLK/RX_CLK独立25MHz共用REF_CLK50MHzFIFO深度需求低较高适合场景对时序裕量要求高的工业板大多数开发板、网关产品但这背后有个容易忽略的坑RMII要求一个50MHz的参考时钟这个时钟的方向必须明确。常见的两颗PHY芯片行为完全相反LAN8720A这类PHY通过外部25MHz晶振在内部倍频然后由PHY主动向MCU输出50MHz的REF_CLK而DP83848这类PHY则需要MCU或者外部振荡器提供50MHz给它。方向搞反PHY的链路状态寄存器可能都是正常的但RMII接口上根本没有有效时钟数据收发全部失败。2.3 固件库初始化ETH的最小代码结构体、时钟、MAC地址在固件库工程模板里ETH初始化一般分三步走配置GPIO复用功能配置MAC和DMA最后配置MAC地址并启动。GPIO部分没有太多悬念把对应引脚全部设成复用推挽输出然后调用GPIO_PinAFConfig绑定到GPIO_AF_ETH。引脚分配以开发板原理图为准下面这段是RMII模式下常见的一组配置。// 以固件库标准外设库方式初始化ETH的GPIORMII模式 void ETH_GPIO_Config(void) { GPIO_InitTypeDef GPIO_InitStructure; // 使能ETH用到的GPIOA/GPIOC/GPIOB时钟 RCC_AHB1PeriphClockCmd(RCC_AHB1Periph_GPIOA | RCC_AHB1Periph_GPIOB | RCC_AHB1Periph_GPIOC, ENABLE); // 把RMII相关引脚全部复用为ETH功能 GPIO_PinAFConfig(GPIOA, GPIO_PinSource1, GPIO_AF_ETH); // PA1: RMII_REF_CLK GPIO_PinAFConfig(GPIOA, GPIO_PinSource2, GPIO_AF_ETH); // PA2: MDIO GPIO_PinAFConfig(GPIOA, GPIO_PinSource7, GPIO_AF_ETH); // PA7: RMII_CRS_DV GPIO_PinAFConfig(GPIOB, GPIO_PinSource11, GPIO_AF_ETH); // PB11: RMII_TX_EN GPIO_PinAFConfig(GPIOB, GPIO_PinSource12, GPIO_AF_ETH); // PB12: RMII_TXD0 GPIO_PinAFConfig(GPIOB, GPIO_PinSource13, GPIO_AF_ETH); // PB13: RMII_TXD1 GPIO_PinAFConfig(GPIOC, GPIO_PinSource1, GPIO_AF_ETH); // PC1: MDC GPIO_PinAFConfig(GPIOC, GPIO_PinSource4, GPIO_AF_ETH); // PC4: RMII_RXD0 GPIO_PinAFConfig(GPIOC, GPIO_PinSource5, GPIO_AF_ETH); // PC5: RMII_RXD1 // 统一配置为复用推挽速度50MHzRMII对IO翻转速度有一定要求 GPIO_InitStructure.GPIO_Speed GPIO_Speed_50MHz; GPIO_InitStructure.GPIO_Mode GPIO_Mode_AF; GPIO_InitStructure.GPIO_OType GPIO_OType_PP; GPIO_InitStructure.GPIO_PuPd GPIO_PuPd_NOPULL; GPIO_InitStructure.GPIO_Pin GPIO_Pin_1 | GPIO_Pin_2 | GPIO_Pin_7; GPIO_Init(GPIOA, GPIO_InitStructure); GPIO_InitStructure.GPIO_Pin GPIO_Pin_11 | GPIO_Pin_12 | GPIO_Pin_13; GPIO_Init(GPIOB, GPIO_InitStructure); GPIO_InitStructure.GPIO_Pin GPIO_Pin_1 | GPIO_Pin_4 | GPIO_Pin_5; GPIO_Init(GPIOC, GPIO_InitStructure); }这段代码的逻辑很直接RCC开时钟AFIO绑定复用功能然后GPIO_Init批量配置。注意PA1在别的外设里也被用作定时器通道启用ETH之后这组引脚就不能同时给别的外设。GPIO_Speed设成50MHz是因为RMII的REF_CLK有50MHz太慢的IO翻转速率会直接导致数据采样错误。然后是ETH_MAC和DMA的初始化。// 固件库ETH初始化配置MAC模式、DMA描述符、MAC地址 void ETH_Config(void) { ETH_InitTypeDef ETH_InitStructure; // 打开ETH时钟注意不是AHB1外设时钟是单独的MAC时钟 RCC_AHB1PeriphClockCmd(RCC_AHB1Periph_ETH_MAC, ENABLE); RCC_AHB1PeriphClockCmd(RCC_AHB1Periph_ETH_MAC_Tx, ENABLE); RCC_AHB1PeriphClockCmd(RCC_AHB1Periph_ETH_MAC_Rx, ENABLE); // 使能PHY的MDIO时钟MDC时钟由APB2分频得到 RCC_AHB1PeriphClockCmd(RCC_AHB1Periph_ETH_MAC_PHY, ENABLE); ETH_DeInit(); // 复位ETH模块保证从干净状态开始 // 配置MAC核心参数 ETH_InitStructure.ETH_AutoNegotiation ETH_AutoNegotiation_Enable; ETH_InitStructure.ETH_Mode ETH_Mode_FullDuplex; ETH_InitStructure.ETH_Speed ETH_Speed_100M; ETH_InitStructure.ETH_MediaInterface ETH_MediaInterface_RMII; ETH_InitStructure.ETH_TxDesc eth_tx_desc; // 描述符数组首地址 ETH_InitStructure.ETH_RxDesc eth_rx_desc; // 接收描述符数组首地址 ETH_InitStructure.ETH_TxBufferLength ETH_TX_BUF_SIZE; ETH_InitStructure.ETH_RxBufferLength ETH_RX_BUF_SIZE; if (ETH_Init(ETH_InitStructure) ETH_SUCCESS) { // 设置MAC地址为单播MAC02开头是本地管理地址不会和真实网卡冲突 ETH_MACAddressConfig(ETH_MAC_Address0, eth_mac_addr); } // 启动DMA发送和接收 ETH_DMACmd(ETH_DMA_Tx, ENABLE); ETH_DMACmd(ETH_DMA_Rx, ENABLE); }eth_tx_desc和eth_rx_desc这两个数组需要在文件作用域定义常见的大小是ETH_TXBUFNB个描述符每个描述符关联一块ETH_TX_BUF_SIZE大小的缓冲。固件库要求这些数组从4字节边界开始所以定义时要用__align(4)或者放在独立的SRAM区里。MAC地址的配置有一个容易被忽略的点F407的MAC模块默认会对接收帧做地址过滤全零MAC地址会导致过滤逻辑异常多播地址第一个字节最低位为1又会导致只收组播不发单播。最稳妥的做法是使用02开头的本地管理单播地址类似02:00:00:12:34:56既能保证单播属性又不会蹭到真实网络设备的厂商OUI。3. LWIP移植的关键拼接从驱动到能ping通3.1 内存布局为什么网卡DMA缓冲不能放在CCMLWIP本身是一套独立于硬件的协议栈它只关心内存、时间基准和一个能接收发送数据包的网卡驱动接口。移植LWIP到F407固件库工程里最难的部分不是协议栈而是把LWIP的netif接口和固件库的ETH驱动缝在一起。动手之前先想清楚内存布局。F407内部有一块64KB的CCM内存地址从0x10000000开始它的特点是访问速度接近零等待但是只有一个CPU内核入口AHB总线上的外设全部访问不到它包括ETH的DMA。如果你的网卡描述符、DMA缓冲区或者LWIP的pbuf池被链接到了CCM区域最常见的结果是程序启动后ETH初始化正常PHY也能连上但一收发数据就是内存乱码甚至直接HardFault。解决方法是把ETH相关数组明确放到0x20000000起始的SRAM区。固件库模板里已经做了这件事但如果你在这个基础上跑FreeRTOS还要注意任务栈和堆也不要往CCM里分配。很多带RTOS的LWIP模板会把系统堆放在启动文件里指定的Heap_Size这个大小决定了tcpip_thread能否正常创建。建议保留模板默认的内存分配方案至少要检查linker脚本里的RAM区间定义是否只包含了SRAM而排除了CCM。内存对齐是第二个隐藏要求。ETH DMA描述符必须按4字节对齐缓冲区的起始地址最好也对齐到4字节。固件库模板里用到__align(4)修饰数组这是标准做法。如果你自己重写了描述符数组不要省略这个修饰符否则在某些编译优化级别下数组地址从2字节边界开始DMA就会在第一次收发时报总线错误。3.2 low_level_init网卡驱动怎么和一个协议栈对接LWIP对网卡驱动的抽象是struct netifnetif_add时传入的init函数负责填充硬件信息和回调函数。在标准移植模板里这个函数叫ethernetif_init它内部又调用了low_level_init。low_level_init的核心职责有四个设置MTU、设置MAC地址、注册linkoutput回调、准备好DMA描述符环。// LWIP网卡驱动初始化把固件库ETH驱动挂到netif上 static err_t low_level_init(struct netif *netif) { // 设置MAC地址长度和MAC地址内容必须和固件库配置的一致 netif-hwaddr_len ETHARP_HWADDR_LEN; memcpy(netif-hwaddr, eth_mac_addr, ETHARP_HWADDR_LEN); // MTU按照标准以太网帧来1500字节 netif-mtu 1500; // 网卡能力标志支持广播、ARP、链路自动检测 netif-flags NETIF_FLAG_BROADCAST | NETIF_FLAG_ETHARP | NETIF_FLAG_LINK_UP; // linkoutput负责把LWIP封好的帧发出去 netif-linkoutput low_level_output; // DHCP或静态IP场景下由ARP拿到MAC后走etharp_output netif-output etharp_output; // 初始化DMA描述符环固件库在ETH_Init里已经做了一部分 // 这里需要把描述符的地址、状态位重新清一遍防止热启动残留 for (int i 0; i ETH_RXBUFNB; i) { eth_rx_desc[i].Status ETH_DMA_RX_OWN; // 把描述符还给DMA } return ERR_OK; }这段代码的要点在linkoutput和output两个回调。low_level_output在模板里实现做的事情是把LWIP传入的pbuf链拆成一段一段连续内存填入DMA描述符的缓冲区地址然后触发DMA发送。理解和这个实现有助于排查发送超时的问题——如果你发现ARP能通但TCP很慢先检查low_level_output里是不是把超长pbuf链拆错了。数据接收方向由另一个函数负责。最常见的设计是裸机轮询主循环里不断调用ethernetif_input(eth_netif)这个函数检查DMA接收描述符状态有数据就把pbuf作为netif-input的参数交给上层。如果跑FreeRTOS通常换成ETH中断里给信号量、独立线程里调用ethernetif_input两种方式各有取舍。3.3 最小配置表一组能开机自通的LWIP参数LWIP的lwipopts.h是移植过程中最容易被改坏的配置文件。模板自带的默认值往往基于大内存平台而F407只有不到128KB可用SRAM参数开得太大会直接编译不过开得太小又会出现TCP连上但传数据就断的问题。下面这组参数是很多F407模板里的常见组合适合裸机或带FreeRTOS的场景。LWIP参数建议值一句话说明MEM_SIZE1600~4096协议栈内部堆大小太小会导致ARP缓存分配失败PBUF_POOL_SIZE16~32接收缓冲池个数每个对应一个可接收的帧PBUF_POOL_BUFSIZE1518单个缓冲能装下一整包以太网帧TCP_MSS1460最大报文段1500减去IP头和TCP头后的净荷TCP_WND2920接收窗口通常设为TCP_MSS的整数倍TCP_SND_BUF2920~5840发送缓冲双向大流量场景需要调大MEMP_NUM_TCP_SEG16~32TCP分段池数量直接影响并发发送能力LWIP_NETCONN1是否启用netconn API跑TCP server建议打开修改参数之后需要重新编译整个工程。这里有一个经验PBUF_POOL_SIZE和PBUF_POOL_BUFSIZE的乘积就是系统能缓冲的流量上限如果板子在突发数据时会丢包优先加大这两个而不是去加大MEM_SIZE。MEM_SIZE堆再大数据包没有足够的pbuf池也照样进不来。裸机上把LWIP跑起来的启动代码很简单核心是lwip_init、netif_add、netif_set_up三个步骤。注意netif_add的第四个参数指向一个和网卡绑定的状态结构体模板里传的是NULL大多数场景不需要额外状态保持NULL即可。// LWIP初始化创建netif并设置IP地址固定IP示例 struct netif eth_netif; ip4_addr_t ipaddr, netmask, gw; // 把IP地址拆成4段填入顺序不能反 IP4_ADDR(ipaddr, 192, 168, 1, 88); IP4_ADDR(netmask, 255, 255, 255, 0); IP4_ADDR(gw, 192, 168, 1, 1); // 1. 初始化协议栈内部内存和定时器 lwip_init(); // 2. 注册网卡ethernetif_init是上一节写的驱动入口 netif_add(eth_netif, ipaddr, netmask, gw, NULL, ethernetif_init, ethernet_input); // 3. 把默认网卡指向eth_netif并启动 netif_set_default(eth_netif); netif_set_up(eth_netif);裸机模式下主循环还需要做两件事周期性调用sys_check_timeouts()处理TCP超时重传以及调用ethernetif_input(eth_netif)轮询收包。如果跑的是FreeRTOS这类RTOS这两个动作会被tcpip_thread和网卡接收线程替代。我在F407上裸机跑过一段时间CPU占用率很低但代价是代码结构里多了两个分散的调用点忘记任何一个都会表现为“能发送但收不到回复”。IP地址的规划也有讲究。模板里经常默认192.168.1.88但如果你把开发板直接插到公司局域网网关、子网掩码和本机IP一旦和局域网冲突ARP就会一直得不到回应。调试初期建议用独立路由器或者直接把电脑网卡设成静态IP和板卡放在同一网段避免各种隔离策略干扰。4. F407以太网跑不通五个高频坑的排错记录4.1 现象网线插上Link灯亮但MDIO读PHY ID失败ping不通Link灯亮说明PHY和网线变压器之间正常但芯片读不到PHY ID问题几乎都出在MDIO或RMII参考时钟上。MDIO读不到ID先确认MDC时钟频率MDC是由APB2时钟分频得到的固件库ETH_Init里会根据APB2频率自动配置但你要保证ETH时钟已经打开。RMII的REF_CLK方向反了也会出现类似现象因为MAC没有时钟就无法完成和PHY之间的数据同步。解决方法是先写一个比LWIP更早执行的PHY ID读取函数用MDIO读PHY寄存器2和3打印出来对比PHY数据手册上的值。这一步能同时验证MDIO总线和PHY上电状态。如果ID读出来是0xFFFF基本是MDC或PHY地址不对如果ID正确但ping不通再回头查REF_CLK方向。我习惯在eth_init之前做这个检查把潜在的硬件问题在协议栈启动前暴露出来。4.2 现象MAC地址配成了02开头ARP还是不通这个坑更容易出现在有人改过MAC地址的场景。固件库的ETH_MACAddressConfig设置的是MAC地址过滤器LWIP的netif里还有一份MAC地址拷贝两处必须保持一致。如果只改了一处ARP请求到了MAC层会因为地址过滤不匹配被硬件丢弃而网卡驱动以为自己已经把数据发出去了。解决方法是把MAC地址定义成一个全局数组固件库初始化和low_level_init都引用同一个变量从源头上避免两份拷贝不一致。另外检查这个数组的第一个字节最低位必须是0否则就是多播地址ARP应答根本不会进来。我踩过一次这个坑当时把MAC地址写成了03开头整整查了两天才意识到是多播位问题。4.3 现象ETH_DMACmd使能DMA后程序直接HardFault典型原因有两个一是DMA描述符或缓冲数组没有4字节对齐二是数组被链接到了CCM区域。固件库模板里通常用__align(4)处理了第一个问题但如果你改了启动文件里的内存布局比如把大数组定义到了0x10000000段ETH DMA一启动就会访问非法地址MCU立刻进HardFault。解决方法是先看map文件确认eth_tx_desc、eth_rx_desc和缓冲数组的实际地址在0x20000000到0x2001FFFF之间并且首地址末两位是0。如果地址不对回到C文件把__align(4)加上或者用attribute指定段。还有一个判断技巧HardFault发生的时间点很关键如果是ETH_Init之后就挂基本就是描述符位置不对如果是第一次发送数据才挂可能是不小心把发送缓冲区也放进CCM了。4.4 现象FreeRTOS下TCP收发正常串口打印偶尔卡顿ETH中断不触发F407的ETH中断号是ETH_IRQn需要单独在NVIC里配置。很多人沿用HAL库里的习惯把中断优先级设成了最高抢占优先级结果在FreeRTOS里把所有任务都饿死了现象是系统反应迟钝但TCP还能勉强跑。另有一种情况是中断服务函数里忘记清DMA中断标志位导致中断标志一直挂着ETH_IRQHandler反复进入但根本没完成收发流程。解决方法是给ETH中断一个适中的优先级比如抢占优先级5、子优先级0确保它低于系统节拍中断但高于普通外设中断。中断服务函数里用ETH_DMAClearITPendingBit把接收和发送的标志位清掉再交给信号量或消息队列唤醒接收线程。另一个容易漏掉的细节是调试时开着Keil的断点如果断在ETH中断里不动DMA描述符会被其他中断的执行打断恢复运行时状态已经错乱这种情况下出现任何怪问题都先别急着改代码。4.5 现象TCP连接一建立立刻HardFault或者连接马上断开这类问题十有八九出在tcpip_thread的任务栈大小上。LWIP在RTOS模式下会创建tcpip_thread任务栈大小由TCPIP_THREAD_STACKSIZE控制。栈太小TCP握手还没走完栈就被压爆。很多模板里的默认值是256或512字节这在F407上跑极简场景勉强够但只要你打开netconn API或者加了DHCP瞬间就崩。解决方法是把TCPIP_THREAD_STACKSIZE调到1024甚至2048并且真机测试时在栈顶填上固定值任务运行一段时间后检查剩余量。LWIP的栈溢出和普通任务栈溢出表现不太一样它不一定立刻HardFault有时表现为连接建立后收几包数据就断因为某个回调里栈帧太大把关键变量覆盖了。另外如果你在recv回调里调用了阻塞型API也要确认这个回调运行在tcpip_thread上下文中栈需求会更敏感。5. 从ping通到真正能用一个TCP服务端的正确起步姿势5.1 最小TCP echo server验证链路通不通的关键代码ping通了只说明ARP和ICMP链路正常TCP的收发送缓冲、窗口管理、分段重传全是另一套逻辑需要单独验证。最稳妥的验证方式是一个TCP echo server客户端发什么服务端原样回什么。它能同时覆盖收、发、窗口更新、pbuf释放四个核心路径。// 最简TCP echo server回调实现 static err_t echo_recv_cb(void *arg, struct tcp_pcb *tpcb, struct pbuf *p, err_t err) { if (p NULL) { // p为NULL表示对端关闭连接这里释放pcb并返回 tcp_close(tpcb); return ERR_OK; } // 1. 先把收到的数据写入发送缓冲 // 最后一个参数1表示允许在发送缓冲满时排队防止频繁超时 tcp_write(tpcb, p-payload, p-len, 1); // 2. 立即触发发送避免等TCP定时器超时 tcp_output(tpcb); // 3. 告诉协议栈这段数据已经处理完可以更新接收窗口 tcp_recved(tpcb, p-len); // 4. 释放pbuf这一步漏掉会造成内存池泄漏 pbuf_free(p); return ERR_OK; }service开始监听的代码有三个关键步骤tcp_new、tcp_bind、tcp_listen。bind的IP地址是IP_ADDR_ANY端口选一个不容易冲突的高位端口比如6000。accept回调里不需要额外处理连接状态在echo场景下accept回调只需要返回ERR_OK真正收数据的地方就是echo_recv_cb。这个实现把tcp_write放在tcp_recved前面先尝试发送再释放窗口好处是发送缓冲满时不会出现窗口已经更新但数据还没写进缓冲的竞态。裸机环境下这个回调跑在主循环或以太网中断的上下文里一定不要在里面调用延时函数。TCP重传机制本身是靠sys_check_timeouts驱动的如果你在回调里加了一个毫秒级延时整个协议栈都会跟着停顿客户端就会出现规律性的超时重传。5.2 收发缓冲参数怎么调TCP_MSS、PBUF池、窗口大小TCP收发性能的瓶颈在内存不在CPU。F407跑在168MHz对于100Mbps以太网来说CPU完全够用真正限制吞吐的是pbuf池不够大和TCP窗口太小。TCP_MSS建议保持1460这是MTU 1500减去IPv4头20字节再减去TCP头20字节后的最大值调小会降低单包效率调大则可能让IP分片性能反而更差。接收路径上最关键的参数是PBUF_POOL_SIZE和PBUF_POOL_BUFSIZE。每个接收到的以太网帧都会占用一个pbufPBUF_POOL_SIZE决定同时能缓冲多少帧。如果客户端用大包连续发送接收方向的pbuf池会被瞬间占满后续帧直接丢弃。TCP_WND决定对端在没有收到ACK前最多能发送多少数据建议设为TCP_MSS的两倍或四倍也就是2920或5840字节这样能充分利用窗口而不至于让缓冲压力过大。发送路径上TCP_SND_BUF和MEMP_NUM_TCP_SEG是协作关系。TCP_SND_BUF是发送缓冲区总量MEMP_NUM_TCP_SEG是能同时存在多少个待发送分段。每个分段都有自己的TCP头信息分段池不够时tcp_write会返回ERR_MEM客户端表现为发送阻塞。实际调试中我一般先跑echo测试通过串口打印tcp_write的返回值只要出现ERR_MEM就按两倍步进加大MEMP_NUM_TCP_SEG直到连续收发一整天不再报错。5.3 性能验证别只看ping用工具测吞吐看丢包和延时ping通说明链路可达但说明不了链路能承载多少业务流量。我验证F407以太网性能通常分三步第一步用Wireshark观察ARP和ICMP交互确认没有重传第二步用PC端TCP调试工具建立echo连接连续发送10万包长度不等的随机数据在板端串口打印正确回显的包数第三步才谈吞吐——用一个固定大小的TCP窗口连续发送记录每秒收包数。第三步有一个常见误区PC端的TCP调试工具在大学物理层已经把大包分片了板端收到的包数会远小于发送包数这不一定是F407的问题。更好的做法是在板端自己统计每次tcp_recv回调收到的字节数累加配合一个1ms的定时器就能算出实际的接收吞吐。当这个数值稳定在900Mbps以下正常F407的100Mbps网口受限于RMII和DMA效率跑到80Mbps以上就算正常低于50Mbps才需要怀疑PBUF池或者描述符数量不够。丢包测试更直接PC端一次性发送10000个包每个包带独立序号板端只统计序号间隙。如果丢包率超过万分之一先看以太网PHY的链路质量——很多丢包不是MCU问题是网线或者变压器焊接虚焊造成的。我遇到过一块板子丢包率奇高换了一根短网线就完全正常这种硬件层面的问题在参数调整之前就该排查掉。6. 进阶这套固件库方案能做到什么程度把这套F407固件库加LWIP的模板从ping通推进到真实可用通常只需要两步给协议栈配一个DHCP客户端让板卡自适应局域网或者直接固定IP跑一个应用层协议。工业场景里Modbus TCP是开销最小的选择LWIP的raw API完全能承载一个从站协议不需要额外引入RTOS线程一个listen回调加一个recv回调就能实现整帧处理和响应拼装。跑FreeRTOS时则简单很多netconn API已经把tcpip_thread的交互封装好了你只需要在任务里阻塞等待连接和数据。换到自己做的板子上时改动清单通常只有四处PHY芯片型号决定MDIO读ID的时序RMII参考时钟方向决定RCC配置PHY复位引脚决定上电顺序MAC地址决定局域网兼容性。这四处里最花时间的往往是PHY复位有的板卡把PHY复位和MCU复位绑在一起看似省事但PHY在上电后需要几十毫秒完成初始化如果MCU在它之前就发起MDIO访问第一笔读写就会丢失。我的习惯是给PHY复位引脚单独接一个GPIO上电后先拉低再拉高等100毫秒再做MDIO操作这套流程能让几乎所有的PHY稳定进入工作状态。另一个进阶方向是让LWIP跑带操作系统版本把ethernetif_input从主循环里挪到一个独立线程里ETH中断只负责释放信号量。这样做的收益是接收路径的阻塞时间变短不会再出现大量数据突发时主循环处理不过来导致丢包。代价是内存压力上升tcpip_thread和网卡接收线程各需要一组栈空间再加上LWIP的pbuf池整体内存占用会多出10KB以上。F407的SRAM对跑一个TCP server来说够用但如果你想同时跑一个HTTP服务器加一个MQTT客户端内存规划就要重新做一遍建议保留至少20KB的余量。验证方法建议保留一份长久有效的自测脚本固定IP下用PC连续echo 10万包统计丢包率再开一个Wireshark同时抓包确认没有TCP快速重传。这两项都稳定通过这套固件库方案就具备了上真实项目的基础。我个人的习惯是每次移植完成都把这份自测结果存成一条串口日志后续再动内存和中断相关的代码都拿这次结果当基准对照。以太网这类问题出现得比较隐蔽很多时候不是靠看代码想到的而是靠对比前后两次测试结果定位的希望这套排查路径能帮到你少走几步弯路。本文还有配套的精品资源点击获取