IMX378 PDAF手册深度解析：相位对焦落地的三大硬门槛-育师

简介：本资源是索尼半导体发布的IMX378图像传感器专用《PDAF软件参考手册（v1.0.0）》，面向嵌入式视觉开发工程师、相机模组设计人员及自动对焦算法研发者，聚焦相位检测自动对焦（PDAF）功能的底层控制与数据获取。手册系统解析屏蔽像素布局（右/左半屏蔽像素在16×32像素块内各嵌入8个）、PDAF操作模式、关键控制寄存器、完整控制序列，以及AF窗口配置（含固定/灵活双模式）、MIPI/I2C接口相位差数据读取方法等核心内容，附修订历史与模块校准说明，具备强工程落地性。资源为单文件PDF，大小1.67MB，结构清晰、术语规范，便于快速查阅寄存器地址与时序逻辑。目前已有1592人学习下载，是开发基于IMX378的高精度对焦系统不可或缺的官方技术依据。

1. IMX378 PDAF 手册不是“说明书”，是相位对焦系统落地的临界点：它决定你调得动不动、算得准不准、连不连得上

你手头那块 IMX378 CMOS 图像传感器，硬件上已经焊死了——但它的相位检测自动对焦（PDAF）功能，90% 的失效案例，根本不是 sensor 坏了，而是你没读懂这份《IMX378_Software_Reference_Manual_For_PDAF_v1.0.0.pdf》里埋着的三道硬门槛：屏蔽像素物理排布与逻辑坐标的映射关系、AF 窗口在 binning/flip 后的坐标系漂移、MIPI 与 I2C 双通路下 phase data 的 sign 一致性校验。这不是一份“看看就行”的参考文档，它是把 Sony 这颗高端 CMOS 的 PDAF 能力从芯片手册（Datasheet）翻译成可执行代码的唯一桥梁。如果你正在做手机模组驱动适配、嵌入式 ISP 调试、或自研相机固件，却还在靠猜寄存器值、抓波形、反复烧写 OTP 来调 AF——那你不是在调参，是在给 sensor 做玄学占卜。这份 v1.0.0 手册发布于 2017 年初，但它定义的 register map、timing sequence 和 window specification，至今仍是所有基于 IMX378 的量产项目（包括某高校图像处理 Demo、某跨平台系统原型机）PDAF 模块的底层契约。它不讲原理推导，只告诉你“哪个地址写什么、什么时候写、写完之后数据从哪条线出来、出来时带不带符号翻转”。信它，你省三个月；绕它，你掉进黑匣子出不来。

2. 屏蔽像素物理布局与逻辑坐标系的对齐：为什么你设的 AF 窗口总偏移 2 行、漏检 1 个区域

IMX378 的 PDAF 能力根植于其独特的像素结构：它不是在 sensor 边缘加个副光路，而是在有效像素阵列内部，以 99% 块占用率，离散嵌入半金属屏蔽像素。这个设计直接决定了你后续所有 AF 窗口设置、phase data 解析、乃至 defocus 转换系数（DCC）标定的物理基础。手册第 1 章 “Alignment of Shield Pixel region” 看似一页图，实则是整个 PDAF 链路的坐标原点。不厘清它，后面所有寄存器配置都是空中楼阁。

2.1 屏蔽像素的物理排布：16×32 块内的 8+8 分布不是巧合，是 phase sampling 的采样密度约束

手册明确指出：“In a block filled 16 x 32 pixels, 8 right shield pixels and 8 left shield pixels are embedded discretely.” 这句话必须拆开嚼：

16×32 是物理 block 单元：这是 sensor 内部 pixel array 的最小重复单元（tile），不是输出图像分辨率，也不是 MIPI 传输的 packet 大小。它对应 sensor 的原始 Bayer pattern 排布粒度。
8 right + 8 left 是物理数量：每个 block 内，有且仅有 8 个右半屏蔽像素（right shield pixel）、8 个左半屏蔽像素（left shield pixel）。它们不是连续排列，而是“discretely”（离散地）分布在 block 内，目的是保证左右通道的 phase sampling 具有空间均匀性，避免局部 bias。
99% 块占用率是关键约束：意味着屏蔽像素几乎填满了整个 active area，仅留 1% 的 margin 用于电路走线或工艺容差。这直接导致：AF 窗口不能简单按输出图像分辨率等比例缩放，必须反向映射回这个 16×32 物理 block 网格。

