DSP/BIOS下UART驱动设计：硬件抽象与软件模拟实现详解

1. 项目概述与核心价值

在嵌入式系统开发，尤其是基于德州仪器（TI）数字信号处理器（DSP）的项目中，串行通信是连接传感器、上位机、调试终端或其他外设的“生命线”。UART（通用异步收发传输器）因其简单、可靠、成本低廉，成为最常用的串行接口之一。然而，在资源受限、实时性要求高的DSP环境中，如何高效、稳定地驱动UART硬件，甚至在缺乏专用UART硬件时“无中生有”地实现串口功能，是每个嵌入式工程师都会面临的挑战。

我曾在多个工业控制和数据采集项目中，与TMS320C54x、C55x和C6000系列DSP打交道，深刻体会到一套设计良好的设备驱动对于项目成败的关键作用。DSP/BIOS提供的IOM（输入/输出管理器）设备驱动模型，正是为了解决这类问题而生。它定义了一套标准化的驱动框架，将硬件操作细节封装起来，向上提供统一的API。本文要深入剖析的，就是基于此模型实现的、同时支持硬件UART和软件模拟UART的驱动方案。

这套方案的精妙之处在于其分层与抽象的设计思想。它将驱动分为两层：通用UART层（UARTMD）和硬件特定层（UARTHW）。通用层负责与DSP/BIOS的IOM模型对接，处理数据缓冲、队列管理、通道状态等“通用杂务”；而硬件特定层则专心与具体的物理外设（如16550 UART芯片）或模拟外设（如McBSP端口）打交道。这种设计带来了巨大的灵活性：应用程序无需关心底层是真实的UART芯片还是由McBSP“伪装”的UART，都可以通过相同的GIO、SIO或PIP接口进行读写操作。对于需要在不同DSP平台间移植代码，或者在同一块板卡上灵活配置通信接口的项目来说，这种硬件抽象能力价值连城。

2. 驱动架构深度解析：IOM模型与分层设计

要理解这个UART驱动的实现，必须先吃透DSP/BIOS的IOM设备驱动模型。你可以把它想象成一个公司的管理体系：应用程序是提出需求的业务部门，类驱动（Class Driver）如GIO、SIO是标准化的流程管理部门，而迷你驱动（Mini-Driver）就是我们实现的UART驱动，它才是真正在一线干活的“技术专家”。

2.1 IOM模型的工作流程

当应用程序调用SIO_get或GIO_read发起一个读操作时，这个请求会被封装成一个IOM_Packet数据包，传递给类驱动。类驱动随后调用迷你驱动的mdSubmitChan函数，将这个“任务包”提交给我们。我们的驱动核心工作就是处理这个包：如果是读请求，就从硬件（或内部缓冲区）获取数据填充包内的缓冲区；如果是写请求，则将包内缓冲区的数据发送出去。处理完成后，我们通过调用包内指定的回调函数来“上报”任务完成状态。

整个过程中，IOM模型帮我们管理了多任务环境下的同步、异步I/O调度问题。我们的驱动只需要专注于“如何从特定硬件收/发一个字节”这个最本质的问题。这种分工极大地降低了驱动开发的复杂度。

2.2 UART驱动的双层架构实现

我们的UART驱动严格遵循了IOM模型，并进一步将自己划分为两层，这是其设计的核心亮点。

第一层：通用UART迷你驱动（UARTMD）这一层是“大脑”和“调度中心”。它不关心数据是从16550芯片的寄存器读出来的，还是从McBSP的DR引脚采样解码出来的。它的核心职责包括：

