先说结论：能用，而且这个组合在工控、嵌入式网关这类场景里已经算经典搭配了。我去年做一块千兆以太网数据采集板，用的就是STM32H750 + Realtek RTL8211F-CG，配LwIP协议栈，大包单向吞吐稳定跑在500Mbps以上，调好之后非常稳。整个过程不像LAN8720那样在CubeMX里点两下就完事，RTL8211F-CG需要自己处理的点不少：RGMII时序、PHY地址、复位时序、扩展寄存器配置、H7的Cache一致性……一个没注意就会卡在“读不到PHY ID”或者“Link起来了但Ping不通”。这篇文章就把我从选型到跑通的完整过程拆开讲，给准备拿H7做千兆以太网的朋友一个参考。
1. 先搞清楚：为什么这个组合成立
1.1 STM32H7的以太网MAC到底支持什么
很多人看到“STM32H7”就直接默认它有千兆以太网，这个前提其实不严谨。H7是个大系列，内部自带Ethernet MAC的型号不少，但配置有区别。以我常用的H743、H750、H753为例，这三颗带的是支持10/100/1000M的MAC，外设接口支持MII、RMII、RGMII三种模式。而H723、H733这些相对新的型号，内置MAC只支持10/100M，物理层接口是MII/RMII，没有千兆。
所以如果你要上RTL8211F-CG这种千兆PHY，第一件事是确认你选的H7子型号带不带1G MAC。如果型号是H723，那就别折腾RTL8211F了，老老实实用百兆PHY（比如LAN8720）更合理。
另外要注意，H7的千兆MAC对外接PHY的接口只支持RGMII。RGMII是4位数据线、双沿采样的并行接口，时钟频率在千兆模式下是125MHz。RTL8211F-CG正好就是RGMII接口的千兆PHY，所以从接口协议上看，这两个芯片是匹配的。
1.2 RTL8211F-CG这个PHY的定位
RTL8211F-CG是Realtek的千兆Ethernet PHY，支持10/100/1000M三种速率自协商，RGMII接口，QFN48封装。它的定位和LAN8720完全不在一个层级，我做了个表对比：
| 对比项 | RTL8211F-CG | LAN8720A |
|---|---|---|
| 支持速率 | 10/100/1000M | 10/100M |
| MAC接口 | RGMII | RMII |
| 基准时钟 | 25MHz晶振 | 50MHz晶振 |
| 信号线数量 | 12根数据/控制线 | 7根数据/控制线 |
| 内部RGMII Delay | 支持（扩展寄存器配置） | 不支持（RMII无此概念） |
| 典型成本 | 中高 | 低 |
如果目标只是百兆通信，比如跑个Modbus TCP、采集低速传感器数据，那LAN8720完全够用，线少、驱动成熟、CubeMX还内置支持，没必要上RTL8211F。但如果目标是千兆吞吐，比如图像传输、高速数据采集、工业实时同步，那RTL8211F-CG就是H7最合适的搭档之一。
1.3 什么场景才需要这套组合
我总结下来，适合STM32H7 + RTL8211F-CG的场景主要有三类：
一是有持续大带宽需求的，比如多路ADC同步采集后通过以太网实时上传，或者摄像头图像数据不压缩直接推流。二是有实时性要求的工业控制，比如多轴运动控制器和上位机之间需要高频率交换状态指令，网口速度不够会造成控制周期抖动。三是想做复杂协议栈的，比如同时跑TCP/UDP、WebServer、TFTP固件升级，千兆端口能给后续扩展留足余量。
反过来说，如果你的项目只需要偶尔传点配置数据，百兆甚至串口都够，那真没必要上这套组合。千兆PHY带来的成本、PCB布局复杂度、调试工作量都是实打实的。
2. 硬件设计：RGMII不是随便连上就能跑的
2.1 引脚信号清单和MCU引脚分配
RGMII接口比RMII多了一半信号线，一共12根：
- 发送方向：TXD[3:0]、TX_CTL、TX_CLK（MAC输出给PHY）
- 接收方向：RXD[3:0]、RX_CTL、RX_CLK（PHY输出给MAC）
- 管理接口：MDC、MDIO（MDIO是双向的，需要上拉电阻）
再加上PHY的复位引脚，整个以太网部分大概要占用15个GPIO。STM32H7的以太网引脚不是任意映射的，每个信号都对应固定的GPIO。最省事的方法是直接在CubeMX里把ETH外设打开，选RGMII模式，让工具自动分配引脚。然后手动检查一遍有没有和串口、SDIO、ADC之类的功能冲突。
我画板时用的是H750VBT6，CubeMX分配后主要用了PG和PD两个端口的一部分引脚。注意不同封装（LQFP100、LQFP144、BGA176）能映射的引脚不同，越小的封装越容易冲突，选型时就要提前看。
2.2 时钟架构：这个环节最容易翻车
RGMII对时钟要求比RMII严得多。千兆模式下RX_CLK和TX_CLK都是125MHz，百兆是25MHz，十兆是2.5MHz。整个时钟拓扑我建议这样做：
PHY侧放一颗25MHz无源晶振，RTL8211F内部PLL把25MHz倍频到125MHz，然后通过RX_CLK引脚输出给STM32H7。H7这一侧，RGMII模式下的TX_CLK可以由MAC内部PLL生成，CubeMX的时钟树里能看到ETH的时钟源，一般用PLL3Q之类的片上PLL分配。
这里有个很关键的点：RGMII信号是DDR双沿采样，TXD/RXD数据和时钟之间必须有明确的相位关系。RTL8211F内部支持配置TX Delay和RX Delay，目的就是补偿PCB走线和芯片内部的建立保持时间。最稳的做法是启用PHY内部的delay功能，PCB走线上不再额外加蛇形等长delay线。如果PCB上已经做了delay线，那就要把PHY内部的delay关掉，二选一，不能两边都做，否则时序反而更差。
我当时第一次画板就是没搞清楚这个，PCB上加了delay线，PHY内部delay也开着，结果千兆模式下CRC错误狂跳。后来把PHY扩展寄存器的delay关掉，问题立刻消失。
2.3 电源、复位和PHY地址
RTL8211F-CG的电源设计有几个细节。VDDIO的电平必须和MCU的IO电平匹配。H7大部分板子的IO bank是3.3V供电，那PHY的VDDIO就接3.3V。如果你的H7设计里以太网引脚所在的bank用了1.8V供电，那VDDIO可以接1.8V，但一定要确认电平兼容，别直接接3.3V去怼1.8V的MCU引脚。
复位时序值得单独说。RTL8211F的复位引脚要求上电稳定后保持低电平一段时间，然后拉高释放。我的做法是用MCU的GPIO控制PHY复位，上电后先延时100ms再释放复位，释放后再延时至少150ms才去访问MDIO寄存器。这样做的原因是PHY内部PLL需要时间锁定，如果复位刚释放就去操作寄存器，经常会读到0xFFFF或者乱码。
PHY地址是通过硬件引脚配置的，不是软件随便设。RTL8211F-CG的PHY地址常见的是0x00或0x01，具体取决于板上PHYAD相关引脚的上下拉。画板时如果想让软件省心，就把PHY地址引脚固定拉低，默认地址0x00。软件初始化里也要有这个意识：读不到PHY ID时，先怀疑地址不对，再把0到7扫一遍。
2.4 布局和PCB注意事项
千兆RGMII对PCB的要求比百兆RMII高，但也没到射频那么玄乎。我的经验是：
信号线尽量等长，RGMII 12根线控制在误差5mm以内，尤其是TXD组整体和RXD组整体。时钟线RX_CLK和TX_CLK不要穿过干扰源，最好包地。PHY的25MHz晶振要靠近PHY芯片摆放，走线短而直，晶振下方不要铺其它信号线。电源引脚用多个0.1uF小电容加一个10uF钽电容组合去耦，PHY的数字电源和模拟电源分开走，用磁珠或0欧电阻单点连接。
还有一点：RJ45连接器最好选带网络变压器的集成座子，比如HR911105A之类，省事而且隔离效果好。如果分离式设计，变压器中心和PHY之间的阻抗匹配要认真算，具体参考PHY datasheet的典型应用电路。
3. 软件接入：把RTL8211F驯化成H7的“标准外设”
3.1 CubeMX配置要点
CubeMX里配置STM32H7的ETH外设，步骤如下：
第一步，在Pinout视图里开启ETH，模式选RGMII。第二步，配置MDC和MDIO引脚，MDIO需要外部上拉电阻，一般4.7k到10k。第三步，进Clock Configuration，确认ETH的时钟源不为0。我见过不少人在时钟树里ETH时钟显示“-”或者0，生成的代码以太网根本不工作。第四步，如果是H7，还要在Project Manager里确认生成的是带MPU初始化代码的工程，后面要改MPU配置。
CubeMX默认生成的PHY驱动是LAN8742或者DP83848之类，没有RTL8211F。所以生成代码后，必须手动改PHY部分。
3.2 自己写PHY驱动：核心只在这几个函数
自己写RTL8211F驱动并不复杂，核心就几个点：PHY地址、PHY ID校验、软复位、自协商、Link状态读取。
先确认PHY能通，通过MDIO读PHY ID寄存器。标准PHY的Reg2和Reg3是厂商ID和型号ID，RTL8211F-CG常见的PHY ID是0x001CC916。如果读出来不是这个，说明地址不对或者硬件有问题。
下面是我简化后的初始化代码：
#define RTL8211F_PHY_ADDR 0x00 #define PHY_REG_BMCR 0x00 #define PHY_REG_BMSR 0x01 #define PHY_REG_ID1 0x02 #define PHY_REG_ID2 0x03 static uint16_t eth_read_phy(uint8_t addr, uint8_t reg) { // 通过HAL库的HAL_ETH_ReadPHYRegister封装 uint32_t val = 0; HAL_ETH_ReadPHYRegister(&heth, addr, reg, &val); return (uint16_t)val; } static void eth_write_phy(uint8_t addr, uint8_t reg, uint16_t val) { HAL_ETH_WritePHYRegister(&heth, addr, reg, val); } int rtl8211f_init(uint8_t phy_addr) { uint16_t reg; uint16_t id1, id2; // 1. 确认PHY是否响应 id1 = eth_read_phy(phy_addr, PHY_REG_ID1); id2 = eth_read_phy(phy_addr, PHY_REG_ID2); printf("PHY ID: 0x%04X 0x%04X\r\n", id1, id2); // 2. 软复位 eth_write_phy(phy_addr, PHY_REG_BMCR, 0x8000); do { reg = eth_read_phy(phy_addr, PHY_REG_BMCR); } while (reg & 0x8000); // 3. 启动自协商，允许全双工 eth_write_phy(phy_addr, PHY_REG_BMCR, 0x1200); return 0; }Link状态检测我建议轮询BMSR寄存器的bit2，为1表示Link Up，同时把BMSR读两遍，因为第一遍可能是未锁存状态。
int rtl8211f_get_link_state(uint8_t phy_addr) { uint16_t reg1 = eth_read_phy(phy_addr, PHY_REG_BMSR); uint16_t reg2 = eth_read_phy(phy_addr, PHY_REG_BMSR); return (reg2 & 0x0004) ? 1 : 0; }RTL8211F的扩展寄存器（比如RGMII delay配置）需要通过Realtek的扩展页寄存器机制访问，一般是先写寄存器0x1F切页，再操作对应寄存器。具体页号和偏移要看datasheet，不同版本（RTL8211F vs RTL8211FD）可能有差异，别照搬网上代码，以你手里那颗芯片的datasheet为准。
3.3 从裸机验证到LwIP/NetX
我强烈建议先不要直接上协议栈，而是用裸机或简单轮询确认PHY工作正常。流程是：上电延时、PHY软复位、启动自协商、轮询Link状态。如果Link都不起来，后面跑LwIP全是空谈。
PHY通了之后，再让H7的MAC开始收发数据。可以先跑一个最简单的Echo回环，PC端ping一下，通了再上LwIP。CubeMX自带LwIP生成插件，用起来很方便，但默认生成的代码在H7上有个大坑，就是MPU和Cache配置。
3.4 H7特有的大坑：Cache与MPU
H7的CPU有L1 Cache，而以太网DMA直接访问内存，不经过CPU Cache。如果你的DMA描述符和buffer区域被Cache缓存了，就会出现CPU发出去的TCP包内容是“脏”的，或者收到的数据CPU看不到最新值。这个问题的经典表现是：PHY Link正常、引脚波形正常、但ping包要么不通、要么收的是乱码。
解决办法有两个方向：
一是把以太网DMA相关的内存区域整体配置成Non-cacheable。CubeMX生成的MPU配置代码里增加一个region，起始地址指向以太网描述符和buffer所在RAM，比如H7的D2域SRAM（地址0x30040000附近），属性设为Non-cacheable或者Device。网上搜“STM32H7 MPU ETH”能找到很多示例。
二是保持Cache开着，但每次收发前后手动做Cache Clean和Invalidate。这种方法灵活但代码麻烦，不推荐新手搞。
我最终选的是MPU方式，把描述符和两片buffer全部放在D2域SRAM3里，MPU region属性设为Non-cacheable，之后以太网收发就再也没有玄学问题。
4. 实测过程与调试经验
4.1 从零到Link Up的验证步骤
我的调试路径很简单，每一步都有明确的可观测结果。
第一步，上电后读PHY ID。如果串口打印出0x001C 0xC916，说明MDIO时序和PHY地址正确，硬件链路基本通了一半。如果读出0xFFFF，先查复位、地址、电源。如果读出别的值，多半是MDIO干扰或者PHY在复位中。
第二步，执行软复位，然后启动自协商。RTL8211F自协商需要几秒时间，不能急。这个阶段可以用示波器量一下PHY的RGMII RX_CLK引脚，正常在千兆模式下应该是125MHz。如果时钟不对，后面Link多半起不来。
第三步，轮询Link状态。PC端网线插上交换机或直连，观察PHY的Link寄存器变化。同时看PC端网卡状态，如果显示1Gbps全双工，说明自协商成功。
第四步，确认速率。RTL8211F的扩展状态寄存器里能看到当前协商速率。我习惯同时读标准寄存器BMSR和Realtek对应状态寄存器，两个一起核对。
第五步，跑通mac层，PC能ping通H7，然后测TCP/UDP吞吐。
4.2 常见问题速查表
我在整个调试过程中遇到过不少问题，整理成表格方便对照排查：
| 现象 | 可能原因 | 排查方法 |
|---|---|---|
| 读PHY ID全是0xFFFF | PHY地址不对、复位未释放、电源没起 | 扫描地址0-7，查复位引脚状态，查电源 |
| PHY ID能读到但Link一直Down | 网线/对端故障、自协商没启动、变压器接错 | 换网线、查ANER寄存器、查RJ45座子引脚 |
| Link Up但Ping不通 | RGMII Delay配置错误、MPU/Cache未配置 | 关掉PHY内部Delay或PCB Delay，配MPU |
| 只能协商到100M | 网线不支持千兆、千兆被PHY寄存器限制 | 换六类线，强制1000M全双工测试 |
| 高负载吞吐明显低或卡死 | 描述符耗尽、中断处理不及时 | 查DMA描述符状态，加接收中断轮询 |
| CRC错误计数一直涨 | RGMII时序不对、时钟抖动 | 查RX Delay、TX Delay，查时钟走线 |
4.3 实测数据与性能参考
我的测试环境是H750 @ 480MHz，RTL8211F-CG，RGMII模式，LwIP 2.1.2，D2域SRAM放描述符和buffer，MPU配置为Non-cacheable。
实测结果：PC直连，千兆全双工自协商成功。ping包延迟稳定在0.3ms到0.8ms之间。UDP大包（1472字节负载）单向吞吐跑了约700Mbps，几乎没有丢包。TCP单线程大包传输稳定在500Mbps左右，进一步调大DMA描述符数量和接收buffer后能到600Mbps出头。
说实话，这个数据离线速还有距离，瓶颈主要在H7的MAC收发路径处理和LwIP的拷贝开销。如果你的应用需要跑满千兆，建议直接上带硬件TCP/IP卸载的芯片或者FPGA方案。但绝大多数MCU项目，500Mbps以上的吞吐已经绰绰有余了。
5. 项目落地中的真实心得
最后分享一些踩坑后的体会。
最先要说的就是：如果你第一次做H7 + RTL8211F-CG，尽量先买一块现成的核心板验证，比如某些带千兆网口的H7开发板，确认软件方案能跑通之后，再照着自己的原理图画板。这样能把“硬件设计问题”和“软件配置问题”分开排查，省掉大量联调时间。
H7以太网调试有个小技巧：串口打印PHY寄存器，尤其是BMSR、BMCR、PHY ID这三个，几乎所有硬件问题都能通过这几组数据定位。不要一上来就怀疑协议栈，协议栈出问题的概率远低于电源和时序。
还有一个让我印象很深的点：RTL8211F-CG的复位时序千万别省。有一次我为了加速启动，把复位释放到MDIO访问之间的延时从150ms改到了50ms，结果十次里有三四次PHY ID读不出来。后来老老实实把延时加回去，问题就消失。PHY的PLL锁定需要时间，这个延时不能省。
这套组合做熟之后，扩展方向很多。比如配合STM32H7的多个以太网实例做双网口冗余，或者把RGMII信号引到光模块做光纤通信，再或者和运动控制、FOC驱动配合做高速工业现场总线。千兆以太网在MCU领域已经不是什么奢侈配置了，但能不能跑稳，取决于你对PHY的每个细节是否足够敬畏。
