我正在我们的嵌入式 Linux 设计中开发 SC16IS752 芯片。在正常的串行活动条件下，该芯片在两个 COM 端口上都能正常工作。然而，我们发现，在串行会话中，当您在大约 30 秒内不发送或接收数据时，TX 线上传输的下一个字节在所有波特率 38400 及以上的情况下都会发生位移。有趣的是，这个问题不会出现在 19k 或更低的波特率（较低的波特率）。
波特率越高，问题就越严重。在 38k 波特率下，发送的字节移动 1 位（尝试发送 0x66 并发送 0xB3）。在 115k 波特率下，发送的字节移动 4 位（尝试发送 0x66 并发送 0xF6）。
此问题仅在现有串行会话中 30 秒不活动后发生。这意味着新串行会话的第一个字节始终正确传输。
如果您等待 30 秒，而是在 NXP 芯片上接收到一个字节，这会以某种方式使 NXP 芯片处于良好状态，从而正确传输后续传输的字节（只要它比接收到的字节晚不到 30 秒） .
我翻阅了 SC16IS752 数据表、应用笔记和勘误表，但无济于事。我调查了睡眠模式、接收超时和所有状态寄存器。我还尝试在传输数据之前清除传输 fifos。我已经用完了可以尝试和调试的东西。我知道我通过 SPI 将正确的字节发送到 NXP 串行芯片，从我的 Linux 驱动程序中的调试。
顺便说一句，我正在使用的 Linux 驱动程序是由 Manuel Stahl 编写的，他在 Linux 内核邮件列表中发布了该驱动程序（未成功），试图将其放入 linux 内核。
后来调查发现：
我们已经连接了一个内联 RS-232 设备，它使用 LED 显示所有引脚的状态。我注意到我们的 SC16 串行芯片（配置为 DTE）在 Tx 或 Rx 事务处理后，其“TD”和“RTS”灯将激活 32 秒，此时 TD 和 RTS 灯都熄灭。
这意味着 SC16 芯片有 32 秒的超时时间，此时它会停用这些引脚。此时，一个 Tx 事务（让 SC16 芯片发送数据）将导致位移问题（和以前一样，它只是位移的第一个字节）。
这是有趣的部分：使用带有 Windows 的调试笔记本电脑和作为 CTE 连接的“RealTerm”（在 SC16 串行连接的另一端），它允许我们切换“CTS”引脚。当我切换此引脚（打开或关闭）时，它会“唤醒”SC16 芯片的 TD 和 RTS 灯，此时 Tx 事务（让 SC16 芯片发送数据）将成功！
所以总结如下：
- 当 SC16 芯片的 TD 和 RTS 灯亮时，后续的 Tx 交易成功。
- SC16 TD 和 RTS 灯在 32 秒后超时（关闭）。后续的 Tx 交易存在位移问题。
- 当我通过切换 CTE 的 RTS 引脚来触发 SC16 芯片时，它“唤醒”了 SC16 芯片的 TD 和 RTS 灯，随后的 Tx 事务成功。
我在 SC16 数据表中没有看到任何提到这种超时的内容。唯一提到的是我禁用的“睡眠模式”。