TI Jacinto平台实现YUV422输出的硬件旁路与TDM配置方案

1. 项目概述与背景

在汽车电子，特别是高级驾驶辅助系统（ADAS）和环视系统（SRV）的开发中，我们常常会遇到一个看似简单却非常棘手的问题：如何让不同供应商、不同标准的硬件模块“说同一种语言”。具体来说，就是视频输出格式的兼容性。我最近在基于德州仪器（TI）的Jacinto或TDA系列平台开发SRV系统时，就撞上了这么一堵墙。平台自带的显示子系统（DSS）功能强大，但原生只支持RGB格式或一种非标准的嵌入式同步YUV422输出。这听起来可能只是个技术细节，但在实际的车规级系统集成中，它直接关系到BOM成本、PCB布局复杂度和整机可靠性。

想象一下这个场景：一辆车原本有一套成熟的后视摄像头（RVC）系统，它通过FPD-LINK III串行器/解串器对，以标准的8位YUV422格式将视频传给中控娱乐主机。现在，主机厂想要升级到360度环视，或者在中高端车型上提供SRV功能。如果新的SRV控制单元（通常基于像Jacinto这样性能强大的SoC）只能输出RGB888，那么主机厂就面临一个尴尬的选择——要么在娱乐主机里再增加一套RGB接口的解串器，要么要求供应商更换整个视频链路。无论哪种，都意味着额外的成本、功耗和潜在的设计风险。

因此，我们的目标很明确：在不更换硬件平台的前提下，让基于TI Jacinto/TDA的SRV系统也能输出标准的、离散同步的YUV422视频流，从而与现有的RVC系统共享同一套解串器接口，实现“无缝升级”。这不仅仅是改个配置寄存器那么简单，它涉及到对DSS硬件流水线的深入理解、对视频时序的精确操控，以及在不同软件框架（如TI的VISION SDK和基于Linux的PSDKLA）下的工程实现。接下来，我就把自己趟过的路、踩过的坑，以及最终验证通过的方案，详细拆解一遍。

2. 核心挑战与方案选型

2.1 问题根源：DSS的“天生局限”与工程现实

TI Jacinto/TDA系列的显示子系统（DSS）是一个非常灵活的模块，但其输出接口的支持情况在技术参考手册（TRM）里写得明明白白，这也是我们所有工作的起点和约束条件。简单总结一下它的能力边界：

1. 对于YUV422格式：仅支持嵌入式同步输出接口，符合BT.656和BT.1120标准。这意味着同步信号（HSYNC, VSYNC）是编码在数据流中的，只需要PCLK和DATA线。
2. 对于RGB格式：支持离散同步输出接口，提供独立的HSYNC、VSYNC和DE（数据使能）信号，支持RGB888、RGB565、RGB444等多种位深。

问题就出在这个“嵌入式同步”上。TRM里有一个非常关键的“警告”（CAUTION）条目：当DSS配置为BT模式（即嵌入式同步的YUV422输出）时，其支持的最大水平消隐期（H-Blanking）仅为256字节。然而，标准的ITU-R BT.656规定，PAL制式需要280字节，NTSC制式需要268字节。这个“缩水”的消隐期导致DSS产生的并不是完全合规的BT.656信号。在实验室里，你可能能找到一两个宽容度高的解码芯片能识别，但在要求严苛、追求供应链稳定性的车规级项目中，依赖这种“非标准”信号无异于埋下一颗定时炸弹。几乎没有主流的分立式解串器芯片（如TI的UB934）敢保证能稳定解析这种非标时序。

所以，直接使用DSS原生的YUV422输出模式，在需要与标准解串器对接的车载场景下，基本是条死路。我们必须另辟蹊径。

2.2 方案思路：借道RGB，暗度陈仓

既然原生的YUV422输出路不通，而离散同步的RGB输出是完好支持的，一个很自然的想法就产生了：我们能不能“欺骗”硬件，让它以为自己在输出RGB，但实际上我们喂给它并让它原样吐出的数据，本质上是YUV422？

