第1章 PX4驱动框架概览

1、PX4驱动框架概览：uORB消息机制、设备框架、驱动生命周期

大家好，我是你们的PX4驱动开发讲师。今天咱们聊聊PX4驱动框架的骨架——uORB、设备框架和驱动生命周期。这三个东西，说白了就是驱动开发的“三件套”。你搞懂了它们，写驱动就像搭积木一样顺手。

我记得刚接触PX4那会儿，第一反应是“这玩意儿怎么这么绕”？后来才发现，其实它的设计思路非常清晰。咱们一个一个来拆解。

1.1 uORB消息机制：驱动之间的“快递员”

uORB，全称是micro Object Request Broker。名字挺唬人，其实就是一个轻量级的发布-订阅消息总线。你可以把它想象成一个快递中转站——各个模块（传感器、控制器、执行器）只管往站里扔包裹（发布消息），或者从站里取包裹（订阅消息）。

为什么需要uORB？

你想想看，一个飞控系统里，传感器数据要传给姿态估计，姿态估计要传给控制器，控制器要传给电机。如果每个模块都直接调用对方的API，那代码就乱成一锅粥了。uORB把这种耦合解开了——模块之间只认消息，不认人。

核心概念：

话题（Topic）：消息的唯一标识，比如 sensor_accel、vehicle_attitude。
发布者（Publisher）：往话题里写数据的模块。
订阅者（Subscriber）：从话题里读数据的模块。
消息结构（Message Structure）：数据格式，定义在 msg/ 目录下的 .msg 文件中。

举个例子，加速度计驱动发布 sensor_accel 话题，姿态估计模块订阅它。驱动只管把原始数据扔进去，姿态估计只管拿数据算角度。两者互不干扰。

uORB的API长什么样？

我习惯用C++写驱动，但uORB的C接口也很常用。下面是一个典型的发布流程：

// 发布者示例
#include <uORB/uORB.h>
#include <uORB/topics/sensor_accel.h>

// 声明话题
struct sensor_accel_s accel_data;
orb_advert_t accel_pub;

// 初始化数据
accel_data.timestamp = hrt_absolute_time();
accel_data.x = 0.1f;
accel_data.y = -0.2f;
accel_data.z = 9.8f;

// 发布话题
accel_pub = orb_advertise(ORB_ID(sensor_accel), &accel_data);
orb_publish(ORB_ID(sensor_accel), accel_pub, &accel_data);

订阅端就更简单了：

// 订阅者示例
int accel_sub = orb_subscribe(ORB_ID(sensor_accel));
struct sensor_accel_s accel_data;

// 轮询读取
orb_copy(ORB_ID(sensor_accel), accel_sub, &accel_data);

我的小技巧： 调试时可以用 uorb top 命令查看所有话题的发布频率和数据量。我曾经靠这个命令抓到一个驱动发布频率不稳定的bug——原来是中断优先级没配好。

1.2 设备框架：驱动与硬件的“适配器”

PX4的设备框架，说白了就是一套标准化的硬件访问接口。它把I2C、SPI、UART、GPIO这些外设操作封装成了统一的API。你写驱动时，不用关心底层是I2C还是SPI，只管调用 dev::Device 或 dev::CDev 的接口就行。

设备框架的层次结构：

总线层（Bus Layer）：管理I2C、SPI等总线，负责设备枚举和通信。
设备层（Device Layer）：提供 read()、write()、ioctl() 等标准接口。
驱动层（Driver Layer）：你写的具体传感器或执行器驱动，继承自设备层。

我画了一张图，帮你理解这个层次关系：

你看，从应用层到硬件，中间隔了两层抽象。uORB负责模块间通信，设备框架负责硬件访问。这样设计的好处是——换一个传感器，你只需要重写驱动层，其他代码纹丝不动。

设备框架的核心类：

类名	用途	常用方法
`dev::Device`	基础设备抽象	`init()`, `read()`, `write()`
`dev::CDev`	字符设备，支持文件操作	`open()`, `close()`, `ioctl()`
`dev::I2C`	I2C总线设备	`transfer()`, `set_address()`
`dev::SPI`	SPI总线设备	`transfer()`, `set_mode()`

注意： 设备框架的 ioctl() 函数是驱动与用户空间交互的“万能钥匙”。我曾经犯过一个错——在 ioctl() 里做了耗时操作，导致整个系统卡死。记住，ioctl() 要快，别在里面做延时或等待。

1.3 驱动生命周期：从出生到死亡

每个PX4驱动都有固定的生命周期。说白了，就是“初始化→运行→销毁”这三个阶段。但PX4把它分得更细：

探测（Probe）：检查硬件是否存在，读取ID寄存器。
初始化（Init）：配置寄存器、设置采样率、分配内存。
注册（Register）：将驱动注册到设备框架，创建uORB话题。
运行（Run）：循环采集数据或执行控制指令。
停止（Stop）：关闭中断、停止任务。
销毁（Destroy）：释放资源、注销话题。

一个典型的驱动启动流程：

// 伪代码：加速度计驱动启动
int accel_main(int argc, char *argv[])
{
    // 1. 探测设备
    if (!probe_device()) {
        PX4_ERR("设备未找到");
        return -1;
    }
    
    // 2. 初始化硬件
    init_device();
    
    // 3. 注册到设备框架
    dev::CDev *dev = new AccelDriver();
    dev->init();
    
    // 4. 创建uORB话题
    orb_advert_t pub = orb_advertise(ORB_ID(sensor_accel), &data);
    
    // 5. 进入运行循环
    while (!should_exit) {
        read_sensor_data();
        orb_publish(ORB_ID(sensor_accel), pub, &data);
        usleep(10000); // 100Hz
    }
    
    // 6. 停止和销毁
    stop_device();
    delete dev;
    return 0;
}

避坑指南： 我曾经在 probe() 阶段用了 usleep() 等待传感器上电稳定。结果系统启动时，这个延时阻塞了调度器，导致其他驱动初始化失败。后来我改用 hrt_absolute_time() 做超时检测，问题就解决了。

驱动的状态机：

每个驱动内部其实都有一个隐式的状态机。我习惯用枚举来管理：

enum DriverState {
    STATE_UNINITIALIZED,  // 未初始化
    STATE_PROBING,        // 探测中
    STATE_INITIALIZED,    // 已初始化
    STATE_RUNNING,        // 运行中
    STATE_STOPPED,        // 已停止
    STATE_ERROR           // 错误状态
};

为什么要有状态机？因为驱动可能会遇到各种异常——传感器掉线、I2C通信失败、内存不足。有了状态机，你就能优雅地处理这些情况，而不是直接崩溃。

举个例子，如果传感器连续5次读取失败，我会把状态切到 STATE_ERROR，然后尝试重新初始化。而不是傻傻地一直重试。

好了，这一章的内容就到这里。uORB、设备框架、生命周期，这三个概念是PX4驱动开发的基石。你理解了它们，后面写具体驱动时就会轻松很多。

记住，驱动开发不是写代码，而是管理状态和资源。把生命周期管好了，你的驱动就稳了。

📚 课程目录

1、PX4驱动框架概览：uORB消息机制、设备框架、驱动生命周期

1.1 uORB消息机制：驱动之间的“快递员”

1.2 设备框架：驱动与硬件的“适配器”

1.3 驱动生命周期：从出生到死亡