第三章 ARINC661通信协议：数据包格式、消息类型与字节序
好，咱们进入通信协议这一章。说实话，ARINC661的协议设计得相当精巧，但初次接触时容易在细节上栽跟头。我当年第一次调试时，就因为字节序搞反了，盯着屏幕看了两个小时，愣是没找到问题在哪。
这一章，咱们把数据包格式、消息类型、字节序和对齐规则彻底讲透。
3.1 数据包格式：UA与DF的对话
ARINC661通信的核心，是UA（用户应用）和CDS（座舱显示系统）之间的数据交换。说白了，就是两个黑盒子在互相发消息。每个消息都是一个数据包，结构非常固定。
一个标准的数据包由两部分组成：数据头和数据体。
3.1.1 数据头结构
数据头固定为8字节，我习惯叫它“信封”。信封上写明了这封信是谁发的、发给谁、信有多长。
| 偏移量 | 字节数 | 字段名 | 说明 |
|---|---|---|---|
| 0 | 2 | Message ID | 消息标识符，区分消息类型 |
| 2 | 2 | Length | 整个数据包长度（含头） |
| 4 | 2 | Source ID | 发送方标识 |
| 6 | 2 | Destination ID | 接收方标识 |
嗯，这里要注意：Length字段包含的是整个数据包的长度，包括这8字节头。我见过有人只算了数据体长度，结果接收方解析到一半就断了。
3.1.2 数据体结构
数据体紧跟在头后面，长度不固定。它里面装的是具体的操作指令，比如“创建一个按钮”、“更新这个数值”、“删除那个控件”。
数据体的格式取决于消息类型。咱们下面细说。
3.2 消息类型：四种基本操作
ARINC661定义了四种核心消息类型。你想想看，座舱里任何一个控件的生命周期，都逃不出这四种操作：创建、删除、更新、事件。
3.2.1 创建消息（Create）
创建消息用于在CDS中实例化一个控件。比如你要在屏幕上放一个高度表，就得先发一条创建消息。
创建消息的数据体包含：
- Widget ID：控件的唯一标识，不能重复
- Parent ID：父控件的ID，用于构建层级树
- Widget Type：控件类型，比如按钮、标签、指针
- 参数列表：控件的初始属性，比如位置、大小、颜色
关键点：创建消息必须在更新或删除之前发送。我曾经在项目中遇到一个bug，控件还没创建就发了更新消息，结果CDS直接丢弃了那条更新，没有任何提示。排查了半天才发现是时序问题。
3.2.2 删除消息（Delete）
删除消息用于移除一个控件。很简单，只需要提供要删除的Widget ID。
但有个坑：删除父控件时，所有子控件也会被自动删除。这是ARINC661的默认行为。我建议你在删除前，先确认清楚层级关系，避免误删。
3.2.3 更新消息（Update）
更新消息是最常用的。它用于修改控件的属性，比如改变数值、切换颜色、移动位置。
更新消息的数据体包含：
- Widget ID：要更新的控件
- 参数ID：要修改哪个属性
- 新值：属性的新数值
举个例子，更新一个高度表的指示值：
// 伪代码示例
UpdateMessage msg;
msg.widgetID = 0x1001; // 高度表控件ID
msg.parameterID = 0x000A; // 指示值参数ID
msg.newValue = 35000; // 新高度：35000英尺3.2.4 事件消息（Event）
事件消息是从CDS发往UA的。当飞行员触摸屏幕、按下按钮时，CDS会生成事件消息，告诉UA“有人操作了”。
事件消息包含：
- Widget ID：哪个控件被操作了
- 事件类型：按下、释放、拖动等
- 事件数据：比如触摸坐标、按键值
我的经验：事件消息的处理一定要快。UA收到事件后，必须在规定时间内响应，否则CDS会认为UA死机了。我曾经在项目中因为事件处理线程阻塞，导致整个显示系统卡死，教训深刻。
3.3 字节序与对齐规则
这一节是很多人容易忽略的，但恰恰是坑最多的地方。
3.3.1 字节序：大端还是小端？
ARINC661规定使用大端字节序（Big-Endian）。也就是说，高位字节在前，低位字节在后。
举个例子，数值0x1234在内存中的存储方式：
- 大端：0x12 0x34
- 小端：0x34 0x12
为什么用大端？因为航空电子系统对可读性要求高。大端序更符合人类阅读习惯，调试时用十六进制查看器一眼就能看出数值。
注意：如果你用的处理器是小端序（比如x86），必须在发送前做字节序转换。我见过一个团队，在ARM平台上开发时忘了转换，结果所有数值都反了。高度表显示-1000英尺，你说吓不吓人？
3.3.2 对齐规则
ARINC661要求数据包中的每个字段都按2字节对齐。也就是说，每个字段的起始地址必须是2的倍数。
为什么要有对齐规则？说白了，是为了提高CPU的访问效率。很多嵌入式处理器访问未对齐的数据时，会触发异常或降低性能。
举个例子，假设数据体中有三个字段：
// 错误示例：未对齐
字段A: 1字节 (偏移0)
字段B: 2字节 (偏移1) // 未对齐！1不是2的倍数
字段C: 1字节 (偏移3)
// 正确示例：对齐
字段A: 1字节 (偏移0)
填充: 1字节 (偏移1) // 填充字节，保证B对齐
字段B: 2字节 (偏移2) // 对齐了
字段C: 1字节 (偏移4)
填充: 1字节 (偏移5) // 填充字节，保证整体长度是2的倍数嗯，这里要注意：整个数据包的长度也必须是2的倍数。如果数据体长度是奇数，需要在末尾补一个填充字节。
3.4 实战中的避坑指南
讲了这么多理论，我分享几个实际项目中踩过的坑。
我曾经犯过的错：
- 字节序搞反：在x86开发机上调试一切正常，部署到PowerPC目标机后全部乱码。后来才发现是字节序问题。从那以后，我都在代码里显式调用字节序转换函数，绝不依赖编译器默认行为。
- 对齐填充遗漏：有一次我手动构造数据包，忘了加填充字节。结果CDS解析时直接报错，整个显示系统崩溃。后来我改用结构体打包，让编译器自动处理对齐，再也没出过问题。
- 消息ID重复：团队里两个人同时添加了新消息，用了相同的ID。结果CDS收到消息后，执行了错误的操作。后来我们建立了消息ID注册表，每个人新增前先查表。
3.5 小结
这一章咱们把ARINC661的通信协议讲透了。数据包格式、四种消息类型、字节序和对齐规则，这些都是基本功。你想想看，如果连消息都发不对，后面的显示设计根本无从谈起。
下一章，咱们会深入讲解控件定义与参数配置。到时候你会看到，这些通信协议是如何支撑起整个座舱显示系统的。
记住我这句话：协议是骨架，控件是血肉。骨架搭稳了，后面才能游刃有余。