这个思路的核心在于利用DSS视频流水线（VID Pipeline）的“旁路”（Bypass）机制。DSS的每个视频管道（如VID1, VID2, VID3）内部都有颜色空间转换（CSC）、缩放（Scaler）等处理模块。当输入格式被配置为RGB时，某些模块（如CSC）默认是旁路的。如果我们把原始的YUV422数据，伪装成某种RGB格式（比如RGB565，因为它也是16位/像素）送入管道，并确保所有处理模块都被旁路，那么理论上，输入的数据就能毫发无损地穿过管道，到达叠加混合器（Overlay）。

最后，我们再利用DSS另一个强大功能——时分复用（TDM），将每个16位的像素拆分成两个8位的数据包，在8位物理数据线上用两个时钟周期发送出去。这样，从物理接口看，我们就是用RGB接口的时序，输出了YUV422的数据流。接收端（解串器）只要按照标准的8位YUV422离散同步时序来解析即可。

这个方案的精妙之处在于，它完全在硬件允许的框架内操作，没有魔改，没有超频，稳定性有保障。整个方案的实现，就围绕着两个关键点展开：一是正确配置视频管道实现“比特精确”的旁路；二是正确配置TDM时序以实现数据格式的转换。

3. 硬件层实现：管道配置与TDM时序

3.1 实现比特精确旁路（Bit-Exact Bypass）

要让YUV422数据伪装成RGB565穿过VID管道，我们需要对管道进行一系列精细的配置，目标是将所有可能修改数据的处理单元全部关闭或旁路。下图展示了VID管道的关键模块与我们的旁路策略：

[YUV422 数据] --> [DMA输入] --> [VC-1范围映射] --(旁路)--> [CSC (YUV->RGB)] --(旁路)--> [缩放器] --(旁路)--> [叠加/混合] --> [输出]

具体的寄存器配置如下，这里以VID1管道为例：

1. 设置输入格式为RGB565：这是“欺骗”硬件的关键一步。硬件看到这个格式，会认为后续处理应该基于RGB色彩空间，从而避免启动YUV相关的转换。

   DISPC_VID1_ATTRIBUTES.FORMAT = 0x6; // RGB16-565格式

2. 禁用缩放功能：确保输入图像的尺寸和输出尺寸完全一致，缩放器就会自动旁路。任何缩放操作都会进行插值计算，必然改变像素值。

   DISPC_VID1_ATTRIBUTES.RESIZEENABLE = 0x0; // 关闭水平和垂直缩放 DISPC_VID1_SIZE.SIZEX = DISPC_VID1_PICTURE_SIZE.MEMSIZEX; // 输出宽度 = 内存缓冲区宽度 DISPC_VID1_SIZE.SIZEY = DISPC_VID1_PICTURE_SIZE.MEMSIZEY; // 输出高度 = 内存缓冲区高度

3. 关闭其他可能影响数据的特性：

   DISPC_CONFIG1.TCKLCDENABLE = 0; // 禁用透明色键功能 DISPC_CONFIG1.CPR = 0; // 关闭色彩相位旋转

   对于RGB565格式，VC-1范围映射和CSC模块本身是默认旁路的，所以我们无需额外设置。完成以上配置后，从DMA写入VID1管道的YUV422数据（此时被硬件视为RGB565数据）将不会被任何处理模块修改，实现比特级的原样输出。

关键细节与避坑指南：

• 内存缓冲区格式：虽然管道配置为RGB565，但你写入DMA缓冲区的必须是原始的YUV422数据。内存中的存储布局应该是Y0 U0 Y1 V1 Y2 U2...（YUYV交错排列）。硬件不会帮你做任何转换，它只是把这块内存当作RGB565来“读取”和“传输”。
• 字节序问题：需要特别注意CPU端内存字节序（Endianness）与DSS读取顺序的匹配。通常，你需要确保16位像素（两个8位YUV分量）在内存中的存储顺序符合DSS在RGB565模式下读取的预期。这可能需要在小端（Little-Endian）系统上对数据字进行适当的打包。一个常见的错误是画面出现色彩错乱，一半原因可能就在这里。
• 验证方法：在初期验证时，可以构造一个简单的测试图案（比如彩条）的YUV422数据，配置好管道后输出，用逻辑分析仪或支持原始数据捕获的接收端抓取数据，与源数据逐字节比对，确保完全一致。

