1

继续 - GPS 中间驱动程序问题

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

我面临的问题是 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 应用程序一起使用，这表明数据可用、正在读取并且是正确的.

4

1 回答 1

0

在获得运行调试版本的设备制造商的支持后，问题的原因是客户端应用程序进行了许多读取调用。串行端口可以自己处理它们，但是通过 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;
}
于 2011-01-10T16:14:55.003 回答