简介：这份资源面向STM32嵌入式开发学习者与工程师，聚焦STM32F407平台下FreeRTOS与LwIP协议栈的移植与联调，配合LAN8742A PHY模块，解决裸机网络通信难以支撑多任务调度的实际问题。工程由CubeMX生成基础框架，再手动添加线程并完成调试，最终实现ping与TCP回响测试，适合已掌握HAL库基础、希望进阶实时操作系统与TCP/IP协议栈的中级开发者参考。压缩包共674个文件，约46.13MB，以C源文件与头文件为主体，辅以编译中间文件、工程配置与调试文件，以及少量说明文档和PDF资料，完整保留了从源码到可执行固件的构建链路。目前已有801人学习下载，读者可借此理清FreeRTOS任务划分与LwIP网卡驱动、协议栈初始化的衔接方式，掌握TCP回响服务的搭建思路与常见网络调试排错方法，也可直接复用工程结构进行二次开发。
1. 从裸机到协议栈：为什么STM32F407上跑FreeRTOS+LwIP值得单独拆一遍
很多做嵌入式的朋友第一次接触网络通信，都是从串口透传模块或者现成的AT指令WiFi模组开始的。但一旦产品要求本地跑TCP Server、要做多客户端并发、还要在通信的同时处理传感器采集和UI刷新，裸机while(1)里塞一个LwIP轮询就明显不够用了。STM32F407这颗片子有168MHz主频、192KB SRAM、自带以太网MAC控制器，配上FreeRTOS做任务调度、LwIP做TCP/IP协议栈，是一套非常经典的“中量级”联网方案。这套组合能解决的核心问题是：在单芯片上同时跑实时控制和标准TCP/IP通信，不依赖外部协议栈芯片，成本可控、延迟可预期。适合谁？适合已经能点灯、能调通串口、想往“带操作系统的网络设备”方向走的嵌入式开发者。但FreeRTOS和LwIP的耦合方式、内存池配置、PHY驱动适配，每一步都有翻车的可能，这也是为什么值得单独拆一遍。
2. 任务划分与内存池：FreeRTOS和LwIP怎么绑才不打架
2.1 三种集成模式的选择逻辑
FreeRTOS和LwIP的集成方式，常见做法有三种：第一种是LwIP跑在裸机主循环里，FreeRTOS只负责其他任务，两者通过信号量同步；第二种是LwIP跑在独立任务中，用sys_arch对接FreeRTOS的邮箱和信号量；第三种是LwIP的tcpip_thread作为唯一协议栈线程，应用任务通过tcpip_api或netconn接口通信。第一种最省事但实时性差，网络事件会阻塞其他任务；第二种灵活但需要自己实现sys_arch.c里的邮箱、信号量、互斥量；第三种是LwIP官方推荐的NO_SYS=0模式，协议栈内部有自己的线程，应用层用netconn或socket接口，隔离性最好。
我一般会选第三种。原因是：tcpip_thread统一处理所有网络事件，应用任务不需要关心协议栈内部状态机，减少竞态。代价是多一个任务栈开销，F407的192KB SRAM完全扛得住。
2.2 lwipopts.h里必须改的五个参数
LwIP的配置全在lwipopts.h里，默认值是按“最小系统”给的，直接用在F407上会出各种玄学问题。下面是我每次必改的五个参数：
// lwipopts.h - STM32F407 + FreeRTOS 关键配置 #define NO_SYS 0 // 使用操作系统模式 #define LWIP_NETCONN 1 // 启用netconn API #define LWIP_SOCKET 1 // 启用socket API（可选） #define MEMP_NUM_TCP_PCB 10 // 同时活跃的TCP连接数 #define MEMP_NUM_TCP_PCB_LISTEN 4 // 监听中的TCP连接数 #define TCP_SND_BUF (4 * TCP_MSS) // 发送缓冲区 #define TCP_WND (4 * TCP_MSS) // 接收窗口 #define MEM_SIZE (16 * 1024) // 堆内存池大小 #define PBUF_POOL_SIZE 16 // pbuf池数量NO_SYS=0是启用OS模式的总开关，不改这个后面全白搭。MEMP_NUM_TCP_PCB控制同时能有多少个TCP控制块，做tcpecho测试时如果只设默认的5，压测到第6个连接就会静默失败。TCP_SND_BUF和TCP_WND设成4倍MSS是吞吐和内存的折中，设太小会导致滑动窗口频繁收缩，吞吐上不去；设太大在F407上容易把堆吃光。MEM_SIZE给16KB是底线，低于这个值在并发连接时mem_malloc会返回NULL。
2.3 sys_arch.c的邮箱和信号量实现
OS模式下必须提供sys_arch.c，核心是实现sys_mbox_new、sys_mbox_post、sys_arch_mbox_fetch、sys_sem_new等函数。这些函数本质是把FreeRTOS的QueueHandle_t和SemaphoreHandle_t包一层：
// sys_arch.c - 邮箱创建（基于FreeRTOS队列） err_t sys_mbox_new(sys_mbox_t *mbox, int size) { *mbox = xQueueCreate(size, sizeof(void *)); if (*mbox == NULL) return ERR_MEM; return ERR_OK; } // 邮箱投递（带超时） void sys_mbox_post(sys_mbox_t *mbox, void *msg) { while (xQueueSendToBack(*mbox, &msg, portMAX_DELAY) != pdTRUE); } // 邮箱接收（返回等待的毫秒数，SYS_ARCH_TIMEOUT表示超时） u32_t sys_arch_mbox_fetch(sys_mbox_t *mbox, void **msg, u32_t timeout) { TickType_t ticks = (timeout == 0) ? portMAX_DELAY : pdMS_TO_TICKS(timeout); if (xQueueReceive(*mbox, msg, ticks) == pdTRUE) { return 0; // 成功 } return SYS_ARCH_TIMEOUT; }这里有个容易翻车的点：sys_mbox_post用portMAX_DELAY阻塞等待，如果队列满了会一直卡住。在中断上下文里调用时必须用sys_mbox_trypost，否则会触发FreeRTOS的断言。另外sys_arch_mbox_fetch的返回值单位是毫秒，不是tick，LwIP内部用它判断超时，返回错了会导致协议栈状态机异常。
3. 从PHY到tcpecho：一次完整的TCP回环链路搭建
3.1 PHY芯片初始化和RMII接口配置
F407通过RMII接口连外部PHY芯片（常见如LAN8720、DP83848）。CubeMX里配置ETH外设时，关键参数是：RMII模式、自动协商开启、校验和卸载按需。PHY地址由PHYAD引脚决定，硬件上拉或下拉，软件里ETH_InitTypeDef的PHYAddress必须和硬件一致，否则ETH_ReadPHYRegister读回来全是0xFFFF。
// eth_init.c - PHY初始化关键片段 ETH_InitTypeDef ETH_InitStructure; ETH_InitStructure.ETH_AutoNegotiation = ETH_AutoNegotiation_Enable; ETH_InitStructure.ETH_Speed = ETH_Speed_100M; ETH_InitStructure.ETH_Mode = ETH_Mode_FullDuplex; ETH_InitStructure.ETH_ChecksumOffload = ETH_ChecksumOffload_Enable; // PHY地址必须和硬件匹配，LAN8720默认地址0 if (ETH_Init(Ð_InitStructure, 0x00) == ETH_ERROR) { // 初始化失败，检查RMII时钟（50MHz）和PHY供电 Error_Handler(); }RMII的50MHz参考时钟来源要确认：要么外部晶振直接给PHY，要么从MCU的MCO引脚输出。如果时钟不对，PHY能读ID但链路协商永远不成功。我遇到过一块板子，PHY ID读得到，但ETH_Init一直返回ERROR，最后查出来是MCO输出的50MHz被误配成了25MHz。
3.2 创建tcpecho任务和netconn API调用
LwIP的netconnAPI比raw API好用，比socket API轻量。tcpecho的标准流程是：新建NETCONN_TCP类型的连接 → 绑定端口 → 监听 → 接受连接 → 循环接收和回发。
// tcpecho.c - 基于netconn的TCP回环服务器 void tcpecho_thread(void *arg) { struct netconn *conn, *newconn; struct netbuf *buf; err_t err; void *data; u16_t len; conn = netconn_new(NETCONN_TCP); netconn_bind(conn, IP_ADDR_ANY, 7); // 端口7是标准echo端口 netconn_listen(conn); while (1) { err = netconn_accept(conn, &newconn); if (err == ERR_OK) { while ((err = netconn_recv(newconn, &buf)) == ERR_OK) { do { netbuf_data(buf, &data, &len); netconn_write(newconn, data, len, NETCONN_COPY); } while (netbuf_next(buf) >= 0); netbuf_delete(buf); } netconn_close(newconn); netconn_delete(newconn); } } }netconn_bind的第二个参数用IP_ADDR_ANY表示绑定所有本地地址，第三个参数是端口号。netconn_recv返回ERR_OK后，netbuf里可能有多段数据，必须用netbuf_next循环取完，只取第一段会丢数据。netconn_write的NETCONN_COPY标志表示数据会被拷贝到协议栈内部缓冲区，调用返回后应用层的data可以释放；如果用NETCONN_NOCOPY，则必须保证数据在发送完成前有效，否则会发出乱码。
3.3 任务优先级和栈大小的实际取值
在FreeRTOS里创建任务时，tcpip_thread的优先级必须高于应用任务，否则网络事件处理不及时。我一般这样分配：
| 任务名 | 优先级 | 栈大小（字） | 说明 |
|---|---|---|---|
| tcpip_thread | 4 | 512 | LwIP核心线程，最高 |
| tcpecho_thread | 3 | 256 | 应用层回环任务 |
| led_task | 1 | 128 | 状态指示，最低 |
栈大小单位是StackType_t，F407上是4字节，所以512字=2KB。tcpip_thread的栈不能小于512字，否则在大量并发连接时tcpip_thread内部调用mem_malloc会栈溢出，表现是随机HardFault。tcpecho_thread的256字够用，但如果要加日志打印，建议加到384字。
4. 避坑排查：tcpecho跑不通时先看这五个地方
4.1 ping不通但PHY链路灯亮
现象：网口灯正常闪烁，PC能识别到链路，但ping不通。原因通常是IP地址配置和PC不在同一网段，或者netif没有正确设置。解决：检查netif_set_default和netif_set_up是否调用，确认IP_ADDR、NETMASK、GW三个宏和PC网段匹配。如果PC是192.168.1.x，设备设成192.168.0.x就ping不通。
4.2 tcpecho连接建立后立即断开
现象：用网络调试工具连上端口7，但马上被断开，回环数据收不到。原因多半是netconn_recv返回了非ERR_OK的错误码，但代码里没有区分错误类型就直接关闭连接。解决：在while循环里加错误码判断，如果是ERR_CLSD或ERR_RST，说明对端主动关闭，正常退出；如果是ERR_MEM，说明pbuf池耗尽，需要增大PBUF_POOL_SIZE。
4.3 大数据量回环时丢包或卡死
现象：发小包正常，一发几KB的数据就卡住或丢包。原因是TCP_SND_BUF和PBUF_POOL_SIZE太小，协议栈没有足够缓冲区容纳数据。解决：把TCP_SND_BUF调到8 * TCP_MSS，PBUF_POOL_SIZE调到32，同时确认MEM_SIZE不低于32KB。另外检查netconn_write是否用了NETCONN_COPY，用NETCONN_NOCOPY时如果数据在发送完成前被修改，也会导致内容错乱。
4.4 中断里调用LwIP函数导致HardFault
现象：网线插拔时随机HardFault，或者收到数据后死机。原因是ETH中断服务函数里直接调用了netconn_或sys_mbox_post（阻塞版本）。解决：中断里只能用sys_mbox_trypost或sys_sem_signal这类非阻塞API，并且要通过tcpip_input把数据包投递给tcpip_thread，不要在中断里直接处理协议栈逻辑。
4.5 DHCP获取不到IP但静态IP正常
现象：设成静态IP能通信，改成DHCP就一直拿不到地址。原因是lwipopts.h里LWIP_DHCP没开，或者dhcp_start没有在netif上调用。解决：确认LWIP_DHCP=1，并在netif_add之后、netif_set_up之前调用dhcp_start(&netif)。另外DHCP超时时间DHCP_COARSE_TIMER_SECS默认是1秒，如果网络环境慢，可以适当加大。
5. 压测与调优：把tcpecho从“能跑”推到“能扛”
5.1 用脚本做并发连接压测
tcpecho跑通只是第一步，真正要验证的是并发能力。我一般用Python写一个简单的并发压测脚本，开50个线程同时连接、发送固定长度数据、校验回显是否一致：
# stress_test.py - 并发tcpecho压测 import socket, threading, time HOST, PORT = "192.168.1.100", 7 THREADS, PAYLOAD = 50, b"A" * 1024 def worker(tid, results): try: s = socket.create_connection((HOST, PORT), timeout=5) s.sendall(PAYLOAD) echoed = b"" while len(echoed) < len(PAYLOAD): chunk = s.recv(4096) if not chunk: break echoed += chunk results[tid] = (echoed == PAYLOAD) s.close() except Exception as e: results[tid] = False results = {} threads = [threading.Thread(target=worker, args=(i, results)) for i in range(THREADS)] start = time.time() for t in threads: t.start() for t in threads: t.join() elapsed = time.time() - start ok = sum(1 for v in results.values() if v) print(f"成功 {ok}/{THREADS}，耗时 {elapsed:.2f}s")这个脚本的关键参数是THREADS和PAYLOAD。50个并发连接对应MEMP_NUM_TCP_PCB至少设50，PAYLOAD设1KB对应PBUF_POOL_SIZE至少32。如果跑出来成功率低于90%，先看lwipopts.h里的MEMP_NUM_TCP_PCB和PBUF_POOL_SIZE是否够用，再看tcpip_thread的栈是否溢出。
5.2 用LWIP_STATS定位瓶颈
LwIP内置了统计功能，在lwipopts.h里打开LWIP_STATS=1和LWIP_STATS_DISPLAY=1，然后在运行时调用stats_display()，串口会打印各层统计信息。重点看三个字段：mem的err计数（内存分配失败次数）、memp的err计数（内存池耗尽次数）、tcp的drop计数（TCP层丢包数）。如果mem.err持续增长，说明MEM_SIZE不够；如果memp.err增长，说明对应的池子（如MEMP_PBUF_POOL）太小；如果tcp.drop增长，说明接收窗口太小或处理速度跟不上。
5.3 一个我踩过的坑：任务栈溢出不会报错
FreeRTOS的栈溢出检测默认是关的，configCHECK_FOR_STACK_OVERFLOW设成0时，栈溢出会直接踩到相邻内存，表现是随机HardFault或数据错乱，没有任何提示。我建议在调试阶段设成2（启用栈填充模式），并实现vApplicationStackOverflowHook，在里面打印任务名并死循环。等产品稳定后再关掉，省一点开销。从那以后我每次新建任务，都会先用uxTaskGetStackHighWaterMark查一下实际栈使用峰值，再决定最终栈大小，而不是拍脑袋给个数。希望帮到你。
本文还有配套的精品资源，点击获取
