组件类

摘要

本应用笔记描述了如何在 RT-Thread 中，如何根据具体的硬件配置网络驱动，并灵活运用调试手段解决问题。

在 RT-Thread 所支持的 BSP 中，大部分都有支持以太网驱动。但具体到用户的硬件中，可能会和默认的代码有所差异。本文选择相对以太网驱动比较完善 stm32f40x，介绍了驱动的主要实现方式，以及针对不同硬件的修改方法。

本文首先介绍了常见的以太网芯片种类和一些常用的名词解释，然后详细描述了 RT-Thread 以太网驱动架构，驱动接口和驱动的移植 ，并给出了在正点原子 STM32F4 探索者开发板上移植的代码示例，最后介绍了驱动的调试方法。

以太网芯片有很多种，大致可以分成 3 种：

MAC：媒体介入控制层，属于 OSI 模型中数据链路层下层子层 。

PHY：PHY 指物理层，OSI 的最底层。 一般指与外部信号接口的芯片。

MII：MII (Media Independent Interface），介质无关接口，也被称为媒体独立接口，它是 IEEE-802.3 定义的以太网行业标准，支持 10Mbit/s 和 100Mbit/s 数据传输模式 。

RMII：RMII (Reduced Media Independent Interface) ，简化媒体独立接口，是 IEEE 802.3u 标准中除 MII 接口之外的另一种实现，支持 10Mbit/s 和 100Mbit/s 数据传输模式 。相比 MII，精简了引脚数量。

lwIP：lwIP 是瑞典计算机科学院(SICS)的 Adam Dunkels 开发的一个小型开源的 TCP/IP 协议栈。实现的重点是在保持 TCP 协议主要功能的基础上减少对 RAM 的占用。

pbuf：lwIP 中用来管理数据包的结构体。

RT-Thread 的 lwIP 移植在原版的基础上，添加了网络设备层以替换原来的驱动层。和原来的驱动层不同的是，对于以太网数据的收发采用了独立的双线程结构，erx 线程和 etx 线程在正常情况下，两者的优先级设置成相同，用户可以根据自身实际要求进行微调以侧重接收或发送。

当以太网硬件设备收到网络报文产生中断时，接收到的数据会被存放到接收缓冲区，然后以太网中断程序会发送邮件来唤醒 erx 线程，erx 线程会按照接收到的数据长度来申请 pbuf，并将数据放入 pbuf 的 payload 中，然后将 pbuf 通过邮件发送给 去处理。

当有数据需要发送时，tcpip 线程会发送一个邮件来唤醒 etx 线程，etx 线程会先判断现在是否正在发送数据，如果没在发送数据，etx 线程会将要发送的数据放入发送缓冲区，然后启动以太网发送来发送数据。如果正在发送数据，etx 线程会将自己挂起，直到获取到发送等待信号量后再发送数据。

RT-Thread 网络设备继承了标准设备，是由 eth_device 结构体定义的，这里贴出 eth_device 结构体代码提供参考

本文以太网驱动比较完善 stm32f40x 为例进行讲解，除 ST 固件库以外，需要实现以下驱动：

标准设备接口需要提供给 eth_device 结构体中的 parent 元素

rt_stm32_eth_init 用于初始化 DMA 和 MAC 控制器。

rt_stm32_eth_open 用于上层应用打开网络设备，目前未使用到，直接返回RT_EOK。

rt_stm32_eth_close 用于上层应用关闭网络设备，目前未使用到，直接返回RT_EOK。

rt_stm32_eth_read 用于上层应用向底层设备进行直接读写的情况，对于网络设备，每个报文都有固定的格式，所以这个接口目前并未使用，直接返回0值。

rt_stm32_eth_write 用于上层应用向底层设备进行直接读写的情况，对于网络设备，每个报文都有固定的格式，所以这个接口目前并未使用，直接返回0值。

rt_stm32_eth_control 用于控制以太网接口设备，目前用于获取以太网接口的mac地址。如果需要，也可以通过增加控制字的方式来扩展其他控制功能。

对应了 eth_device 结构体中的 eth_rx 及 eth_tx 元素，实现数据包收发功能，如下所示：

rt_stm32_eth_tx 函数被 etx 线程调用，实现了数据发送的功能，这里贴出 stm32f40x 部分代码片段提供参考

rt_stm32_eth_rx 函数被 erx 线程调用，实现了接收数据的功能，这里贴出 stm32f40x 部分代码片段提供参考

rt_hw_stm32_eth_init 用于注册以太网设备，以太网硬件，配置 MAC 地址等。

STM32F407 芯片自带以太网模块，该模块包括带专用 DMA 控制器的 MAC 802.3（介质访问控制）控制器，支持介质独立接口 (MII) 和简化介质独立接口 (RMII)，并自带了一个用于外部 PHY 通信的 SMI 接口，通过一组配置寄存器，用户可以为 MAC 控制器和 DMA 控制器选择所需模式和功能。

因为同系列 stm32 的 MAC 控制器初始化基本一样，所以同系列的驱动 MAC 部分的代码不需要做修改，要修改的只是 PHY 的部分，这里以 LAN8720 为例讲解。

在调试驱动时，建议先打开 stm32f4xx_eth.c 中的日志功能。

查看原理图，RESET 引脚为 PD3，修改复位管脚为 PD3。

在rt_hw_stm32_eth_init函数中，使用 GPIO 对 PHY 芯片进行了复位。如果不修改为正确的引脚，除了 PHY 可能没有被正确复位外，还可能造成引脚冲突而损坏板子。

根据原理图，确认外接的 PHY 是使用 MII 还是 RMII 模式。

修改 stm32f4xx_eth.c 中的模式设置

驱动默认使用 IO 比较简洁的 RMII 模式，当使用 MII 模式时需要修改为

不少单片机为了布线方便，都有引脚映射功能，需要根据原理图来确定和 PHY 相连的引脚。

STM32F4 的以太网，可以通过 IO 映射选择不同的 IO，默认是按组选择的，正点原子探索者用的是 GPIOG,不需要修改代码。

实际上 F4 的每个 IO 都可以独立设置，如果 TX 所有的 IO 不在同一个 GPIO PORT 上面，如 TX1 在 GPIOB 上面，而 TX0 在 GPIOG 上面。这种情况则需要大篇幅修改代码，确保每个 IO 都映射到对应的端口。

除了数据 IO 外，部分引脚多的芯片，MDIO 接口也可以映射到不同的端口，这部分配置也需要一一核对。

下面列出正点原子探索者用于连接外部 PHY 的引脚,用户需要按照自己的原理图对相应的管脚进行初始化。

PHY 是 IEEE802.3 中定义的一个标准模块。PHY 寄存器的地址空间为 5 位，因此寄存器范围是0 到 31 ，最多有 32 个寄存器。IEEE802.3 定义了地址为 0-15 这 16 个基础寄存器的功能，因此只需要修改少量寄存器的定义即可完成移植。

驱动默认使用 LAN8720，如果使用的是其它型号的 PHY。应该修改自动协商、状态和速率指示寄存器相关的宏定义，使程序能正确设置自动协商并读取 PHY 的连接状态和速率。

下面列出需要在 stm32f4xx_eth.h 中配置 LAN8720 常用的几个寄存器和控制状态位的定义

RT-Thread 的驱动实现中，做了 PHY 地址搜索的功能，可以正确搜索出 PHY 的地址，所以不必定义 PHY 地址

这里贴出 stm32f4xx_eth.c 文件中 phy_monitor_thread_entry函数中的地址搜索函数供用户参考

RT-Thread 实时操作系统提供了一套设备管理框架 ，应用程序通过 RT-Thread 的设备操作接口实现通用的设备驱动。 我们这里对 ETH 设备，实现 Network Interface 类型的设备驱动，然后注册到 RT-Thread。

stm32f4xx_eth.c 中的 rt_hw_stm32_eth_init 是 ETH 设备初始化入口，负责 stm32_eth_device 结构体的初始化，并将其注册到 RT-Thread。

rt_stm32_eth_init是初始化以太网外设的，应按照实际需求初始化

这里只贴出 MAC 配置和 DMA 配置的代码

rt_stm32_eth_control函数需要实现获取 MAC 地址的功能

别的设置标准驱动接口可以不实现，先写个空函数即可。

rt_stm32_eth_rx会去读取接收缓冲区中的数据，并放入 pbuf（lwIP中利用结构体 pbuf 来管理数据包 ）中，并返回 pbuf 指针。

“erx”接收线程会阻塞在获取eth_rx_thread_mb邮箱上，当它接收到邮件时，会调用rt_stm32_eth_rx去接收数据。

rt_stm32_eth_tx会将要发送的数据放入发送缓冲区，等待 DMA 来发送数据。

“etx”发送线程会阻塞在获取eth_tx_thread_mb邮箱上,当它接收到邮件时，会调用rt_stm32_eth_tx来发送数据。

工程默认启用了 DHCP 功能，需要有 DHCP 服务器来分配 IP 地址，常见的连接拓展如图：

如果没有方便的实际环境，也可以先通过 ENV 配置固定 IP，然后用网线直接连接到调试用的电脑。

电脑和开发板需要设置同网段的 IP 地址。

当支持网络的固件在开发板上面运行起来后，应该首先检查 RJ45 指示灯的状态。

正常应该是有灯常亮，且有数据收发时会出现闪烁。

如果发现灯没有亮，请先确认开发板硬件是否完好；然后检查供电是否充足，网线是否接好。

然后程序上配合硬件确认是否有正确复位 PHY，直到正常闪烁为止。

在shell命令行执行ifconfig命令即可查看网卡的 IP 地址。

如果启用了 DHCP 功能，且此时显示已经获取到了 IP 地址，说明驱动的收发功能都已经正常。

如果是静态 IP 或是没有获取到 IP，请留意网卡 FLAG 中的 UP 和 LINK_UP 标志。如果显示有 LINK_DOWN，请确认 PHY 的管理程序有正确识别到 PHY 的速率和双工状态。并正确通过eth_device_linkchange通知到 lwIP。

如果启用了 DHCP 功能，且已经显示 LINK_UP。但没能正确获取到 IP。说明开发板与 DHCP 服务器通信不畅，需要进一步调试。

可以通过拔插网线观察 LINK 状态来判断是否正确读取了 PHY 寄存器的值

通过打开驱动中的 ETH_RX_DUMP 和 ETH_TX_DUMP 功能。可以把收发的数据包打印出来。

当 RJ45 指示灯正常闪烁时，说明有数据包在收发。因为网络中经常会有广播数据包，如果此时有数据包进来，会有 RX_DUMP 的打印。如果一直没有打印，则重点检查两点：

MII/RMII 的 RX 线路有问题，包括硬件问题或 IO 映射错误。

EMAC 和 PHY 的速率和双工模式不配置，如 EMAC 工作在 10M，而 PHY 连接为 100M。

需要确认有正确获取 PHY 的速率和双工模式，同时可以与网线另外一端对比。如电脑上在显示 10M，而板子上面没有更新 PHY 管理程序，默认为 100M。

如果有必要，也可以打印 PHY 的 LOOPBACK 功能。以确认 MII/RMII 总线是完好的。

可以通过电脑 ping 板子或者板子 ping 电脑（需要开启netutils组件包中的 ping 功能）来测试驱动是否移植成功。

ping 之前要注意一下事项：

如果板子有 RX DUMP，但依然无法通信时，可以在电脑上面使用 wireshark 抓包。

电脑 ping 开发板，开发板收到目标地址为自己的 IP 地址的请求包(request)，然后，板子会给电脑做出回应，发送一个目标地址为电脑 IP 地址的回应包(reply)。

根据是否有回应(reply)，可以分两种情况检查

当板子有发出广播包，在电脑上面可以收到。（如 DHCP Discoverer）

在使用 wireshark 抓包过程中，主要是灵活使用各种过滤器，过滤出我们所关心的数据包。

当开发板还没有拿到 IP 地址时，可以使用开发板的 MAC 地址作为过滤器条件。

当开发板成功 link_up 时，会主动发出 DHCP 请求包，源地址就是开发板自己的 MAC 地址。

或配置开发板为静态 IP，然后 PC 上面执行 ping 命令，ping 开发板的 IP 地址。

这里把开发板的 IP 地址作为过滤条件，正常情况下，PC 会先发出请求包(request)。

原文: https://www.rt-thread.org/document/site/rtthread-application-note/components/network/an0010-rtthread-system-lwip-driver-porting/