第1章 PX4驱动架构概览

1. PX4驱动架构概览：从uORB到设备文件

大家好，我是你们的PX4驱动开发讲师。今天咱们聊聊PX4驱动架构的底层逻辑。说实话，我刚接触PX4时也被它的分层设计搞晕过——uORB是什么？驱动怎么启动的？设备文件又是干嘛的？别急，我一个一个给你拆开讲。

核心要点：PX4驱动架构 = uORB通信总线 + 驱动生命周期管理 + 设备文件抽象层。这三者缺一不可。

1.1 uORB：驱动之间的“消息快递站”

uORB，全称是micro Object Request Broker。说白了，它就是PX4内部的一个轻量级发布-订阅消息总线。驱动之间不直接调用函数，而是通过uORB来交换数据。

我举个例子你就明白了：

传感器驱动（比如IMU）采集到数据后，通过uORB发布一个sensor_accel消息
姿态估计模块订阅了这个消息，拿到数据做融合计算
控制模块再订阅姿态结果，输出控制指令

你看，每个模块只关心自己订阅了什么、发布了什么，完全解耦。我在项目中遇到过一个问题：某个传感器驱动崩溃了，整个飞控都卡死。后来发现是驱动直接调用了其他模块的函数，绕过了uORB。嗯，这就是不遵守规则的代价。

我的习惯：写新驱动时，先定义好uORB消息结构体。消息字段宁多勿少，因为后期加字段要改所有订阅者，很麻烦。

uORB的核心API就几个：

// 发布消息
orb_publish(orb_id, publisher_handle, &data);

// 订阅消息
int sub_fd = orb_subscribe(orb_id);

// 读取最新数据
orb_copy(orb_id, sub_fd, &data);

// 检查是否有新数据
orb_check(sub_fd, &updated);

这里有个坑：orb_check只是检查是否有新数据发布，但不会阻塞。如果你需要等待数据，得自己加轮询或者用poll()。我曾经在写GPS驱动时忘了这茬，结果主循环空转吃掉了30%的CPU。后来加了个poll()，CPU占用直接降到5%。

1.2 驱动生命周期：probe → init → exit

每个PX4驱动都有固定的生命周期。你想想看，一个设备从插入到拔出，系统要做什么？

probe（探测）：检查硬件是否存在，读取设备ID，验证通信是否正常
init（初始化）：配置寄存器、分配内存、注册uORB发布者、创建设备文件
exit（退出）：释放资源、关闭设备文件、取消uORB订阅

我画了个流程图，帮你理解这个生命周期：

实际代码中，probe和init通常写在一起：

class MySensor : public ModuleBase<MySensor>
{
public:
    MySensor() : _device(nullptr), _publisher(nullptr) {}
    
    // probe阶段：检查硬件
    int probe() {
        // 尝试打开I2C设备
        _device = px4_i2c_bus_attach(1, 0x76);
        if (!_device) return -1;
        
        // 读取芯片ID
        uint8_t id = 0;
        _device->read(REG_CHIP_ID, &id, 1);
        if (id != EXPECTED_ID) return -1;
        
        return OK;
    }
    
    // init阶段：初始化
    int init() {
        // 配置传感器
        _device->write(REG_CONFIG, 0x00);
        
        // 注册uORB发布者
        _publisher = orb_advertise(ORB_ID(sensor_accel), &_data);
        
        // 创建设备文件
        register_class_devname("my_sensor");
        
        return OK;
    }
};

注意：probe失败后，init不会被执行。我曾经在调试一个气压计时，probe里忘了检查通信超时，结果init时寄存器写不进去，整个系统hang住。所以probe一定要做充分的硬件验证。

1.3 设备文件与Fd操作：用户态访问驱动的桥梁

PX4里，每个驱动都会在/dev/下创建一个设备文件。比如/dev/accel0、/dev/gyro0。用户态程序通过标准的文件操作（open、read、write、ioctl、close）来和驱动交互。

为什么这么做？说白了，就是让驱动看起来像一个普通文件。你想想看，用read()读传感器数据和用fread()读文本文件，API完全一样，多方便。

设备文件操作的核心是file_operations结构体：

static struct file_operations my_sensor_fops = {
    .open = my_sensor_open,
    .close = my_sensor_close,
    .read = my_sensor_read,
    .write = my_sensor_write,
    .ioctl = my_sensor_ioctl,
};

// 注册设备
register_driver("/dev/my_sensor", &my_sensor_fops, 0666, &private_data);

这里我重点说一下ioctl。它是控制命令的入口，比如设置采样率、校准传感器等。我在项目中遇到过一个问题：用户态程序调用ioctl设置采样率，但驱动里没做参数校验，传了个非法值进去，结果传感器直接罢工。从那以后，我写ioctl一定会做边界检查：

static int my_sensor_ioctl(struct file *filp, int cmd, unsigned long arg)
{
    switch (cmd) {
    case SET_SAMPLE_RATE:
        uint32_t rate = (uint32_t)arg;
        // 边界检查，防止非法值
        if (rate < MIN_RATE || rate > MAX_RATE) {
            return -EINVAL;
        }
        // 设置寄存器
        return _set_sample_rate(rate);
        
    case GET_SENSOR_DATA:
        // 返回最新数据
        return _copy_to_user((void *)arg, &_data, sizeof(_data));
        
    default:
        return -ENOTTY;  // 不认识这个命令
    }
}

我的习惯：每个ioctl命令都加上参数校验，哪怕你觉得用户不会传错。因为飞控系统里，一个非法参数可能导致炸机。安全第一。

最后，咱们用一张表总结一下设备文件操作和uORB的关系：

特性	设备文件 (Fd)	uORB
通信方向	用户态 ↔ 内核态	驱动 ↔ 驱动 / 模块 ↔ 模块
数据模型	字节流 / 控制命令	结构化消息
典型用途	参数配置、固件升级、调试	传感器数据、状态信息、控制指令
性能	低（每次调用有上下文切换）	高（内存拷贝，无系统调用）
使用场景	低频控制操作	高频数据流（如IMU 1kHz）

嗯，看到这里你应该明白了：设备文件适合做控制，uORB适合传数据。两者配合使用，才能写出高效稳定的驱动。

好了，这一章的内容就到这里。记住这三个核心概念：uORB是消息总线，生命周期是驱动的骨架，设备文件是用户态的接口。下一章咱们会深入uORB的源码实现，看看它到底是怎么做到高性能的。

📚 课程目录

1. PX4驱动架构概览：从uORB到设备文件

1.1 uORB：驱动之间的“消息快递站”

1.2 驱动生命周期：probe → init → exit

1.3 设备文件与Fd操作：用户态访问驱动的桥梁