1. IOM接口适配：实现mdBindDev，mdCreateChan，mdDeleteChan，mdSubmitChan，mdControlChan等IOM要求的标准函数接口，成为类驱动合格的“供应商”。
2. 数据包与队列管理：维护每个通道的请求队列（QUE_Obj）。当多个读写请求同时到达时，它能按顺序排队处理，避免数据混乱。
3. 环形缓冲区管理：内部维护一个CIRC_Obj（环形缓冲区）。这是实现高效流控的关键。当应用程序没有及时读取数据时，硬件中断收到的字符可以暂存于此；当应用程序写入速度超过硬件发送能力时，数据也可以在此缓冲。这有效避免了数据丢失，平滑了数据流。
4. 事件回调机制：管理应用程序注册的事件通知（如CTS状态变化、奇偶校验错误等）。当底层硬件层上报事件时，通用层负责判断该事件是否在应用程序的关注列表（evtMask）内，如果是，则调用应用程序注册的回调函数。

第二层：硬件特定层（UARTHW）这一层是“手”和“脚”，是直接操作硬件的部分。它向上对通用层提供一组标准化的接口函数（如UARTHW_writeChar，UARTHW_getModemStatus），向下则与具体硬件绑定。

• 对于硬件UART（如DSK5402板载16550）：这一层就是一组对UART芯片寄存器进行读写的函数。UARTHW_writeChar函数就是将一个字节写入THR（发送保持寄存器）；UARTHW_getModemStatus就是读取MSR（调制解调器状态寄存器）。
• 对于软件UART（基于McBSP模拟）：这一层的工作就复杂得多。它需要配置McBSP（多通道缓冲串行口）和DMA（直接内存访问），将同步的McBSP时序“模拟”成异步的UART信号。UARTHW_writeChar函数需要将待发送的字符按照UART帧格式（起始位+数据位+停止位）编码成一串比特流，放入DMA传输缓冲区；UARTHW_getModemStatus这类函数可能直接返回不支持，因为软件模拟无法提供真实的硬件状态线。

这种架构的优势是显而易见的。可移植性：如果你要把代码从C5402移植到C6711，只需要更换底层的uarthw_dsk5402.l54库为uarthw_c6x1x_mcbsp.l62库，上层的应用程序和通用驱动代码几乎不用改动。可维护性：所有硬件相关的“脏活累活”被隔离在一个小模块里，调试和优化都集中在此处。可扩展性：如果你想支持一种新的UART芯片，只需要按照UARTHW_接口规范实现一套新的底层函数，即可无缝接入现有系统。

3. 硬件UART驱动实现详解（以DSK5402的16550为例）

硬件UART驱动的实现相对直观，因为16550这类芯片已经将UART协议的大部分复杂性用硬件实现了。我们的驱动本质上是一个“寄存器配置器”和“中断服务员”。

3.1 初始化与配置流程

驱动的初始化始于UARTHW_attach函数。这个函数在DSP/BIOS启动阶段，由通用层在mdBindDev中调用。它的工作流程如下：

1. 解析配置参数：从传入的UARTHW_DSK5402_Params结构中获取波特率、数据位、停止位、奇偶校验和流控方式。如果应用未提供，则使用默认参数（115200， 8N1， 无流控）。
2. 计算波特率除数：这是关键一步。16550的波特率发生器基于一个基准时钟（通常是1.8432MHz或3.072MHz的晶振）工作。需要根据目标波特率计算除数锁存器（DLL和DLH）的值。公式为除数 = 基准时钟频率 / (16 * 期望波特率)。计算出的除数必须是整数，否则会产生波特率误差。例如，对于1.8432MHz时钟和115200波特率，除数为1843200/(16*115200) = 1。
3. 配置线路控制寄存器（LCR）：设置数据位长度（5/6/7/8）、停止位数（1/1.5/2）和奇偶校验类型（无/奇/偶/标志/空格）。需要先将LCR的Bit 7（DLAB）置1，以便访问波特率除数寄存器。
4. 配置FIFO控制寄存器（FCR）：使能或禁用FIFO，设置触发阈值。在资源紧张的DSP系统中，有时为了简化中断处理逻辑，会选择禁用FIFO，采用每个字节触发一次中断的模式。文档中提到的驱动实现就禁用了FIFO。
5. 配置调制解调器控制寄存器（MCR）：设置DTR、RTS等输出信号，以及是否启用中断。
6. 配置中断使能寄存器（IER）：决定哪些事件能触发中断。通常使能“接收数据可用”（Bit 0）和“发送保持寄存器空”（Bit 1）中断。对于需要监控CTS/DSR等状态线的应用，还需要使能“调制解调器状态改变”中断（Bit 3）。
7. 挂接中断服务程序（ISR）：将驱动自己的中断处理函数挂接到DSP/BIOS的HWI（硬件中断）管理器中，对应16550的中断向量（在DSK5402上是中断17）。