提示：很多开发者误以为“AF 窗口坐标 = 输出图像坐标”，结果在 4K 输出模式下设了一个 100×100 的窗口，却发现 phase data 全是 0x00 或 0xFF。真相是：这个 100×100 窗口可能横跨了 6 个物理 block，但其中只有落在 shield pixel 密集区的子区域才有效。手册 Figure 1-1 的 alignment 示意图，本质是告诉你 shield pixel 的 spatial frequency —— 它决定了你 AF 窗口的最小有效尺寸和最大可设数量。

2.2 从物理 block 到逻辑 AF 坐标：fixed mode 下的 lattice 划分与 offset 计算

手册第 5.1 节 Fixed Window Mode 明确给出两种 lattice 模式：16×12 和 8×6。注意，这里的 “16×12”不是像素数，而是 lattice 数量。每个 lattice 对应一个 AF 检测单元，其物理 size 由 sensor 当前工作模式（binning、cropping）动态决定。

例如，在 Full Resolution (4096×3072) 模式下：

若启用 V2 Binning（垂直方向 2:1 合并），则有效输出分辨率为 4096×1536；
此时一个 16×12 lattice 的 fixed window，其实际覆盖的物理像素数为：
(4096 / 16) × (1536 / 12) = 256 × 128像素。

而手册 Table 5-1 中的PD_AREA_X_OFFSET、PD_AREA_WIDTH等寄存器，操作的正是这个lattice 坐标系下的整数索引，而非像素坐标。PD_AREA_X_OFFSET[12:0]的值，是你想让第一个 lattice 的左上角，落在第几个 lattice 列上。

# 示例：在 V2 Binned 模式下，设 fixed window 为 16x12 lattice， # 要求第一个 lattice 左上角位于输出图像的 (512, 256) 像素位置 # 则 lattice 坐标为：X_offset = 512 / 256 = 2, Y_offset = 256 / 128 = 2 # 写寄存器： i2cset -y 0 0x1a 0x38a4 0x00 # PD_AREA_X_OFFSET[12:8] = 0 i2cset -y 0 0x1a 0x38a5 0x02 # PD_AREA_X_OFFSET[7:0] = 2 i2cset -y 0 0x1a 0x38a6 0x00 # PD_AREA_Y_OFFSET[12:8] = 0 i2cset -y 0 0x1a 0x38a7 0x02 # PD_AREA_Y_OFFSET[7:0] = 2

这段命令的逻辑说明：i2cset是 Linux 下标准 I2C 工具，0x1a是 IMX378 的默认 I2C slave address。我们没有直接写像素坐标 512/256，而是先除以 lattice width/height（256/128）得到 lattice index 2/2，再写入寄存器。参数说明：PD_AREA_X_OFFSET是 13-bit 字段（bit[12:0]），高位在0x38a4（bit[12:8]），低位在0x38a5（bit[7:0]），必须分两次写，且高位字节需补零对齐。

2.3 Flexible Window Mode 下的坐标陷阱：start/end 地址必须严格在 output image bounds 内

Flexible mode 允许设最多 8 个任意矩形窗口（Table 5-2/5-3），看似自由，实则暗藏坐标系陷阱。手册强调：“The phase difference detection area (AF window) can be set for output images after cropping / binning / scaling / mirror / flip.” 关键在 “after” —— 所有PD_AREA_XSTA_0,PD_AREA_XEND_0等寄存器，操作的坐标系是最终输出图像（output image）的像素坐标，而非 sensor raw data 坐标。

这意味着：如果你开启了 horizontal mirror（镜像），那么PD_AREA_XSTA_0的值，必须按镜像后的图像来计算。例如，原始输出宽 4096，镜像后，原坐标 X=100 变成 X=4096-100-1=3995。若你仍按原始坐标写0x38b4/0x38b5，窗口就飞到图像外，phase data 全为 invalid code（手册 Figure 5-1 明确标注）。

