企业官网建设流程全解析

简介：面向STM32F407开发者的以太网应用学习资源，整合了官方固件库与LWIP轻量级TCP/IP协议栈，适合需要在嵌入式设备上实现网络通信、TCP/UDP服务或HTTP服务器的中高级开发者。压缩包共2000个文件，以1041个h头文件、881个c源文件和78个txt文档为主，涵盖硬件驱动、协议栈源码、示例程序与说明文本，整体大小约28.86MB，便于按目录索引查阅。已有447人学习该资源，反馈场景集中于工业控制、物联网网关等项目的以太网功能开发。通过其中的ETH_LWIP例程，读者可以掌握STM32F407以太网MAC的初始化流程，学会配置MAC地址与网络参数，并基于LWIP建立TCP或UDP连接，进一步实现数据收发、DHCP自动获取IP等实用功能。这份资料将寄存器操作、HAL库调用与协议栈移植整合为可参考的工程模板，能显著缩短网络功能的调试周期。

1. 别急着解压编译：这套 STM32F407 固件库里的 ETH+LwIP 到底能解决什么

STM32F407 固件库里带 ETH 目录的压缩包，是很多人在拿到评估板后收到的第一份网络参考。它把 MAC 驱动、外挂 PHY 的管理代码、ETH 的 DMA 描述符和 LwIP 协议栈打包在一个工程里，解决的不是让你从零写 TCP/IP，而是把这套模板里的硬件初始化、协议栈配置和示例回调改到自己的板子上，最快一天之内能听到 ping 的返回。

如果你要做裸机下的以太网数据采集、简易 web 服务器、TCP 上报或 UDP 广播，这份资源很适合作为起点。它默认按标准外设库组织代码，对刚接触 F407 以太网的人比直接啃协议栈源码友好得多。接下来我会从数据通路、移植步骤和踩坑记录三部分展开，最后给出一套我每块板子都跑的验证流程。

2. ETH 外设和 LwIP 的关系：MAC、外挂 PHY 与 DMA 描述符三块基石

拿到压缩包后，我一般不会先急着打开 main.c，而是把芯片手册里 ETH 相关章节翻一遍。STM32F407 内部集成了一个 10/100M 以太网 MAC，支持 MII 和 RMII 两种外部接口，但它不包含物理层收发器。也就是说，板上那颗 PHY 芯片才是真正负责把差分信号送到网口变压器上的角色。固件库例程里已经为某颗常见 RMII PHY 写好了底层寄存器读写函数，但换到你的板子时，PHY 地址、时钟输入方式、复位引脚必须按原理图重新核对，否则例程跑起来像是在解一道没有题干的应用题。

从宏观上看，F407 的 ARM Cortex-M4 主频虽然不低，但让 CPU 去逐帧解析 ARP、IP、TCP 的状态机太不经济。LwIP 是一个高度可裁剪的轻量协议栈，能把协议处理状态机做成一个可调用的模块，裸机下只占一个主循环，带 RTOS 时又能用信号量把收发线程解耦。这也是固件库例程普遍选择 LwIP 而不是从零写协议的原因：你只需要把驱动层的“网卡”抽象做对，剩下的 TCP 重传、分片、路由表都交给协议栈处理。

2.1 内置 MAC 与外挂 PHY：评估板上为什么网口只跑 100M

很多人拿到一块带千兆网口的评估板，以为 F407 能跑千兆，其实 F407 的 ETH 外设最高只支持 100M。这个限制不在 PHY，而在 MAC 和内部数据路径。MII 接口需要 25MHz 参考时钟，占用的引脚较多；RMII 接口把发送和接收各压缩到 2 根数据线，只需要 50MHz 参考时钟，引脚数量明显减少，因此在紧凑型板卡上更常见。固件库例程默认使用的多半是 RMII 模式，你的板子如果走的是 MII，那引脚配置和时钟源都要重新设定，不是简单改一个宏就能绕过去的。

RMII 虽然没有 MII 那么多引脚，但多出一个 50MHz 参考时钟的要求。这颗时钟可以由外部晶振提供，也可以由主控的 MCO 引脚输出。如果例程里用的是 PA8 输出 50MHz 的写法，而你的 PHY 实际上需要外部晶体，两者会在时序上打架。我的习惯是先读 PHY 厂商手册里的时钟模式章节，再去对照固件库里的ETH_BSP_Config函数，而不是先改代码再量波形。

提示：PHY 地址不要靠猜，看原理图上地址引脚的上拉和下拉组合，再去读 PHY ID 寄存器确认。这一步错了，后面整个网口都像黑匣子。

