MPC860 SCC HDLC模式解析：总线碰撞检测与异步透明传输实战

1. MPC860 SCC HDLC模式深度解析：从硬件原理到实战编程

在嵌入式通信领域，尤其是工业控制、电信接入设备和早期的网络设备中，飞思卡尔（现恩智浦）的MPC860 PowerQUICC系列处理器堪称一代经典。其内置的串行通信控制器（SCC）功能之强大，设计之精妙，至今仍被许多资深工程师津津乐道。其中，SCC对HDLC协议的支持，特别是其独特的HDLC总线模式和异步HDLC模式，是实现高效、可靠数据链路层通信的利器。今天，我们就抛开枯燥的数据手册，从一个实际调试过多个项目的工程师视角，来彻底拆解MPC860 SCC的HDLC世界，聊聊寄存器配置背后的逻辑、总线模式下的碰撞仲裁机制，以及异步模式下那些容易踩坑的透明字符处理。

HDLC协议本身是一个“古老”但极其健壮的链路层协议，它的核心思想是通过特定的帧结构（标志位、地址、控制信息、FCS）和一套严格的规程来保证数据可靠传输。MPC860的SCC将这套规程的大部分工作硬件化了，比如自动插入/删除零比特、CRC生成与校验、帧标志的识别与生成等。这意味着，你只需要配置好几个关键寄存器，准备好数据缓冲区，CPU就可以从繁重的比特流处理中解放出来，专注于应用层逻辑。这种硬件加速对于当时主频不高的嵌入式CPU来说，是提升系统吞吐量和实时性的关键。

1.1 核心模式概览与选型考量

MPC860的SCC支持多种HDLC衍生模式，选择哪种模式取决于你的物理层和网络拓扑。简单来说，可以分成三大类：

1. 标准HDLC模式：最基础的同步HDLC，用于经典的点对点（PPP）或点对多点（如X.25）连接。通信双方需要独立的时钟线（或从数据流中恢复时钟），链路是独占的，没有碰撞问题。
2. HDLC总线模式（带碰撞检测）：这是MPC860的一个特色功能。它允许多个节点通过一根开漏（Open-Drain）总线连接，共享同一个通信信道，类似于一个简单的局域网（LAN）。硬件会自动检测总线上的数据碰撞，并按照既定优先级进行仲裁和重传。这非常适合需要多个设备平等通信或主从轮询的工业现场总线场景。
3. 异步HDLC模式：用于支持PPP over Async（例如通过RS-232串口拨号）和IrDA（红外数据协议）。它本质上是将HDLC的帧结构承载在异步串行字符（8N1格式）上，并增加了RFC 1549定义的透明字符处理机制。

选型时，第一个要问自己的问题就是：你的设备需要和几个对方通信？是固定的一对一，还是一个总线上的多个节点？如果是多个节点，是主从轮询（半双工）还是多主竞争（需要碰撞检测）？物理接口是同步串行（有时钟线）还是异步串行（如UART）？回答清楚这些问题，模式的选择就明朗了。

注意：HDLC总线模式和异步HDLC模式在寄存器配置上有一些关键位是不同的，一旦选错模式，可能导致数据根本无法收发，或者CRC校验永远失败。在项目初期进行硬件设计时，就必须明确通信模式，并据此设计原理图（比如总线模式需要连接CTS引脚用于碰撞检测）。

2. HDLC总线模式详解：硬件实现的碰撞检测与仲裁

HDLC总线模式是我认为MPC860 SCC最精彩的设计之一。它巧妙地将局域网中的载波侦听多路访问/碰撞检测（CSMA/CD）思想，用纯硬件逻辑在HDLC协议上实现了出来。让我们深入其核心机制。

2.1 总线拓扑与硬件连接

典型的HDLC总线是一个多主（Multi-Master）配置。所有节点的TXD（发送）引脚通过一个上拉电阻连接到共享总线，同时，所有节点的CTS（清除发送，在此模式下用作碰撞检测输入）引脚也连接到这根总线上。所有节点共享同一个发送/接收时钟（TCLK/RCLK）。这就形成了一个“线与”（Wired-OR）逻辑：任何一个节点输出低电平（0），总线就是低电平；只有所有节点都输出高电平（1）或处于高阻态，总线才被上拉电阻拉高。

+5V | R (上拉电阻) | |---- CTS & TXD 总线 | |-----|-----|-----| | | | | 节点A 节点B 节点C ... (MPC860) (MPC860) (MPC860)