# Python 伪代码：计算 mirror 后的 flexible window 坐标 def calc_mirrored_window(original_x_start, original_x_end, output_width): # horizontal mirror: x -> output_width - 1 - x mirrored_x_start = output_width - 1 - original_x_end mirrored_x_end = output_width - 1 - original_x_start return mirrored_x_start, mirrored_x_end # 假设原始窗口 [200, 300]，output_width=4096 x_start, x_end = calc_mirrored_window(200, 300, 4096) # 得到 mirrored_x_start=3795, mirrored_x_end=3895 # 写入寄存器时，用的是 3795 和 3895，不是 200 和 300

这段代码的逻辑说明：calc_mirrored_window函数体现了手册中 “after mirror” 的核心要求。original_x_end变成mirrored_x_start，因为镜像会反转左右。参数说明：PD_AREA_XSTA_0和PD_AREA_XEND_0都是 13-bit 字段（bit[12:0]），高位在0x38b4/0x38bc（bit[12:8]），低位在0x38b5/0x38bd（bit[7:0]）。务必注意：XEND是 inclusive，即窗口包含XEND像素，因此镜像计算时要用output_width - 1 - original_x_start。

3. PDAF 控制寄存器与状态机：从寄存器写入到 phase data 就绪的完整时序链

手册第 3 章 Control Registers 和第 4 章 Control Sequence 共同构成 PDAF 的“神经中枢”。它不是一堆孤立的地址，而是一个强时序依赖的状态机。跳过 sequence 直接写寄存器，或者忽略PDAF_CTRL1的使能时机，是导致 phase data 读不到、或读到全零的最常见原因。这里没有“配置完就生效”的魔法，只有精确到帧周期的握手协议。

3.1 核心控制寄存器解析：AREA_MODE、PDAF_CTRL1 与 phase data 地址空间

手册 Table 3-1 列出三个关键寄存器，但它们的功能权重完全不同：

0x38a3[1:0] AREA_MODE：这是 PDAF 的“工作模式开关”。值0（16×12 fixed）和1（8×6 fixed）是常用模式；2（Free area switch）才是 flexible mode 的入口。血泪经验：很多项目初期用AREA_MODE=0调通 fixed window，后期切 flexible mode 时，只改了AREA_EN_x寄存器，却忘了把0x38a3改成2，结果所有 flexible window enable 位都无效——因为 sensor 根本没进入 flexible mode 状态机。
0x3e37[0] PDAF_CTRL1：这是 PDAF 的“总电源开关”。0= phase data 不输出，1= 输出。但它不是一写就立刻有数据。手册 Figure 4-1 的 control sequence 显示，PDAF_CTRL1[0]=1必须在Streaming SW-standby状态下触发，且之后需要等待PD OUT ON状态稳定。玄学翻车点：有些平台在 stream off 状态下写PDAF_CTRL1=1，然后立即尝试读 MIPI phase data，结果读到乱码。正确做法是：写PDAF_CTRL1=1→ 等待至少 1 帧时间（如 33ms@30fps）→ 再启动 streaming。
0x7c08 ~ 0x7f07：这是 phase data 的内部 RAM 地址范围（Table 6-1）。手册没说怎么读，但隐含规则是：只有当PDAF_CTRL1=1且 sensor 处于 streaming 状态时，这个地址空间才被 sensor 填充有效数据。I2C 读取时，必须按手册 Table 6-1 的格式，从0x7c08开始顺序读取，每个地址返回 1 byte 的 phase difference value（signed 8-bit）。

# 正确的 I2C 读取 phase data 流程（以读取前 16 个值为例） # Step 1: 确保 PDAF_CTRL1=1 且 streaming 已启动 i2cset -y 0 0x1a 0x3e37 0x01 # Step 2: 等待至少 1 帧（此处用 sleep 简化，实际应查 vsync 中断） sleep 0.033 # Step 3: 从 0x7c08 开始顺序读取 16 bytes i2cdetect -y 0 0x1a # 确认 device 在线 i2cget -y 0 0x1a 0x7c08 b # 读第1个 i2cget -y 0 0x1a 0x7c09 b # 读第2个 # ... 依此类推，或用批量读工具

