1. 项目缘起与整体设计思路嵌入式网络通信这块STM32F4 系列配合 LWIP 协议栈算是经典组合了。我最早接触这套方案是在一个数据采集终端项目上当时的需求很明确设备上电后自动获取 IP然后周期性地把采集到的数据通过 HTTP POST 发到远端服务器。听起来简单但真做起来DHCP 自动获取地址、DNS 域名解析、TCP 客户端连接、HTTP 报文拼装每一个环节都有坑。这个例程标题里列出的几个关键词——STM32F4、LWIP、HTTP client、DHCP、DNS——基本涵盖了嵌入式设备联网的核心链路。先说说为什么选这套方案。STM32F4 自带 10/100M 以太网 MAC 控制器外接一颗 PHY 芯片就能实现有线网络通信硬件成本低、稳定性好。LWIP 是轻量级 IP 协议栈RAM 占用可以裁剪到几十 KB非常适合资源受限的 MCU。相比用串口转以太网模块或者外挂 WiFi 模组直接跑 LWIP 的好处是链路可控、延迟低、不依赖第三方模组的固件质量。当然代价就是你需要自己啃协议栈配置和网络编程。整个例程的核心思路是这样的系统启动后先初始化以太网外设和 LWIP 协议栈然后启动 DHCP 客户端去获取 IP 地址、子网掩码、网关和 DNS 服务器地址。拿到 IP 之后通过 DNS 模块把目标服务器的域名解析成 IP 地址。最后创建 TCP 客户端连接按照 HTTP 协议格式发送请求报文接收响应并解析。这条链路走通了基本上嵌入式设备联网的大部分场景都能覆盖。我见过不少人一上来就直接写死 IP 地址、跳过 DHCP 和 DNS调试阶段确实省事但产品化的时候就会遇到问题现场网络环境千差万别客户不可能给你手动配 IP。所以这个例程把 DHCP 和 DNS 都包含进来是很有实际意义的。2. 核心细节解析与实操要点2.1 硬件层STM32F4 以太网外设与 PHY 连接STM32F4 的以太网外设支持 MII 和 RMII 两种接口模式。RMII 用的引脚少只需要 7 根信号线在 PCB 布线紧张的时候是首选。我一般推荐用 RMII 模式外部提供一个 50MHz 的时钟源给 PHY 和 MCU 共用。PHY 芯片选型上常见的有 LAN8720、DP83848 这些LAN8720 性价比高支持自动协商跟 STM32F4 搭配很成熟。接线的时候有几个容易出错的地方。RMII_REF_CLK 这个 50MHz 时钟如果 PHY 芯片自己产生那就配置 PHY 输出时钟给 MCU如果 MCU 这边有外部晶振提供那就反过来。这个方向搞错了MDIO 通信直接不通。另外复位引脚和中断引脚别接反了PHY 的复位时间要保证足够长一般至少 100ms太短了 PHY 内部寄存器还没准备好。注意PCB 布线时 RMII 的时钟线和数据线要等长差分线阻抗控制在 50 欧姆否则高速通信时误码率会明显上升。2.2 协议栈层LWIP 的裁剪与配置LWIP 的配置文件 lwipopts.h 是整个协议栈行为的控制中心。这个文件里每一个宏定义都直接影响内存占用和功能特性。我一般会重点关注这几个参数配置项推荐值说明MEM_SIZE16KB~32KB协议栈堆内存太小会导致分配失败PBUF_POOL_SIZE8~16pbuf 池数量影响并发处理能力TCP_SND_BUF2~4倍MSS发送缓冲区影响吞吐量TCP_WND2~4倍MSS接收窗口影响接收效率MEMP_NUM_TCP_PCB4~8TCP 控制块数量按并发连接数设置LWIP_DHCP1启用 DHCP 客户端LWIP_DNS1启用 DNS 解析LWIP_NETCONN1启用 Netconn API方便应用层调用MSS 在以太网环境下一般是 1460 字节。TCP_SND_BUF 设成 2920 或者 4380 比较合适太小了发送效率低太大了浪费内存。STM32F4 有 192KB 的 SRAM跑 LWIP 加应用程序绰绰有余但如果你用的是 F4 系列里 RAM 较小的型号就得精打细算了。还有一个关键点是内存对齐。LWIP 的 pbuf 结构体要求 4 字节对齐如果你自定义内存池地址必须对齐到 4 字节边界否则在某些编译器优化级别下会出现硬件异常。这个坑我踩过现象是随机性的 HardFault查了好久才定位到。2.3 DHCP 客户端的工作流程DHCP 获取 IP 的过程分四个阶段DISCOVER、OFFER、REQUEST、ACK。LWIP 的 DHCP 模块把这些都封装好了你只需要在初始化的时候调用dhcp_start()然后在主循环里定期调用dhcp_fine_tmr()和dhcp_coarse_tmr()就行。但实际使用中有几个细节要注意。第一DHCP 获取地址是需要时间的通常几秒钟如果网络环境复杂可能更久。你的应用程序不能一上来就假设网络已经通了得等 DHCP 状态变成DHCP_BOUND才能开始后续操作。第二DHCP 租约到期后会续租如果续租失败会重新走一遍获取流程这时候 IP 可能会变你的 TCP 连接会断开应用层要做好重连准备。我一般的做法是注册一个回调函数在 DHCP 状态变化的时候打印日志方便调试。LWIP 提供了dhcp_set_struct()来绑定自定义的 dhcp 结构体这样你可以同时管理多个网络接口的 DHCP 状态。2.4 DNS 解析的实现细节DNS 解析这块LWIP 提供了dns_gethostbyname()函数支持同步和异步两种模式。同步模式会阻塞当前线程直到解析完成在裸机环境下容易导致看门狗复位不推荐。异步模式需要你提供一个回调函数解析完成后 LWIP 会调用这个回调通知你结果。err_t dns_err dns_gethostbyname(api.example.com, server_ip, dns_found_callback, NULL); if (dns_err ERR_INPROGRESS) { // 解析进行中等待回调 } else if (dns_err ERR_OK) { // 缓存命中直接拿到IP }DNS 服务器地址是从 DHCP 获取的如果 DHCP 没启用或者没拿到 DNS 地址你也可以手动设置一个。dns_setserver(0, dns_server_ip)可以设置主 DNS 服务器。提示DNS 解析超时时间默认是 14 秒左右如果网络环境差可以适当调大 DNS_MAX_RETRIES 和 DNS_TIMEOUT 的值。3. 实操过程与核心环节实现3.1 工程搭建与底层驱动初始化我一般用 STM32CubeMX 生成基础工程把 ETH 外设配置好LWIP 中间件勾上然后手动调整 lwipopts.h 里的参数。CubeMX 生成的代码框架比较规范但有些默认配置需要改。比如 PHY 地址CubeMX 默认是 0但实际硬件上 PHY 地址可能由引脚电平决定得根据原理图确认。底层驱动初始化顺序很重要先初始化 GPIO 和时钟再初始化 ETH 外设然后初始化 LWIP最后启动 DHCP。顺序搞反了会出现 ETH 中断触发了但 LWIP 还没准备好导致数据包丢失。// 典型的初始化流程 MX_GPIO_Init(); MX_ETH_Init(); MX_LWIP_Init(); // 内部会调用 lwip_init() 和 netif_add() // 启动DHCP dhcp_start(gnetif);MX_LWIP_Init() 里面做了几件事调用 lwip_init() 初始化协议栈内核配置 netif 结构体的 IP 地址、子网掩码、网关DHCP 模式下这些先设成 0设置 netif 的 output 和 linkoutput 函数指针指向以太网发送函数最后调用 netif_add() 把网络接口注册到 LWIP 里。3.2 主循环中的协议栈处理裸机环境下LWIP 需要周期性调用几个定时器处理函数。我一般放在主循环里配合 SysTick 中断来计时。while (1) { // 处理以太网接收 ethernetif_input(gnetif); // 处理LWIP超时 sys_check_timeouts(); // 处理DHCP定时器 // 如果用了NO_SYS0的模式这些由tcpip_thread处理 // 应用层逻辑 if (dhcp_supplied_address(gnetif)) { // 网络已就绪执行HTTP请求 } }如果用的是 FreeRTOSLWIP 可以跑在独立的 tcpip_thread 里应用层通过 Netconn API 或者 Socket API 跟协议栈交互这样实时性更好。裸机模式下所有操作都在主循环里串行执行要注意别在某个环节阻塞太久。3.3 HTTP 客户端报文拼装与发送HTTP 请求报文的格式是有严格规范的。一个典型的 POST 请求长这样POST /api/data HTTP/1.1\r\n Host: api.example.com\r\n Content-Type: application/json\r\n Content-Length: 45\r\n Connection: close\r\n \r\n {temperature:25.6,humidity:60.2}每一行以\r\n结尾头部和正文之间有一个空行。Content-Length 必须准确否则服务器会一直等或者直接拒绝。Connection 头设成 close 表示请求完成后关闭连接这样简单可靠不用处理长连接的心跳和重连。发送的时候用 Netconn API 比较方便struct netconn *conn netconn_new(NETCONN_TCP); netconn_connect(conn, server_ip, 80); netconn_write(conn, http_request, strlen(http_request), NETCONN_COPY); // 接收响应 struct netbuf *buf; netconn_recv(conn, buf); // 解析响应... netconn_close(conn); netconn_delete(conn);netconn_write 的最后一个参数用 NETCONN_COPY 表示 LWIP 会拷贝一份数据这样你的 http_request 缓冲区可以立即复用。如果用 NETCONN_NOCOPY那缓冲区在发送完成前不能修改得配合信号量使用。3.4 响应接收与解析接收响应的时候要注意TCP 是流式协议一次 netconn_recv 不一定能拿到完整的 HTTP 响应。你需要根据 Content-Length 或者 Transfer-Encoding 来判断响应是否接收完整。简单的做法是循环接收直到连接关闭把所有数据拼起来再解析。解析 HTTP 响应主要是提取状态码和正文。状态码在第一行的空格后面200 表示成功404 表示路径不对500 表示服务器内部错误。正文从第一个空行之后开始。如果响应头里有 Content-Length就按这个长度截取正文如果是 chunked 编码还得先解码。注意接收缓冲区要留够空间HTTP 响应头可能有好几百字节正文可能更大。我一般用 2KB 的缓冲区如果响应特别大就分片处理。4. 常见问题与排查技巧实录4.1 网络不通的排查思路网络不通是最常见的问题排查要按层次来。先看物理层网口的 Link 灯亮不亮不亮说明 PHY 没协商成功检查网线、PHY 供电、复位电路。Link 灯亮了再看 MAC 层用netif_is_link_up()确认 LWIP 是否检测到链路状态。然后看 IP 层DHCP 有没有拿到地址dhcp_supplied_address()返回什么。最后看应用层DNS 解析成不成功TCP 连接能不能建立。我整理了一个速查表现象可能原因排查方法Link灯不亮PHY供电异常、网线故障、复位未释放测PHY电压、换网线、查复位引脚DHCP获取不到IP网络中没有DHCP服务器、防火墙拦截抓包看DISCOVER有没有发出DNS解析失败DNS服务器地址不对、域名拼写错误打印DNS服务器IP、用IP直连测试TCP连接超时服务器端口不对、网络路由不通ping服务器IP、telnet端口HTTP返回400请求报文格式错误打印完整请求报文逐字节检查随机HardFault内存对齐问题、栈溢出检查pbuf地址对齐、增大栈空间4.2 内存分配失败的定位LWIP 内存不够的时候mem_malloc()会返回 NULLpbuf_alloc 会返回 NULL。如果你发现网络时通时不通或者大数据量传输时崩溃大概率是内存不够。可以打开 LWIP_STATS 和 MEM_STATS通过mem_stat()查看内存使用情况。我遇到过一次TCP_SND_BUF 设了 8KBPBUF_POOL_SIZE 设了 16结果系统跑一会儿就死机。后来发现是 MEM_SIZE 只设了 8KB协议栈堆不够用。把 MEM_SIZE 调到 24KB 之后问题解决。所以这几个参数要匹配着调不能只看一个。4.3 实际项目中的经验教训第一个教训是别在中断里调用 LWIP 的 API。以太网接收中断里只做数据包入队具体的协议栈处理放到主循环或者 tcpip_thread 里做。我见过有人在中断里直接调 netconn_write结果各种奇怪的死锁。第二个教训是 DHCP 和静态 IP 要能切换。产品出厂默认用 DHCP但有些客户现场没有 DHCP 服务器需要手动配 IP。我一般会在 Flash 里存一个配置标志上电的时候读出来决定用哪种模式。第三个教训是 DNS 缓存。LWIP 的 DNS 模块有缓存机制默认缓存 4 条记录。如果你的设备需要访问多个域名可以把 DNS_TABLE_SIZE 调大一点。另外 DNS 缓存有过期时间过期后会重新解析这个过程中如果网络断了解析会失败应用层要能处理这种情况。第四个教训是看门狗。网络操作可能耗时较长比如 DHCP 获取地址、DNS 解析、TCP 连接超时这些操作加起来可能十几秒。如果你的看门狗超时时间设得比较短记得在这些操作中间喂狗或者把看门狗超时时间设长一点。5. 性能优化与进阶方向5.1 提高 TCP 传输效率默认配置下LWIP 的 TCP 发送窗口和接收窗口都比较保守吞吐量上不去。如果你的应用需要传大文件或者高频发送数据可以调整这几个参数TCP_WND 设成 4 倍 MSS 也就是 5840TCP_SND_BUF 同样设成 4 倍 MSSTCP_MSS 确认是 1460。另外开启 TCP_NODELAY 可以禁用 Nagle 算法减少小包延迟。还有一个技巧是用零拷贝发送。Netconn API 的 netconn_write 用 NETCONN_NOCOPY 标志配合 pbuf 直接引用你的数据缓冲区避免一次内存拷贝。但要注意数据缓冲区在发送完成前不能被修改需要配合信号量或者回调来管理。5.2 多连接与并发处理如果你的设备需要同时跟多个服务器通信比如一个上报数据、一个接收指令那就需要多个 TCP 连接。MEMP_NUM_TCP_PCB 要设成至少 4每个连接占一个 PCB。用 Netconn API 的话每个连接对应一个 netconn 结构体可以在不同的线程里独立操作。裸机环境下做多连接比较麻烦因为所有操作都在主循环里串行执行。我一般用状态机来管理每个连接一个状态变量主循环里轮询处理。如果连接数多或者数据量大还是建议上 FreeRTOS每个连接一个任务逻辑清晰得多。5.3 断线重连机制网络环境不稳定的时候TCP 连接可能会断开。LWIP 会通过回调通知你连接状态变化你需要在回调里做重连处理。我一般的做法是设置一个重连标志主循环里检测到这个标志就重新走一遍 DNS 解析和 TCP 连接流程。重连间隔设成 5 秒左右太频繁了会给服务器压力太慢了数据延迟大。DNS 解析结果可以缓存起来重连的时候直接用缓存的 IP不用每次都重新解析。但要注意 DNS 缓存有过期时间如果解析失败或者连接失败多次还是要重新解析一次。6. 调试工具与手段6.1 串口打印与日志分级调试网络问题串口打印是最基本的手段。我一般会定义一个日志宏支持不同级别ERROR、WARN、INFO、DEBUG。发布版本只保留 ERROR 和 WARN调试版本打开全部。LWIP 本身也支持调试输出在 lwipopts.h 里把 LWIP_DEBUG 打开然后按模块设置 LWIP_DBG_MIN_LEVEL可以看到协议栈内部的详细流程。但要注意串口打印本身会占用时间如果打印太多会影响网络性能。我一般只在关键节点打印比如 DHCP 状态变化、DNS 解析结果、TCP 连接建立和断开、HTTP 请求发送和响应接收。6.2 抓包分析如果条件允许用网络抓包工具抓一下数据包能解决大部分疑难问题。可以看到 DHCP 的交互过程、DNS 的查询和响应、TCP 的三次握手和四次挥手、HTTP 的请求和响应内容。抓包的时候最好在设备和服务器两端同时抓对比着看能快速定位是设备没发出去还是服务器没响应。6.3 内存与 CPU 占用监控LWIP 提供了统计功能可以查看内存使用、pbuf 使用、TCP 连接数等信息。在 lwipopts.h 里打开 LWIP_STATS、MEMP_STATS、MIB2_STATS然后定期调用 stats_display() 打印统计信息。这个对优化内存配置很有帮助能看到哪个池子快用完了哪个参数需要调整。CPU 占用方面可以在主循环里翻转一个 GPIO用示波器看占空比粗略估计 CPU 负载。如果主循环跑一圈的时间太长说明协议栈处理或者应用逻辑有阻塞需要优化。7. 从例程到产品的距离这个例程跑通只是第一步真正用到产品上还有不少工作要做。首先是稳定性要长时间跑看会不会内存泄漏、会不会死机。我一般会做一个 72 小时连续运行测试期间不断发送 HTTP 请求观察内存使用曲线和连接状态。其次是异常处理网络断开、服务器无响应、DNS 解析失败、DHCP 续租失败这些异常情况都要有对应的处理逻辑。不能一出问题就死机或者重启要能自动恢复。然后是配置管理服务器地址、端口、上报周期这些参数最好做成可配置的存在 Flash 里通过串口或者网页界面修改。这样现场调试的时候不用重新烧固件。最后是安全性如果数据敏感HTTP 要换成 HTTPS但这需要 TLS 支持。LWIP 可以配合 mbedTLS 实现不过对 RAM 和 Flash 的占用会明显增加STM32F4 跑起来会比较吃力可能需要外扩 RAM 或者换更高端的型号。我在实际项目中还遇到过一个情况设备在客户现场能获取到 IP但 DNS 解析总是失败。后来发现是客户的网络里 DNS 服务器地址是通过 DHCP 选项下发的但那个选项不是标准选项LWIP 默认不解析。解决办法是在 dhcp 结构体里手动处理那个选项或者干脆在代码里写死一个公共 DNS 地址作为备选。这种问题没有通用解法只能具体环境具体分析。总的来说STM32F4 加 LWIP 这套方案成熟度很高资料也多适合作为嵌入式网络开发的入门和进阶平台。把 DHCP、DNS、TCP、HTTP 这条链路吃透再去看 MQTT、CoAP 这些应用层协议会发现底层逻辑都是相通的。
