第一讲：多Camera系统概述与HAL层同步的必要性

大家好，我是你们这门课的主讲。在嵌入式领域摸爬滚打了十几年，我见过太多多Camera系统翻车的案例。今天咱们就从最基础的问题聊起——为什么需要同步？HAL层到底扮演什么角色？

1.1 多Camera系统长什么样？

先说说多Camera系统的典型形态。你想想看，现在的手机至少三颗摄像头：主摄、广角、长焦。车载系统更夸张，环视摄像头、DMS、ADAS摄像头，加起来七八颗很正常。我参与过一个项目，一台设备上挂了12颗摄像头，光调试同步就花了两个月。

多Camera系统通常分三类：

• 多视角拼接型：比如全景相机、车载环视。每颗摄像头拍不同角度，最后拼成一张图。
• 多焦距融合型：手机上的主摄+长焦+广角。不同焦距拍同一场景，融合出更好的画质。
• 多模态感知型：比如RGB摄像头+ToF深度摄像头。一个拍颜色，一个拍距离。

我个人的习惯是，拿到需求先问清楚：这些摄像头是同时工作，还是轮流工作？如果是同时工作，那同步就是绕不开的坎。

1.2 为什么非要同步？

说白了，不同步的后果很严重。我举个例子你就明白了。

假设你有一台双摄手机，主摄和长焦同时拍一张照片。如果两颗摄像头曝光时间差了几十毫秒，拍到的画面就不一样了——手抖了、人动了、光线变了。融合出来的照片边缘会有重影，甚至直接糊掉。

更极端的场景是车载环视。四个摄像头分别拍车的前后左右，拼成俯视图。如果不同步，车已经往前开了两米，左侧摄像头才拍到上一帧的画面。你想想看，驾驶员看到的全景图里，车的位置和周围障碍物的位置是对不上的。这可不是糊不糊的问题，是要出事故的。

所以，同步的核心目标就两个：

1. 时间对齐：所有摄像头在同一时刻曝光，拿到同一时刻的画面。
2. 帧率一致：所有摄像头以相同的节奏输出帧，避免累积偏差。

1.3 HAL层到底管什么？

嗯，这里要讲清楚HAL层的角色定位。Android的Camera HAL层，说白了就是硬件和Framework之间的翻译官。Framework说我要拍照，HAL层就去操作Sensor、ISP、MIPI接口。Framework说我要预览，HAL层就启动数据流。

但在多Camera场景下，HAL层的职责远不止这些。我把它总结成三个核心角色：

你可能会问：这些事为什么不在Framework层做？我告诉你，Framework离硬件太远了。它发一个命令下来，经过层层传递，到Sensor端已经延迟了几十毫秒。而HAL层直接操作硬件寄存器，延迟可以控制在微秒级。同步这件事，越靠近硬件越好做。

1.4 同步方案的技术选型

讲到这里，你可能已经意识到同步不是小事。实际项目中，同步方案的选择取决于硬件能力。我大致分三种：

• 硬件同步（最可靠）：用GPIO或专用的同步信号线，连接所有Sensor的Trigger引脚。HAL层配置好时序，Sensor自己按信号曝光。我强烈推荐这种方案，只要硬件支持，无脑选它。
• 软件同步（次选）：没有硬件同步线，靠HAL层计算时间差，动态调整曝光时机。精度差一些，但成本低。我做过一个项目，Sensor不支持硬件Trigger，只能用软件同步，最终精度控制在1ms以内，勉强能用。
• 混合同步（折中）：部分摄像头用硬件同步，部分用软件。比如主摄和长焦用硬件同步，广角用软件同步。这种方案调试起来最麻烦，我建议新手别碰。

我个人习惯是，设计阶段就和硬件工程师确认好：有没有同步信号线？能不能共用MCLK？这些硬件细节决定了HAL层怎么设计。如果硬件不支持，那HAL层再牛也白搭。

1.5 课程路线图

好了，第一讲就到这里。咱们这门课一共30讲，我会从最基础的同步原理讲起，逐步深入到HAL层的代码实现。后面几讲我会带你手写一个同步调度器，还会讲怎么调试同步问题。

下一讲，咱们聊聊同步的核心技术——曝光时序控制。我会用实际代码演示怎么配置硬件Trigger信号。到时候见。