搞过以太网方案的朋友都知道PHY芯片是整个链路里最容易被低估的一环。CPU和MAC层的驱动写得再漂亮只要PHY这边 link 不稳定、协商模式不对上层TCP/IP协议栈再干净也白搭。RTL8201F这颗10/100M PHY在国产和海外的中低端板卡里出镜率极高ST官方评估板上也经常拿它搭配STM32F407、F429来跑LWIP。但手头这芯片的资料分散手册里有些细节写得不够直白很多刚入坑的朋友会在 RMII 时钟配置、PHY 地址读取、LWIP 底层驱动这些地方反复卡壳。这篇文章我就完整记录一遍从 RTL8201F 芯片手册解读、硬件点检、MDIO 寄存器调试到 STM32CubeMX 里配置 ETH LWIP 并最终 ping 通的全过程。适合正在做板级调试、需要自己移植网络协议栈的嵌入式工程师也适合第一次接触 PHY 驱动、想搞明白底层逻辑的初学者。我会把寄存器地址、时序注意点、踩过的坑全部拆开讲你照着做基本能少走一半弯路。1. 内容整体设计与思路拆解拿到一个不熟悉的 PHY 芯片很多人第一反应是赶紧找现成驱动代码找到就往上糊。这个做法在原型验证阶段勉强可行一旦硬件链路有问题你根本分不清是驱动不对还是电路不对最后只能全线返工。我调试 RTL8201F 的思路是先读手册把芯片的接口模式、寄存器布局、时钟要求全部弄清楚然后直接从 MDIO 寄存器层面验证物理层通信是否正常最后再谈 LWIP 协议栈的移植。这样的顺序看着多花时间实际上是最快的路径。因为 LWIP 本身是纯软件协议栈它不关心底层 PHY 是谁家的它只依赖你提供的 ethernetif 接口函数。只要 PHY 工作正常MAC 和 DMA 配置正确LWIP 移植就是一个机械动作。反过来如果 PHY 的 link 状态、自适应结果都是错的你就算把 LWIP 换成 lwIP 2.2.0 最新版、把内存池调得再大网络也照样不通。RTL8201F 的选型逻辑也很典型。它支持 RMII 和 MII 两种 MAC 接口我这次用的是 RMII 模式因为只需要 50MHz 参考时钟引脚占用少STM32F407 这类 MCU 的 ETH 外设刚好配套。芯片内置 100BASE-TX 收发器支持 Auto-Negotiation内部有 1.6kV 隔离变压器驱动能力外围只需要接一个网络变压器和 RJ45 座子就能出网口。成本低、外围少、资料相对齐全这是它被大量用在工业控制板和物联网网关上的核心原因。还有一个让我比较意外的地方是很多教程直接把 PHY 地址写死为 0也不去读芯片的 PHYIDR 寄存器做校验。RTL8201F 的 PHY 地址由 RXER/PHYAD0 和 MDIO/PHYAD1 这两个引脚的电平决定板子上拉下拉接法不同地址就可能是 0、1、2 或者其他值。如果地址不对MDIO 读回来的数据全是 0xFFFF你还在那儿死磕 LWIP 内存配置完全搞错了方向。后面第三部分我会专门讲怎样用代码确认 PHY 地址。2. 芯片手册解读与硬件准备2.1 RTL8201F 手册里的关键信息在哪几页RTL8201F 的数据手册不算厚但信息密度很高。我建议拿到手册后优先看这几块内容其余的先跳过芯片功能框图看 RMII/MII 接口引脚分布确认电源域、晶振/时钟输入方式、LED 驱动引脚的位置。Pin Assignment 和 Pin Description这里决定了你的硬件原理图对不对重点看 RMII 模式下的 TXD[1:0]、RXD[1:0]、TX_EN、RXDV/CRS_DV、MDC、MDIO、REF_CLK 这 8 个信号。MDIO/MDC 接口时序手册里有时序图需要注意 MDC 的最大频率和数据采样沿一般 STM32 HAL 库默认配置问题不大但如果你自己用 GPIO 模拟 MDIO 就得严格看时序。寄存器描述Register Description核心寄存器包括 BMCR地址 0x00、BMSR0x01、PHYIDR1/PHYIDR20x02/0x03、ANAR0x04、ANLPAR0x05、PHYSTS0x10等。RTL8201F 的 PHYIDR1 和 PHYIDR2 组合起来是 0x001CC816这个值对应 OUI 000001 1100 1100 和厂商型号。读 PHY ID 是判断 MDIO 通信是否正常的最直接手段比读 link 状态更可靠因为 link 状态还要考虑网线、对端设备等外部因素。2.2 参考电路设计时的必查项RTL8201F 的参考电路在手册里很完整照抄基本能用但有三个细节我会反复核查第一是REF_CLK来源。RMII 模式下要求 MAC 和 PHY 共用一个 50MHz 参考时钟。RTL8201F 的 XI 引脚可以接 50MHz 晶振也可以由外部直接输入 50MHz 时钟。如果是 STM32F407 的 MCO2 引脚产生 50MHz 给 PHY那 STM32 这边的 PLL 配置必须准确否则 RMII 时序直接错乱表现为偶尔能 link 上、一传数据就断。第二是PHY地址配置引脚。前面提到 RXER/PHYAD0 和 MDIO/PHYAD1 决定地址设计原理图时会用上拉或下拉电阻固定电平。我在调试一块板子时就因为厂家把 PHYAD0 下拉、PHYAD1 上拉导致实际地址是 2而软件里写死为 0MDIO 怎么读都不对。所以点检电路时务必确认这两个引脚的默认状态。第三是变压器和终端电阻。RTL8201F 的差分收发引脚需要搭配 1:1 的网络变压器中心抽头接法要看是电压驱动型还是电流驱动型。参考电路上如果有 49.9Ω 电阻对地或者对电源的连接别乱删。之前有块板子为了省成本砍掉了接收端的共模电阻结果近距离通信正常拉长网线或者过交换机就丢包严重。2.3 焊接和上电后的基本测量拿到板子先别急着写代码。焊接完 RTL8201F 之后我习惯先用万用表和示波器做一轮快速验证把问题最集中的硬件故障排除掉。用万用表量电源对地阻抗排除虚焊、短路。RTL8201F 一般有 3.3V 和 1.05V内部 LDO 输出等电源轨如果是独立供电还要确认各路电压值。然后示波器看 50MHz 参考时钟是否起振、频率是否准确、幅度是否足够如果用的是 STM32 MCO2 输出还要看波形有没有过冲。再就是看复位时序。RTL8201F 的复位引脚在低电平保持期间芯片处于复位状态释放后需要一定的稳定时间才能访问 MDIO。MCU 上电后如果立刻去读 PHY容易读到 0xFFFF。我一般会在初始化代码里加一个 100ms 左右的延时确保 PHY 内部上电和复位流程完成再去读写寄存器。这个细节看起来无关紧要但实际调试中发现很多 link 不上的问题就出在初始化顺序上。3. MDIO 寄存器读写与 PHY 地址确认3.1 用 STM32 HAL 库操作 MDIO 接口STM32F407 的 ETH 外设自带 MDIO 接口HAL 库提供了 HAL_ETH_ReadPHYRegister 和 HAL_ETH_WritePHYRegister 两个函数。不过要注意HAL 库早期版本里的 ReadPHYRegister 函数在读取失败时不会返回错误码可能让你误以为读到了有效数据。所以我强烈建议在调试阶段把读到的寄存器原始值直接从串口打印出来亲眼确认读数合理再继续。基础工程建议直接用 STM32CubeMX 生成选择对应的 MCU 型号使能 ETH 外设并设置为 RMII 模式然后生成一个带串口的空工程。CubeMX 生成的 ETH 初始化代码里 PHY 地址默认是 0如果你不确定板子的 PHY 地址可以先把这个值改成 0 到 31 循环扫描逐个地址读 PHYIDR1/PHYIDR2看看哪个地址能读出 RTL8201F 的特征 ID 0x001CC816。3.2 循环扫描 PHY 地址的小工具这里分享一个调试期的实用函数。把下面这个扫描逻辑加到工程里上电后通过串口把扫描结果发出来就能知道芯片的物理地址。void PHY_ScanAddress(void) { uint16_t idr1 0, idr2 0; uint8_t addr 0; for (addr 0; addr 32; addr) { HAL_ETH_ReadPHYRegister(heth, addr, PHY_REG_IDR1, idr1); HAL_ETH_ReadPHYRegister(heth, addr, PHY_REG_IDR2, idr2); if ((idr1 0x001C) ((idr2 0xFFF0) 0xC810)) { printf([PHY] Found RTL8201F at addr %d, IDR10x%04X, IDR20x%04X\r\n, addr, idr1, idr2); } else { printf([PHY] Addr %d: IDR10x%04X, IDR20x%04X\r\n, addr, idr1, idr2); } } }这个函数在空工程里就能跑不需要 LWIP。只要串口能看到正确的 IDMDIO 物理通信就是通的后面所有问题都限定在 MAC 配置或者软件协议栈层面。如果扫描一圈全是 0xFFFF先排查 MDC/MDIO 引脚复用配置、PHY 供电和复位再去怀疑芯片本身。3.3 理解 BSR 和 PHYSTS 寄存器的状态位读到了 PHY ID 还不够要通过状态寄存器确认 link 是否建立。BMCR地址 0x00的 bit12 是 Auto-Negotiation 使能位bit13 是速度选择1 为 100M0 为 10Mbit8 是全双工模式位。BMSR地址 0x01的 bit5 是 Auto-Negotiation 完成标志bit2 是 link 状态注意 BMSR 的 link 状态位是锁存的读完之后会自动清零重新反映当前状态所以连续读两次比较稳妥。RTL8201F 私有寄存器 PHYSTS地址 0x10里也有 link 状态和速度/双工指示并且比 BMSR 更直观。做调试的时候我一般把这三个寄存器的值每隔一两秒打印一次然后插拔网线观察变化。插上网线后AN 完成位置 1link 状态位置 1速度和双工位显示为 100M Full。如果没有这些变化问题就在物理链路先换网线、换对端设备、查变压器焊接而不是去动 LWIP。3.4 用 GPIO 模拟 MDIO 的场景不是所有板子都方便用 STM32 的 ETH 外设。有些低成本的 MCU 没有 MAC只想把 RTL8201F 当一个裸 PHY 用那就得自己用 GPIO 模拟 MDIO。MDIO 时序其实不复杂MDC 提供时钟MDIO 是双向数据线。读操作时MCU 先发送 32 个 1 作为前导码然后是起始码 01、操作码 10、5 位 PHY 地址、5 位寄存器地址接着是 2 个时钟周期的 turnaround 时间释放总线让 PHY 驱动数据线最后在 16 个时钟周期内读出寄存器值。GPIO 模拟时要注意 MDC 频率不能太高一般 2.5MHz 以下都没问题我习惯控制在 1MHz 左右留够电平翻转和数据采样裕量。另外 MDIO 在输出和输入切换时要小心别让总线冲突通常用开漏输出加外部上拉读的时候直接把 GPIO 切到输入模式。这个方案虽然代码多一些但对理解 MDIO 时序非常有帮助。我建议新手至少在调试阶段手动实现一次 GPIO 模拟的 MDIO 读写比直接用 HAL 库函数更能理解 PHY 通信的本质。4. LWIP 底层驱动移植与 ethernetif 分析4.1 移植前先搞清楚层次关系LWIP 移植不复杂但容易让人糊涂因为层数多。我的理解是分三层最底层是 STM32 HAL 库的 ETH 驱动负责配置 MAC、DMA 描述符、收发数据包。中间层是针对 LWIP 的网卡适配层也就是常见的 ethernetif.c 文件实现 low_level_init、low_level_output、low_level_input 这几个函数把 STM32 ETH 的 DMA 收发和 LWIP 的 pbuf 对接起来。最上层是 LWIP 协议栈本身包括 TCP/IP 协议处理、内存管理、netif 注册等。RTL8201F 的驱动在这个架构里只扮演配置和状态读取的角色LWIP 本身不关心 PHY 芯片具体型号。所以移植核心工作其实是把 PHY 初始化包括地址配置、自动协商开启和 link 状态检测函数写好再把 ethernetif.c 里的 PHY 相关常量替换成 RTL8201F 对应的值。4.2 STM32CubeMX 配置 ETH 与 LWIP 的步骤我用 STM32F407VET6 这块板子做例子RTL8201F 通过 RMII 接口连接。CubeMX 里的配置步骤是这样的第一步使能 ETH选择 RMII 模式。RMII 模式下会自动分配 TXD[1:0]、RXD[1:0]、TX_EN、CRS_DV、MDC、MDIO 这些引脚。REF_CLK 这个 50MHz 时钟要单独配置如果用 MCO2 引脚输出需要在 RCC 配置里把 MCO2 使能并设置频率为 50MHz。第二步配置 LWIP。CubeMX 的 Middleware 里选 LWIP协议版本建议用 2.1.2因为 2.0.3 的老版本在内存管理上有一些已知问题而最新 2.2.x 改动比较大部分教程代码不一定完全匹配。开启 DHCP 客户端还是静态 IP看你的测试环境。开发调试阶段我习惯先用静态 IP比如 192.168.1.10掩码 255.255.255.0网关 192.168.1.1省去 DHCP 等待时间。第三步配置串口用于日志打印。调试阶段日志非常重要比如 PHY 初始化结果、link 状态变化、收到的数据包计数这些都能帮助你快速定位问题。CubeMX 生成代码后ETH 和 LWIP 的基本框架就有了但 PHY 地址和 PHY 初始化函数需要手动修改。HAL 库生成的 eth.c 里会有一个 ETH_MACDMAConfig 函数其中 heth.Init.PhyAddress 默认是 0要改成你扫描出来的实际地址。4.3 low_level_init 里的关键操作low_level_init 是网卡初始化的核心。它在 LWIP 启动时被调用主要做这几件事设置 MAC 地址从 EEPROM 或者固定数组读取。初始化 DMA 描述符包括 TxDescriptor 和 RxDescriptor。为 DMA 接收描述符分配 pbuf并把 pbuf 的地址写入描述符的数据缓冲区指针。使能 ETH 外设的接收和发送功能。有一个很容易踩的坑是 DMA 描述符内存对齐。STM32 的 ETH DMA 要求描述符和缓冲区都要按 4 字节对齐如果 pbuf 分配的内存地址不对齐DMA 传输会直接报错。LWIP 的内存池默认对齐通常没问题但如果你用了自定义内存分配函数或者外部 SRAM就必须检查对齐属性。我调试时遇到过 ping 包偶尔通偶尔不通的情况最后定位到就是内存对齐问题导致的 DMA 传输异常。4.4 low_level_output 的发送流程low_level_output 负责把 LWIP 要发送的数据通过 DMA 发送出去。它的流程是遍历待发送的 pbuf 链表把每个 pbuf 中的数据拷贝到预分配的 DMA 发送缓冲区中。设置 TxDescriptor 的控制字包括数据长度、起始和结束标志。将 TxDescriptor 的 ownership 标志位交给 DMA启动发送。等待 DMA 发送完成释放描述符。实际调试中如果 ping 不通可以在 low_level_output 里加一个计数变量通过串口周期性打印发送计数。如果发送计数在增加说明协议栈产生了数据包但物理层可能没发出去如果发送计数为 0说明上层网络配置有问题比如 IP 地址没设置好、ARP 没解析成功。这个简单的计数方法能帮你快速缩小排查范围。4.5 low_level_input 的接收流程接收方向比发送稍微复杂一些。ETH 外设通过 DMA 自动把收到的数据写入预先分配好的 RxDescriptor 缓冲区中然后触发接收中断。low_level_input 要做的是检查 RxDescriptor 的 ownership确认 DMA 已经写入数据。把数据封装成一个 pbuf 链表交给 LWIP 协议栈处理。重新分配一个新的 pbuf 给这个描述符准备接收下一包数据。这里有一个性能相关的细节。如果收到的数据帧长度超过一个 pbuf 的大小LWIP 会把数据串成链表。low_level_input 里需要用 pbuf_alloc 分配类型为 PBUF_POOL 的 pbuf因为这种 pbuf 可以从内存池快速分配适合中断上下文。如果分配失败直接丢弃这一帧否则后续 DMA 无法重新接管描述符时间长了接收会卡死。4.6 修改 netconf.c 里的 PHY 相关宏CubeMX 生成的代码中ethernetif.c 或 netconf.c 里往往有一些 PHY 相关的宏定义。比如 PHY 地址、link 状态检测的超时时间、Auto-Negotiation 完成后的读取函数等。把这些地方改成适配 RTL8201F 的值#define PHY_ADDRESS 2 // 根据实际扫描结果修改 #define PHY_READ_TOUT 1000 #define PHY_WRITE_TOUT 1000Link 检测函数里我习惯先读 BMSR 寄存器两次第二次得到的 bit2 才是当前真实 link 状态。有些 PHY 芯片的 BMSR 会在读操作后清除已经锁存的变化位连续读可以清除上一次的状态残留。RTL8201F 上这个现象不太明显但有其他 PHY 踩过坑养成连续读两次的习惯比较好。5. 常见问题与排查技巧实录5.1 MDIO 读取不到 PHY ID这个是出现频率最高的问题。扫描 PHY 地址时所有地址都返回 0xFFFF或者只有某个地址返回全 FF。排查顺序我一般是这样先用万用表确认 PHY 的电源电压正常尤其是 AVDD、DVDD 这些引脚。然后示波器看 MDC 引脚有没有时钟信号MDIO 引脚有没有数据活动。如果 MDC 没波形先查 STM32 的 ETH 引脚复用配置是否正确如果 MDC 有波形但 MDIO 一直为高说明 PHY 没有驱动数据线大概率是 PHY 在复位状态下或者 PHYAD 引脚配置不正确。RTL8201F 的复位引脚不要太早释放。如果 MCU 和 PHY 共用同一个复位信号而 MCU 启动时间很快可能在 PHY 内部 LDO 还没有稳定时就开始操作 MDIO。遇到这种情况把 PHY 的硬复位引脚用一个单独的 GPIO 控制在初始化 ETH 之前先拉低复位、保持 20ms 以上再拉高然后再延时 100ms。5.2 PHY Link 状态一直为 DownMDIO 能正确读到 ID但就是 link 不上。先看板子 RJ45 座子的指示灯有没有亮RTL8201F 有专门的 LED 驱动引脚如果 PHY 认为 link 建立了LED 会亮。如果 LED 亮但软件读状态一直 down问题在寄存器读取逻辑如果 LED 不亮物理层就没通。物理层不通时我优先换一根短网线直连电脑排除交换机和长网线的影响。然后检查网络变压器中心抽头接法RTL8201F 参考电路里一般要求通过 1kΩ 电阻接到电源或者是直接接电容到地不同设计差别很大。再就是量一下变压器次级到 RJ45 之间的共模电感是否焊反。这些电路细节在高速信号下容错率很低一处虚焊就能让 link 不稳定。5.3 Ping 不通但 PHY 已经 Link UpPHY 状态显示 link 已经建立但 ping 不通这是另一个高频问题。这种情况说明物理层和自动协商都没问题问题在 MAC 层、LWIP 配置或者中断处理。先用串口看 LWIP 有没有打印出 netif 初始化成功的信息确认 IP 地址和掩码正确。然后在 PC 端用 ipconfig 查看本机 IP确保和板卡同一网段。再在板端加打印看有没有收到 ARP 请求。如果收到了 ARP 请求但没回包问题在发送路径如果根本没收到问题在接收路径或者 DMA 中断没有触发。还有一个比较容易忽略的点是中断优先级。ETH 的接收中断优先级要设置合理不能太低否则在高负载下可能丢包。但优先级太高又会和系统其他关键中断竞争。我一般把 ETH 中断优先级设置在比系统节拍中断低一到两个等级具体数值要看你的 RTOS 和中断分配情况。5.4 网络不稳定传大文件必断这种问题隐蔽性最强往往是低速小包测试一切正常一跑大文件传输就断。排查方向有两个一个是 DMA 描述符数量不够默认配置可能只有 4 个发送和 4 个接收描述符大流量下容易耗尽另一个是内存池大小不合适PBUF_POOL 节点数量不足会导致接收时分配 pbuf 失败协议栈直接丢包。CubeMX 里 LWIP 的 MEMP_NUM_PBUF、PBUF_POOL_SIZE 这些参数可以调大。我实测过 TCP 下载大文件时把 PBUF_POOL_SIZE 从默认的 8 改到 24稳定性明显提升。代价是 RAM 占用增加所以要根据芯片的 RAM 容量量力而行别一上来就拉满。另外检查一下 ETH DMA 描述符是否使用了 cache 一致性问题。如果你的 MCU 有 D-Cache比如 STM32H7 系列必须先配置 MPU 区域把 DMA 描述符和缓冲区设为非 cacheable或者使用 cache clean/invalidate 操作。在带 cache 的 MCU 上跑 LWIP如果不处理缓存一致性会出现极其诡异的数据错乱而且不是必现排查起来非常折磨。虽然 STM32F407 没有 D-Cache 这个问题不突出但换到更高端的系列一定要注意。5.5 调试工具推荐与使用心得调试 PHY 和 LWIP 链路时我常用的工具和技巧如下串口调试助手是最基础的。确认串口参数把波特率锁定在 115200 或者 921600日志输出尽量精简别在中断里直接 printf否则会拖慢系统导致丢包。我习惯用一个环形缓冲区承接中断里的日志主循环里再批量输出。网络调试助手比如 NetAssist 或者 SocketTool用来测试 UDP 和 TCP 通信非常方便。先测试 UDP 回环功能板卡收到 UDP 数据后原样发回上位机收到就说明协议栈路径是通的。TCP 测试用电脑端自己写个简单的 socket 工具或者用 Python 脚本都行。Wireshark 是排查网络问题的大杀器。把 PC 网卡和板卡直连在 PC 上开 Wireshark 抓包。看板卡有没有发 ARP 请求、有没有回 ARP 响应、ICMP echo request 是否到达板卡、板卡有没有回 echo reply。通过这些包的流向能精确判断问题在哪个环节。我之前遇到过一个奇怪现象板卡能收到 ping 包但回包发不出去就是靠 Wireshark 抓包发现 PC 收到了 ARP 请求但板卡发出的 ARP 响应没到最终定位到是 MAC 地址配置被覆盖了。5.6 常见问题速查表整理一下调试过程中最高频遇到的问题和对应的解决动作现象可能原因排查动作MDIO 全 FFPHY 供电/复位异常量电压、查复位时序MDIO 全 FFPHY 地址不对循环扫描 0-31 地址Link Down网线/对端设备问题换短网线直连电脑Link Down变压器电路异常检查中心抽头、共模电阻Ping 不通IP 配置不一致检查 PC 和板卡 IP 是否同网段Ping 不通中断未触发或优先级过低检查 ETH 中断配置大流量丢包DMA 描述符不足调大 TX/RX 描述符数量大流量丢包内存池过小调大 PBUF_POOL_SIZE数据错乱Cache 一致性问题配置 MPU 或做 clean/invalidate这些坑我在不同项目里基本都踩过一遍很多时候不是单个问题而是两三个问题叠加在一起。所以调试时一定不要着急下结论每改动一个变量就重新测试一轮这轮测试通过后再动下一个不要同时改多项配置否则出了问题根本不知道是哪一步引起的。6. 从 PHY 调试到 LWIP 移植的经验复盘整个流程走下来我最想强调的一点是调试 RTL8201F 和移植 LWIP底层逻辑其实是分离的。PHY 调试考验的是你对硬件手册的理解和 MDIO 通信的熟练度LWIP 移植考验的是你对协议栈分层、内存管理、中断处理的把握。两者用 ethernetif.c 这个适配层衔接起来只要一层一层验证每个环节都确认没问题再进入下一层排查效率会高很多。在我实际调试的过程中最花时间的往往不是代码本身而是那些“看起来都正常但就是不通”的隐性故障。比如 PHY 地址引脚被复用成了其他功能比如复位时序被板载看门狗影响比如 50MHz 时钟抖动超标导致 RMII 数据采样出错。这些故障在原理图上是看不出来的必须靠示波器实测和寄存器打印一点一点排除。最后分享一个个人习惯每次拿到新板子我都会先写一个独立的 PHY 寄存器调试工具不跑任何协议栈单纯通过串口命令来读写 PHY 寄存器。这个工具不仅开发阶段有用量产后的产测程序里也可以保留用来快速验证每块板子的网络硬件是否正常。你只需要实现串口解析和 MDIO 读写就能通过串口发送命令来读任意 PHY 寄存器的值非常方便。比如串口发送reg 2 0就读取 PHY 地址 2 的寄存器 0。响应返回寄存器值就能在产线上判断 PHY 是否正常工作。这个工具我用了很多年从 RTL8201F 到其他 PHY 芯片都适用强烈建议你也准备一个。调试之路说难也难说简单也简单。只要你愿意先花时间把芯片手册啃透把 MDIO 底层通信调通再往上移植 LWIP 就是按部就班的事。希望这篇经验记录能帮你在 RTL8201F 和 LWIP 上少走一些弯路顺利把网口调通。