注意：配置寄存器时，顺序很重要。必须先设置DLAB位才能写波特率除数，写完后再清除DLAB位进行其他设置。同时，在使能中断前，最好先读取一次中断标识寄存器（IIR）以清除可能存在的未决中断标志，避免一开中断就误触发。

3.2 中断服务程序（ISR）的设计

中断处理是驱动实时性的核心。16550的中断有多种类型，需要在ISR中读取IIR来判别。

1. 中断判别：进入ISR后，首先读取IIR。Bit 0为0表示有中断待处理，Bit 1-3指示中断类型。
2. 接收数据中断（IIR=0x04）：从接收缓冲寄存器（RBR）读取数据。这里有一个关键点：不能简单地把读到的字节直接交给上层。如果应用程序之前通过mdSubmitChan提交了一个读请求包正在等待数据，我们应该把字节直接填入那个包的缓冲区。如果没有等待的读请求，则应将字节放入驱动内部维护的环形缓冲区（CIRC_Obj）中暂存。然后，调用通用层注册的cbRxHandler回调函数，通知上层“有新数据到达”。
3. 发送保持寄存器空中断（IIR=0x02）：这意味着芯片可以发送下一个字节了。驱动需要检查是否有待发送的数据。如果有（例如，有写请求包正在处理，且其缓冲区还有数据），则从缓冲区取出下一个字节，写入发送保持寄存器（THR）。如果所有数据都已发送完毕，则必须禁用“发送保持寄存器空”中断，否则会引发持续的中断风暴。当新的写请求到来时，再重新使能该中断。
4. 线路状态中断（IIR=0x06）：读取线路状态寄存器（LSR），检查是否有溢出错误（OE）、奇偶错误（PE）、帧错误（FE）或间隔中断（BI）。这些错误需要记录并通过cbLineStatus回调通知上层应用，应用可以根据策略决定是重发、报警还是忽略。
5. 调制解调器状态中断（IIR=0x00）：读取调制解调器状态寄存器（MSR），获取CTS、DSR、RI、DCD等状态线的变化，并通过cbModemStatus回调通知应用。

实操心得：在DSP/BIOS的HWI中，中断服务程序运行在最高优先级，必须尽可能短小精悍。我们的策略是“快进快出”：在ISR中只做最必要的硬件操作（读/写寄存器）和记录状态，将复杂的数据搬移、队列管理、回调通知等操作，通过调用cbRxHandler等函数，交给通用层在更合适的上下文（可能是SWI或任务级）中处理。这符合DSP/BIOS的实时编程原则。

3.3 数据流控的实现

硬件UART支持RTS/CTS硬件流控。在UARTHW_DSK5402_Params中，flowControl参数可以设置为UARTHW_DSK5402_FLOW_AFE_RTSCTS。

• 自动流量控制（AFE）：当驱动接收缓冲区快满时，通过UARTHW_setRTS函数将RTS线置为无效（高电平），通知对方“暂停发送”。当缓冲区有空间后，再置为有效（低电平）。同时，驱动会监控CTS线，只有当CTS有效（低电平）时，才允许调用UARTHW_writeChar发送数据。这部分逻辑通常由硬件特定层根据LSR/MSR的状态，在cbTxHandler被调用时判断执行。
• 注意事项：使能硬件流控时，必须确保连接双方的串口线完整连接了RTS和CTS线（通常是DB9接头的7脚和8脚），否则通信会挂起。

4. 软件UART驱动实现详解（基于McBSP模拟）