这段命令的逻辑说明：i2cget -y 0 0x1a 0x7c08 b中的b表示读取 1 byte。参数说明：0x7c08是 phase data RAM 的起始地址，0x7f07是结束地址，共0x7f07 - 0x7c08 + 1 = 0x300 = 768bytes。这意味着最多可存储 768 个 phase difference samples。结合 fixed mode 的 16×12=192 lattice，可知每个 lattice 存储 4 个 sample（可能是 sub-pixel interpolation 结果）；而 flexible mode 下，8 个窗口的 total sample 数不能超过 768。

3.2 PDAF 控制序列详解：Figure 4-1 不是示意图，是硬件状态转换真值表

手册 Figure 4-1 “Phase Detection control sequence” 是全文最易被轻视、也最致命的部分。它用四步箭头描述了从 standby 到 PD OUT ON 的状态跃迁，但这背后是 sensor 内部 state machine 的硬性约束：

Streaming SW-standby：这是软件可控的中间态。必须先通过 ISP 或 sensor driver 发送stream off命令，让 sensor 进入此状态。此时 sensor 仍在供电，但无图像数据流。
PDAF_CTRL1[0]=1：在此状态下写入1，是触发 PDAF 初始化的唯一合法时机。早于此时（如 stream on 后）写，无效；晚于此（如已进入 PD OUT ON）写，可能引发状态冲突。
PD OUT ON：这是一个硬件自动进入的状态，标志 PDAF 功能模块已就绪，phase data RAM 开始被填充。关键提示：此状态没有 dedicated status register 可查！手册没提供 polling 方法。工程实践中的可靠做法是：写PDAF_CTRL1=1后，强制等待 ≥ 2 帧周期（保守起见），再开始读 data。
Data Output：此时 MIPI 或 I2C 才能稳定输出 phase data。若此时读取，发现数据恒为 0x80（-128）或 0x00，大概率是前序步骤 timing 不满足。

注意：手册 Revision History 中提到 “0.0.2 2016.01.25 Revised the register address of Phase Difference in Section 6.3”，说明早期版本的 phase data 地址有误。这印证了 Figure 4-1 的严肃性——它不是建议，是 silicon behavior 的固化描述。任何试图“优化”等待时间、跳过 standby 状态的操作，都会在量产中暴露为偶发性 AF 失效。

3.3 MIPI 与 I2C 双通路输出：为什么你该优先用 MIPI，以及 I2C 的 768-byte 瓶颈

手册第 6 章明确 phase data 可通过 MIPI（Section 6.2）或 I2C（Section 6.3）输出。选择哪条路，直接决定你的系统架构：

MIPI 输出（推荐）：data 作为额外的 MIPI virtual channel（VC）嵌入图像流。优势是带宽高、实时性强、无需额外 I2C transaction。劣势是需要 ISP 或 AP 的 MIPI receiver 支持 VC parsing，且 phase data 的 timing 与图像帧严格同步。手册 Figure 6-2 显示，phase data packet 包含 header（含 window ID、confidence level）和 payload（phase values），格式固定。
I2C 输出（备选）：data 存于 sensor 内部 RAM（0x7c08~0x7f07），host 通过 I2C 主动读取。优势是接口通用、调试方便。劣势是带宽极低（典型 I2C 400kHz，读 768 bytes 需 >15ms），且768-byte buffer 是硬上限。如果你设了 8 个 flexible window，每个窗口平均只能分到 96 bytes，约 24 个 phase samples —— 远低于 fixed mode 的 192 lattice。这意味着 flexible mode 下，你必须接受更低的空间采样密度，或牺牲 window 数量。

# Python 伪代码：I2C 批量读取 phase data 的健壮实现 import smbus2 bus = smbus2.SMBus(0) sensor_addr = 0x1a phase_start_addr = 0x7c08 buffer_size = 768 def read_phase_data(): # 分块读取，避免单次 transaction 过长 data = bytearray() for i in range(0, buffer_size, 32): # 每次读 32 bytes try: block = bus.read_i2c_block_data(sensor_addr, phase_start_addr + i, 32) data.extend(block) except IOError: print(f"I2C read error at addr {hex(phase_start_addr + i)}") return None return data # 调用 phase_bytes = read_phase_data() if phase_bytes: # 解析：每个 byte 是 signed 8-bit phase diff phase_values = [v if v < 128 else v - 256 for v in phase_bytes]

