第四章 嵌入式基础与硬件知识：MCU/MPU选型与常用外设接口原理

在鸿蒙南向设备开发中，无论是驱动开发、硬件适配还是系统移植，都离不开对嵌入式硬件基础的深刻理解。OpenHarmony 的南向生态覆盖了从轻量系统（如 IoT 传感器、智能家居设备）到标准系统（如开发板、多媒体设备）的广泛硬件形态，其底层硬件核心通常为 MCU（微控制器）或 MPU（微处理器）。本章将系统回顾嵌入式系统的基础知识，重点聚焦于 MCU/MPU 的选型逻辑，以及 GPIO、UART、I2C、SPI、PWM、ADC 这六大最常用外设接口的工作原理、工程判断方法和实战注意事项。这些知识是后续编写 HDF（硬件驱动框架）驱动、配置设备树和进行鸿蒙系统移植的基石。

上图展示了嵌入式硬件知识的核心架构。在鸿蒙南向开发中，我们面对的硬件平台千差万别，但底层逻辑高度一致：CPU 内核负责计算，外设接口负责与物理世界交互，总线与时钟系统负责数据流转。理解这张图，就掌握了硬件适配的全局视角。接下来，我们将逐一深入每个关键模块。

4.1 MCU 与 MPU 的选型逻辑

核心原理：从架构差异看选型本质

MCU（Microcontroller Unit）与 MPU（Microprocessor Unit）的本质区别在于存储架构和设计目标。MCU 将 CPU、RAM、Flash、外设接口集成在单颗芯片上，强调高集成度、低功耗和实时性，典型代表是 STM32F4 系列、ESP32、Hi3861 等。MPU 则通常只包含 CPU 核心和必要的外设控制器，需要外部搭配 DDR、eMMC 等存储器件，强调高算力和复杂操作系统支持，典型代表是 RK3568、Hi3516、全志 V3s 等。

在 OpenHarmony 的生态中，这种差异直接决定了系统镜像的类型：轻量系统（如 IoT 场景）通常运行在 MCU 上，使用 LiteOS-M 内核；标准系统（如开发板）则运行在 MPU 上，使用 Linux 内核。选型时，我们需要从以下维度进行权衡：

判断方法：三步锁定目标平台

第一步，明确产品形态。如果是智能灯泡、温湿度传感器、智能门锁，直接锁定 MCU；如果是带屏幕的智能音箱、人脸识别门禁，则必须 MPU。第二步，评估软件生态需求。是否需要运行 OpenHarmony 的 JS 应用框架？是否需要支持 WiFi/BLE 协议栈的复杂组网？这些需求会直接推高对内存和算力的要求。第三步，验证外设资源。列出产品需要的所有外设接口，逐一核对候选芯片的可用引脚数和外设实例数量。例如，一个需要 3 路 UART、2 路 SPI、8 路 PWM 的电机控制板，选型时就要特别注意芯片的定时器资源是否足够。

案例拆解：智能家居网关的选型决策

假设我们要设计一款智能家居网关，需求如下：支持 Zigbee 协调器（需要 1 路 UART）、WiFi 连接（需要 SDIO 或 SPI 接口）、以太网（需要 RMII 接口）、驱动 3 个 LED 和 1 个蜂鸣器（需要 4 路 GPIO/PWM）、以及一个 OLED 显示屏（需要 I2C）。

初始方案考虑使用 ESP32（MCU），但评估后发现：ESP32 的 UART 资源虽然够用，但其以太网 MAC 需要外接 PHY 芯片，且 OpenHarmony 对 ESP32 的适配目前仅停留在轻量系统，无法满足后续可能增加的本地语音识别功能。最终方案改为瑞芯微 RK3308（MPU），虽然成本增加了约 15 元，但获得了：① 完整的 Linux 内核支持，可直接运行标准系统；② 丰富的 UART/SPI/I2C 控制器，无需引脚复用冲突；③ 充足的算力余量，为后续 OTA 升级和本地规则引擎预留了空间。复盘经验：选型不是选最强的，而是选“刚刚好且有余量”的，同时必须考虑 OpenHarmony 的软件适配成本。

常见误区与总结

