我是自发自收测试,程序框架如下while(1)
{
    TRACE("Write %d  ",GetTickCount());              //在这里输出一个时间点    BOOL bWrite = pComPort->Write(buff,size);                //向串口写入数据
    if(bWrite)
    {
         pComPort->Read(buff,size);                 //读串口
         TRACE("Read%d  \n",GetTickCount());              //在这里输出一个时间点
    }
}
通过两个时间点的比较发现,大概在1毫秒之内读写3~4次,然后就会消耗15个毫秒左右的时间然后再在
1毫秒之内读写3~4次,输出如下所示,请问这是什么原因?Write 101192000   Read 101192000
Write 101192000   Read 101192000
Write 101192000   Read 101192000
Write 101192015   Read 101192015
Write 101192015   Read 101192015 
Write 101192015   Read 101192015 
Write 101192015   Read 101192030
Write 101192030   Read 101192030 
... 

解决方案 »

  1.   

    与CPU的处理有关系,底层的CPU操作是对寄存器的读/写和中断操作
    CPU繁忙时IO读写的任务调度也会受到影响
    例如你在发送时是否移动鼠标都会造成速率略有不同
      

  2.   

    应该不是数据传输错误影响或底层cpu处理影响,因为它是很有规律的,我猜会不会是因为波特率的原因,它为了达到在一毫秒之内传输规定的位数,而专门在中间插进空闲或等待?
      

  3.   

    首先PC串口是有硬件缓冲的,其次串口驱动是有缓冲的,另外Windows操作系统是非实时的,因此串口驱动被堵塞1-2s而不能发送数据都是有可能的,
      

  4.   

    读写缓冲,CPU处理能力等,都有关
      

  5.   

    wljin(衣冠清瘦):
        能不能说的详细一点呢?我用串口精灵测试过,也有这种现象。
      

  6.   

    谢谢各位,那能不能将数据传输设定的匀速呢?将缓冲设置小一点行不行呢?还有字节间超时对这个有没有影响呢?
    /////////////////////////////////
    设备管理器中串口设置页面中的高级选项中可以关闭硬件FIFO缓冲。这会降低性能字节间超时是异步(多任务操作系统通常是异步的)操作系统的标志,设置太低会影响操作系统的性能,有可能导致其他任务堵塞,不要想着Windows操作系统能够匀速完成这种IO操作,因为这种操作系统建议你的程序都是异步的,根本不可能达到匀速,如果非要匀速的话,你可以用DOS,多任务的话可以用UCOSSII UcLinux之类