在这种配置下，任何一个节点都可以发起传输。问题来了：如果两个节点同时开始发送，怎么办？这就是碰撞检测要解决的。

2.2 碰撞检测的硬件原理

碰撞检测的核心逻辑在于比较“自己发送的比特”和“总线上实际呈现的比特”。在MPC860中，这个过程完全由硬件自动完成：

1. 发送前监听（载波侦听）：当节点准备发送时，它的SCC控制器会通过CTS引脚持续监听总线状态。它会计数连续收到的“1”的个数。只有当连续收到8个“1”（代表总线空闲）时，它才会认为信道空闲，并开始发送帧起始标志0x7E。
2. 发送中比较（碰撞检测）：一旦开始发送，控制器会在每个比特时间的中间点（使用TCLK的上升沿采样）采样CTS引脚的状态，并与自己当前正在发送的比特（TXD）进行比较。
   • 匹配（TXD == CTS）：说明总线上只有本节点在发送，或者与其他发送“0”的节点无冲突（因为“线与”逻辑下，0优先）。继续发送。
   • 不匹配（TXD == 1 但 CTS == 0）：碰撞发生！这说明本节点试图发送“1”（释放总线为高），但总线上有另一个节点正在发送“0”（将总线拉低）。根据“线与”逻辑，0具有优先级。

这里有一个关键点：发送“0”的节点赢得碰撞。因为“线与”下，只要有一个节点发0，总线就是0。因此，当碰撞发生时，发送“0”的节点会 unaware（因为它发送的0和总线上的0匹配），继续完成自己的帧传输。而发送“1”的节点会检测到不匹配（自己发1，总线是0），它会立即停止发送，并进入退避重传流程。

2.3 优先级与公平性机制

仅仅检测碰撞还不够，还需要一套规则来防止某个节点“饿死”其他节点。MPC860的HDLC总线模式实现了一套简单的优先级切换机制：

• 普通优先级：节点在尝试发送前，需要侦听到总线连续8个比特时间为“1”（空闲）。
• 低优先级：当一个节点成功发送完一帧数据后，它会自动将自己的优先级降低。下次它想再发送时，需要侦听到总线连续10个比特时间为“1”。
• 优先级恢复：如果一个处于低优先级的节点在尝试发送时再次遭遇碰撞（即它等待了10个“1”后发送，仍然碰撞），那么在这次尝试失败后，它的优先级会恢复为普通优先级（只需等待8个“1”）。

这个机制保证了基本的公平性。刚刚成功发送的节点会“礼让”一下，给其他等待的节点一个机会。如果其他节点都不发送（总线持续空闲10个比特以上），那么这个节点才能再次发送。

2.4 延迟RTS模式与TDM结合的应用

在一些复杂的组网中，HDLC总线可能不是终点。手册中提到了“延迟RTS模式”和“使用时隙分配器（TSA）”两种高级配置。

延迟RTS模式常用于本地总线通过一个线路驱动器连接远程传输线的场景。通常，RTS信号在帧标志的第一比特就开始有效，用于使能线路驱动器。但如果线路驱动器本身有延迟，可能导致本地总线上的碰撞检测时序错乱。设置PSMR[BRM] = 1可以将RTS激活延迟一个比特时间，从而将本地总线的电气碰撞效应与传输线隔离。

与TSA结合则是一种非常强大的设计，用于构建基于时分复用（TDM）总线的多通道共享网络。想象一下，一条E1/T1链路被划分为多个时隙（Time Slot）。你可以将多个MPC860节点的SCC配置在同一个HDLC总线模式下，但它们的收发时钟和数-据引脚（L1TXD,L1RXD）连接到TSA，由TSA控制只在分配给它们的时隙内激活。这样，多个逻辑上的HDLC总线可以共享一条物理TDM链路。碰撞检测仍然通过每个SCC独立的CTS引脚进行，但只会在它们共享的时隙内发生。这种架构非常适合需要多条低速逻辑链路复用到一条高速物理链路的集中器设备。

3. 异步HDLC模式编程要点：PPP与IrDA的基石

异步HDLC模式是连接“同步HDLC世界”和“异步字符流世界”的桥梁。它的主要任务是把HDLC帧用异步串行字符（8N1）包装起来，并处理RFC 1549定义的“透明传输”问题。

3.1 透明字符处理：RFC 1549的精髓