• 误区一：认为 MCU 不能跑 OpenHarmony。实际上，OpenHarmony 轻量系统（LiteOS-M）就是为 MCU 设计的，Hi3861、STM32F407 等都能运行。
• 误区二：只关注 CPU 主频，忽略总线带宽和外设时钟树。有时 MCU 主频很高，但 APB 总线时钟配置不当，导致 UART 波特率误差过大。
• 误区三：忽略引脚复用冲突。很多 MCU 的多个外设共享同一引脚，选型时必须使用芯片厂商的 PinMux 工具进行交叉验证。

4.2 GPIO 与 UART 接口原理

核心原理：数字世界的“开关”与“对话”

GPIO（General Purpose Input/Output）是最基础的外设，本质是一个可编程的电子开关。通过配置寄存器，可以将引脚设置为输入模式（读取外部电平）或输出模式（驱动外部设备）。GPIO 的工程要点包括：上拉/下拉电阻配置、开漏/推挽输出模式选择、以及中断触发方式（上升沿、下降沿、双边沿、低电平）。在鸿蒙 HDF 驱动中，GPIO 操作通常通过 GpioRead/GpioWrite/GpioSetDir 等接口完成。

UART（Universal Asynchronous Receiver/Transmitter）是一种异步串行通信协议，只需两根信号线（TX 和 RX）即可实现全双工通信。其原理是：发送方将并行数据转换为串行比特流，按照约定的波特率逐位发送；接收方通过起始位和停止位进行帧同步。UART 的帧格式包括：1 位起始位（低电平）、5-8 位数据位、可选奇偶校验位、1-2 位停止位（高电平）。

判断方法与操作流程：GPIO 调试三板斧

当 GPIO 驱动异常时，按以下顺序排查：

1. 检查引脚复用：使用 cat /sys/kernel/debug/pinctrl/pinctrl-handles 查看当前引脚是否被其他外设占用。
2. 验证电气特性：用万用表测量引脚电压。输出模式下，高电平应接近 VDD，低电平应接近 GND；输入模式下，悬空引脚电平不确定，必须依赖外部上拉/下拉。
3. 确认寄存器配置：在 HDF 驱动中打印 GPIO 控制器的寄存器值，核对方向寄存器（DIR）和数据寄存器（DATA）是否按预期写入。

对于 UART，调试时首先使用逻辑分析仪抓取波形，确认 TX 引脚在空闲时保持高电平，发送数据时出现正确的起始位（低电平跳变）。然后检查波特率误差，公式为：误差 = |实际波特率 - 理论波特率| / 理论波特率 × 100%，误差超过 3% 时通信将不稳定。

案例拆解：UART 通信乱码的排障过程

某设备使用 Hi3861 的 UART1 与 GPS 模块通信，波特率设置为 9600。现象是：GPS 数据偶尔出现乱码，且集中在设备启动后 1-2 分钟内。初步分析认为可能是电源干扰，但用示波器测量 VCC 纹波仅 50mV，排除电源问题。进一步检查发现，Hi3861 的 UART1 默认使用 40MHz 晶振作为时钟源，而 GPS 模块要求 9600 波特率，实际分频后波特率误差达到 2.8%，接近临界值。解决方案：将 UART1 的时钟源切换为 32MHz 内部 RC 振荡器，重新计算分频系数后，误差降至 0.2%，乱码消失。复盘经验：UART 波特率误差是嵌入式开发中最隐蔽的“软故障”之一，尤其在低功耗模式下，时钟源切换后必须重新校验波特率。

4.3 I2C 与 SPI 同步通信接口

核心原理：两种主流的板级总线

I2C（Inter-Integrated Circuit）是一种两线制（SCL 时钟线 + SDA 数据线）的半双工同步通信协议。其核心机制是：主设备通过 SCL 产生时钟，SDA 在时钟高电平期间保持稳定（数据有效），在时钟低电平期间变化。I2C 支持多主多从，通过 7 位或 10 位地址寻址，标准模式 100kbps，快速模式 400kbps。I2C 的电气特性要求 SDA 和 SCL 均为开漏输出，必须外接上拉电阻（典型值 4.7kΩ）。

SPI（Serial Peripheral Interface）是一种四线制（SCLK、MOSI、MISO、CS）的全双工同步通信协议。SPI 没有地址概念，通过片选信号 CS 选择从设备。SPI 的时钟极性（CPOL）和相位（CPHA）有四种组合（Mode 0-3），主设备和从设备必须配置一致。SPI 的传输速率远高于 I2C，典型可达 10-50Mbps，适合高速数据采集（如传感器、Flash 存储）。

