GPS中间驱动程序减慢虚拟串行端口驱动程序中的数据 [英] GPS Intermediate Driver Slowing down the data from a virtual serial port driver
问题描述
继续阅读 - GPS中间驱动程序问题
上面的问题没有得到成功解答，并且觉得我有关于这个问题的新信息以寻求新的问题。
我面临的问题是GPS中级驱动程序正在交付数据的速度。
我已经成功地使用Pocket Putty读取串行端口并查看已暴露的确切信息。
COM 1 - GPS中间驱动程序
COM 6 - 串行端口至PC（手动输入数据）
COM 8 - 用于GPS硬件的虚拟串口。
在阅读COM 8时，我可以看到约18个NMEA字符串出现在每个〜 3秒钟，这个速度与我们通过有限的USB连接一样快。它很快显示在屏幕上。当读取COM 6（手动发送来自PC的数据）时，其显示速度相同。所以这些数据没有问题。
输入GPS中间驱动程序。 GPS中间驱动程序设置为COM1（软件）和COM6（硬件）时。在COM1上输入的数据在COM1上显示的速度与没有GPS中间驱动程序时一样快。数据没有改变，所以如果我在COM6上发送JON，它将出现在COM1上，即使它的NMEA数据不是有效的，这很好。
问题是与COM8。 GPS中间驱动程序设置为COM1（软件）和COM8（硬件）时。在Pocket1上显示的数据在COM1上真的很慢。屏幕上的输出大约每秒5个字符，数据有效，但传输速度非常慢。这给我指出了在实现虚拟串行端口时的一个问题，就好像GPS中间驱动程序不是一次只读取一个字符的所有数据一样，因为我已经将问题隔离到了我的虚拟串行端口。 >
任何人都可以提供一个虚拟串口实现的清晰示例，因为我不知道我可以改变什么来改进它，因为COM8直接与GPS软件和PocketPutty应用程序一起工作表示数据可用，正在读取并且是正确的。
获得设备制造商运行调试版本的支持后，问题的原因是客户端应用程序正在进行多次读取调用。串口可以自行处理它们，但通过GPS中间驱动程序，调用的数量太高，开销损害了沟通，这是由于互斥锁和一般线程问题。
客户端应用程序需要将每次读取的960字节数据读取到GPS中间层驱动程序，以使它们正常工作。这不是一个理想的解决方案，所以找到了另一个修复程序。
解决方案是在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;
}
}
//读取代码放在这里
return dataOut;
}
Follow on from - GPS Intermediate Driver Issues
The above was not successfully answered and feel I have new information over the issue to go for a new question.
The issue I am facing is the speed of which data is being delivered by the GPS Intermediate Driver.
I have successfully used Pocket Putty to read the serial ports and see the exact information been exposed.
COM 1 - GPS Intermediate Driver
COM 6 - Serial port to PC (Input data manually)
COM 8 - Virtual serial port for GPS hardware.
When reading COM 8, I can see about 18 NMEA strings appear every ~3 seconds, this is as fast as we can push it over the limited USB connection. And it appears quickly on the display. When reading COM 6 (send data from PC manually), it is displayed equally as quick. So there is no problem with the data been available.
Enter in the GPS Intermediate Driver. When The GPS Intermediate Driver is set to COM1 (Software) and COM6 (Hardware). The data entered on COM6 is displayed on COM1 just as quickly as it was without the GPS Intermediate Driver. The data is unaltered, so if I send "JON" on COM6, it will appear on COM1, even though its not valid NMEA data, which is fine.
The problem is with COM8. When the GPS Intermediate Driver is set to COM1 (Software) and COM8 (Hardware). The data showing in PocketPutty on COM1 is really slow. The output on the screen is about 5 characters per second, the data is valid but it just been delivered very slowly. This to me points out an issue in the implementation of the virtual serial port, as if the GPS Intermediate Driver is not reading all the data just one character at a time, given I have isolated the issue to my virtual serial port.
Can anyone provide a clear example of a virtual serial port implementation, as im not sure what I could change to improve this, given COM8 directly works with GPS software and the PocketPutty application, which indicates the data is available, being read, and is correct.
After getting support from the device manufacturer running a debug build, the cause of the problem was client applications were making to many read calls. The serial port could handle them on its own, but via the GPS Intermediate driver the number of calls were too high and the overhead was crippling the communication, this was down to Mutex locks and general threading issues.
Client applications need to read 960 bytes of data per read to the GPS Intermediate driver for them to work ok. This is not an ideal solution so another fix was found.
The resolution was to add in a WaitForSingleObject(IsThereEnoughGPSDATAEvent, COMTotalTimeout) in the read method, so that all reads would only get data if there was a sufficient amount of data available. Originally I requested 960 to be available in the buffer but i've set it down to just 10 bytes and it still works.
Sample Code
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;
}
这篇关于GPS中间驱动程序减慢虚拟串行端口驱动程序中的数据的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