3.2 配置时分复用（TDM）输出模式

我们的VID管道现在输出的是16位/像素的“RGB565”数据流。但物理接口是8位的，如何传输？这就需要启用TDM模式。TDM允许将一个像素的数据分在多个时钟周期内送出。

对于16位到8位的转换，我们配置为“2 cycles per pixel”模式。下图说明了数据在时钟周期内的映射关系：

时钟周期1 (Cycle 1): 输出高8位数据 (D[15:8]) -> 对应YUV422像素的Y[7:0] 时钟周期2 (Cycle 2): 输出低8位数据 (D[7:0]) -> 对应YUV422像素的U[7:0]或V[7:0]（取决于像素位置）

具体寄存器配置如下：

DISPC_VP1_CONTROL.TDMENABLE = 0x1; // 启用TDM模式 DISPC_VP1_CONTROL.TDMPARALLELMODE = 0x0; // 选择8位并行输出接口 DISPC_VP1_CONTROL.TDMCYCLEFORMAT = 0x2; // 2个时钟周期传输1个像素 // 配置数据线映射：定义每个周期数据线D[7:0]上承载的是原始32位数据中的哪些位。 // 对于RGB565伪装YUV422，且希望按字节顺序输出，通常配置如下： DISPC_DATA1_CYCLE1 = 0x8; // 第一个周期，输出高8位 (D[15:8]) DISPC_DATA1_CYCLE2 = 0x8; // 第二个周期，输出低8位 (D[7:0]) DISPC_DATA1_CYCLE3 = 0x0; // 我们只用2个周期，第三个周期未使用

时序计算与实战要点：

• 像素时钟（PCLK）翻倍：这是最容易忽略的一点！因为每个像素现在需要2个时钟周期，所以最终的输出像素时钟频率必须是原始视频帧率所需频率的两倍。例如，对于1280x720@30fps的视频流： 原始带宽 = 1280 * 720 * 30 = 27.648 MHz（像素/秒）。 启用TDM后，所需PCLK = 27.648 MHz * 2 =55.296 MHz。 你必须在DSS的时序生成器（Timing Generator）中配置这个翻倍后的PCLK频率，否则输出帧率会减半，或者出现时序混乱。
• 同步信号时序：HSYNC、VSYNC、DE的时序参数（HFP, HSW, HBP, VFP, VSW, VBP）仍然按照原始像素维度（1280x720）来配置，而不是按照TDM周期数。DSS内部会处理好同步信号与TDM周期之间的对齐。
• 物理连接：确保你的板级设计上，DSS的8位数据线正确连接到串行器（如UB933）的8位数据输入口。同时，PCLK、HSYNC、VSYNC、DE这些离散同步信号也必须一并连接。

4. 系统集成：在SRV应用中的完整数据流

理解了底层硬件配置原理后，我们要把它放到一个真实的SRV应用场景中。一个典型的SRV系统通常包含多个视频源：DSP算法生成的泊车辅助线（YUV422）、GPU渲染的3D鸟瞰图（RGB888）、以及MCU绘制的用户界面（RGB888）。这些图层需要在DSS内部进行叠加（Overlay），最终合成一帧画面输出。

4.1 数据流转与格式转换瓶颈

在标准的RGB888输出方案中，数据流是直观的：

1. DSP的YUV422辅助线图层 -> VID2管道。
2. GPU的RGB888鸟瞰图 -> VID3管道。
3. GUI的RGB888 UI图层 -> GFX管道。
4. 三个图层在DSS的叠加管理器（Overlay Manager）中混合。
5. 混合后的RGB888帧直接通过24位RGB接口输出。