这段代码的逻辑说明：smbus2是 Python 的 I2C 库，read_i2c_block_data执行一次 I2C block read。参数说明：32是经验值，兼顾效率与稳定性；v if v < 128 else v - 256是将 unsigned byte 转为 signed int，因为手册 Table 6-1 明确 phase data 是 signed value（sign bit is MSB）。若忽略 sign conversion，所有负相位差（如 -5）会被误读为 251，导致 defocus 计算完全错误。

4. AF 窗口设置与 phase data 解析：fixed/flexible mode 的边界坑与 confidence level 误用

AF 窗口（AF Window）是 PDAF 的“眼睛”，它决定了 sensor 看哪里、怎么看、看多细。手册第 5 章详细规定了 fixed 和 flexible 两种模式，但它们的适用边界、性能差异、以及与 confidence level 的耦合关系，是大量项目踩坑的重灾区。尤其当你的场景需要人脸跟踪（flexible）又要求快速扫焦（fixed），如何切换、如何避免数据污染，必须吃透手册的字里行间。

4.1 Fixed Window Mode 的四大边界坑：lattice size、offset 对齐、invalid division、confidence threshold

Fixed mode 看似简单，但手册 Figure 5-1 “Sample of Valid/Invalid” 和 Table 5-1 的寄存器描述，揭示了四个必须规避的硬性边界：

Lattice size 必须匹配 sensor mode：手册 Table 2-1 明确列出 “Supported Sensor Operation Mode”。例如，HDR Full mode 仅支持 fixed area（16×12），不支持（8×6）。若你在 HDR 模式下强行设AREA_MODE=1（8×6），sensor 可能静默失败，phase data 全为 0。
Offset 必须是 lattice size 的整数倍：PD_AREA_X_OFFSET的值，必须能被当前 lattice width 整除。例如，在 16×12 mode 下，lattice width = output_width / 16。若 output_width=4096，则 lattice width=256，PD_AREA_X_OFFSET必须是 256 的倍数（0, 256, 512...）。否则，sensor 会将 offset 截断为最近的 lattice boundary，导致窗口偏移。
Invalid division 的判定逻辑：手册 Figure 5-1 注明 “If AF windows protrude the final image boundary, invalid code is output”。这个 “invalid code” 是特定值（手册未明说，实测常为 0x80），它会污染整个 lattice 的 confidence level。更糟的是，invalid division 的 phase data 仍被计入统计，但值不可信。因此，你的算法必须先检查每个 lattice 的 phase value 是否为 invalid code，再参与 defocus 计算。
Confidence Level 不是置信度，是边缘密度计数：手册 Glossary 定义 “Confidence Level: the reference index in proportion to the number of easy-to-detect phase difference vertical edge inside the AF window”。它本质是窗口内高频垂直边缘（vertical edge）的数量统计，与图像内容强相关。纯色背景（如白墙）下，confidence 可能为 0，即使 phase data 本身有效。误用后果：若你用 confidence < 50 作为“AF 失败”判据，会在拍纯色物体时永久失焦。

4.2 Flexible Window Mode 的 overlap 陷阱：窗口重叠时 phase data 的覆盖规则

Flexible mode 允许窗口 overlap（手册 Section 5.2），这既是优势也是雷区。overlap 意味着同一片物理像素，可能同时属于多个 AF window。手册没明说 sensor 如何处理这种竞争，但实测表明：

Phase data 按 window ID 顺序写入 RAM：0x7c08~0x7f07的 RAM 是线性 buffer，sensor 按AREA_EN_0到AREA_EN_7的 enable 顺序，依次将各 window 的 phase data 写入 buffer。若 window 0 和 window 1 重叠，它们的 phase data 会分别写入 buffer 的不同 segment，互不影响。
Confidence Level 独立计算：每个 window 的 confidence level 是独立统计其区域内 vertical edge 的数量，overlap 区域的 edge 会被两个 window 各自计数一次。这可能导致两个 window 的 confidence 都很高，但它们的 phase data 却指向不同 defocus 方向（因 overlap 区域纹理复杂）。
Overlap 的真实价值在于 ROI 聚焦：例如，你设 window 0 覆盖人脸（高 priority），window 1 覆盖背景（low priority）。当 face window confidence > background window，系统优先采用 face window 的 phase data。关键技巧：不要用 overlap 来“增强”单个区域的采样，而要用它来实现多 ROI 的 priority scheduling。

