我正在使用嵌入式Linux设计的SC16IS752芯片。在正常的串行活动条件下，该芯片在两个COM端口上都能很好地工作。但是，我们发现，在串行会话中，当您不发送或接收数据约30秒时，TX线上传输的下一个字节在所有波特率38400及以上的位移位。有趣的是，这个问题不会发生在19k波特或更低（波特率更低）。
波特率越高，问题就越严重。在38k波特率下，发送的字节移位1位（尝试发送0x66并发送0xB3）。在115k波特，发送的字节被移位4位（尝试发送0x66和0xF6被发送）。
此问题仅在现有串行会话中30秒不活动后发生。这意味着新串行会话的第一个字节始终正确传输。
如果等待30秒而不是在NXP芯片上接收一个字节，这就会使NXP芯片处于良好的状态，其中后续发送的字节被正确传输（只要它发生的时间少于30秒。收到字节）。
我已经倾注了SC16IS752数据表，应用说明和勘误表无济于事。我调查了睡眠模式，接收超时和所有状态寄存器。我还尝试在传输数据之前清除传输FIFO。我已经用完了尝试和调试的东西。我知道我从Linux驱动程序的调试中得到了通过SPI发送到NXP串行芯片的正确字节。
顺便说一下，我正在使用的Linux驱动程序是由Manuel Stahl编写的，他在Linux内核邮件列表中发布了（不成功）尝试将其放入Linux内核。
后来的调查显示以下内容：
我们已经连接了一个内联RS-232设备，它显示了使用LED的所有引脚的状态。我注意到我们的SC16串行芯片（配置为DTE）将在Tx或Rx事务发生后32秒内激活其“TD”和“RTS”指示灯，此时TD和RTS指示灯都熄灭。
这意味着SC16芯片有超时32秒，此时它会停用这些引脚。此时，Tx事务（使SC16芯片发送数据）将导致比特移位问题（如前所述，它只是第一个被移位的字节）。
这是有趣的部分：使用带有Windows的调试笔记本电脑和连接为CTE的“RealTerm”（在SC16串行连接的另一端），它允许我们切换“CTS”引脚。当我切换此引脚（ON或OFF）时，它“唤醒”来自SC16芯片的TD和RTS灯，此时Tx事务（SC16芯片发送数据）将成功！
所以摘要是：
我在SC16数据表中没有看到提到这种类型的超时。唯一提到的是我已经禁用的“睡眠模式”。
答案 0 :(得分：1)
我发现了问题。问题是我们使用的是ISL4270E RS232电平转换器（而不是SC16IS752演示板中使用的SP3243E），它支持自动断电功能，在30秒无活动后为芯片供电。当它检测到数据并上电时会出现问题，它的速度不足以以115k波特率发送所有位。这就是为什么在更高的波特率下比特移位问题会更糟。