第三章 RT-Thread设备驱动框架：I/O设备模型、PIN设备、UART设备、I2C/SPI设备、ADC/DAC设备

做汽车电子嵌入式开发，打交道最多的就是各种外设。传感器要读，执行器要控，通信接口要调。RT-Thread 这套设备驱动框架，说白了就是帮我们把底层硬件操作封装好，让你写应用层代码时不用再跟寄存器死磕。

我个人习惯，拿到一个新板子，第一件事就是把设备驱动框架跑通。框架顺了，后面开发就像搭积木。今天咱们就聊聊 RT-Thread 里最常用的几个设备模型：I/O 设备、PIN、UART、I2C/SPI、ADC/DAC。每个我都会结合项目经验，讲讲怎么用、坑在哪。

3.1 I/O 设备模型：一切皆设备

RT-Thread 的 I/O 设备模型，核心思想就四个字——统一接口。不管你接的是温度传感器、电机驱动还是显示屏，操作方式都一样：open、read、write、control、close。

这个设计我在做 BMS 项目时体会特别深。当时要同时管理十几个传感器，每个传感器驱动都不一样。用 RT-Thread 的设备模型后，所有传感器都注册成设备，上层逻辑完全不用关心底层是 I2C 还是 SPI。代码量直接砍掉三分之一。

设备模型核心结构：

  • 设备对象：rt_device，包含设备名、类型、操作函数集
  • 操作函数集：init、open、close、read、write、control
  • 设备类型：字符设备、块设备、网络设备等

注册一个设备其实很简单。你写一个驱动，实现那几个操作函数，然后调用 rt_device_register() 注册到内核。应用层就能通过 rt_device_find() 找到它，直接读写。

// 设备注册示例
static rt_err_t my_drv_init(rt_device_t dev) {
    // 初始化硬件
    return RT_EOK;
}

static rt_size_t my_drv_read(rt_device_t dev, rt_off_t pos, void *buffer, rt_size_t size) {
    // 读取数据
    return size;
}

static struct rt_device my_device = {
    .type = RT_Device_Class_Char,
    .init = my_drv_init,
    .read = my_drv_read,
    // ... 其他函数
};

// 注册到内核
rt_device_register(&my_device, "my_dev", RT_DEVICE_FLAG_RDWR);

我的经验：设备名尽量用有意义的字符串，比如 "temp_sensor"、"motor_drv"。别用 "dev0"、"dev1" 这种，项目大了根本记不住哪个是哪个。我曾经在一个项目里吃过这个亏，调试时满屏找设备名，浪费了半天。

3.2 PIN 设备：最基础的控制

PIN 设备就是 GPIO 控制。汽车电子里，PIN 设备用得特别多——控制继电器、读取按键状态、驱动 LED 指示灯。RT-Thread 的 PIN 设备框架把 GPIO 操作抽象成了几个简单函数。

你想想看，以前操作 GPIO 要查数据手册，找寄存器地址，配置模式。现在呢？

// PIN 设备操作示例
#define LED_PIN     GET_PIN(C, 13)  // PC13
#define KEY_PIN     GET_PIN(A, 0)   // PA0

// 设置引脚模式
rt_pin_mode(LED_PIN, PIN_MODE_OUTPUT);
rt_pin_mode(KEY_PIN, PIN_MODE_INPUT_PULLUP);

// 输出高低电平
rt_pin_write(LED_PIN, PIN_HIGH);
rt_pin_write(LED_PIN, PIN_LOW);

// 读取输入
rt_uint8_t value = rt_pin_read(KEY_PIN);

嗯，这里要注意。GET_PIN 这个宏是 RT-Thread 帮你算引脚编号的。不同芯片的引脚编号规则不一样，但用这个宏就统一了。我在移植代码时特别喜欢这个设计，换芯片只要改引脚定义，逻辑代码完全不用动。

