STM32F407+FreeRTOS+LwIP移植实战：从Lan8720A到稳定TCP通信

很多人买回 STM32F407 开发板之后第一阶段几乎都是点灯、串口、读传感器真正卡住进度的往往是把 FreeRTOS 和 LwIP 组合起来让设备具备稳定的网络通信能力。这个组合在 F407 上已经被大量工业产品验证过但资料越杂越容易踩坑。这篇文章我会以 F407 LAN8720A 为例子完整复盘移植 FreeRTOS 与 LwIP 的过程从源文件取舍、时钟结构、任务划分到 PHY 调试、TCP 断连排查、内存和栈优化都过一遍。这篇文章适合已经会跑 HAL 库基础外设、但对 RTOS 和网络协议栈还没有形成完整思路的开发者。我把每个环节里最容易让人困惑的“为什么”也讲清楚不只是甩几段代码。移植的本质是让 FreeRTOS 管好任务让 LwIP 驻留在 tcpip_thread 里处理协议二者不是独立叠加而是一套有前后依赖的嵌入式系统架构。1. 为什么 F407 搭配 FreeRTOS 和 LwIP 是经典开局而不是玄学1.1 F407 的资源基础到底够不够STM32F407 主频最高 168MHzCortex-M4F 带 FPU内部有 1MB Flash 和 192KB SRAM。这个规格在嵌入式世界里并不夸张但跑一个小型协议网关、数据采集器、工业设备联网模块绰绰有余。它最大的优势在于内置了 10/100M 以太网 MAC并且支持 MII 和 RMII 两种接口。只要外接一颗 PHY 芯片就能引出标准网口数据帧搬运由 MAC 内部的 DMA 完成CPU 不需要逐字节参与 nic 的收发。相比 F103 那种没有内置 MAC 的芯片F407 的网络方案本质上更完整。F103 常见做法是外挂 SPI 接口的 W5500把 TCP/IP 协议栈直接放在网卡芯片内部MCU 只能通过 SPI 读写寄存器。这种方案简单但灵活性差而且吞吐量受 SPI 速度和芯片 SRAM 限制。F407 的方案则是协议栈由 LwIP 在 MCU 上运行所有 TCP 状态机、缓冲区、路由决定都掌握在开发者手里碰到非标准协议或需要深度定制时不会被困住。在实际项目中我通常这样估算 F407 的资源占用基础系统加上 FreeRTOS 任务调度占用 SRAM 大约 10KB 到 20KBLwIP 协议栈加 TCP 收发缓冲再占用 30KB 到 60KB。剩下 100KB 左右留给业务任务。如果你只想做一个简单 TCP 透传32KB 的 LwIP 内存配置都够如果要做 MQTT、HTTP Server、Modbus TCP 同时在线那也要为它们各自预留连接结构。先把这个账算清楚再去想具体移植后面才不会捉襟见肘。1.2 FreeRTOS 和 LwIP 到底是怎么协作的FreeRTOS 负责任务调度、信号量、队列、软件定时器这是它的老本行。LwIP 则是一个开源的 TCP/IP 协议栈它本身可以在裸机上以轮询方式工作也可以移植到 RTOS。当 LwIP 运行在 FreeRTOS 上时最常见的结构是创建一个专门的 tcpip_thread 线程。所有 IP 层、TCP 层、UDP 层逻辑都在这个线程上下文中执行不会出现多个任务同时操作同一个 TCP 控制块的竞态。网卡收到数据帧后中断服务程序只做最轻量的动作把指向 pbuf 的指针送给 LwIP 的内部邮箱或者释放一个信号量然后由 tcpip_thread 被唤醒时统一处理。发送方向也是一样用户任务调用 netconn_write 或 socket send 时API 会把请求打包成消息送到 tcpip_thread而不是直接在用户任务里访问协议栈内部状态。这套协作机制决定了移植时不能简单地把 LwIP 当作普通函数库到处调用否则很容易出现数据竞争、死锁和内存泄漏。我和不少做过裸机以太网开发的朋友交流大家最容易犯的错就是把裸机时代的逻辑搬过来中断收包后直接调用某个解析函数主循环里直接调用 tcp_output。在 FreeRTOS 环境里这种大杂烩风格会瞬间破坏协议栈的状态一致性。正确做法是明确划分三层驱动层只负责 DMA 和 PHY协议栈层由 tcpip_thread 全权处理应用层统一通过 Netconn 或 Socket API 访问网络。1.3 移植前必须丢掉的两个心态第一种心态是“CubeMX 里勾一下 FreeRTOS 和 LwIP 就等于移植成功”。CubeMX 确实能生成骨架代码但它生成的 LwIP 移植层依赖具体的 PHY 驱动PHY 地址、RMII 时钟模式、链接状态寄存器这些信息需要你根据实际板子去匹配。很多人烧录后发现 HAL_ETH_Init 报错不是因为代码生成失败而是 PHY 地址没对上。第二种心态是“任务栈和堆先随便给能编译就行”。FreeRTOS 下任务栈溢出往往不是马上崩溃而是跑了几小时甚至几天后随机复位排查难度极高。LwIP 的缓冲池如果设太小TCP 吞吐会断崖式下降连接还会莫名其妙断开。我后面会专门讲堆栈和内存参数的调整经验但第一步就是不要抱着侥幸心理做移植。2. 硬件前提RMII、PHY 和时钟树移植前先打消这些误会2.1 RMII 接口连线与 50MHz 参考时钟F407 的以太网 MAC 可以工作在 MII 或 RMII 模式。RMII 只用 7 根信号线IO 占用少是绝大多数 EVB 板的选择。这 7 根线的核心是 REF_CLK必须提供 50MHz 的参考时钟。很多移植失败案例最后定位到硬件层都是 REF_CLK 没接对或者 PHY 的时钟模式没配置。RMII 信号一般包括ETH_RMII_REF_CLK50MHz 参考时钟ETH_RMII_CRS_DV载波侦听和数据有效ETH_RMII_RXD0 / RXD1接收数据ETH_RMII_TX_EN发送使能ETH_RMII_TXD0 / TXD1发送数据ETH_MDC / ETH_MDIO管理接口用于读取 PHY 寄存器REF_CLK 的来源有两种常见方案。第一种是 PHY 自己外接 25MHz 晶振PHY 内部倍频到 50MHz 后输出给 MCU。第二种是 MCU 通过 MCO 引脚输出 50MHz 给 PHY。这两种方式在 LAN8720A、DP83848 上都有对应配置但细节不同。我建议使用第一种因为 PHY 自己产生 REF_CLK 时MCU 侧的时钟输入更稳定也少一个复用引脚配置。如果你用的是 LAN8720A还要留意它的时钟输出模式引脚。有些模块把 CLKOUT 作为默认输出有些需要设置寄存器否则 PHY 上电后 REF_CLK 线上根本没有信号。碰到 link 起不来的情况先拿示波器看 REF_CLK 有没有波形比反复检查软件配置更高效。2.2 PHY 地址和复位电路最容易被忽视的硬件约束每一颗 PHY 都有一个 MDIO 设备地址由 PHY 芯片的外部引脚决定。LAN8720A 的 PHYAD0 引脚如果悬空或接地地址通常是 0如果拉高地址就是 1。DP83848 的配置引脚更多地址由 PHYAD0 到 PHYAD4 的组合决定。CubeMX 生成代码时有一个 PHY Address 参数HAL_ETH_Init 内部会通过 MDIO 读取 PHY 的 ID 寄存器来验证链路。如果 PHY 地址填错HAL_ETH_Init 会返回 HAL_ERROR因为读回来的是全 1 或者错误值。我之前在某个板子上遇到过类似问题软件排查了两个小时最后看图才看到 PHYAD0 被上拉到了 3.3V地址是 1把宏从 0 改成 1 立即恢复正常。所以拿到一块新板子第一件事是看原理图确认 PHY 型号、地址引脚和复位引脚而不是埋头改代码。PHY 的复位电路同样影响初始化。多数 PHY 复位引脚是低有效而且要求低电平保持一段时间。如果 MCU 的 GPIO 在启动阶段默认是低可能让 PHY 一直处于复位状态。常见做法是用 MCU 的 IO 控制 PHY 复位上电后延时 50ms 再拉高复位引脚。这个延时必须放在初始化 MAC 之前否则 PHY 还没准备好MDIO 通信自然失败。2.3 CubeMX 时钟树和中断配置的基本框架在 CubeMX 里配置 F407 以太网时除了把 ETH 外设打开并选择 RMII还要在时钟树里确认 ETH 时钟。F407 的 MAC 时钟来自系统时钟域但如果 REF_CLK 由 MCU 输出还要确认 MCO 相关引脚和分频配置。我自己更习惯把 ETH 时钟交给硬件完成MCU 只接收 PHY 送来的 50MHz 参考时钟这样软件负担最小。中断优先级也要在 CubeMX 里提前设计。F407 的 NVIC 优先级分组常用 Group4即 4 位抢占优先级数值从 0 到 15数值越小优先级越高。ETH 中断回调里通常会触发信号量或邮箱给 tcpip_thread这属于 FreeRTOS 的 FromISR API中断优先级必须满足 FreeRTOS 的安全限制。我的做法是给 ETH 中断分配 6 或 7既不会把系统高优先级中断饿死也能安全调用 LwIP 相关通知函数。3. FreeRTOS 移植落地源码组织、系统时基与中断优先级的取舍3.1 源码文件的选择和移植目录FreeRTOS 源码并不是把所有文件都扔进工程就能跑。手动移植时我只保留了核心内核文件tasks.c、queue.c、list.c、timers.c如果用到事件组再加 event_groups.c。内存分配器选用 heap_4.c因为 heap_4 支持相邻空闲块合并对长期运行的项目更友好。与 MCU 相关的移植文件是 portable 目录下的端口实现。Cortex-M4F 对应 portable/RVDS/ARM_CM4F 或 GCC/ARM_CM4F这取决于你的编译工具链。很多新手会漏掉 portmacro.h 里的中断优先级配置导致 FreeRTOS 在启动后无法正常触发 SysTick这个后面细说。建议的工程目录结构可以简单分成三块FreeRTOS 源码目录只读不修改FreeRTOSConfig.h所有内核配置集中在这里应用层任务代码、网卡驱动、LwIP 移植层这样做最大的好处是升级 FreeRTOS 版本时只需要替换源码目录不用在几十个文件里找自己改过的代码。FreeRTOSConfig.h 和应用文件独立版本升级不会覆盖你的个性化配置。3.2 FreeRTOSConfig.h 里的关键宏FreeRTOSConfig.h 是移植的核心。我见过太多人直接抄示例项目的配置结果 CPU 频率和实际不符时间基准完全乱掉。下面列出我常用的关键参数和选择理由配置项常用值说明configCPU_CLOCK_HZ168000000必须与 PLL 输出的主频一致configTICK_RATE_HZ1000默认 1000Hz系统开销可接受configTOTAL_HEAP_SIZE32 * 1024包含任务栈、内核对象LwIP 的不包含在内configMAX_PRIORITIES7任务优先级 0~6 够用configUSE_PORT_OPTIMISED_TASK_SELECTION1Cortex-M4 硬件计算最高优先级任务效率更高configCHECK_FOR_STACK_OVERFLOW2开启栈溢出检测调试期必须开configMINIMAL_STACK_SIZE128默认最小栈实际任务按需分配configTICK_RATE_HZ 的选择需要权衡。1000Hz 会让 SysTick 每毫秒触发一次适合时间精度敏感的场景如果业务逻辑大多在百毫秒级别用 250Hz 可以降低系统负荷同时把 CPU 精力留给以太网和协议栈。F407 主频足够高我通常还是用 1000Hz排查问题时更直观。configTOTAL_HEAP_SIZE 不要一开始就给成最大值。192KB SRAM 里还要给 LwIP DMA 描述符、PHY 寄存器映射和业务数据留空间。我的习惯是先给 32KB 跑通然后用空闲内存统计函数观察峰值最后再微调。3.3 SysTick 与 HAL 时基冲突Must Fix 的一步FreeRTOS 的 Cortex-M4 移植默认使用 SysTick 作为系统节拍而 HAL 库初始化时也默认使用 SysTick 作为 HAL 时基。如果手动移植时不处理会看到两种诡异现象一种是系统始终不进入任务调度另一种是 HAL_Delay 时间乱跳甚至卡死。原因很简单启动文件里只有一个 SysTick_Handler 中断入口HAL 和 FreeRTOS 都要抢占它。CubeMX 在勾选 FreeRTOS middleware 后会自动处理但手动移植时必须自己决定时基归属。我强烈建议让 FreeRTOS 使用 SysTickHAL 改用一颗 TIM 来做时基。具体做法是把 HAL 的 HAL_InitTick 替换为基于 TIM6 的中断实现或者在 CubeMX 初始化阶段选择其他定时器作为 Timebase Source。这样 FreeRTOS 的 tick 调度精度不变HAL_Delay 也不会影响系统节拍。如果你偷懒直接把 HAL_GetTick 映射到 xTaskGetTickCount需要非常小心。调度器启动前和中断上下文里xTaskGetTickCount 并不是完全安全的。我试过将 HAL_GetTick 简单替换为 xTaskGetTickCountFromISR短时间没出问题但移植到更复杂场景就开始不稳定。所以宁可多花几分钟配 TIM6 作为 HAL 时基也不要给自己埋定时炸弹。3.4 任务栈和中断优先级的设置逻辑任务栈大小是移植过程中经常被低估的地方。我的经验是先按最大值给跑通后再用高水位检测收缩。普通业务任务给 256 words1KB到 512 words2KB如果任务里调用了 printf、sprintf、snprintf 之类格式化输出栈需求量会剧增建议起步就用 512 words。下面是一个简单的任务创建示例static TaskHandle_t xNetTaskHandle NULL; void vNetTask(void *argument) { for (;;) { /* 网络收发、状态查询等逻辑 */ vTaskDelay(pdMS_TO_TICKS(10)); } } int main(void) { /* ... 硬件初始化 ... */ xTaskCreate(vNetTask, net, 512, NULL, 4, xNetTaskHandle); vTaskStartScheduler(); for (;;) {} }中断优先级方面FreeRTOS 要求所有调用 FromISR 函数的中断优先级数值必须大于等于 configMAX_SYSCALL_INTERRUPT_PRIORITY。这个宏在数值上等于 5 时意味着优先级数值 5 到 15 的中断可以安全调用 API0 到 4 的高优先级中断不能调用。STM32 的优先级数值和它的逻辑优先级是相反的数值越小优先级越高。这一点非常反直觉我见过有人把 ETH 中断设为优先级 0然后在中断里调用 xSemaphoreGiveFromISR结果系统直接死在断言里。标准建议是从硬实时中断调用的 API 要非常克制以太网和串口这类中断优先级设置在 5 到 7 之间既不会影响系统关键响应又能安全使用 FreeRTOS 的通信机制。4. LwIP 移植从驱动 pbuf 到 netif 注册的完整链路4.1 HAL 以太网驱动和 pbuf 的对接LwIP 的网卡驱动层做了两件事告诉 netif 如何发送一帧数据以及接收一帧数据后怎样转给协议栈。F407 的 HAL 库已经封装了 MAC 和 DMA 描述符移植层需要把 DMA 和 pbuf 结合起来。接收方向上DMA 配置时通常会预留多个描述符每个描述符对应一块内存。LwIP 的 pbuf 既可以直接承载 DMA 数据也可以在收到中断后把数据复制到 pbuf。直接映射的方式效率最高但要求内存地址满足 DMA 的对齐条件。我建议给 LwIP 的 MEM_ALIGNMENT 设置为 4并且检查启动文件和 DMA 描述符地址都满足对齐要求。实际开发中我一般直接采用 CubeMX 生成的 ethernetif.c它已经把 low_level_init、low_level_input、low_level_output 这些函数实现了。需要改的主要是 PHY 相关的宏PHY 地址、PHY 状态寄存器地址、PHY 链接状态掩码。LAN8720A、DP83848、YT8512H 这几颗 PHY 的寄存器定义差异较大千万不能拿着一个驱动硬套另一个 PHY。4.2 lwipopts.h 的核心开关和内存分配LwIP 的行为几乎全部由 lwipopts.h 控制。网上示例非常多但不能照抄因为每个项目的 RAM 预算和业务模型不同。下面是我在 F407 上比较常用的一组配置适合 TCP 为主、少量 UDP 的小型网关。#define NO_SYS 0 #define LWIP_TCP 1 #define LWIP_UDP 1 #define LWIP_NETCONN 1 #define LWIP_SOCKET 0 #define TCP_MSS 1460 #define TCP_WND (4 * TCP_MSS) #define TCP_SND_BUF (4 * TCP_MSS) #define MEM_SIZE (10 * 1024) #define MEMP_NUM_PBUF 16 #define MEMP_NUM_TCP_SEG 16 #define PBUF_POOL_SIZE 16 #define MBOX_SIZE 16NO_SYS 必须设为 0这样 LwIP 才会使用 FreeRTOS 提供的邮箱和信号量模拟层。如果你看到某个示例把 NO_SYS 设为 1那个示例跑在裸机主循环里跟 FreeRTOS 不是同一种玩法。内存方面LwIP 有自己的内存池和堆。MEM_SIZE 主要影响 TCP/IP 报文的动态分配PBUF_POOL_SIZE 影响接收缓冲区数量。F407 的 RAM 虽然大但 FreeRTOS 堆也占用不少所以我习惯先保守配置等业务稳定后再逐步加。每调整一次内存参数都要编译后查看 map 文件中 RAM 占用避免链接时才发现溢出。4.3 netif 注册和 tcpip_input 的角色LwIP 初始化最终要把网卡挂到 netif 链表上。网卡驱动和协议栈的桥接函数是 netif_add 的第六个参数。这里有一个非常容易混淆的点到底传 ethernetif_input 还是 tcpip_input。我的做法是 netif_add 里传 tcpip_input。这是因为 tcpip_input 会把收到的 pbuf 直接投递到 tcpip_thread 的邮箱由协议栈线程统一处理。而 ethernetif_input 通常是裸机示例里使用的它负责把 pbuf 从驱动层的接收队列中拉出来然后手动调用 netif-input。如果你在 FreeRTOS 环境下仍使用裸机示例的中断回调一不小心就会形成双路并发处理导致 LwIP 内核数据竞争。netif 初始化的典型代码是这样的struct netif g_netif; ip4_addr_t ipaddr, netmask, gw; IP4_ADDR(ipaddr, 192, 168, 1, 100); IP4_ADDR(netmask, 255, 255, 255, 0); IP4_ADDR(gw, 192, 168, 1, 1); netif_add(g_netif, ipaddr, netmask, gw, NULL, ethernetif_init, tcpip_input); netif_set_default(g_netif); netif_set_up(g_netif);初始化完成后网卡收包中断只负责做一件事从 DMA 描述符取出 pbuf然后调用 tcpip_input或者向某个邮箱发送通知。不要在中断里做复杂的处理也不要在多个上下文同时调用 tcpip_input。4.4 DHCP 启动和 link 状态管理如果项目需要 DHCP在 netif_set_up 之后调用 dhcp_start(g_netif)。但 DHCP 依赖底层链路先就绪所以在 PHY 的 link 状态发生变化时需要调用 netif_set_link_up 或 netif_set_link_down。我在 ethernetif.c 中实现了 PHY 状态轮询每隔几百毫秒读取 PHY 的状态寄存器检测到链接恢复就通知 LwIP 重新进入链路就绪状态。有的板子没有做 link 检测插拔网线后协议栈完全无感知表现就是 ping 不通直到设备复位。调试初期建议先使用静态 IP跳过 DHCP 的不确定性。等固定 IP 下 TCP 通信稳定了再打开 DHCP 验证租约获取。这样出问题时你能明确区分是 DHCP 流程的锅还是底层 PHY 的锅。5. 实测中的硬坑TCP 断连、堆栈溢出和吞吐量的排查思路5.1 先搭一个最小化验证链路移植完成后不要直接跑复杂业务先用最小测试环境确认链路。我通常先固定 IP通过网线把设备接到电脑然后在命令行 ping。如果 ping 不通进入下面检查清单用示波器或万用表确认 PHY 电源和 REF_CLK串口打印 HAL_ETH_Init 返回值读取 PHY 的 ID 寄存器确认 MDIO 通信正常打印 netif 的 link 状态和 IP 地址抓一次 PC 端 ping 包看设备是否发出 ARP 应答如果 ping 通了再用网络调试助手开一个 TCP Server。注意设备和 PC 必须处于同一网段掩码和网关配置要一致。这一步通过后再切换 DHCP 或接入路由器测试。5.2 TCP 断连的排查链路“TCP 连接建立后不定时断开”是最常见的稳定性问题也是最难定位的问题。我不会直接给结论分享一下我的排查链路。先检查 PHY 的 link 状态。如果 PHY 状态轮询误判网线断开netif_set_link_down 会让协议栈主动断开 TCP 连接。这种情况通常在电源电压不稳或者 RMII 信号质量差时出现。我遇到过一次持续一天的排查最后发现是 PHY 地址宏配错导致 PHY 状态寄存器读取失败轮询函数拿到的永远是 0于是每隔几秒就触发一次断链重连。再确认 ETH 中断调用 API 是否满足优先级约束。如果 ETH 中断优先级设得太高并且调用了 FreeRTOS API可能在特定时序下触发断言或任务切换错误。把优先级调到 5 到 7 区间可以规避大部分问题。第三步看 LwIP 的邮箱和缓冲。如果接收中断向邮箱投递 pbuf 失败说明 MBOX_SIZE 太小或 tcpip_thread 消费太慢。打开 LwIP 的统计宏观察 pbuf 分配失败次数和内存池失配次数这个比猜更直接。还要考虑 TCP 保活机制。LwIP 默认不开启 TCP KeepAlive如果设备接入家用路由器连接长时间空闲后会被 NAT 和路由器表项清掉服务器端看到的就是连接断开。如果需要设备主动维持长连接可以在 lwipopts.h 里开启 LWIP_TCP_KEEPALIVE并设置相应的探测间隔和重试次数。5.3 堆栈溢出检测和高水位分析前面说过任务栈溢出是隐形的系统杀手。开启 configCHECK_FOR_STACK_OVERFLOW 后FreeRTOS 会在任务切换时检查栈指针和栈标志。一旦发现溢出会调用 vApplicationStackOverflowHook。这个钩子不能直接 printf因为此时系统可能已经处于非常不可靠的状态。我的处理是让钩子控制一个专用 GPIO点亮板上的故障 LED然后停在一个死循环中。代码类似void vApplicationStackOverflowHook(TaskHandle_t xTask, char *pcTaskName) { (void) xTask; printf(stack overflow: %s\r\n, pcTaskName); GPIO_SetBits(GPIOB, GPIO_Pin_0); while (1) { } }但 printf 本身也依赖栈溢出钩子里调用 printf 有二次崩溃风险。把它改成写一个共享变量然后在 main 循环或另一个高可靠任务中周期性打印会更稳。真正量化每个任务栈余量的函数是 uxTaskGetStackHighWaterMark。我在任务创建后让它定期打印UBaseType_t highWater uxTaskGetStackHighWaterMark(xNetTaskHandle); printf(net task high watermark: %u words\r\n, (unsigned int)highWater);这个值表示该任务运行中剩余最少栈的 words 数而不是已用栈。如果高水位低于 50 words就说明栈给小了需要调大。我经常在调整任务栈配置时反复用这个函数观察比靠感觉改数靠谱得多。5.4 吞吐量上不去时从哪里入手F407 的 10/100M 以太网理论极限是 12.5MB/s实际 LwIP 移植在理想情况下能跑到 8 到 9MB/s。如果吞吐量只有 1 到 3MB/s而且 ping 延迟明显抖动一般不是算法问题而是下面某一项配置没有到位。首先是 DMA 描述符数量。CubeMX 默认 RX/TX 描述符可能只有 4 个如果加大 LwIP 缓冲池却不同步增加描述符DMA 接收能力会成为瓶颈。我建议 RX 描述符数量改为 8 或 12TX 描述符保持 4 到 8。然后是串口日志。很多调试代码在发送路径上加了 printf每收一包就打印一包。串口的波特率再高也只有 9 到 12MBbps比 DMA 收发慢得多直接拖垮整个任务调度。带上网络抓包工具跑一轮再把日志降低到只打印异常和统计吞吐立刻会改变。最后是 tcpip_thread 的存活保障。tcpip_thread 的优先级不能比普通业务任务低太多否则高优业务任务疯狂占用 CPU协议栈就没机会及时出包。建议将 tcpip_thread 的优先级保持在业务任务之上数值上对应 FreeRTOS 的高优先级区域但不要影响硬件中断实时性。6. 移植完成后代码组织、内存收缩和扩展方向6.1 建议的分层目录结构当 FreeRTOS 和 LwIP 都跑通后工程会变得庞大。如果不做分层三个月后你自己也找不着函数。我的项目管理习惯是这样的project/ ├─ app/ │ ├─ net_task.c │ ├─ mqtt_task.c │ └─ sensor_task.c ├─ board/ │ ├─ bsp_eth.c │ ├─ bsp_phy.c │ └─ bsp_led.c ├─ freertos/ │ ├─ FreeRTOSConfig.h │ └─ src/ ├─ lwip/ │ ├─ lwipopts.h │ └─ netif/ └─ main.cboard 层不要依赖 LwIP 类型只提供寄存器读写和 GPIO 控制。app 层统一通过 net_task 访问网络。这样如果换 PHY只需要改 board/bsp_phy.c如果换协议栈版本不需要动业务任务。6.2 内存和任务数的收缩调优跑通以后项目会自然进入资源优化阶段。先用 FreeRTOS 的 xPortGetFreeHeapSize 看整体空闲内存再逐个打印任务高水位根据数据缩小任务栈。不要一次性砍到刀刃上每次只改一个任务让设备持续运行半天再看高水位。LwIP 的资源收缩同理。如果项目不需要 TCP Server 同时连接很多客户端可以把 MEMP_NUM_TCP_PCB 调小如果只用 UDP可以把 LWIP_TCP 关掉释放一批连接结构的内存。我见过一个小型传感器采集设备RAM 总量只给了 128KB通过关闭 TCP、裁剪不必要的定时器最后空闲内存比初始方案多了 20KB运行稳定性反而更高。6.3 时间同步、MQTT 和 Modbus TCP 的扩展空间F407 FreeRTOS LwIP 这套组合稳定之后扩展空间非常大。SNTP 同步时间很适合做数据采集设备MQTT 可以接入常见物联网云平台但要注意 TLS 在 MCU 上的内存开销Modbus TCP 在工业场景里比裸 socket 更实用LwIP 的 Netconn API 很容易实现。我在实际项目中最常用的是把网络任务做成一个独立模块对外提供接收接口和发送接口。上层任务传入结构化数据网络任务负责把数据打包成 JSON 或者私有帧发出去。这样即使底层从 TCP 换成 UDP或者把 IP 地址改成 DHCP 获取上层代码几乎不用动。最后分享一个小技巧把 PHY 型号、PHY 地址、RMII 时钟模式这几项写在 bsp_eth.c 文件头部注释里。移植完成半年后再回来看代码你会发现这些注释比任何设计文档都管用。这个组合本身已经很成熟但每次改动硬件版本时这三项都是最需要重新确认的。如果把这一层底料打好后面不管换 PHY 还是换板子你都不至于再从零开始排查。