在异步线路上（比如RS-232），某些控制字符（如XON/XOFF）可能被中间设备（如调制解调器）解释为流控命令，从而破坏数据。此外，HDLC的标志位0x7E和转义字符0x7D本身也可能出现在用户数据中。RFC 1549的解决方案是“字符填充”：

• 发送端（编码）：SCC硬件会自动扫描待发送缓冲区中的每一个字节。
  • 如果字节等于标志字符（PPP为0x7E， IrLAP为0xC0或0xC1）或控制转义字符（0x7D），则将其替换为两字节序列：0x7D后跟(原字节 ^ 0x20)。
  • 如果字节值在0x00-0x1F之间（ASCII控制字符），并且发送控制字符映射表（Tx Control Character Map）中对应位被置位，则同样进行上述替换。
  • 例如，数据中的0x7E会被替换为0x7D, 0x5E；0x01（如果被映射）会被替换为0x7D, 0x21。
• 接收端（解码）：SCC硬件对接收到的字符流进行反向操作。
  • 如果收到0x7D，则将其丢弃，并将下一个字节与0x20进行异或还原，再将结果存入缓冲区。
  • 如果收到一个在接收控制字符映射表（Rx Control Character Map）中被标记的字符，则直接丢弃（认为它是中间设备插入的）。

这个过程完全由SCC的微码自动完成，对CPU透明。你需要做的，就是在参数RAM中正确设置BOF（帧开始标志）、EOF（帧结束标志）、ESC（转义字符）以及两个控制字符映射表。

3.2 参数RAM配置与常见陷阱

异步HDLC模式的参数RAM布局是配置的重点和易错点。除了标准的缓冲区描述符表，以下几个字段必须正确初始化：

// 假设 SCC 参数 RAM 基地址为 sccp typedef struct scc_async_hdlc_param { uint32_t reserved1; uint32_t c_mask; // CRC 常数，必须初始化为 0x0000F0B8 uint32_t c_pres; // CRC 预置值，必须初始化为 0x0000FFFF uint16_t bof; // 帧开始标志：PPP用0x7E， IrLAP用0xC0 uint16_t eof; // 帧结束标志：PPP用0x7E， IrLAP用0xC1 uint16_t esc; // 控制转义字符，固定为0x7D uint32_t reserved2; uint16_t zero; // 必须清零 } scc_async_hdlc_param_t; scc_async_hdlc_param_t *param = (scc_async_hdlc_param_t *)&sccp->scc_psmr; param->c_mask = 0x0000F0B8; param->c_pres = 0x0000FFFF; param->bof = 0x7E; // 对于PPP param->eof = 0x7E; // 对于PPP param->esc = 0x7D; param->zero = 0;

陷阱1：CRC常量和预置值。这两个值c_mask和c_pres是CRC-CCITT计算所需的硬件初始化值，必须严格按照手册设置。我见过不止一个项目因为这里填错，导致对方设备永远报CRC错误，排查了整整两天链路层和物理层。

陷阱2：BOF/EOF混淆。对于PPP，开始和结束标志都是0x7E。但对于IrLAP，开始标志是0xC0，结束标志是0xC1。如果搞反了，帧边界识别就会出错。

陷阱3：控制字符映射表。这个表（位于参数RAM更早的偏移位置）决定了哪些ASCII控制字符需要被透明处理。如果你不确定中间设备（如老式调制解调器）会如何处理这些字符，一个保守的做法是将0x00-0x1F全部映射（即填充）。但这会增加协议开销。最佳实践是根据实际链路测试来调整。

3.3 发送与接收流程的细微差别

异步HDLC的发送接收流程虽然也是基于BD（缓冲区描述符）链，但有一些细节需要注意：

• 发送：你提供给SCC的发送缓冲区数据，应该是已经包含HDLC地址字段和控制字段的完整帧信息部分。SCC会自动为你加上CRC和标志位，并在传输过程中进行透明编码。这意味着你的应用层协议（如PPP的LCP、IPCP包）需要自己构建地址和控制字段（对于PPP，通常是固定的0xFF和0x03）。
• 接收：SCC在将数据写入你的接收缓冲区时，已经去掉了标志位和透明转义字符，并且包含了最后两个字节的CRC。你的驱动需要在将数据上交协议栈前，检查BD中的状态位（如RXF- 帧接收完成，CR- CRC正确），并剥离CRC字段。如果CR位指示CRC错误，这一帧应该被丢弃。
• Abort序列：当CPU发出STOP TRANSMIT命令时，SCC会发送一个Abort序列（连续多个“1”），然后持续发送空闲字符（0xFF）。在异步模式下，这个Abort序列对于对端设备是明确的中断信号。