避坑指南：我曾经在汽车电子项目里遇到一个问题——用 rt_pin_write 控制继电器，结果继电器频繁抖动。后来发现是中断里调用了 PIN 操作，导致时序错乱。记住，PIN 操作不是线程安全的，多线程访问要加锁。另外，汽车电子的 GPIO 驱动能力有限，驱动继电器一定要加三极管或光耦，别直接推。

3.3 UART 设备：通信的老大哥

UART 在汽车电子里无处不在。诊断用的 K线、CAN 的调试口、GPS 模块、蓝牙模块，很多都用 UART。RT-Thread 的 UART 设备框架支持中断、DMA、轮询三种模式。

我个人建议，汽车电子项目里优先用 DMA 模式。为什么？因为 UART 接收数据时，如果 CPU 一个一个字节去读，很容易丢数据。DMA 模式让 DMA 控制器帮你搬数据，CPU 可以干别的事。

// UART 设备使用示例
rt_device_t uart_dev = rt_device_find("uart2");
struct serial_configure config = RT_SERIAL_CONFIG_DEFAULT;

// 配置波特率、数据位、停止位、校验位
config.baud_rate = BAUD_RATE_115200;
config.data_bits = DATA_BITS_8;
config.stop_bits = STOP_BITS_1;
config.parity = PARITY_NONE;

rt_device_control(uart_dev, RT_DEVICE_CTRL_CONFIG, &config);
rt_device_open(uart_dev, RT_DEVICE_FLAG_DMA_RX | RT_DEVICE_FLAG_DMA_TX);

// 发送数据
rt_device_write(uart_dev, 0, "Hello RT-Thread", 15);

// 接收数据（使用信号量等待）
rt_device_set_rx_indicate(uart_dev, uart_rx_ind);
static rt_err_t uart_rx_ind(rt_device_t dev, rt_size_t size) {
    rt_sem_release(&rx_sem);
    return RT_EOK;
}

关键点：UART 接收一定要用中断或 DMA，配合信号量或消息队列。千万别用轮询，CPU 会被占死。我在做车载 T-Box 项目时，GPS 数据就是通过 UART DMA 接收的，每秒 10Hz 的数据流，CPU 占用率不到 2%。

3.4 I2C/SPI 设备：传感器与执行器的桥梁

汽车电子里，I2C 和 SPI 是传感器和执行器的主要通信方式。温度传感器、加速度计、陀螺仪、EEPROM，基本都是 I2C 或 SPI 接口。RT-Thread 对这两种总线都提供了完善的驱动框架。

I2C 的特点是线少（两根线），速度适中，适合短距离通信。SPI 速度快，全双工，适合大数据量传输。选哪个？看场景。传感器采集一般用 I2C，显示驱动、Flash 存储用 SPI。

// I2C 设备操作示例
struct rt_i2c_bus_device *i2c_bus;
struct rt_i2c_msg msgs[2];
rt_uint8_t addr = 0x50;  // 设备地址
rt_uint8_t reg = 0x00;   // 寄存器地址
rt_uint8_t data[4];

i2c_bus = (struct rt_i2c_bus_device *)rt_device_find("i2c1");

// 写寄存器
msgs[0].addr  = addr;
msgs[0].flags = RT_I2C_WR;
msgs[0].len   = 1;
msgs[0].buf   = ®

msgs[1].addr  = addr;
msgs[1].flags = RT_I2C_WR | RT_I2C_NO_START;
msgs[1].len   = 4;
msgs[1].buf   = data;

rt_i2c_transfer(i2c_bus, msgs, 2);
// SPI 设备操作示例
struct rt_spi_device *spi_dev;
rt_uint8_t tx_buf[10] = {0x01, 0x02, 0x03};
rt_uint8_t rx_buf[10];

spi_dev = (struct rt_spi_device *)rt_device_find("spi10");

// 配置 SPI 模式
struct rt_spi_configuration cfg;
cfg.data_width = 8;
cfg.mode = RT_SPI_MODE_0 | RT_SPI_MASTER;
cfg.max_hz = 1000000;  // 1MHz
rt_spi_configure(spi_dev, &cfg);