当目标DSP板卡没有硬件UART时，利用McBSP（多通道缓冲串行口）和DMA来模拟一个UART，是一种经典且实用的解决方案。其核心思想是：用同步通信硬件，通过精密的定时和软件解码，来模拟异步通信协议。

4.1 基本原理与挑战

UART是异步通信，没有时钟线，依靠双方约定的波特率来同步。每个字符帧以起始位（低电平）开始，然后是5-9位数据位，可选的奇偶校验位，以及1、1.5或2位停止位（高电平）。

用McBSP模拟的难点主要在接收端：

1. 起始位检测：如何让McBSP在Rx引脚出现下降沿（起始位开始）时，自动开始采样一帧数据？
2. 精确采样：如何确保在每个数据位的中间时刻进行采样，以避开边沿的抖动区域？
3. 时钟容错：双方时钟可能存在微小偏差，如何防止采样点逐渐“漂移”出数据位？

4.2 驱动实现的关键技术点

文档中的驱动采用了一种巧妙的设计来解决上述问题：

1. 硬件连接与触发设置：将外部异步数据线同时连接到McBSP的数据接收（DR）引脚和帧同步接收（FSR）引脚。将McBSP接收器配置为由FSR下降沿触发，且帧同步后忽略后续同步信号（FSRM=1， FSRP=0）。这样，当起始位的下降沿到来时，FSR的下降沿会触发McBSP开始接收一个完整的数据帧。

2. McBSP与DMA的协同配置：这是软件UART的引擎。驱动将McBSP配置为双相位帧（Dual-phase frame）。

• 第一相位：接收16个位（即16个串行时钟周期）。这对应UART帧中的起始位（1位）和第一个数据位（假设为8位数据位中的前几位，具体取决于过采样率）。
• 第二相位：接收8个位。这对应UART帧中剩余的数据位和部分停止位。 通过精心计算串行时钟（CLKR）的频率，使得16个CLKR周期正好等于UART的一个位时间。例如，对于115200波特率，一个位时间约8.68μs。如果设置CLKR频率为16 * 115200 = 1.8432 MHz，那么16个CLKR周期就是8.68μs，完美匹配一个位时间。这样，McBSP在每个位时间内采样16次（即16倍过采样）。

3. 数据解码：DMA将McBSP接收到的过采样数据（比如16个样本表示一个位）搬运到内存缓冲区。在DMA接收完成中断中，驱动软件开始解码：

• 对于每个位（由16个样本表示），检查中间位置的样本（例如第7或第8个样本）的电平，来决定该位是0还是1。这有效抵抗了边沿抖动。
• 根据UART帧格式，从这串比特流中识别出起始位、数据位和停止位，组合成一个完整的字节。
• 只检查停止位的前半部分。这样即使发送方和接收方时钟有微小偏差，导致停止位采样点有所偏移，只要偏移不超过半个位时间，通信仍能成功。这提供了更好的时钟容错性。

4. 发送实现：发送相对简单。驱动需要将待发送的字节，按照UART帧格式（起始位0 + 数据位 + 停止位1）预先编码成一个比特流。例如，对于8N1格式，一个字节需要编码成10个位（1+8+1）。这个比特流被放入DMA的发送缓冲区。McBSP发送器也被配置为双相位帧，以固定的时钟频率（同样是16*波特率）将这个比特流一位一位地发送出去。DMA采用双缓冲机制，确保发送的连续性。

4.3 配置结构与关键参数

软件UART的配置结构UARTHW_MCBSP_Params包含了所有必要的硬件参数：

• mcbspId：���用哪个McBSP端口（例如McBSP0， McBSP1）。
• dmaRxId/dmaTxId：用于接收和发送的DMA通道号（C5000系列特有，C6000使用EDMA，参数不同）。
• mcbspClkIn：McBSP的输入时钟频率。这是计算采样时钟分频器（CLKGDV）的基础。
• baud：目标波特��。驱动内部会根据mcbspClkIn和baud计算产生16倍波特率时钟所需的分频值。
• intrMask：中断掩码，用于控制使能哪些DMA中断。