2.2 DMA 描述符环形队列：pbuf 和 MAC 之间的“信箱”

F407 的 ETH 数据收发不是靠 CPU 一个字节一个字节搬的，而是由 DMA 直接访问内存。这个 DMA 维护两组描述符，一组给发送方向，一组给接收方向。每个描述符里存有缓冲区地址、数据长度、状态标志和控制标志。接收方向，当 MAC 收到一帧数据，DMA 自动把数据放进描述符指向的缓冲区，并把描述符的所有权标志位清掉，软件看到这个标志就能安全读取数据。发送方向则相反，软件把待发数据放在缓冲区里，将所有权交给 DMA，由 DMA 在发送完成后写回状态。

在 LwIP 的移植模板中，ethernetif.c负责把 LwIP 的pbuf结构挂到这些描述符上。收包时，ethernetif_input从接收描述符拿到数据，转成一个或多个pbuf，再交给协议栈；发送时，协议栈把待发数据打包在pbuf链里，驱动层通过遍历描述符把数据交给 DMA。理解这条循环对之后调“能发不能收”的 bug 至关重要，因为多数问题都出在描述符的所有权没有及时交还。

我调试时习惯把 TX 描述符个数配成 4 个，RX 描述符个数配成 4 或 8 个。描述符在内存里需要 4 字节对齐，如果对齐不满足，DMA 会报总线错误，这类问题在编译阶段完全看不到，只能靠调试器读 ETH DMA 状态寄存器定位。固件库例程里ETH_Init会替你分配描述符数组，但换到自己的 RAM 布局后，数组放在哪个段、是否对齐，都要重新确认。

2.3 固件库例程目录：先认准这三个文件

解压后的目录通常不会太复杂，常见组织方式如下：

. ├── Libraries │ ├── CMSIS │ └── STM32F4xx_StdPeriph_Driver ├── Project │ ├── ewarm │ └── mdk-arm ├── User │ ├── main.c │ ├── ethernetif.c │ ├── lwipopts.h │ └── stm32f4xx_it.c └── LwIP └── src

这份目录清单可以帮你快速定位移植重点。Libraries下的stm32f4xx_eth.c是芯片外设驱动，正常情况下不需要大改；User下的ethernetif.c是 MAC 与 LwIP 之间的适配层，这是你换板子时最常动的地方；lwipopts.h则控制协议栈的内存池长度、超时时间、是否使用操作系统等全局策略。三者分工清楚，可以用一张表记住：

我在实际工程里会把ethernetif.c当成第一个审查对象，因为很多“网口不通”其实不是协议栈问题，而是描述符分配或 pbuf 释放时机不对。另外要留意，资源里自带的 LwIP 源码版本和ethernetif.c是配套的，如果工程文件夹里同时塞了两套 LwIP，链接器会直接报重复定义，这也是很多人解压后立刻编译翻车的常见原因。

3. 移植到自己的板子：PHY 复位、LwIP 参数与裸机轮询顺序

配套例程跑在官方评估板上，与你手上板子的晶振、PHY、引脚不可能完全一致。移植的本质是把例程中三段关键路径重写一遍：硬件引脚与 PHY 管理、协议栈内存参数、协议栈初始化与数据轮询。

3.1 先让 RMII PHY 稳定：时钟、复位和地址识别

以太网 PHY 是模拟混合芯片，上电后需要一段时间稳定，否则内部寄存器的默认状态无法可靠建立。许多固件库例程只在 GPIO 配置里顺带拉高复位引脚，没有严格做低电平保持和延时，板子一上电就卡在等待 PHY 寄存器应答。

常见做法是单独留一个复位脚，用普通 GPIO 控制：