但现在我们要输出YUV422，而DSS的叠加混合器必须在RGB色彩空间下工作。这意味着，所有输入图层在混合前都必须被转换到RGB空间。我们的YUV422辅助线图层在VID2管道中会被硬件CSC转换为RGB（这是我们不希望的，因为最终输出要YUV422）。更关键的是，混合后的结果是RGB888，我们需要把它再转换回YUV422才能输出。

因此，我们需要一个额外的“格式转换”步骤。TI DSS提供了一个完美的硬件模块来完成这个任务：回写管道（Writeback Pipeline）。回写管道可以将叠加管理器最终输出的画面捕获到内存中，并且其内置的CSC模块支持将RGB转换为YUV。

4.2 VISION SDK框架下的实现

在基于RTOS的VISION SDK框架下，实现相对直接。SDK提供了显示链路（Display Link）抽象，我们可以通过修改链路配置来插入回写捕获环节。

修改后的数据流如下：

1. 原有的三个图层（VID2, VID3, GFX）绑定到同一个叠加管理器（例如Overlay Manager #2），其输出不直接送到显示端口，而是路由到回写管道（Writeback）的输入。
2. 配置回写管道的输出格式为YUV422。这样，回写管道就会执行RGB888到YUV422的硬件转换，并将转换后的YUV422帧写入指定的内存缓冲区。
3. 新增一个显示链路任务，负责从上述内存缓冲区中取出YUV422帧。
4. 将这个YUV422帧，作为一个新的视频源，绑定到VID1管道。VID1管道就按照我们第三章所述的方法配置：输入格式设为RGB565（实际喂YUV422数据），启用TDM，输出离散同步信号。
5. VID1管道的输出连接到最终的物理显示端口（如VOUT1），输出标准的离散同步YUV422信号。

在VISION SDK的图形化配置工具或链路描述文件中，你需要增加一个Capture_dsswb的节点，并将其连接到原有的显示链路之后，再连接到新的Display_YUV422链路。这种基于数据流的编程模型，使得架构修改变得清晰。

4.3 PSDKLA (Linux DRM) 框架下的实现

在基于Linux的PSDKLA环境下，事情变得复杂一些，因为显示驱动遵循的是Linux内核的DRM/KMS框架。我们不能直接像在RTOS里那样“布线”，而需要按照DRM的概念来操作。

核心思路是利用“虚拟”的显示设备：

1. 创建虚拟CRTC用于合成：由于DRM要求每个显示平面（Plane）必须绑定到一个CRTC（显示控制器），我们首先创建一个不实际连接物理输出的“虚拟”CRTC（例如在驱动中模拟一个CRTC34）。将三个源图层（DSP的YUV422， GPU的RGB888， GUI的RGB888）的Plane绑定到这个虚拟CRTC上。这个CRTC负责合成，但其输出不指向任何物理编码器（Encoder）或连接器（Connector）。
2. 利用回写设备捕获帧：DSS的回写管道在Linux中通常表现为一个V4L2捕获设备，例如/dev/video11。编写一个用户空间的服务程序，使用标准的V4L2 API，将这个设备的输出格式设置为YUV422，并不断从它那里捕获帧缓冲区。这个缓冲区里的内容，就是经过虚拟CRTC合成并经由回写管道转换后的YUV422图像。
3. 将捕获的帧送显：将上一步捕获到的YUV422帧缓冲区，通过DRM的API，设置到另一个真实的、连接了物理端口的Plane（例如Plane37）上。将这个Plane绑定到真实的CRTC（例如CRTC38），该CRTC连接着实际的编码器和连接器（如DPI接口，连接UB933串行器）。
4. 配置真实CRTC/Plane：这个真实的Plane和CRTC，就需要配置成我们第三章所述的“RGB565输入+TDM YUV422输出”模式。用户空间程序提交的缓冲区虽然是YUV422数据，但在通过DRM接口设置帧缓冲区时，需要将其格式声明为DRM_FORMAT_RGB565（或对应的FourCC码），以此来“欺骗”驱动和硬件。驱动层需要确保该Plane对应的底层VID管道寄存器被正确配置为旁路和TDM模式。