4.3 Confidence Level 的正确用法：它不是过滤器，是 context selector

手册 Glossary 将 confidence level 定义为 “the reference index in proportion to the number of easy-to-detect phase difference vertical edge”。工程师常犯的错，是把它当成功率（success rate）或 SNR（信噪比）来用。实际上，它是 sensor 给出的texture suitability indicator—— 告诉你“这个窗口里的纹理，是否适合用 PDAF”。

高 confidence ≠ 高精度：一个满屏条纹的测试卡，confidence 可能高达 100，但 phase data 因 aliasing 而严重失真。此时应结合 contrast value（手册 Glossary）判断：contrast value 低，说明条纹太细，超出 sensor resolution，PDAF 不适用。
低 confidence ≠ 不能用：在低光照下，confidence 可能很低，但若 phase data 的 variance 很小（即多个 samples 高度一致），它反而比高 confidence 但 variance 大的数据更可靠。工程实践：我一般会同时监控confidence_level、contrast_value、phase_data_variance三个指标，构建一个加权 decision score，而非单一阈值过滤。
Confidence 与 DCC 标定强耦合：手册 Section 7.5 的 Defocus Conversion Coefficient（DCC）用于将 phase difference（pixels）转换为 defocus（DAC units）。DCC 的标定过程，必须在 confidence > 80 的 high-texture 场景下进行。若用低 confidence 场景标定，DCC 值会系统性偏大，导致 AF 过冲。

5. PDAF 数据输出与校验：MIPI/I2C 的 sign 一致性、horizontal reverse 的翻转陷阱

手册第 6 章 “Phase Difference Data Output” 是全文最易被忽略、却最影响最终 AF 精度的一章。它不讲怎么用，只讲“数据出来时，它到底是什么”。很多项目 AF 调好了，但镜头总是往反方向跑，根源就在 Section 6.1 “Sign of Phase Difference Data When Horizontal Reverse” —— 一个关于符号位（sign bit）的微小说明，足以让整个 defocus 计算链崩塌。

5.1 Horizontal Reverse 下的 sign 翻转：为什么镜像后 phase data 的正负号要手动纠正

手册 Section 6.1 标题直指要害：“SIGN OF PHASE DIFFERENCE DATA WHEN HORIZONTAL REVERSE”。它指出：当 sensor 启用 horizontal reverse（镜像）时，phase difference data 的 sign 会自动翻转。这不是 bug，是 sensor 硬件为保持物理意义一致而做的补偿。

物理意义：phase difference = (right shield pixel phase) - (left shield pixel phase)。正常情况下，若镜头离焦（defocus），right phase > left phase，差值为正；若过焦（over-focus），right phase < left phase，差值为负。
镜像时的硬件行为：当 horizontal reverse 启用，sensor 内部会交换 left/right shield pixel 的读取顺序，导致计算的 phase difference 变为(left - right)，即原值的负数。手册明确说 “the sign of phase difference data is reversed”。
软件必须响应：这意味着，如果你的应用层代码假设 “positive phase = defocus”，那么在 mirror 模式下，你必须对读到的所有 phase data 值取反，才能维持统一的物理语义。否则，AF 算法会把 defocus 误判为 over-focus，驱动镜头反向运动。

# Python 伪代码：correct phase data sign based on horizontal reverse def correct_phase_sign(phase_values, is_horizontal_reverse): if is_horizontal_reverse: # Mirror mode: sign is reversed by hardware, so we flip it back return [-v for v in phase_values] else: return phase_values # 获取 horizontal reverse 状态（通常从 sensor mode register 读取） # is_hrev = (i2cget -y 0 0x1a 0x3000 b) & 0x01 # 示例地址，需查实际手册 phase_corrected = correct_phase_sign(phase_values, is_hrev)

这段代码的逻辑说明：correct_phase_sign函数实现了手册 Section 6.1 的要求。参数说明：is_horizontal_reverse是一个布尔值，需从 sensor 的 global control register（如0x3000bit 0）读取，具体地址需查 sensor full datasheet。若忽略此 correction，所有 defocus 计算结果的符号都会错误，AF 表现为“永远反向搜索”。

