TI中文支持网利用AM335X芯片的GPMC扩展8路串口，2400~57600bps条件下通讯收发均正常，在115200bps条件下出现误码，收到的数据通过485监测，数据是正确的，但在应用层读进来的数据，当接收的数据超过18个字节时，多了随机的00字节，请各路大神指点一下！谢谢
监测到的数据帧：7E 32 30 30 31 34 30 30 30 30 30 30 30 46 44 42 39 0D
通过read读取的数据帧：7e 32 0 30 30 31 34 30 30 30 30 30 30 30 46 44 42 39
当向AM335X的扩展串口发送18个字节时，最后一个字节0D被截断，收到的数据第三个字节被00填充了，当接收的数据超过18个字节都会出现这种情况
Jian Zhou：
如同你发的相同帖子的回复，能否调整一下应用层的串口收发速度
leo chen：
是否可以增加数据协议来保证数据的完整性和可靠性
xuegang zhou：
回复 Jian Zhou:
串口的收发速度都作了延时控制，在115200pbs条件下，当通过串口调试助手向AM3352发送902个字节时，扩展串口只能接收到671个字节，丢包的情况还是比较严重的。在接收到的671个字节中，每隔16个字节都会被插入一个“0”字节。2400~57600pbs波特率条件下不存在丢包的现象。
7e 32 0 30 30 31 34 31 30 30 32 33 37 34 30 30 32 38 37 0 46 46 46 46 46 46 46 46 46 46 46 46 46 46 46 46 0 46……46 0 46 46 46 46 46 46 46 46 46 46 46 46 46 46 46 46 0 46 46 46 46 46 46 46 46 46 46 46 46 31 32 30
通过示波器对TL16C554的RX引脚上波形进行分析时，发现波形是完成正确的。通过查阅相关帖子，有如下描述“当连续接收大量数据时，如果串口IST不能及时读走FIFO中的数据(发生中断时FIFO再接收两个字节就满)，将导致串口通信出现丢失数据的情况，当系统任务繁重时这种情况就会更加严重。”
不知道Jian Zhou工有什么更好的解决方法没有？
xuegang zhou：
回复 Jian Zhou:
目前，通过示波观测TL16C554的读（IOR）、中断信号，以及在驱动里对线路状态寄存器（LSR）的打印信息，基本可以确定导致在115200bps条件下丢包是由于出现超限错误（LSR的OE位）导致的，也就是说当FIFO中断信号产生后，CPU没有及时产生读控制信号，数据手册上有如下描述“在至少四个字符时间段内没有对接收FIFO进行读操作”，通过示波器监测波形确实出现超时了。那么这个读信号的发出是和tl16c554_timings密切相关的吧？我的gpmc_timings参考之前你给出的时序，是否可以从这里进行优化呢？
.sync_clk = 0,
.cs_on = 0, .cs_rd_off = 90, .cs_wr_off = 70,
.adv_on = 0, .adv_rd_off = 15, .adv_wr_off = 15, .we_off = 65, .oe_off = 70,
.access = 90, .rd_cycle = 140, .wr_cycle = 90,
.wr_access = 90, .wr_data_mux_bus = 0,
另外，TL16C554数据手册里提到自动流控功能可以避免超限误差——“在TL16C554A中的ACE1和ACE2的自动流控功能被使能时，可以避免超限误差。不然，在数据发送速率超过接收器FIFO读操作等待时间时，就可能出现超限误差”。这里说的FIFO读操作等待时间太过于模糊了，感觉没有说得更具体一点，难道115200bps就超过了，如果这解决这个问题必须要用自动流控功能吗？
Jian Zhou：
回复 xuegang zhou:
你可以先优化下时序看看，如果是16C554需要硬件流控，需要在Linux驱动层添加。