计算示例：假设DSP CPU主频为100MHz，McBSP输入时钟（CLKSRG）来自CPU/2=50MHz。目标波特率为115200。我们需要CLKR时钟为16 * 115200 = 1.8432 MHz。McBSP的采样率发生器分频系数CLKGDV = (mcbspClkIn / (2 * desired_CLKR)) - 1。代入计算：CLKGDV = (50e6 / (2 * 1.8432e6)) - 1 ≈ 12.56。取整为12或13，会产生微小的波特率误差，需要评估是否在可接受范围内（通常误差应小于2%）。

4.4 不同DSP平台的实现差异与约束

文档提到了C54x， C55x和C6x平台的不同实现，主要差异和约束来自其DMA/EDMA架构和内存系统：

• C54x：其DMA只能访问低地址数据空间（地址小于0x4000）。因此，驱动内部用于DMA传输的缓冲区（rxBuffer，txBuffer）必须通过#pragma DATA_SECTION指令分配到特定的内存段（例如.uartbuf），并在链接器命令文件（.cmd）中将该段定位到DMA可访问的区域。
• C55x：DMA默认使用DARAM端口。因此，DMA缓冲区最好放在片内DARAM中以保证最高性能。同样可以通过#pragma DATA_SECTION指定。
• C6x11 (C621x/C671x)：使用EDMA，且CPU有缓存。如果DMA缓冲区位于可缓存（Cacheable）的内存区域，则存在缓存一致性问题。CPU写入缓冲区的数据可能还在Cache里，未更新到内存，导致EDMA发送了旧数据；EDMA接收的新数据在内存中，但CPU Cache里是旧数据。解决方案有两种：一是将缓冲区分配到非缓存内存区；二是在启动DMA传输前后，使用CSL库的缓存写回（CACHE_wb）和无效化（CACHE_inv）函数来手动维护一致性。

踩坑记录：在C6713项目上首次使用软件UART时，曾因为忽略了缓存一致性问题，导致发送的数据全是乱码。调试时发现，CPU写入发送缓冲区的数据是正确的，但用仿真器查看内存该区域，数据却是旧的。根本原因就是Cache未写回。后来在UARTHW_writeChar函数中，在填充缓冲区后立即调用CACHE_wb，问题得以解决。这是一个非常典型的DSP编程陷阱。

5. 应用层集成与配置实战

理解了驱动原理，最终目的是在应用程序中用好它。下面以一个典型的DSP/BIOS应用程序为例，展示如何集成和配置UART驱动。

5.1 静态配置（使用DSP/BIOS配置工具）

这是最常用的方式，适合在系统初始化时就确定通信参数。

1. 打开DSP/BIOS配置工具（.cdb文件）。
2. 在Instrumentation->DEV（设备驱动）下，右键点击User-Defined Devices，选择Insert UDEV。
3. 将新建的UDEV对象重命名为一个有意义的名称，如myUart。
4. 右键点击myUart，打开属性对话框，进行关键配置：
   • Init function table: 填入_UARTMD_init。这是通用UART层的初始化函数表。
   • Function table ptr: 填入_UARTMD_Fxns。这是驱动函数表指针。
   • Function table type: 选择IOM_Fxns（如果使用GIO接口）或DEV_Fxns（如果使用SIO接口）。
   • Device params ptr: 这是核心，指向一个UARTMD_DevParams结构体。我们需要在C代码中定义并初始化这个结构体及其包含的硬件参数结构。

5.2 代码示例：配置与使用硬件UART

假设我们在DSK5402上使用16550硬件UART，通过GIO接口进行通信。

