[参考译文] CC2642R：UART2 接收中断触发器具有过长的延迟

尊敬的 runfa：

这是 UART2 TI 驱动程序的一个预期行为 、仅依赖于 RT（读取超时）中断来处理读取事件。  TRM 的第 21.4.6 节提供了对中断的准确描述、但您最感兴趣的是下面两个部分：

• Rx：当发生以下事件之一时、接收中断会改变状态：–如果 FIFO 启用且接收 FIFO 达到编程的触发电平。 当发生这种情况时、接收中断会置为高电平。 可以通过从接收 FIFO 读取数据直至其低于触发电平来清除接收中断、或者通过清除中断来清除该中断。 –如果 FIFO 禁用（深度为一个位置）并且接收到数据、从而填充该位置、则接收中断置为高电平。 可以通过对接收 FIFO 执行单次读取或清除中断来清除接收中断。
• RX 超时：当接收 FIFO 不为空且在 32 位周期内没有接收到更多数据时、接收超时中断将置为有效。 当 FIFO 通过读取所有数据变为空（或通过读取保持寄存器）、或者当 1 被写入中断清除寄存器 (UART：ICR) 的相应位时、接收超时中断会被清除。

本质上、UART2 驱动程序当前将使用 RX 超时值在接收到用于 FIFO 存储的数据超时后等待 32 位周期。  这考虑了在接收到初始字节后额外的 1.67ms、即 1/19200 = 52.08us * 32 = 1.67ms。

通过将 UART2CC26X2.c 文件直接复制到我的工程工作区、禁用 FIFO 启用（即删除了 HWREG (hwAttrs->baseAddr + UART_O_LCRH)|= UART_LCRH_FEN；从 UART2CC26X2_initHw 交换 UART_INT_RT 使用情况）、我能够观察到最短的延迟

我在下面提供了样片修改。  当然、这是一个初步演示、需要进行更多的开发工作、才能根据您的需求全面测试和验证此解决方案。  例如、我担心字节连续出现时、没有 FIFO 可用于存储在读取/处理前一个字节时可能错过的字节。  如果不使用读取超时中断、您确实应该考虑设计中 FIFO 阈值的可能性。

e2e.ti.com/.../UART2CC26X2.c

此致、
Ryan

尊敬的 runfa：

将 UART2CC26X2.c 文件直接复制到我的工程工作区

在实践中表现为：

这是我对默认项目所做的唯一更改。  我已确认我正在使用发行版 SDK、并且我向您提供的.c 文件进行了相应的更改。  我在 LAUNCHXL-CC26X2R1 上进行了测试、该器件应相当于该意义上的 CC2642R。

此致、
Ryan

您好、Ryan、

感谢您的答复。 添加UART2CC26X2.c到工程后、对此文件的修改按预期生效。

在演示 (examples\rtos\CC26X2R1_LAUNCHXL\drivers\uart2callback) 中、UART 接收延迟已显著降低。 接下来、我将尝试将此修改应用于使用 UART2 模拟 LIN 总线的设计。

顺便说一下、贵公司是否提供有关使用 CC2642 UART2 模拟 LIN 的示例项目或文档？

此外、我想与你确认一点：

以UART2CC26X2_hwiIntFxn()为例—

• 如果UART2CC26X2.c没有添加到 CCS 项目中、则映射文件显示的实现UART2CC26X2_hwiIntFxn()来自预编译的库source/ti/drivers/lib/iar/m4f/drivers_cc26x2.a。

• 添加UART2CC26X2.c到 CCS 项目后、映射文件显示的实现UART2CC26X2_hwiIntFxn()直接来自UART2CC26X2.c。

这是我第一次在此平台上进行开发、因此这种配置机制会感觉有点容易出错。 是否有任何详细的文档说明此驱动程序库和源覆盖机制的工作原理？

此致。