第2章基础概念

基础概念：帧同步、曝光同步、时间戳同步、硬件触发模式

好，咱们正式开始聊多Camera同步。说实话，这个概念刚接触时容易懵。我当年第一次做双摄项目，就被同步问题折腾得够呛。你想想看，两个摄像头拍同一个场景，结果一帧早一帧晚，那画面根本没法用。

所以今天咱们先把四个核心概念理清楚。帧同步、曝光同步、时间戳同步、硬件触发模式。这四个词，你搞懂了，后面HAL层的设计思路就顺了。

帧同步，说白了就是让多个摄像头在同一时刻开始采集新的一帧。我习惯把它理解成「发令枪」。所有运动员（Camera）听到枪声同时起跑，这样每一帧的起点就对齐了。

为什么需要这个？举个例子。你做一个三摄的VR相机，左中右三个镜头。如果帧不同步，左镜头拍的是t0时刻的画面，右镜头拍的是t0+10ms的画面。拼接起来，物体边缘全是撕裂的。嗯，这就是典型的「帧不同步」问题。

关键点：帧同步只保证起始时刻对齐，不保证曝光时长一致。

我在项目中遇到过一种情况：两个Sensor的帧率都是30fps，但一个用卷帘快门，一个用全局快门。结果帧同步信号发下去，一个立即开始，另一个要等上一帧读完才响应。这就是「帧同步延迟」的坑。

曝光同步比帧同步更精细。它要求多个Camera的曝光时间窗口在时间轴上尽可能重叠。你想想看，如果两个摄像头曝光时刻错开了，拍运动物体时，一个拍到的是清晰的手，另一个拍到的是手的残影。这画面怎么融合？

我个人习惯把曝光同步分成两种：

我曾经在一个车载环视项目里踩过坑。四个鱼眼摄像头，用的都是卷帘快门。我一开始只做了帧同步，没管曝光同步。结果车子一颠簸，四个画面的运动模糊方向都不一样。后来加了曝光同步，让每帧的曝光窗口对齐到同一个时间区间，问题才解决。

注意：曝光同步对Sensor的驱动能力要求很高。有些低端Sensor不支持外部触发，或者触发后响应延迟不稳定。选型时一定要看Datasheet里的「Trigger Delay」参数。

时间戳同步，嗯，这个最容易理解。就是给每一帧图像盖个章，写上「这帧是什么时候拍的」。但难点在于：这个「什么时候」要统一。不能一个用Sensor内部时钟，一个用系统时钟，另一个用GPS时钟。

我建议的做法是：所有Camera共用同一个时间基准。比如都用系统启动后的单调时钟（CLOCK_MONOTONIC）。HAL层在收到帧中断时，立即读取当前时间戳，然后附在帧数据里往上抛。

这里有个细节要注意：帧中断到时间戳读取之间，有微秒级的延迟。我见过有人直接用中断服务函数里的时间，结果发现每次都比实际曝光结束时间晚了几十微秒。后来我改成在Sensor的VSYNC（帧同步信号）上升沿触发一个GPIO中断，在中断里用硬件定时器捕获时间戳。精度能到纳秒级。

小技巧：如果硬件不支持硬件时间戳捕获，可以在驱动里用ktime_get()函数。虽然精度不如硬件，但比用jiffies靠谱多了。

前面说的帧同步、曝光同步、时间戳同步，最终都要靠硬件触发来实现。硬件触发模式，就是通过物理信号（通常是GPIO或I2C命令）来精确控制每个Camera的启动时刻。

常见的硬件触发模式有这几种：

模式	描述	适用场景
外部触发模式	由主控发送一个脉冲信号，所有Sensor同时开始曝光	多摄同步、工业检测
主从模式	一个Sensor作为Master，输出同步信号给其他Slave	双摄、三摄手机
自由运行模式	每个Sensor独立运行，靠软件对齐时间戳	低精度场景、调试阶段

我个人最推荐外部触发模式。为什么呢？因为它简单、可靠。主控发一个脉冲，所有Sensor同时响应。延迟只取决于信号传输路径的物理长度和Sensor内部电路的响应时间。我在一个无人机项目里用过这种方案，四个摄像头同步误差控制在1微秒以内。

但要注意，外部触发模式对硬件布线有要求。信号线要等长，否则触发信号到达不同Sensor的时间就不一样。我曾经因为PCB走线没注意，导致两个Sensor的触发信号差了200多皮秒。虽然看起来不多，但在高速同步场景下，这个误差会被放大。

总结一下：

这四个概念，是后面所有同步方案的基础。你如果现在觉得有点绕，没关系。后面实战章节我会带着你一步步搭代码，到时候你就全明白了。

好，这一节就到这儿。下一节咱们聊聊HAL层里同步模块的整体架构设计。到时候我会把我在几个量产项目里用过的架构图拿出来，咱们一起拆解。