这种方式相当于在Linux下构建了一个“内部环”：一个虚拟CRTC负责合成并输出到回写设备，另一个真实CRTC负责将回写设备捕获的内容以YUV422格式送出。虽然比VISION SDK的方案��了数据拷贝和用户空间交互的开销，但它严格遵循了Linux DRM模型，兼容性更好。

5. 调试、验证与常见问题排查

方案实现后， rigorous的验证至关重要。以下是我在实际项目中总结的验证步骤和排错经验。

5.1 验证方案

1. 硬件环回测试（首选）：

   • 方法：将Jacinto开发板DSS输出口的串行器（如UB933）的输出，直接通过同轴电缆环回到板载的视频输入端口（VIP）的解串器（如UB934）上。在软件中，配置VIP捕获此路视频信号。
   • 优势：无需外部显示设备，在单板上即可完成闭环验证。可以精确对比发送和接收到的数据。
   • 关键配置：在此测试中，建议DSS输出使用DE（数据使能）模式而非单独的HSYNC模式。因为VIP捕获对DE信号的支持通常更稳定，能避免因行消隐时序细微差异导致的捕获错位。

2. 外部显示器测试：

   • 方法：将DSS输出连接到支持YUV422输入的LCD屏幕或专业的视频分析仪。
   • 优势：真实环境验证，可以直观看到图像质量、色彩和同步稳定性。
   • 关键配置：连接大多数商用LCD屏时，建议使用HSYNC/VSYNC/DE模式。因为LCD控制器通常需要明确的HSYNC信号来标识行开始，对消隐期时序有固定要求。务必根据屏幕数据手册调整DSS的HFP、HSW、HBP等参数。

5.2 常见问题与排查清单

以下表格整理了实施过程中最容易遇到的典型问题及其排查思路：

5.3 性能与优化考量

• 带宽与内存：回写管道进行RGB888到YUV422的转换，以及后续的缓冲区拷贝，会消耗额外的内存带宽和CPU/DSP周期。需要评估在最高分辨率（如1080p）和帧率（如30fps）下，系统总带宽是否足够。
• 延迟：增加的格式转换和缓冲区传递环节会引入额外的处理延迟（通常在一到数帧之间）。对于实时性要求极高的ADAS应用（如依赖环视图进行低速障碍物检测），需要精确测量并评估此延迟是否在允许范围内。
• 功耗：启用额外的视频管道（回写、VID1）和进行格式转换，会比直接输出RGB888消耗更多的显示子系统功耗。在电池供电或对热设计有严格要求的项目中需予以关注。

6. 总结与延伸思考

通过上述的硬件配置技巧和系统级数据流重构，我们成功地在TI Jacinto/TDA平台上实现了标准的离散同步YUV422输出。这套方案的价值在于，它没有依赖任何非标特性或“黑魔法”，而是充分利用了DSS硬件已有的、文档化的功能，通过巧妙的配置组合达成了目标，因此具有很高的可靠性和可移植性。

在VISION SDK和PSDKLA两个不同软件生态下的实现，也体现了嵌入式系统软件架构的差异。VISION SDK的链路式设计更贴近硬件数据流，直观高效；而PSDKLA遵循Linux标准框架，虽然实现稍显迂回，但带来了更好的可维护性和社区支持。

最后，分享一个更深层次的体会：这个项目的本质是在固定的硬件约束下进行“协议转换”。DSS硬件是一个功能强大但接口固定的“黑盒”，我们的工作就是研究其数据手册，找到输入（RGB565格式数据+旁路模式）和输出（8位TDM接口+离散同步）的精确控制方法，从而让这个黑盒执行我们想要的转换功能。这种思路可以延伸到很多嵌入式显示问题，比如输出其他非原生支持的色彩格式、实现特殊的视频特效旁路等。核心永远是：理解硬件数据流，善用旁路和重组功能，并通过严格的时序配置确保信号完整性。