4. 实战编程：从寄存器配置到驱动调试

理论说再多，不如一行代码。下面我们以HDLC总线模式为例，梳理一遍关键的初始化步骤和调试心得。异步HDLC模式的初始化与之类似，主要区别在于GSMR的模式选择位和参数RAM的配置。

4.1 HDLC总线模式初始化序列

假设我们使用SCC2，并希望启用RTS2/CTS2/CD2引脚功能。

1. 端口复用配置：首先，需要通过PAPAR,PADIR,PAODR等寄存器，将SCC2对应的TXD、RXD、RTS、CTS、CD引脚功能从通用IO切换到SCC专用功能。这一步常常被遗忘，导致引脚无输出。
2. 时钟配置：为SCC2提供时钟。可以从BRG（波特率发生器）获取，也可以从外部引脚CLKx引入。确保时钟频率是所需比特率的16倍（16x oversampling）。
3. 参数RAM初始化：清除SCC2的参数RAM区域，初始化缓冲区描述符（BD）环。对于HDLC，需要设置C_MASK和C_PRES（与异步HDLC相同）。
4. 协议特定模式寄存器（PSMR）配置：

   // PSMR2 - HDLC总线模式设置 // NOF: 帧标志数量，例如 0b0001 (两个标志，一个开放标志+一个额外标志) // RTE: 发送CRC使能，必须为1 // BUS: HDLC总线模式使能，必须为1 // BRM: 延迟RTS模式，根据硬件设计选择0或1 // CRC: CRC类型，0b00代表16-bit CCITT uint16_t psmr_val = 0; psmr_val |= (1 << 12); // NOF = 1 (两个标志) psmr_val |= (1 << 11); // RTE = 1 psmr_val |= (1 << 10); // BUS = 1 (启用总线模式！) // psmr_val |= (1 << 9); // BRM = 1 (如果需要延迟RTS) psmr_val |= (0b00 << 4); // CRC = 00 (CCITT) // 其他位保持默认0 SCC2_PSMR = psmr_val;

5. 通用SCC模式寄存器（GSMR）配置 - 第一步：先配置基本模式，但先不使能收发器。

   // GSMR_L2 - 高16位 // MODE: 0b0000 = HDLC 模式 // CTSS: 1 = CTS引脚功能控制发送（用于碰撞检测） // CDS: 1 = CD引脚功能控制接收 // 其他DIAG, RDCR, TDCR, TENC, RENC等按需设置 uint32_t gsmr_l_val = 0; gsmr_l_val |= (0b0000 << 28); // MODE = HDLC gsmr_l_val |= (1 << 18); // CTSS = 1 gsmr_l_val |= (1 << 17); // CDS = 1 gsmr_l_val |= (0b00 << 20); // DIAG = 00 (正常操作) gsmr_l_val |= (0b00 << 14); // TDCR = 00 (1x clock) gsmr_l_val |= (0b00 << 10); // RDCR = 00 (1x clock) gsmr_l_val |= (0b000 << 7); // TENC = 000 (NRZ) gsmr_l_val |= (0b000 << 4); // RENC = 000 (NRZ) // 注意：此时不设置 ENT 和 ENR 位！ SCC2_GSMR_L = gsmr_l_val;

6. 通用SCC模式寄存器（GSMR）配置 - 第二步：最后一步，再次写入GSMR_L，仅设置ENT和ENR位来使能收发器。这是一个重要的顺序，确保其他配置稳定后再激活。

   SCC2_GSMR_L = gsmr_l_val | (1 << 31) | (1 << 30); // 设置 ENT 和 ENR

4.2 调试技巧与常见问题排查

调试HDLC通信，尤其是总线模式，逻辑分析仪或带协议分析功能的示波器是必不可少的。以下是一些实战中总结的排查思路：

问题1：根本收不到数据，发送似乎也没反应。

• 检查时钟：这是第一嫌疑犯。用示波器测量TCLK引脚，确认有时钟信号，且频率正确。没有时钟，SCC寸步难行。
• 检查引脚复用：确认PAPAR等寄存器已正确配置，TXD/RXD等信号确实从SCC输出，而不是被锁定为GPIO。
• 检查GSMR的ENT/ENR：读回GSMR_L寄存器，确认第31和30位已被置1。有时在复杂初始化序列中，这两位的写入可能被意外覆盖。
• 检查BD环状态：确认发送BD的R（就绪）位已由CPU置1，并且接收BD的E（空）位已置1。SCC只会处理就绪/空的BD。