判断方法与操作流程：I2C 设备地址冲突排查

在 I2C 总线挂载多个设备时，地址冲突是常见问题。排查流程：

1. 使用 i2cdetect -y 0 扫描总线，查看所有应答的设备地址。
2. 对比芯片手册中的设备地址，注意 7 位地址与 8 位地址的换算（左移一位）。
3. 如果发现两个设备地址相同，检查硬件上是否有地址选择引脚（如 A0/A1/A2），通过硬件拉高/拉低来修改地址。

对于 SPI，调试重点是确认时序模式。使用示波器同时抓取 SCLK 和 MOSI 信号，在 SCLK 的第一个边沿（上升沿或下降沿）检查 MOSI 数据是否稳定。如果数据在错误的边沿被采样，就会出现“读到的数据全是 0xFF”或“数据错位”的现象。

案例拆解：SPI Flash 驱动适配中的时序问题

在将一款国产 SPI NOR Flash（型号 GD25Q64）适配到 OpenHarmony 标准系统时，发现读取 JEDEC ID 失败，返回 0x00。硬件连接无误，CS 片选正常。使用逻辑分析仪抓取波形后发现：主设备配置的 SPI Mode 为 Mode 0（CPOL=0, CPHA=0），但 GD25Q64 的数据手册要求 Mode 0 或 Mode 3 均可。进一步分析发现，问题出在时钟频率上——主设备 SPI 时钟配置为 50MHz，而 GD25Q64 的最高支持频率为 120MHz，理论上没问题。但检查 PCB 走线发现，SPI 信号线长度超过 5cm，且未做阻抗匹配，导致高速信号反射。将 SPI 时钟降频至 20MHz 后，ID 读取正常。复盘经验：SPI 高速通信时，PCB 布局和信号完整性比软件配置更关键。在鸿蒙驱动开发中，如果遇到 SPI 偶发错误，优先尝试降低时钟频率验证。

常见误区与总结

• 误区一：I2C 上拉电阻越小越好。实际上，上拉电阻过小会导致灌电流过大，损坏开漏 MOS 管；过大则上升沿变缓，限制通信速率。3.3V 系统常用 2.2kΩ-4.7kΩ。
• 误区二：SPI 的 CS 片选可以一直拉低。对于大多数从设备，CS 必须在每次传输前拉低、传输后拉高，否则设备无法正确识别帧边界。
• 误区三：忽略 I2C 总线电容限制。I2C 规范规定总线电容不得超过 400pF，挂载设备过多或走线过长时，需要增加总线缓冲器。

4.4 PWM 与 ADC 模拟接口

核心原理：数字控制模拟世界

PWM（Pulse Width Modulation）是一种利用数字方波模拟模拟电平的技术。通过调整方波的占空比（高电平时间占整个周期的比例），可以控制负载的平均功率。PWM 的两个关键参数是：频率（决定控制的响应速度）和占空比（决定输出大小）。在电机控制中，PWM 频率通常为 10kHz-20kHz（避开人耳可听范围）；在 LED 调光中，频率需大于 100Hz 以避免闪烁。PWM 的实现通常依赖硬件定时器，而非软件延时，以保证波形精度。

ADC（Analog-to-Digital Converter）将连续变化的模拟电压转换为离散的数字值。ADC 的核心指标包括：分辨率（如 12 位表示 0-4095）、采样率（每秒采样次数）、参考电压（Vref，决定量程）。常见的 ADC 类型有逐次逼近型（SAR）和 Sigma-Delta 型。在鸿蒙驱动中，ADC 通常通过 HDF 的 AdcRead 接口读取原始值，然后转换为实际电压：电压 = ADC值 / 4095 × Vref。

判断方法与操作流程：PWM 波形验证

当 PWM 输出异常时，使用示波器测量引脚波形，检查以下三点：

1. 频率是否正确：测量两个上升沿之间的时间间隔，计算实际频率。
2. 占空比是否精确：测量高电平时间与周期的比值，与配置值对比。
3. 波形是否干净：观察上升沿和下降沿是否有过冲或振铃，这会影响电机驱动的 EMI 性能。