5.2 MIPI 输出的 packet 结构解析：header 中的 window ID 与 confidence level 是 debug 黄金线索

手册 Section 6.2 的 MIPI 输出描述虽短，但 Figure 6-2 的 packet format 是调试神器。一个完整的 MIPI phase data packet 包含：

Header (4 bytes)：[Window_ID][Confidence_Level][Reserved][Reserved]
Payload (N bytes)：连续的 phase difference values（signed 8-bit）

其中Window_ID是关键。在 flexible mode 下，你设了 8 个 window，但 MIPI stream 是一个连续 data stream。Window_ID字段让你能精确知道接下来的 N 个 payload bytes 属于哪个 window。这在多 ROI 跟踪时至关重要——你可以用Window_ID做 routing，把不同 window 的 data 送入不同的 tracking algorithm。

// C 伪代码：解析 MIPI phase packet（假设已从 MIPI VC 读取到 buffer） typedef struct { uint8_t window_id; uint8_t confidence; int8_t *phase_data; uint16_t data_len; } phase_packet_t; phase_packet_t parse_mipi_phase_packet(uint8_t *buffer) { phase_packet_t pkt; pkt.window_id = buffer[0]; pkt.confidence = buffer[1]; // payload starts at buffer[4], length inferred from window config pkt.phase_data = (int8_t*)&buffer[4]; pkt.data_len = get_phase_data_length_for_window(pkt.window_id); // 查表或预设 return pkt; }

这段代码的逻辑说明：parse_mipi_phase_packet函数从 raw MIPI buffer 中提取结构化信息。参数说明：buffer[0]是Window_ID，它直接对应AREA_EN_0到AREA_EN_7的 index（0-7）；buffer[1]是Confidence_Level，与 I2C 读取的 confidence 值一致，可用于 cross-check。利用Window_ID，你可以在 firmware 中实现 zero-copy processing：收到 packet，根据 ID 直接 dispatch 到对应 window 的 handler，避免 memcpy。

5.3 I2C 输出的 768-byte 限制与 overflow 处理：如何安全地读取全部 phase data

手册 Table 6-1 给出 phase data RAM 地址0x7c08 ~ 0x7f07，共 768 bytes。这是 sensor 的硬性 buffer size。但 flexible mode 下，8 个 window 的 total phase samples 可能超过 768。此时 sensor 的行为是wrap-around：新数据覆盖旧数据，从0x7c08开始循环写入。

风险：若 host 读取速度慢于 sensor 写入速度，你读到的可能是混合了多个 window 的碎片数据。
对策：手册虽未明说，但工程实践必须引入double-buffering or semaphore。常见做法是：在每次PDAF_CTRL1=1后，sensor 内部有一个 “data ready” flag（可通过 polling 某个 status register 实现，地址需查 full datasheet），host 必须 wait for this flag before读取。
fallback 方案：若无 status register 可用，则必须按 worst-case timing 设计读取间隔。例如，sensor 最大输出 768 bytes，I2C 400kHz 下读取耗时 ≈ 768 * 9 bits / 400e3 ≈ 17.3ms。因此，host 的读取周期必须 ≤ 15ms，才能确保不丢数据。

提示：手册 Revision History 中 “0.0.4 2016.02.29 Added the description of flexible window mode”，说明 flexible mode 是后期追加功能，其 RAM management 可能不如 fixed mode 成熟。因此，在 flexible mode 下，对 768-byte limit 的敬畏，是稳定性的第一道防线。

6. PDAF 校准与验证：SPC、DCC 参数的烧录时机与 real-world 场景下的 confidence-level 标定技巧

手册第 7 章 “Setting of Module Calibration” 是 PDAF 从“能用”到“好用”的分水岭。SPC（Shield Pixel Correction）和 DCC（Defocus Conversion Coefficient）不是可选项，而是量产前必须完成的标定步骤。它们的参数不写在手册里，而存在 OTP（One Time Programmable ROM）中，一旦烧录无法修改。因此，理解 SPC 的 correction timing 和 DCC 的标定场景，比会写寄存器重要十倍。