void PHY_Reset_Init(void) { GPIO_InitTypeDef GPIO_InitStructure; RCC_AHB1PeriphClockCmd(RCC_AHB1Periph_GPIOG, ENABLE); GPIO_InitStructure.GPIO_Pin = GPIO_Pin_11; GPIO_InitStructure.GPIO_Mode = GPIO_Mode_OUT; GPIO_InitStructure.GPIO_OType = GPIO_OType_PP; GPIO_InitStructure.GPIO_Speed = GPIO_Speed_2MHz; GPIO_InitStructure.GPIO_PuPd = GPIO_PuPd_NOPULL; GPIO_Init(GPIOG, &GPIO_InitStructure); GPIO_ResetBits(GPIOG, GPIO_Pin_11); delay_ms(20); // 低电平至少保持 10~20ms GPIO_SetBits(GPIOG, GPIO_Pin_11); }

这段代码的逻辑是先把复位引脚配成推挽输出，再拉低持续 20ms，最后释放复位。之所以不直接在系统初始化时钟之前操作，是因为 GPIO 外设本身也需要时钟先就绪，否则寄存器写不进去。参数上，复位低电平时间我一般取 20ms，比手册要求的 10ms 留出一倍余量；引脚编号必须换成原理图上的实际连接，delay_ms也要换成你自己工程里的延时函数，不能用未实现的函数占位。

时钟方面，RMII 模式要求 PHY 芯片收到 50MHz 的参考时钟。有的板子用外部有源晶振直接供给 PHY，有的则把主控 MCO1 复用输出作为时钟源。后一种写法常见于评估板，但换板后如果 PHY 使用独立晶体，那么主控的时钟输出配置就要删掉。检查方法很简单：量 PHY 的时钟引脚，看有没有相对稳定的 50MHz 方波。

PHY 地址确认也在这个阶段做。例程里通常定义ETH_PHY_ADDRESS，但地址不代表所有板子都相同。第一次上电时先读 PHY 的 ID 寄存器：

uint32_t id1 = ETH_ReadPHYRegister(ETH_PHY_ADDRESS, 0x02); uint32_t id2 = ETH_ReadPHYRegister(ETH_PHY_ADDRESS, 0x03);

读到的两个寄存器值应该能拼出 PHY 型号标识。如果读回来全是 0xFFFF 或 0x0000，先别怀疑通信问题，绝大部分情况是复位时序没走完，或者地址引脚搭配错误。把这两个寄存器读通了，后续的自动协商和链路状态判断才有意义。

3.2 lwipopts.h：裸机还是带 OS，先定义清楚

LwIP 协议栈的配置全部集中在lwipopts.h。里面最关键的一组开关是 NO_SYS、LWIP_SOCKET 和 LWIP_NETCONN。如果你的项目不用 RTOS，想让协议栈裸奔，通常会这样定义：

#define NO_SYS 1 #define LWIP_SOCKET 0 #define LWIP_NETCONN 0 #define MEM_SIZE (1600 * 10) // 内部堆大小，单位字节 #define MEMP_NUM_PBUF 10 // 同时管理的 pbuf 数量 #define PBUF_POOL_SIZE 20 // 池式 pbuf 数量 #define PBUF_POOL_BUFSIZE 1518 // 池式 pbuf 缓冲区大小 #define TCP_MSS 1460 #define TCP_WND (4 * TCP_MSS) // TCP 接收窗口 #define TCP_SND_BUF (4 * TCP_MSS) // TCP 发送缓冲

NO_SYS置 1 说明协议栈不需要依赖任何操作系统锁和线程；LWIP_SOCKET和LWIP_NETCONN关闭后，应用层只能用 raw API，也就是直接操作tcp_new()和回调函数，而不是用 socket 风格接口。裸机项目里这样定义最省内存，也最直观。如果你的项目已经跑在一个 RTOS 上，那NO_SYS反而要设成 0，并打开LWIP_SOCKET，让协议栈运行在独立线程中，方便用信号量阻塞和唤醒。

内存参数方面，TCP_MSS在以太网默认 MTU 1500 的前提下，减去 IP 头和 TCP 头，通常是 1460。窗口TCP_WND如果小于 4 个 MSS，高速传输时吞吐会被反复的 ACK 等待拖垮；如果开得太大，内存池数量也要跟着加。PBUF_POOL_BUFSIZE必须不小于一个完整以太网帧，一般给 1518，包含 14 字节以太网头、20 字节 IP 头、20 字节 TCP 头和可能的校验字段。实际项目里可以根据 MTU 调整，但要保证至少能容纳最大帧。

3.3 netif_add 与裸机初始化顺序：主循环里少做多余事

配置完宏，接下来就是例程里最常见的初始化段落。我的裸机工程会按以下顺序写：

struct netif g_netif; ip4_addr_t ipaddr, netmask, gw; IP4_ADDR(&ipaddr, 192, 168, 1, 10); IP4_ADDR(&netmask, 255, 255, 255, 0); IP4_ADDR(&gw, 192, 168, 1, 1); netif_add(&g_netif, &ipaddr, &netmask, &gw, NULL, ethernetif_init, ethernetif_input); netif_set_default(&g_netif); netif_set_up(&g_netif); while (1) { ethernetif_input(&g_netif); sys_check_timeouts(); }

这段代码先把 IP 地址、子网掩码和网关绑定到全局 netif 结构体，再调用netif_add把网络接口注册进 LwIP 协议栈。这里的初始化函数ethernetif_init会完成 MAC 和 DMA 描述符的配置，ethernetif_input则作为主循环的数据入口函数指针。之后设置默认接口并启动接口，主循环里只需要做两件事：把从网口收到的帧喂给协议栈，以及检查 LwIP 内部定时事件。

ethernetif_input不建议在中断服务函数里直接调用，原因在于裸机模式下协议栈回调可能涉及内存池操作，如果在高优先级中断里运行，很容易破坏没有加锁的内存管理。如果你确实需要中断驱动收包，可以在 ISR 里置一个标志位，主循环检测到标志再调用ethernetif_input，这样既保留了中断的及时性，也避开了重入风险。

3.4 用一个 TCP echo 回调验证通路

初始化完成后，写一个最简单的 TCP echo 功能，比直接上 HTTP 服务器更容易排查。在 raw API 里，新建一个 TCP PCB 并绑定监听端口，收到数据后原样回写：

static err_t echo_recv(void *arg, struct tcp_pcb *pcb, struct pbuf *p, err_t err) { LWIP_UNUSED_ARG(arg); if (p != NULL) { tcp_write(pcb, p->payload, p->len, 1); tcp_recved(pcb, p->len); pbuf_free(p); } else { tcp_close(pcb); } return ERR_OK; }

这段代码的回调逻辑是：对端发来一包数据时，p非空，调用tcp_write把同样的内容放进发送缓冲，同时用tcp_recved告诉协议栈这包已经被应用层消费，最后释放 pbuf。如果p为空，说明对端关闭连接，这里直接关闭 PCB 做清理。用这种最小回显程序做验证时，用 PC 端网络调试工具连上端口发字符串，能看到原样返回，说明从 PHY、MAC、DMA 到协议栈的链路已经完整跑通。

4. 以太网调试避坑：ping 不通、闪断和“玄学”卡死的真实来源

协议栈能跑通之前，你会经历几轮看起来不可解释的失败。以下每条都是我在实际项目中反复踩过的坑，按“现象、原因、解决”的顺序记录，希望能帮你少走一段弯路。

4.1 ping 不通：先读 PHY ID，再怀疑复位时序

现象：固件烧进去后网口灯不亮，PC 上 ping 目标 IP 超时，进 debugger 看到初始化函数卡死在状态寄存器等待循环里。很多人的第一反应是代码里某个宏没配对，但实际上连 PHY 都没有给出有效应答。

原因：PHY 地址配置错，或者复位引脚没有按上电时序走。固件库例程默认的 PHY 地址是 0x00，但常见板卡上地址引脚组合出来是 0x01。复位低电平时间不足时，PHY 会一直保持复位状态，总线读操作自然无响应。

解决：把复位低电平时间从 10ms 拉长到 20ms，释放后再延时 30ms 等待内部上电初始化。接着用 ETH 驱动函数读 0x02 和 0x03 寄存器，核对读回的值是否对应你板上的 PHY 型号。如果读回 0xFFFF，检查复位引脚有没有被复用成其他功能；如果读到全 0，检查 PHY 地址引脚对应的上下拉是否被 GPIO 初始化影响了。

4.2 能发不能收：RX 描述符所有权没有交还给 DMA

现象：ARP 请求能发出去，PC 上也看到板子网卡有发送计数，但板子收不到任何应答。UDP 发送正常，接收方向却迟迟没有数据，状态寄存器里接收错误计数持续增长。

原因：接收描述符环初始化后，所有描述符的所有权都应该交还给 DMA。但有的移植模板在初始化完成后漏了最后一步，或者ethernetif_input处理完一帧后没有正确设置描述符状态，导致 DMA 认为没有可用缓冲区，一有新帧进入就被丢弃。

解决：逐行检查ethernetif_init中描述符链表的建立函数，确认每个描述符的DESC_OWN位都设为 1，且最后一个描述符链回第一个形成环。在ethernetif_input的收包路径里，处理完一帧数据后重新初始化该描述符的控制状态，并再次置位所有权。判断这个问题的标志是：接收方向错误计数递增，而发送方向计数正常。

4.3 传大文件卡死：内存池被调小，TCP 窗口分片丢包

现象：TCP echo 小数据包完全正常，ping 也不丢包，但通过上位机连续传输几十 KB 文件时，进度条停滞，随后连接被重置。停掉传输重新连接，系统又能继续，但每次都在相近的位置卡住。

原因：这是典型的内存池饥饿。LwIP 收包需要从 PBUF_POOL 申请 pbuf，发送路径还需要额外的内存做分段和重传缓存。如果PBUF_POOL_SIZE或MEM_SIZE设置得过小，多个 TCP segment 同时占用缓冲时，后续 pbuf 申请失败，协议栈只能丢弃数据。表现就是数据量一大就停滞。

解决：不要只改一个宏。我一般以 TCP 接收窗口TCP_WND为基准，把接收缓冲至少做成窗口大小的两倍；发送方向TCP_SND_BUF也要与窗口匹配。一个比较稳妥的起点是PBUF_POOL_SIZE=40，PBUF_POOL_BUFSIZE=1518，MEM_SIZE=16000，具体值再根据 RAM 余量微调。如果 Flash 里存了大量常量，先看一眼链接脚本的 RAM 占用再动手。

4.4 换 LwIP 版本后编译不过：先看接口签名，再谈优化

现象：把旧工程的ethernetif.c整个搬到一个更新版本的 LwIP 源码中，编译后报出一堆类型不匹配或者 undefined reference，有的错误指向pbuf_free或netif_add这类公共函数。

原因：LwIP 不同版本之间并不完全保持 API 兼容。例如 1.4.1 的netif_add参数与 2.1.x 的默认模板就有差异，回调函数接收指针的 const 修饰也可能变化。旧版驱动适配新的协议栈时，单纯复制文件必然引起签名冲突。

解决：不要执着于让旧文件适应新协议栈。从新版本配套的ethernetif.c模板出发，把你自己项目里的 PHY 地址、GPIO 和内存参数迁移过去，而不是反向迁移协议栈。修改过程中多看一眼更新日志里的接口变更说明，很多“灵异”报错都能在这里找到答案。

4.5 板子断电重启后连不上：PHY 状态没有被重新协商

现象：板子第一次上电能跑通，断电后再上电有时等很久才能链路上线，甚至彻底连不上。反复复位时间里偶发能通，大约每几次就失败一次，像是复位后设备和 PC 在链路协商上抢跑了。

原因：PC 的网卡和 PHY 在上电瞬间都有一个自协商过程，如果板卡在网口链路建立前就调用netif_set_up并尝试发送 ARP，某些 PHY 会错过协商窗口，之后无法自行恢复。

解决：在上电初始化时先等待 PHY 的基础状态寄存器显示链路已同步，再调用netif_set_up。最简单的方法是循环读取 PHY 状态寄存器不超过 2 秒，若链路标志位未置位，打印警告但不强制阻塞；也可以在网口调零后让ethernetif_input只接收不发送，等链路恢复后再正常收发。

5. 验证工程是否稳定：ping 丢包、吞吐量和隔夜运行三关

写完代码不是结束，我会用一套固定流程验证网络功能是否真正可用。这套流程听起来简单，但能把大多数固件层面的隐患逼出来。

5.1 第一关：ping 丢包率

在 PC 上对板子做 1000 次连续 ping，每次带上接近最大长度的 ICMP 净载：

ping 192.168.1.10 -n 1000 -l 1472 -w 500

-l 1472是最大可用 ICMP payload，能验证 IP 分片和底层缓冲；-w 500表示每个包最多等 500ms。正常情况下丢包率为 0%，最大延迟波动应该小于 1ms。如果出现连续几个超时，优先怀疑 PHY 复位时序或电源纹波，而不是 TCP 窗口配置。

5.2 第二关：TCP 吞吐量

ping 只能证明链路通，不能证明数据通路够快。我一般会在 PC 上起一个带宽测试服务，让板子作为客户端持续发送 1MB 数据，观察速率是否稳定在百兆以太网的合理范围。如果吞吐量在几十 KB 到几 MB 之间剧烈跳动，多半是TCP_WND或PBUF_POOL_SIZE设置不匹配。这个阶段出现卡死，一定要先看 RAM 余量和 LwIP 内存池使用率。

5.3 第三关：隔夜稳定性

网口工程最怕的不是一上来不通，而是跑几个小时后才死。我会跑一个 TCP 回显或 UDP 心跳 8 小时，同时用抓包工具确认没有异常重传。如果长时间后内存可用率下降，检查热点代码里有没有遗漏pbuf_free，这种泄漏在初次调试时很难看出来，但一夜之后就现形。

从那以后，我每次拿到新型号的 F407 以太网板卡，都会强制走一遍这三步：先读 PHY ID，再跑 1000 次 ping，最后挂一晚上抓包。虽然不能保证所有网络问题都被提前拦住，但至少能让我对这块板子的网口心里有底。希望帮到你。

本文还有配套的精品资源，点击获取