GPS中间驱动程序减慢来自虚拟串口驱动程序的数据

Question

后续内容来自- GPS Intermediate Driver Issues

上面的问题没有得到成功的回答，我觉得我在这个问题上有了新的信息，可以提出一个新的问题。

我面临的问题是GPS中间驱动程序传送数据的速度。

我已经成功地使用Pocket Putty读取了串行端口，并查看了所暴露的确切信息。

COM 1- GPS中间驱动程序

COM 6- PC串行端口(手动输入数据)

COM 8- GPS硬件的虚拟串行端口。

当读取COM 8时，我可以看到大约每3秒出现18个NMEA字符串，这是我们在有限的USB连接上所能推送的最快速度。它很快就会出现在显示屏上。当读取COM 6(手动从PC发送数据)时，它同样快速显示。因此，数据是没有问题的。

输入GPS中间驱动程序。当GPS中间驱动程序设置为COM1 (软件)和COM6 (硬件)时。在COM6上输入的数据在COM1上的显示速度与没有GPS中间驱动程序时一样快。数据没有改变，所以如果我在COM6上发送"JON“，它会出现在COM1上，即使它不是有效的NMEA数据，这是很好的。

问题出在COM8上。当GPS中间驱动程序设置为COM1 (软件)和COM8 (硬件)时。在COM1上的PocketPutty中显示的数据非常慢。屏幕上的输出大约是每秒5个字符，数据是有效的，只是传输速度非常慢。这对我来说指出了虚拟串行端口实现中的一个问题，就好像GPS中间驱动程序一次只读取一个字符的所有数据一样，因为我已经将问题隔离到我的虚拟串行端口。

谁能提供一个虚拟串口实现的明确例子，因为我不确定我可以改变什么来改进这一点，因为COM8直接与GPS软件和PocketPutty应用程序一起工作，这表明数据是可用的，正在读取，并且是正确的。

Answer 1

在获得运行调试构建的设备制造商的支持后，问题的原因是客户端应用程序对许多读取调用进行了调用。串口可以自己处理它们，但通过GPS中间驱动程序调用的数量太高，开销严重影响了通信，这是由于互斥锁和一般线程问题造成的。

客户端应用程序每次读取到GPS中间驱动程序时都需要读取960字节的数据，才能正常工作。这不是一个理想的解决方案，因此找到了另一个解决方案。

解决方案是在read方法中添加一个WaitForSingleObject(IsThereEnoughGPSDATAEvent，COMTotalTimeout)，以便所有读取仅在有足够数量的数据可用时才会获得数据。最初，我请求960在缓冲区中可用，但我将其设置为只有10个字节，它仍然有效。

示例代码

DWORD COM_Read( DWORD hOpenContext, LPVOID pBuffer, DWORD Count )
{
    if(gpsThreadEvents[GPS_THREAD_EVENT_DATA_AVAILABLE] != NULL)
    {
        if(WaitForSingleObject(gpsThreadEvents[GPS_THREAD_EVENT_DATA_AVAILABLE], GPSTimeouts.ReadTotalTimeoutConstant) != WAIT_OBJECT_0)
        {
            return 0;
        }
    }

    //read code goes in here

    return dataOut;
}