问题2：能发送，但对方收不到；或对方能发，我方收不到。

• 检查电平与物理连接：对于开漏总线，测量总线在不发送时的电压，应该是被上拉电阻拉高。发送时，应能看到明确的0/1变化。确认所有节点的TXD、CTS都正确连接到总线，且共地良好。
• 检查帧结构：用逻辑分析仪捕获TXD上的数据流。看看是否以标志位0x7E开始和结束？中间数据是否有零比特插入（连续5个1后插入一个0）？CRC是否正确？这能帮你判断SCC的HDLC处理是否正常。
• 检查碰撞检测逻辑（仅总线模式）：让两个节点同时尝试发送。观察在碰撞发生时，发送“0”的节点是否继续，发送“1”的节点是否停止。可以在代码中检查SCC事件寄存器（SCCE）的TXE（发送错误）位，碰撞会导致该位置位。

问题3：通信不稳定，偶尔丢帧或CRC错误。

• 检查缓冲区大小：手册中明确警告：“Frames larger than 256 bytes cause a busy (out-of-buffers) condition”。确保你的接收BD缓冲区足够大，或者使用多个BD链接来接收长帧。一个常见的错误是只准备了一个256字节的BD，却试图接收1500字节的IP包。
• 检查时钟抖动和同步：在高速率下，时钟质量至关重要。时钟抖动可能导致采样错误。确保时钟源稳定，布线远离噪声源。
• 检查中断服务程序（ISR）效率：如果丢帧，可能是ISR处理太慢，来不及清空已满的接收BD，导致SCC没有可用的空BD而丢弃后续数据。优化ISR，或者使用BD轮询方式。

问题4：异步HDLC模式下，对端设备报告“非法字符”或协议无法建立（如PPP LCP协商失败）。

• 检查透明字符处理：最可能的原因是控制字符映射表配置错误。尝试将发送和接收控制字符映射表全部置为0xFFFFFFFF（映射所有控制字符），看问题是否消失。如果消失，再逐步缩小映射范围以优化效率。
• 检查BOF/EOF/ESC设置：确认它们符合对端协议要求（PPP是0x7E/0x7E/0x7D，IrLAP是0xC0/0xC1/0x7D）。
• 捕获原始字符流：在SCC的TXD引脚上捕获数据，看看发出的字节流是否正确。例如，数据中的0x7E是否被正确替换为0x7D, 0x5E？这能直接验证SCC的透明编码是否工作。

4.3 性能优化考量

• 缓冲区描述符环大小：对于高速或突发数据流，增大BD环的长度可以减少CPU因频繁处理中断而带来的开销。但也会增加内存占用和数据结构管理的复杂性。需要根据数据流量和CPU负载权衡。
• 使用NMSI vs TDM：如果只有一个HDLC信道，使用非复用串行接口（NMSI）最简单。如果需要多个HDLC信道，或者要与其他协议（如UART、BISYNC）共享SCC，则需要使用时分复用（TDM）模式，这涉及到更复杂的SI（串行接口）和TSA（时隙分配器）配置，但能极大提高硬件资源利用率。
• 总线模式下的上拉电阻与波特率：开漏总线的上升时间受上拉电阻和总线电容限制，这决定了最高可用波特率。电阻越小，上升越快，但功耗越大。需要根据总线长度、节点数量计算合适的RC常数，并在实际环境中测试眼图。手册中提到的使用非对称占空比的时钟（低电平时间更长）来给上升沿更多时间，是一种有效的硬件优化技巧。

MPC860的SCC HDLC控制器是一个功能极其丰富的模块，其设计思想体现了那个时代通信处理器的精髓：将复杂的、耗时的协议处理任务卸载到专用硬件，让CPU专注于业务逻辑。深入理解其总线模式的碰撞仲裁、异步模式的透明处理，不仅能帮你搞定MPC860上的开发，其背后蕴含的通信系统设计理念，对理解其他嵌入式网络协议栈也大有裨益。调试过程虽然可能充满挑战，但当你用逻辑分析仪看到总线上完美的HDLC帧，各个节点有序地竞争、发送、应答时，那种成就感是无与伦比的。记住，多看手册，善用调试工具，从物理层到链路层逐层排查，问题总能解决。