#include <gio.h> #include <uartmd.h> #include <uarthw_dsk5402.h> /* 1. 定义并初始化硬件特定参数结构 */ UARTHW_DSK5402_Params hwParams = { UARTHW_DSK5402_FLOW_NONE, /* flowControl: 无流控 */ UARTHW_DSK5402_WORD8, /* wordSize: 8位数据位 */ UARTHW_DSK5402_DISABLE_PARITY, /* parity: 无校验 */ UARTHW_DSK5402_STOP1, /* stopBits: 1位停止位 */ UARTHW_DSK5402_BAUD_115200, /* baud: 115200 */ 0xFFFF /* intrMask: 使能所有中断 */ }; /* 2. 定义并初始化通用设备参数结构 */ UARTMD_DevParams devParams = { 0x0100, /* versionId: 驱动版本号 */ FALSE, /* packedChars: C54x/C55x特有，FALSE表示只处理低8位 */ (Ptr)&hwParams /* uarthwParams: 指向硬件参数结构 */ }; /* 3. 在DSP/BIOS配置工具中，将UDEV的`Device params ptr`设置为 &devParams */ /* 4. 应用程序代码 */ Void main() { GIO_Handle gioHandle; Char rxBuffer[100]; Int status; Uns modemStatus; /* 打开GIO设备，设备名与配置工具中的UDEV对象名一致 */ gioHandle = GIO_open("myUart", GIO_INOUT, NULL, NULL); if (gioHandle == NULL) { /* 处理打开失败 */ return; } /* 示例：读取调制解调器状态 */ status = GIO_control(gioHandle, UARTMD_GETMODEMSTATUS, &modemStatus); if (status == IOM_COMPLETED) { if (modemStatus & UARTMD_MSR_CTS) { /* CTS线有效，可以发送数据 */ } } /* 示例：注册事件回调，监听线路错误 */ UARTMD_NotifyStruct notify; notify.notifyFunc = myUartNotifyHandler; /* 应用定义的回调函数 */ notify.evtMask = UARTMD_EVT_PERR | UARTMD_EVT_FERR | UARTMD_EVT_OERR; status = GIO_control(gioHandle, UARTMD_REGISTER_NOTIFY, &notify); /* 示例：同步读取数据 */ status = GIO_read(gioHandle, rxBuffer, sizeof(rxBuffer)); if (status == IOM_COMPLETED) { /* 处理接收到的数据 */ } else if (status == IOM_PENDING) { /* 读操作已提交，将在后台完成，通过回调通知 */ } /* 示例：异步写入数据 */ GIO_Issue(gioHandle, GIO_WRITE, "Hello UART\n", 11, NULL, myWriteCallback, NULL); /* ... */ GIO_close(gioHandle); } /* 事件回调函数 */ Void myUartNotifyHandler(Uns evtStatus, Uns val) { if (evtStatus & UARTMD_EVT_FERR) { /* 处理帧错误 */ LOG_printf(&trace, "UART Framing Error detected!"); } /* 处理其他事件... */ }

5.3 动态创建与高级控制

除了静态配置，驱动也支持在运行时动态创建和配置。通过DEV_create函数，并传入一个包含参数的结构体，可以在不修改CDB配置的情况下创建设备实例。这对于需要根据运行情况（如从EEPROM读取配置）动态创建多个UART实例的应用非常有用。

控制命令UARTMD_SETBREAK，UARTMD_SETRTS等，为应用程序提供了底层的控制能力。例如，在实现某些特殊的工业协议时，可能需要主动拉低BREAK信号一段时间。

6. 调试技巧与常见问题排查

在实际项目中，UART通信不出问题几乎是不可能的。以下是我总结的一些调试经验和常见问题解决方法。

6.1 硬件连接与信号测量

问题现象：完全无通信，或数据全为乱码。

• 排查步骤1：确认硬件连接。使用万用表或示波器检查TX， RX， GND三线是否连接正确、牢固。特别注意：交叉连接TX和RX（A板的TX接B板的RX）。
• 排查步骤2：测量波特率。用示波器抓取TX引脚信号。测量一个位的时间宽度。对于115200波特率，一个位的时间应为约8.68μs。如果测量值偏差很大，检查DSP的系统时钟配置和驱动中的波特率计算参数（mcbspClkIn， 分频系数）。
• 排查步骤3（针对软件UART）：测量McBSP的CLKX/CLKR时钟。确认其频率是否为16 * 目标波特率。同时检查FSR引脚，是否在每个起始位的下降沿都有同步脉冲。