对于 ADC，调试时使用信号发生器输入已知电压（如 1.5V），读取 ADC 原始值并反算电压，验证线性度。如果读数跳变过大，检查参考电压 Vref 是否稳定，以及 ADC 引脚是否有滤波电容（典型 100nF）。

案例拆解：电池电量检测的 ADC 校准

某鸿蒙 IoT 设备使用 12 位 ADC 检测锂电池电压，量程 0-3.3V，通过电阻分压（100kΩ + 100kΩ）将电池电压（最高 4.2V）分压至 ADC 输入范围。初始实现时，直接读取 ADC 值并乘以比例系数，发现电量显示误差高达 15%。分析原因：① 电阻分压存在 1% 精度误差；② ADC 的参考电压 Vref 实际为 3.28V 而非理想 3.3V；③ 电池在负载变化时存在内阻压降。解决方案：① 使用 0.1% 精度电阻；② 在系统校准时，用万用表实测 Vref 并写入校准参数；③ 在软件中增加滑动平均滤波，采样 10 次取平均值。优化后，电量检测误差控制在 3% 以内。复盘经验：ADC 的精度不仅取决于 ADC 本身，更取决于参考电压和前端电路。在鸿蒙驱动中，建议将校准参数存储在 NVS 或 KV 存储中，便于量产时逐台校准。

// 在 HDF 驱动中读取 ADC 通道 0 的原始值
int32_t ret;
uint32_t value = 0;
struct AdcDevice *adcDev = AdcGetDevice(0);
if (adcDev == NULL) {
    HDF_LOGE("Failed to get ADC device");
    return -1;
}
ret = adcDev->ops->Read(adcDev, 0, &value);
if (ret != HDF_SUCCESS) {
    HDF_LOGE("ADC read failed, ret=%d", ret);
    return ret;
}
// 转换为电压值，假设 Vref=3.3V，12位分辨率
float voltage = (float)value * 3.3f / 4095.0f;
HDF_LOGI("ADC value=%u, voltage=%.2fV", value, voltage);

常见误区与总结

• 误区一：PWM 频率越高越好。频率过高会导致开关损耗增加，且驱动电路（如 MOS 管栅极驱动）可能无法响应。
• 误区二：ADC 采样时间越短越好。采样时间过短会导致采样电容未充满，引入转换误差。STM32 的 ADC 采样时间通常配置为 1.5-239.5 个时钟周期。
• 误区三：忽略 PWM 和 ADC 的共地问题。在电机控制中，PWM 驱动电路和 ADC 采样电路必须共地，否则会产生共模干扰。

4.5 综合实战：从硬件原理到鸿蒙驱动的映射

理解硬件原理的最终目的是为了编写正确的鸿蒙驱动。在 HDF（Hardware Driver Foundation）框架中，每个外设驱动都需要实现对应的操作接口。例如，GPIO 驱动需要实现 GpioRead/GpioWrite，UART 驱动需要实现 UartRead/UartWrite，I2C 驱动需要实现 I2cTransfer。这些接口的底层实现，本质上就是对本章所述硬件原理的代码化。

在编写驱动时，建议遵循以下流程：

1. 阅读芯片手册：确认外设的寄存器基地址、时钟使能位、引脚复用配置。
2. 参考官方 SDK：大多数芯片厂商提供裸机或 RTOS 的驱动代码，可将其逻辑移植到 HDF 框架。
3. 编写 HDF 驱动模型：定义驱动私有数据、绑定（Bind）、初始化（Init）和释放（Release）函数。
4. 配置设备树或 HCS：在鸿蒙的 HCS（Hardware Configuration Source）文件中描述硬件资源，如 GPIO 引脚号、UART 波特率、I2C 地址等。
5. 验证与调试：使用 hdc shell 进入系统，通过 cat /dev/xxx 或编写测试应用验证驱动功能。

本章内容为后续的鸿蒙驱动开发奠定了坚实的硬件基础。无论是 GPIO 的点灯操作，还是复杂传感器的 I2C 数据读取，其本质都是对本章所述接口原理的工程化应用。在实际项目中，建议开发者建立自己的“硬件知识速查表”，将常用芯片的引脚复用表、外设时钟配置、典型电路设计参数记录下来，这将极大提升开发效率。