// 发送接收
rt_spi_transfer(spi_dev, tx_buf, rx_buf, 10);

我的经验：I2C 通信最容易出问题的是时序。汽车电子环境复杂，线束长，干扰大。我建议 I2C 速率别超过 100kHz，上拉电阻选 4.7kΩ 左右。SPI 的话，注意片选信号，多设备共用总线时，片选一定要独立控制。我曾经遇到一个 bug，两个 SPI 设备共用一个片选，结果数据互相串扰，查了两天才发现。

3.5 ADC/DAC 设备：模拟世界的窗口

汽车电子离不开模拟信号。电池电压检测、温度采集、油门踏板位置，都是 ADC 的活。DAC 则用于输出模拟信号，比如控制电机转速、调节灯光亮度。RT-Thread 的 ADC/DAC 设备框架让这些操作变得特别简单。

说白了，ADC 就是把电压值转成数字量。你只要告诉它要读哪个通道，它返回给你一个数值。DAC 反过来，你给一个数值，它输出对应的电压。

// ADC 设备操作示例
rt_adc_device_t adc_dev;
rt_uint32_t value;
rt_uint32_t voltage;

adc_dev = (rt_adc_device_t)rt_device_find("adc1");

// 使能通道
rt_adc_enable(adc_dev, 3);  // 通道3

// 读取原始值
value = rt_adc_read(adc_dev, 3);

// 转换为电压（假设参考电压3.3V，12位ADC）
voltage = value * 3300 / 4096;  // 单位mV

rt_adc_disable(adc_dev, 3);
// DAC 设备操作示例
rt_dac_device_t dac_dev;

dac_dev = (rt_dac_device_t)rt_device_find("dac1");

// 使能通道
rt_dac_enable(dac_dev, 1);  // 通道1

// 输出模拟值（12位，输出2.5V）
rt_dac_write(dac_dev, 1, 3100);  // 3100/4096 * 3.3V ≈ 2.5V

// 使用完关闭
// rt_dac_disable(dac_dev, 1);

避坑指南：ADC 采样有个大坑——参考电压。很多开发板用 VDD 做参考电压，但 VDD 本身可能不稳定。汽车电子的电池电压波动很大，从 9V 到 16V 都有可能。我建议用外部精密参考电压源，比如 TL431。另外，ADC 采样结果要做滤波，简单移动平均或中值滤波都行。我曾经在项目里没做滤波，结果采集到的电压值跳来跳去，导致电池电量估算完全不准。

3.6 设备驱动框架在汽车电子中的实战要点

聊了这么多，最后总结几个实战要点。这些是我在多个汽车电子项目里踩坑踩出来的经验。

设备类型 常见应用 关键注意事项
PIN 继电器控制、按键检测、LED指示 驱动能力不足时加缓冲器；中断中避免长时间操作
UART 诊断通信、GPS、蓝牙 优先用DMA；接收用信号量或消息队列；注意波特率误差
I2C 温度传感器、EEPROM、加速度计 速率别太高；上拉电阻要合适；注意总线电容
SPI Flash存储、显示驱动、ADC 片选独立控制；注意时钟极性和相位；高速时考虑信号完整性
ADC 电压检测、温度采集、位置传感 参考电压要稳定；采样结果做滤波；注意采样时间
DAC 电机控制、模拟输出 输出阻抗匹配；注意负载能力；考虑输出纹波

嗯，设备驱动框架这块内容不少，但核心就一句话——RT-Thread 帮你把硬件操作封装好了，你只管用。但用之前一定要理解底层原理，不然出了问题都不知道怎么查。

我个人建议，学完理论后，找个开发板把每个设备都跑一遍。PIN 控制个 LED，UART 打印个 "Hello"，I2C 读个温度传感器，ADC 测个电压。跑通了，你就真正掌握了。下次咱们聊线程管理和同步，那才是 RT-Thread 的精髓所在。

← 上一章 📖 返回目录 下一章 →