6.2 驱动配置与资源冲突

问题现象：驱动初始化失败，或通信不稳定。

• 排查步骤1：检查DSP/BIOS配置中的中断向量分配。确保UART或McBSP/DMA使用的中断号没有被其他设备占用。在C6000上，还要检查EDMA通道和参数RAM的分配是否冲突。
• 排查步骤2：检查内存配置。对于软件UART，务必确认DMA缓冲区（rxBuffer，txBuffer）所在的内存段（如.uartbuf）在链接器命令文件（.cmd）中已被正确定义，且其地址范围符合该型号DSP的DMA访问限制（如C54x的0x4000以下）。
• 排查步骤3：验证配置结构体参数。在调试器中，在UARTHW_attach函数入口处设置断点，检查传入的UARTHW_MCBSP_Params或UARTHW_DSK5402_Params结构体各字段的值是否与预期一致。一个常见的错误是mcbspClkIn填写了错误的CPU主频值。

6.3 数据错误与流控问题

问题现象：能收到数据，但偶尔有错误、丢包，或通信一段时间后死锁。

• 排查步骤1：启用并检查错误事件。在应用程序中注册UARTMD_EVT_OERR（溢出错误），UARTMD_EVT_FERR（帧错误）等事件通知。如果频繁收到溢出错误，说明接收端处理速度跟不上发送端。需要增大驱动内部环形缓冲区的大小（需修改UARTMD源码中的CIRC_Obj尺寸），或者优化应用程序的读取逻辑。
• 排查步骤2：检查流控。如果使能了RTS/CTS硬件流控，用示波器测量这两根线的电平。观察当接收缓冲区满时，RTS是否变为高电平（无效）以通知对方停止发送；当对方CTS无效时，本方是否停止了发送。如果流控逻辑失效，会导致缓冲区溢出丢数。
• 排查步骤3（针对软件UART）：检查过采样和解码逻辑。可以在cbRxHandler函数或DMA接收中断中，将McBSP接收到的原始过采样数据（16个样本表示一个位）通过其他端口（如另一个UART或LCD）打印出来，观察其波形。确认起始位、数据位、停止位的电平变化是否符合预期。这能帮助定位是硬件采样问题还是软件解码算法问题。

6.4 性能优化建议

1. 中断延迟：文档的附录给出了各驱动版本的最大中断禁用时间（约150-217个周期）。在实时性要求极高的系统中，需要评估此中断延迟是否可接受。如果不可接受，可以考虑优化驱动代码，将非关键操作移出中断服务程序，或者使用DMA链式传输减少中断频率。
2. 缓冲区大小：驱动内部环形缓冲区的大小直接影响通信的突发处理能力。对于大数据量传输，可以适当增大CIRC_Obj的尺寸。但也要考虑内存占用。
3. DMA优先级：对于软件UART，DMA/EDMA通道的优先级会影响数据传输的实时性。在C6000上，可以通过配置QPn（队列优先级）来调整EDMA传输的优先级，确保UART数据搬运不会被其他高带宽外设（如SDRAM控制器）长时间阻塞。
4. 功耗考虑：对于电池供电设备，当UART长时间空闲时，可以考虑在驱动层增加休眠机制。例如，在cbTxHandler发现发送队列为空，且一段时间内无接收活动后，调用UARTHW_resetDevice进入低功耗模式，并在下次有数据时通过外部中断唤醒。这需要硬件和驱动的协同设计。

这套DSP/BIOS下的UART驱动方案，将复杂的硬件操作和协议处理封装成简洁的API，其分层设计和硬件抽象的思想，至今在嵌入式驱动开发中仍具有很高的参考价值。无论是使用成熟的硬件UART，还是挑战性的软件模拟，它都提供了一套稳定可靠的框架。理解其内部机制，不仅能帮助我们在项目中用好它，更能提升我们设计复杂嵌入式系统驱动架构的能力。