本文介绍了间歇性慢速数据传输/程序执行的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我编写了一个程序,允许用户从外部设备读取信息,修改数据并将其写回。但随机时间通信非常缓慢。

I have written a program that allows the user to read in information from an external device, modify the data, and write it back. But at random times the communications is very slow.

数据在车辆ECU(发动机控制单元)中,我们通过CAN总线通过我们创建的设备将其读出,以将CAN协议转换为USB。该设备使用FTDI FT2232芯片通过USB将数据发送到PC,当驱动程序发出数据可用的事件并在我的程序中处理它时,我'抓住'
FTDI驱动程序中的数据。 ECU要求响应时间不到50ms,否则会使请求无效。

The Data is in a vehicles ECU (Engine Control Unit), we read it out through the CAN bus through a device we created to convert the CAN protocol to USB. The device uses a FTDI FT2232 chip to send the data to the PC through USB, I 'grab' the data from the FTDI driver when the drivers fires an event saying data is available and deal with it in my program. The ECU requires responses in less than 50ms, or it invalidates the request.

没有任何押韵或原因我可以确定,响应时间将从几毫秒到70毫秒不等。

Without any rhyme or reason I can determine, the response times will vary from a few ms to 70ms.

通过FTDI驱动程序与设备通信的例程是用C#编写的,并包装到从主程序调用的DLL中,该程序用VB编写。所有通信例程都在DLL中,只有Data传递给VB。我在DLL中运行
多个任务来处理返回的信息。数据作为原始字节流进入,是"打包"的。进入消息,过滤,然后排队等待使用。每个步骤都是循环运行的任务。 (处理器利用率
很小)。 "分组"保存在自定义类"数据包"的并发队列中

The routines that communicate with the device through the FTDI drivers are written in C# and wrapped into a DLL that is called from the main program which is written in VB. All of the communications routines are in the DLL and only Data passes to VB. I run multiple tasks inside of the DLL to deal with the information being returned. The data comes in as a raw stream of bytes, is "packetized" into messages, filtered, and then queued for use. Each step is a task running in a loop. (processor utilization is small). "Packets" are held in Concurrent Queues of custom class "packet"

似乎DLL中的执行有时会减慢..."数据包"。永远需要从任务到任务... 是否有一些窗口可能正在做隔离代码,因为它直接与USB驱动程序对话,或者......我只是b
$ b'甚至想想可能发生的事情......

It seems like execution inside the DLL is slowed down at times... "packets" will take forever to get from task to task... Is there something windows might be doing to isolate the code since it directly talks to the USB drivers, or ... I'm just baffled, can't even think of what might be happening...

在调试中我已经检查过以确保我没有创建多个例程实例...

In debug I have checked to make sure I am not creating multiple instances of routines...

你可以多次运行程序,一切都很好,然后下一次,它是慢动作。一气呵成,没有什么我能看到的变化...

You can run the program a number of times and everything is great, then the next time, it's in slow motion. All in one sitting, nothing that I can see changing...

只是因为我不知所措而把它扔出去,也许其他人遇到过这样的事情。

Just throwing this out there because I am at a loss, maybe someone else has run across something like this.

谢谢,

约翰

伙计,我在我的脑海里!

Man, Im in way over my head!!!

推荐答案

如果缓冲区数据长度很小,问题可能出在硬件或驱动程序上。如果事件之间经过的时间很长且缓冲区数据长度很大,则问题出现在您的代码上。

If the buffer data length is small, the problem would be either on hardware or driver. If the time elapsed between event is long and the buffer data length is large, the problem is on your code.


这篇关于间歇性慢速数据传输/程序执行的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!

08-15 03:30