[WIFI学院] - 00-01 WIFI网卡的整体工作模型
WiFi 网卡的整体工作模型
一、WiFi 网卡是什么
在正式研究 Linux WiFi 驱动以及 RTL8812EU 源码之前，我们首先需要回答一个最基础的问题：
一块 WiFi 网卡到底是什么？
平时使用 WiFi 网卡时，我们很容易把它理解成：
一个让计算机连接 WiFi 的设备。
这个理解从用户角度没有问题，但对于驱动开发来说远远不够。
从驱动开发者的角度看，一块 WiFi 网卡实际上位于两个完全不同的世界之间：
计算机中的数字数据 -> WiFi 网卡 -> 无线空间中的电磁波
因此，WiFi 网卡最核心的作用可以暂时概括成：
WiFi 网卡是连接“计算机数字数据世界”和“无线通信世界”的硬件设备。
发送数据时，它需要把计算机中的数字数据最终转换成可以通过天线发射的无线信号。
接收数据时，则执行相反的过程：
无线信号 -> WiFi 网卡 -> 计算机能够处理的数字数据
后续整个 RTL8812EU 驱动的研究，本质上都围绕这个基本过程展开。
1.1 从计算机的角度理解 WiFi 网卡
首先暂时完全不考虑 WiFi 网卡内部是如何工作的, 从计算机的角度来看，WiFi 网卡首先是一个外部硬件设备。
根据不同产品，它可能通过 USB, PCIe, SDIO 等接口连接到计算机。
例如我们准备研究的 RTL8812EU，就是通过 USB 与 Host 连接的。
因此可以先建立一个非常简单的模型：
+-----------------------+
| Host |
| |
| CPU |
| RAM |
| Operating System |
| Application |
+-----------------------+
|
| USB
|
v
+-----------------------+
| RTL8812EU |
| |
| WiFi Chip |
+-----------------------+
|
v
Antenna
Host 中运行：
Application
Operating System
Driver
而 RTL8812EU 是连接在 Host USB 总线上的一个独立硬件设备。
因此，从 Host 的角度来看：
RTL8812EU 首先是一个 USB Device。
但是它又不是普通 USB Device, 它通过 USB 与 Host 交换的是数字数据，而它的另一端连接的是无线通信系统。
所以更准确地说：
RTL8812EU 是一个通过 USB 与 Host 通信，同时能够进行 WiFi 无线收发的专用通信芯片。
1.2 Host 与 WiFi 网卡
后续学习中会频繁出现一个词：Host, 这里首先明确它的含义。
Host 可以简单理解为：
运行操作系统和应用程序，并负责控制 WiFi 网卡的主机系统。
例如：
PC
树莓派
OpenIPC 摄像机
嵌入式 Linux SoC
MCU
理论上都可能成为 Host。
对于典型的 OpenIPC + RTL8812EU 系统，可以暂时理解成：
OpenIPC SoC
|
| USB
|
RTL8812EU
|
Antenna
其中：
OpenIPC SoC = Host
RTL8812EU = WiFi Device
这是一个非常重要的物理边界。
以后阅读驱动源码时，我们必须始终知道：
哪些代码运行在 Host CPU 上？
以及：
哪些工作发生在 RTL8812EU 芯片内部？
例如 Linux 驱动显然运行在 Host CPU 上。
所以, Linux Driver 并不是运行在 RTL8812EU 芯片里的程序。
可以先建立如下认识：
Host
+--------------------------------+
| |
| Application |
| |
| Linux |
| |
| RTL8812EU Driver |
| |
+--------------------------------+
|
| USB
|
v
+--------------------------------+
| |
| RTL8812EU |
| |
+--------------------------------+
|
Antenna
至于 RTL8812EU 芯片内部还有什么，现在暂时把它当作一个黑盒。
这个黑盒将在后面的课程中逐渐打开。
1.3 WiFi 网卡为什么不是“无线串口”
刚开始接触 WiFi 驱动时，很容易建立一个过度简化的模型。
例如：
Application
|
| "Hello"
v
WiFi Chip
|
| 无线
v
Another WiFi Chip
|
| "Hello"
v
Application
这会让 WiFi 网卡看起来很像一个“无线串口”。
例如串口发送：
0x48 0x65 0x6C 0x6C 0x6F
硬件按照串口协议把这些 Byte 一个一个发送出去。
于是可能自然产生一个想法：
WiFi 网卡是不是也只是把这些 Byte 通过无线发送出去？
实际上不是, WiFi 是一个复杂的无线通信系统。
应用程序产生的数据，在真正通过 WiFi 发射之前，需要经历多层处理。
暂时可以粗略理解成：
Application Data
↓
Network Data
↓
WiFi Data
↓
Wireless Physical Processing
↓
RF Signal
↓
Antenna
因此：
WiFi 网卡并不是简单地把 Host 提供的一串 Byte 原样变成无线电波。
WiFi 通信需要解决很多问题，例如：
这一帧数据发给谁？
使用哪个 WiFi Channel？
使用什么传输速率？
使用什么调制方式？
使用多大的信道带宽？
什么时候允许发送？
接收到的数据是否正确？
收到的数据属于哪个无线设备？
这些问题最终会涉及：
802.11
MAC
PHY
Baseband
RF
MCS
Channel
Bandwidth
等大量概念, 现在不需要理解这些概念, 这一节只需要建立一个认识：
WiFi 网卡不是一个“无线 Byte 搬运器”，而是一个实现复杂无线通信功能的专用硬件系统。
二、WiFi 网卡的数据收发模型
理解 WiFi 网卡最好的方式之一，就是观察一个数据包如何穿过整个系统。
WiFi 网卡最核心的工作可以分成两个方向：
TX = Transmit = 发送
RX = Receive = 接收
以后阅读 RTL8812EU 源码时，会大量看到 tx, rx, xmit, recv 这些名字。
其中, TX / xmit 通常与发送相关; 而 RX / recv 通常与接收相关。
2.1 数据从应用程序到 WiFi 网卡
假设应用程序现在产生了一段数据："Hello", 这个数据最开始只存在于 Host 的内存中。
例如：
Host RAM
+-----------------------+
| |
| 48 65 6C 6C 6F |
| |
+-----------------------+
这些只是计算机内存中的数字, 它们不会自动变成无线信号, 要通过 WiFi 发送出去，需要经过一系列软件和硬件层。
暂时可以建立如下模型：
Application
↓
Operating System
↓
Network Stack
↓
WiFi Subsystem
↓
WiFi Driver
↓
USB / PCIe / SDIO
↓
WiFi NIC
对于 RTL8812EU，则是：
Application
↓
Linux
↓
Linux Network / WiFi Subsystem
↓
RTL8812EU Driver
↓
USB
↓
RTL8812EU
注意, 这里暂时不要关心每一层内部究竟发生了什么, 现阶段只需要知道：
应用程序的数据通常不会直接交给 RTL8812EU。
在 Application 和 RTL8812EU 之间，还存在操作系统、网络系统、WiFi 系统、具体设备驱动以及 USB。
因此以后研究发送路径时，我们实际上是在不断打开这些黑盒：
Application
↓
[黑盒]
↓
[黑盒]
↓
[黑盒]
↓
RTL8812EU
2.2 WiFi 网卡内部对发送数据做了什么
现在假设数据已经通过 USB 到达 RTL8812EU, 接下来会发生什么？
最简单但错误的理解是：
USB Data -> Antenna
实际上 USB 中传输的是数字信息，而天线最终处理的是射频电信号, 两者之间存在巨大的差异。
因此 RTL8812EU 内部必须继续进行大量处理, 现在先把这些复杂处理统一称为：
WiFi Processing
于是可以得到：
Host
|
| USB Digital Data
|
v
+-------------------------+
| RTL8812EU |
| |
| WiFi Processing |
| |
+-------------------------+
|
| RF Signal
|
v
Antenna
以后我们会把 WiFi Processing 继续拆开, 最终会看到：
MAC
PHY
Baseband
RF
等不同硬件模块, 但这些属于下一讲：
00-02_MAC_PHY_BB_RF的分层与关系
当前只需要知道：
RTL8812EU 收到 Host 通过 USB 发送的数据之后，还需要经过 WiFi 协议处理、数字信号处理以及射频处理，最终才能通过天线发射。
2.3 从数字数据到无线电波
这是理解 WiFi 硬件非常重要的一步。
假设程序中存在：
0x48 0x65 0x6C 0x6C 0x6F
这些数字本身不能在空气中传播, CPU 和 RAM 处理的是数字数据, 而天线最终发送的是：
随时间变化的电磁波。
因此整个发送过程实际上发生了一系列“表示形式”的变化。
可以先粗略理解为：
Application Data
↓
Digital Network Data
↓
802.11 Related Data
↓
Digital Signal Processing
↓
RF Electrical Signal
↓
Antenna
↓
Electromagnetic Wave
也就是说, 内存中的 Byte 和 空气中的 WiFi 电磁波 并不是同一种东西。
WiFi 芯片的重要工作之一，就是完成这两个世界之间的转换。
发送方向：
Digital Data
↓
WiFi Chip
↓
RF Signal
↓
Antenna
↓
Electromagnetic Wave
接收方向：
Electromagnetic Wave
↓
Antenna
↓
RF Signal
↓
WiFi Chip
↓
Digital Data
以后学习：
OFDM, BPSK, QPSK, QAM, MCS, Bandwidth
等概念，本质上都是在逐渐解释：
数字信息究竟如何被表示到无线信号中。
但阶段 0 暂时不需要深入这些数学和通信原理。
2.4 WiFi 数据的接收过程
发送过程理解以后，接收过程就容易建立整体概念。
假设另外一个 WiFi 设备发送了一帧无线数据, 首先到达的是 RTL8812EU 的天线：
Wireless Signal -> Antenna
RTL8812EU 对接收到的无线信号进行处理：
Wireless Signal -> Antenna -> RTL8812EU
然后 RTL8812EU 把处理得到的数字数据通过 USB 交给 Host：
RTL8812EU -> USB -> Host
进入 Host 后，再经过 Driver 和操作系统：
RTL8812EU
↓
USB
↓
RTL8812EU Driver
↓
Linux WiFi / Network System
↓
Application
所以完整 RX 路径可以暂时表示为：
Wireless Signal
↓
Antenna
↓
RTL8812EU
↓
USB
↓
RTL8812EU Driver
↓
Linux WiFi / Network System
↓
Application
把 TX 和 RX 放在一起：
TX:
Application
↓
Linux
↓
Driver
↓
USB
↓
RTL8812EU
↓
Antenna
↓
Wireless Signal
RX:
Wireless Signal
↓
Antenna
↓
RTL8812EU
↓
USB
↓
Driver
↓
Linux
↓
Application
这两条路径非常重要。
后面研究 RTL8812EU 源码时，大量工作其实就是把 Driver 这个简单方框逐渐展开。
最终我们会得到类似：
Application
↓
Linux
↓
Driver Function A
↓
Driver Function B
↓
Driver Function C
↓
TX Descriptor
↓
USB Buffer
↓
USB Transfer
↓
RTL8812EU
这样的详细调用路径。
三、WiFi 驱动在整个系统中的位置
现在我们已经知道：
Host -> USB -> RTL8812EU
但 Host 并不能天然知道如何操作 RTL8812EU, 这就是 Driver 存在的重要原因。
3.1 为什么需要 WiFi 驱动
假设 Host USB 接口上连接了一个设备。
Host 可以通过 USB 发现：USB 总线上出现了一个设备。
但是仅仅知道有一个 USB Device 并不意味着操作系统就知道：
它是什么设备？
应该怎样初始化？
它有哪些功能？
应该怎样设置 Channel？
应该怎样发送数据？
应该怎样接收数据？
应该怎样读取设备状态？
不同硬件的控制方式可能完全不同。
例如：
RTL8812EU
RTL8812AU
其他 Realtek WiFi
MediaTek WiFi
Atheros WiFi
Broadcom WiFi
它们可能具有不同的：
Register
Firmware
Command
Descriptor
Initialization Sequence
Hardware Capability
操作系统不可能仅凭“这是一个 USB Device”就自动知道所有硬件细节。
因此需要一层专门了解具体硬件的软件：
Driver
可以建立：
Linux
|
| 通用操作需求
v
+-------------------------------+
| RTL8812EU Driver |
| |
| 知道如何操作 RTL8812EU |
+-------------------------------+
|
| RTL8812EU能够理解的操作
v
RTL8812EU
所以 Driver 最基本的意义可以理解为：
Driver 是操作系统与具体硬件设备之间的软件桥梁。
3.2 WiFi 驱动最基本的职责
不同 WiFi 驱动非常复杂，但从最高层看，它们都需要完成一些基本工作。
例如：
发现设备
当 RTL8812EU 插入 USB 时：
Linux
↓
发现 USB Device
↓
找到能够管理它的 Driver
初始化设备
设备刚刚上电时通常不能立即正常工作, Driver 需要完成各种初始化工作。
可以暂时理解成：
Device Found
↓
Driver Initialization
↓
Hardware Ready
配置设备
例如 WiFi 工作时可能需要设置：
Channel, Bandwidth, Mode, TX Power
这些最终都需要通过 Driver 控制硬件。
发送数据
Host 要发送数据时：
Linux -> Driver -> Hardware
Driver 需要把上层提供的数据转换成硬件能够处理的形式。
接收数据
硬件收到数据以后：
Hardware -> Driver -> Linux
Driver 又需要把硬件提供的数据转换成操作系统能够理解的形式。
因此可以暂时把 WiFi Driver 的职责总结成：
WiFi Driver
|
+------------+------------+
| | |
初始化 配置 数据收发
| | |
+------------+------------+
|
WiFi Hardware
真实驱动远比这个模型复杂。
但是这个模型已经足够支撑我们进入后续学习。
3.3 Driver 是 Host 与 WiFi 硬件之间的软件桥梁
现在可以进一步完善整个系统：
+-----------------------------------+
| Host |
| |
| Application |
| ↓ |
| Operating System |
| ↓ |
| WiFi Driver |
| |
+-----------------------------------+
|
| USB / PCIe / SDIO
|
v
+-----------------------------------+
| |
| WiFi NIC |
| |
+-----------------------------------+
|
Antenna
Driver 有两个方向需要面对。
向上, Operating System;
向下, Hardware.
因此 Driver 本质上同时需要理解两个世界：
Operating System
|
v
+----------------+
| Driver |
+----------------+
|
v
Hardware
向上，它需要符合操作系统规定的软件接口。
向下，它需要知道具体硬件的控制方法。
这个认识对以后做 MCU 移植尤其重要。
因为如果未来我们把 RTL8812EU 从 Linux 移植到 MCU：
Linux -> MCU / RTOS
变化最大的很可能就是 Driver 面向操作系统的这一侧。
而 RTL8812EU 硬件本身并没有因为 Host 从 Linux 变成 MCU 就发生变化。
也就是说：
Linux Host
|
Linux Driver
|
RTL8812EU
未来可能变成：
MCU / RTOS
|
MCU RTL8812EU Driver
|
RTL8812EU
因此后续阅读源码时，我们始终需要思考一个问题：
这一段代码是因为 Linux 要求这样写，还是因为 RTL8812EU 硬件要求这样做？
这是未来能够把 RTL8812EU 驱动移植到其他平台的关键思维方式。
四、回到 RTL8812EU：建立第一张系统地图
现在把前面所有抽象概念放回我们的实际研究对象：
svpcom/rtl8812eu
我们暂时完全不进入源码，只确定它在整个系统中的位置。
4.1 RTL8812EU 在整个系统中的位置
对于 OpenIPC + RTL8812EU，可以先建立如下模型：
+-------------------------------------------+
| OpenIPC Host |
| |
| Application / WFB-NG |
| |
| Linux |
| |
| Linux Network / WiFi System |
| |
| RTL8812EU Driver |
| |
+-------------------------------------------+
|
| USB
|
v
+-------------------------------------------+
| |
| RTL8812EU |
| |
| WiFi Processing |
| |
+-------------------------------------------+
|
|
Antenna
|
v
Wireless Medium
现在我们已经能够明确几个非常重要的边界。
第一：
WFB-NG
Linux
RTL8812EU Driver
运行在 Host。
第二：RTL8812EU 是独立于 Host 的 WiFi 硬件。
第三：Host 与 RTL8812EU 之间通过 USB 连接。
第四：RTL8812EU 与无线空间之间通过 Antenna 连接。
因此整个系统实际上存在两个非常重要的接口：
Host
|
| USB
|
RTL8812EU
|
| RF
|
Antenna
USB 一侧属于数字计算机世界。
天线一侧属于无线通信世界。
RTL8812EU 正好位于两者之间。
4.2 RTL8812EU 的发送与接收方向
现在建立第一版 RTL8812EU TX 数据路径。
TX
WFB-NG / Application
↓
Linux
↓
Linux Network / WiFi System
↓
RTL8812EU Driver
↓
USB
↓
RTL8812EU
↓
WiFi Physical Processing
↓
Antenna
↓
Wireless Signal
反方向则是 RX：
Wireless Signal
↓
Antenna
↓
RTL8812EU
↓
USB
↓
RTL8812EU Driver
↓
Linux Network / WiFi System
↓
WFB-NG / Application
以后研究 RTL8812EU 驱动，实际上就是不断细化这两张图。
4.3 为后续学习建立第一张完整系统图
现在可以建立整个 RTL8812EU 学习过程中第一张完整系统地图：
Host
+--------------------------------------------------+
| |
| Application |
| | |
| v |
| Operating System |
| | |
| v |
| Network / WiFi Subsystem |
| | |
| v |
| RTL8812EU Driver |
| |
+--------------------------------------------------+
|
| USB
|
v
+--------------------------------------------------+
| |
| RTL8812EU |
| |
| WiFi Processing |
| |
+--------------------------------------------------+
|
v
Antenna
|
v
Wireless Medium
现在这张图里面仍然存在大量黑盒, 这完全没有问题。
整个学习过程就是不断打开这些黑盒。
例如下一讲：
00-02_MAC_PHY_BB_RF的分层与关系
就会首先打开 RTL8812EU 这个黑盒的一部分。
我们会逐渐把 RTL8812EU 展开成类似：
RTL8812EU
|
+--- MAC
|
+--- PHY / Baseband
|
+--- RF
之后又会学习 Driver 与 Firmware，把系统进一步展开。
再往后学习 Linux WiFi 子系统，把：
Linux Network / WiFi Subsystem
这个黑盒打开。
最终到了真正研究 RTL8812EU 源码时，我们才会开始把：
RTL8812EU Driver
展开成：
os_dep
core
hal
USB
TX
RX
Firmware Interface
Hardware Control
...
所以整个学习过程可以理解成：
第一步：
Application
↓
Linux
↓
Driver
↓
RTL8812EU
↓
Antenna
第二步：逐渐打开每一个黑盒
最终：
Application
↓
具体 Linux 接口
↓
具体 Driver 函数
↓
具体数据结构
↓
TX / RX Descriptor
↓
USB Transfer
↓
具体硬件模块
↓
MAC
↓
BB
↓
RF
↓
Antenna
这也是为什么现阶段不应该立即进入 RTL8812EU 源码。
如果没有前面的系统地图，直接看到大量：
rtw_*
hal_*
usb_*
xmit_*
recv_*
函数时，很容易陷入局部代码，而不知道这些函数究竟处于整个系统的什么位置。
4.4 本讲最终需要回答的问题
现在回到本讲最开始的问题：
一块 WiFi 网卡到底是什么？
从最简单的系统视角，可以回答：
WiFi 网卡是连接 Host 数字数据系统与无线通信系统的专用硬件设备。
对于 RTL8812EU：
Host
|
| USB
|
RTL8812EU
|
| 无线信号处理
|
Antenna
|
Wireless Medium
Host 中的软件通过 Driver 控制 RTL8812EU。
发送时：
Application Data
↓
Operating System
↓
WiFi Driver
↓
USB
↓
RTL8812EU
↓
Wireless Processing
↓
Antenna
↓
Electromagnetic Wave
接收时则执行相反的过程：
Electromagnetic Wave
↓
Antenna
↓
RTL8812EU
↓
USB
↓
WiFi Driver
↓
Operating System
↓
Application
因此，在现阶段可以把整个 RTL8812EU 系统浓缩成下面这张图：
数字数据世界
|
v
+------------------------------------------+
| Host |
| |
| Application |
| ↓ |
| Operating System |
| ↓ |
| WiFi Driver |
| |
+------------------------------------------+
|
USB
|
v
+------------------------------------------+
| |
| RTL8812EU |
| |
| 数字数据 → 无线信号 |
| 无线信号 → 数字数据 |
| |
+------------------------------------------+
|
Antenna
|
v
无线通信世界
这就是阶段 0 第 1 讲需要建立的最核心认知。
五、本讲知识总结
- WiFi 网卡连接 Host 的数字数据世界与无线通信世界。
- Host 与 WiFi 网卡是两个相对独立的系统，通过 USB、PCIe、SDIO 等接口通信。
- WiFi 网卡不是简单的“无线串口”，数据需要经过 WiFi 协议和无线物理层处理。
- Driver 是操作系统与具体 WiFi 硬件之间的软件桥梁。
- RTL8812EU 的基本链路为：Host → Driver → USB → RTL8812EU → Antenna。
六、下一讲
下一讲, 00-02_MAC_PHY_BB_RF的分层与关系
将进一步打开 RTL8812EU 这个黑盒，建立 MAC、PHY、BB、RF 的基本概念以及它们之间的关系。
浙公网安备 33010602011771号