1. 从一颗哑巴交换芯片说起RTL8306MB移植的真实场景手上有一块带RTL8306MB的板子主控是个资源紧巴巴的MCU引脚已经被各种外设占得七七八八偏偏这颗交换芯片的SDK又必须通过MDC/MDIO去配置寄存器。更麻烦的是主控的硬件MAC控制器要么没引出MDIO要么被别的PHY占用了总之就是——没有现成的管理接口可用。这时候唯一的路子就是拿两个普通GPIO一个当时钟、一个当数据线用软件把MDC/MDIO的时序敲出来。这个场景在嵌入式网络设备里其实非常常见。RTL8306MB是瑞昱的一颗6口百兆交换芯片支持5个10/100M自适应电口加1个MAC接口可接CPU或光口内部集成了交换矩阵、VLAN、QoS、端口镜像等一堆功能。它的所有配置——从端口使能、速率双工、VLAN划分到流量控制——都要通过MDC/MDIO这套两线制管理接口去读写寄存器。芯片本身不带默认全通的傻瓜模式上电后如果不去初始化端口状态是未知的所以SDK移植是绕不过去的一步。所谓移植SDK说白了就是把瑞昱官方提供的那套寄存器操作代码适配到你的硬件平台上。官方SDK通常假设你有一个标准的MDIO控制器直接调用读写函数就行。但现实是很多低成本方案里根本没有这个控制器于是GPIO模拟MDC/MDIO就成了必备技能。这篇文章面向的是做过单片机、懂一点寄存器操作、但没怎么碰过交换芯片的嵌入式工程师我会把整个流程从时序原理到代码落地、从踩坑到验证完整地讲一遍。读完你至少能做到拿两个GPIO把RTL8306MB的寄存器读出来、写进去让芯片按你的意思工作。2. MDC/MDIO时序的本质为什么GPIO能骗过交换芯片2.1 两线制管理接口的物理层逻辑MDC/MDIO本质上是一个同步串行接口跟I2C有点像但更简单。MDC是时钟线由主控也就是你的MCU产生频率范围通常在1MHz到12.5MHz之间RTL8306MB对时钟占空比没有严格要求但高低电平的持续时间有最小值约束。MDIO是双向数据线在MDC的节拍下逐位传输。一次完整的寄存器访问帧是32位有些芯片是64位RTL8306MB用的是标准的32位帧格式结构是这样的前32位里开头是32个连续的1作为前导码preamble然后是起始码01接着是操作码读为10写为01再是5位PHY地址、5位寄存器地址最后2位是TATurn Around状态位。读操作时TA是Z0高阻后由从机拉低写操作时TA是10。这里有个关键点MDIO是开漏或者双向的主控在发送完地址后如果是读操作必须把数据线切换成输入模式等待芯片把数据驱动上来。这个方向切换的时机就是整个模拟过程中最容易出错的地方。2.2 为什么不用硬件MDIO而选择GPIO模拟有人会问既然MDIO这么标准为什么不用MCU自带的MAC控制器原因很现实第一很多低端MCU根本没有以太网MAC更别说MDIO控制器第二即使有MAC它的MDIO可能被板载PHY占用了而交换芯片是挂在另一个地址上的硬件控制器不一定支持多PHY管理第三有些项目的引脚分配是硬件工程师定死的软件只能将就。GPIO模拟的好处是灵活——任意两个引脚都能用不挑硬件坏处是时序全靠软件控制频率上不去而且容易因为中断打断导致时序错乱。实测下来用GPIO模拟跑个1MHz左右的MDC完全没问题RTL8306MB的寄存器读写对速度要求不高初始化阶段几百个寄存器写下来也就几毫秒的事。2.3 时序参数的实际约束RTL8306MB的数据手册里对MDC/MDIO的时序有明确要求我整理了几个关键参数基于常见实践具体以你手上的datasheet为准参数含义典型值注意事项MDC周期时钟周期≥400ns对应最高2.5MHz保守点用1MHzMDC高电平高电平持续时间≥160ns别太短否则芯片采样不到MDC低电平低电平持续时间≥160ns同上MDIO建立时间数据在MDC上升沿前稳定≥10nsGPIO翻转后加几个NOPMDIO保持时间数据在MDC上升沿后保持≥10ns同样加延时这些参数看起来宽松但如果你用的是几百MHz的MCUGPIO翻转速度极快反而可能因为太快导致建立保持时间不够。我的做法是在每次电平变化后插入几个空操作NOP或者一个微秒级的延时函数把MDC频率压到1MHz左右既安全又够用。3. 动手前的准备引脚选择、时钟配置与SDK裁剪3.1 GPIO引脚的选择原则选哪两个GPIO来模拟MDC和MDIO不是随便挑的。我的经验是遵循三条第一避开有特殊功能的引脚比如某些引脚上电时有默认复用配置成GPIO可能影响启动第二MDIO因为是双向的要选支持输入输出切换的引脚最好是不带上拉的外部已经有上拉电阻如果内部有弱上拉也可以第三两个引脚尽量在同一个GPIO端口上这样操作寄存器时可以用位带或者端口级操作速度更快。具体到代码层面你需要封装四个基本操作MDC拉高、MDC拉低、MDIO拉高输出模式、MDIO拉低输出模式以及MDIO读输入模式。如果用的是STM32可以用HAL库的HAL_GPIO_WritePin但为了速度我建议直接操作BSRR寄存器。如果是其他平台找到对应的位操作寄存器即可。3.2 时钟与延时的处理GPIO模拟的时序精度完全依赖延时。有两种做法一种是忙等busy-wait用循环做NOP另一种是用系统滴答或者硬件定时器。对于MDC这种微秒级的时序忙等最可靠因为定时器中断可能被其他中断打断。我通常写一个简单的延时函数参数是循环次数然后根据实测调整。比如在168MHz的STM32上一个for循环空转大概几个纳秒跑10次差不多就是几十纳秒。你可以用示波器量一下MDC的实际频率调到1MHz左右就行。没有示波器的话用逻辑分析仪也行实在没有就靠能读写成功来反推——如果读出来的寄存器值全是0或者全是1多半是时序太快了。3.3 SDK的裁剪与适配层设计瑞昱的SDK通常是一个大压缩包里面包含寄存器定义、API函数、示例代码可能还有针对特定平台的驱动。移植时不要一股脑全塞进去先做减法只保留rtl8306mb_reg.h寄存器地址定义、rtl8306mb_api.c读写和配置函数这几个核心文件。然后写一个适配层把SDK里调用的mdio_read和mdio_write替换成你自己的GPIO模拟实现。适配层的接口一般长这样// 适配层头文件 void rtl8306_mdc_init(void); void rtl8306_mdio_init(void); uint16_t rtl8306_mdio_read(uint8_t phy_addr, uint8_t reg_addr); void rtl8306_mdio_write(uint8_t phy_addr, uint8_t reg_addr, uint16_t data);SDK里原本可能是直接操作某个硬件寄存器你把这几个函数实现好SDK的其他部分基本不用动。这就是移植的核心思路——把硬件相关的部分隔离出来用GPIO模拟去填这个坑。4. 逐位敲出MDC/MDIO从帧结构到读写函数的完整实现4.1 写寄存器的位操作流程写操作相对简单因为数据方向始终是主控输出。整个帧32位我按顺序拆解前导码是32个1但RTL8306MB实际上对前导码的要求没那么严格有些实现里直接发32个1有些发完前导码后跟起始码。标准帧是32位前导码 2位起始码01 2位操作码写为01 5位PHY地址 5位寄存器地址 2位TA10 16位数据。总共64位不对这里要澄清一下MDIO帧有两种格式一种是Clause 2232位一种是Clause 4564位。RTL8306MB用的是Clause 22帧结构是32位前导码 2位起始 2位操作 5位PHY 5位寄存器 2位TA 16位数据 64位。等等32225521664确实是64位。但很多资料里说32位帧是指去掉前导码后的有效部分。实际发送时前导码是必须的用来同步。所以完整的一帧是64个MDC周期。写操作的代码逻辑void mdio_write(uint8_t phy, uint8_t reg, uint16_t val) { uint32_t data 0; // 构造帧前导码32个1 // 起始码01写操作01PHY地址5位寄存器地址5位TA10数据16位 data (0xFFFFFFFFUL 32) | (0x1 30) | (0x1 28) | ((phy 0x1F) 23) | ((reg 0x1F) 18) | (0x2 16) | val; // 逐位发送从高位到低位 for (int i 63; i 0; i--) { mdc_low(); if (data (1UL i)) mdio_high(); else mdio_low(); delay(); mdc_high(); delay(); } // 发送完后释放总线 mdio_input(); }注意TA位在写操作时是10即主控先拉高再拉低实际上写操作的TA是主控驱动10然后释放。读操作的TA是主控驱动Z高阻然后芯片驱动0。4.2 读寄存器的方向切换陷阱读操作是坑最多的地方。帧的前半部分和写一样但在TA阶段主控必须把MDIO从输出切换到输入。切换的时机是在发送完寄存器地址的最后一位后下一个MDC周期主控先输出高阻把GPIO设为输入然后芯片会在TA的第一个周期拉低第二个周期开始输出数据。很多人的代码在这里出错表现为读出来的数据永远是0xFFFF或者0x0000。原因通常是切换太早或太晚。太早芯片还没准备好太晚芯片已经开始驱动数据主控还在输出造成总线冲突。我的做法是在发送完寄存器地址的最后一位后立即把MDIO设为输入模式然后产生一个MDC周期TA的第一个周期再产生一个MDC周期TA的第二个周期之后开始读16位数据。每个数据位在MDC的上升沿采样。uint16_t mdio_read(uint8_t phy, uint8_t reg) { uint32_t frame 0; uint16_t data 0; // 构造前导码起始读操作PHY寄存器 frame (0xFFFFFFFFUL 32) | (0x1 30) | (0x2 28) | ((phy 0x1F) 23) | ((reg 0x1F) 18); // 发送前30位到寄存器地址结束 for (int i 63; i 34; i--) { mdc_low(); if (frame (1UL i)) mdio_high(); else mdio_low(); delay(); mdc_high(); delay(); } // 切换为输入 mdio_input(); // TA第一个周期主控释放芯片拉低 mdc_low(); delay(); mdc_high(); delay(); // TA第二个周期芯片输出0 mdc_low(); delay(); mdc_high(); delay(); // 读16位数据 for (int i 15; i 0; i--) { mdc_low(); delay(); mdc_high(); delay(); if (mdio_read_pin()) data | (1 i); } mdio_input(); // 保持输入 return data; }这里有个细节TA的第一个周期芯片拉低主控不需要读第二个周期芯片输出0主控也不需要读。从第17个周期开始才是真正的数据位。所以读循环是16次每次在MDC高电平期间采样。4.3 用示波器验证时序的实操方法代码写完后别急着跑SDK先用示波器或者逻辑分析仪抓一下波形。重点看三个地方MDC的频率是不是在1MHz左右MDIO的数据变化是不是在MDC低电平期间并且在MDC上升沿前稳定读操作的TA阶段MDIO是不是从主控驱动变成了芯片驱动。如果没有仪器可以用一个笨办法先写一个已知寄存器比如芯片ID寄存器再读回来看是否一致。RTL8306MB的芯片ID寄存器地址是0x00和0x01具体以手册为准读出来应该是固定的值。如果读出来不对先降低MDC频率再检查方向切换。5. 移植过程中那些让人抓狂的坑5.1 前导码不足导致的时好时坏有一次调试发现写寄存器偶尔成功偶尔失败成功率大概七成。查了半天最后发现是前导码只发了31个1。因为我的循环写成了for(i63; i32; i--)少发了一位。RTL8306MB对前导码的要求是至少32个连续1少一个就可能同步失败。这种问题最恶心因为它不是完全不通而是大部分时候通让你以为是硬件接触不良。提示前导码必须是32个完整的1建议用0xFFFFFFFF左移32位来构造确保位数正确。5.2 GPIO速度太快反而读不到数据另一个坑是MCU主频太高。我用的是200MHz的片子GPIO翻转一次只要几纳秒MDC频率轻松跑到10MHz以上。结果读寄存器全是0xFFFF。一开始以为是芯片坏了后来用逻辑分析仪一看MDC周期只有80ns远低于手册要求的400ns。芯片根本来不及响应。解决办法很简单在每次电平变化后加延时。但延时的粒度要控制好太长了MDC频率太低初始化时间变长太短了又不够。我的经验是调到MDC周期1us左右即频率1MHz这个速度下RTL8306MB工作得很稳。5.3 中断打断时序造成的随机错误GPIO模拟最大的软肋是怕中断。如果MDC时序正在跑突然来个中断延时被拉长MDC周期变得不均匀芯片可能就解析错了。表现是初始化偶尔失败重启几次才好。对策有两个一是在MDIO读写函数里关中断读写完再开二是把MDC频率降得更低给中断留出余量。我一般用第一种因为MDIO操作本身很快关中断几十微秒不会影响系统实时性。但要注意如果SDK里在中断上下文调用MDIO就不能关中断了得用第二种。5.4 PHY地址和寄存器地址的位序搞反MDIO帧里PHY地址是5位寄存器地址也是5位都是MSB先发。我见过有人把位序搞反结果访问的寄存器全错。RTL8306MB的PHY地址通常是0到4对应5个端口或者用0表示全局寄存器。具体哪个地址对应哪个功能一定要查手册的寄存器映射表。5.5 SDK里的延时函数与平台不兼容瑞昱SDK里经常有一些delay_us或者mdelay的调用这些函数在不同平台上实现不一样。移植时要么自己实现一个基于系统滴答的延时要么直接替换成空函数如果时序要求不严格。我遇到过SDK里有个delay_ms(100)在初始化时被调用结果我的平台没有毫秒延时编译报错。后来用循环凑了一个虽然不准但够用。6. 跑通之后验证、调试与性能优化6.1 用寄存器读写做自检SDK移植完第一步不是急着配置VLAN而是做自检。写一个测试函数往某个可读写的寄存器比如端口控制寄存器写一个值再读回来看是否一致。如果一致说明MDIO通路没问题。然后读芯片ID确认能正确识别RTL8306MB。RTL8306MB的芯片ID通常在寄存器0x00和0x01读出来应该是0x8306或者类似的值。如果读出来是0x0000或0xFFFF说明时序还有问题。6.2 端口Link状态与自协商的观察自检通过后可以配置端口使能和自协商。把网线插到某个端口读该端口的状态寄存器看Link位是否置起速率和双工是否和协商结果一致。这一步能验证SDK的配置函数是否真正生效。我通常会用SDK提供的API把5个端口都使能开启自协商然后逐个插网线测试。如果某个端口Link不上先检查硬件变压器、RJ45再检查寄存器配置。6.3 批量读写时的效率优化初始化阶段可能要写几百个寄存器如果每个寄存器都走一遍完整的64位帧时间会比较长。优化方法有一是提高MDC频率在时序允许的前提下尽量快二是合并操作有些寄存器可以连续写三是用位带操作加速GPIO翻转。实测下来1MHz的MDC下写一个寄存器大概64us写500个寄存器就是32ms完全可以接受。如果嫌慢把MDC提到2.5MHz时间减半。6.4 长期运行的稳定性考量GPIO模拟的MDIO在长期运行中可能因为中断、任务调度等原因出现偶发错误。我的做法是在关键配置后加一个回读校验如果发现写入的值和读回的不一致就重试几次。另外MDIO总线上的上拉电阻要合适通常4.7k到10k太小了功耗大太大了上升沿变缓。还有一个经验如果系统里有多个任务可能同时访问MDIO一定要加互斥锁。否则两个任务同时操作GPIO时序就乱了。7. 一些让移植更顺手的个人习惯我在做这类移植时习惯先把GPIO模拟的MDIO读写封装成一个独立的模块不依赖任何SDK单独测试通过后再接入SDK。这样出问题时容易定位——到底是MDIO时序问题还是SDK配置问题。另外我会在代码里留一个宏开关可以切换硬件MDIO和GPIO模拟。如果以后硬件改版有了MDIO控制器直接改宏定义就行不用重写代码。还有个小技巧把MDC和MDIO的引脚定义、延时参数、PHY地址都放在一个头文件里用宏定义。这样换平台时只改这一个文件其他代码不动。我甚至见过有人把不同平台的GPIO操作写成函数指针运行时动态切换虽然有点过度设计但对于多平台维护确实方便。最后说一个调试习惯每次修改时序参数后先读芯片IDID对了再往下走。芯片ID是最可靠的握手信号它对了说明前导码、起始码、操作码、地址位序、TA切换全对了。这比读任何其他寄存器都管用。