On Apr 28, 2019, at 2:54 AM, hong_zhong wrote:
>
> I found that the uvc protocol is the same， so i think it not our driver problem， it is an operating system issue? is the usb controller driver issue?
Hang on. Are you saying this a UVC camera? If so, then why do you have a driver at all? The WHQL specs require that a UVC camera be driven by usbvideo.sys alone.
Even if you have chosen to have your own private side channel for out of band information, it should have been done as a bulk endpoint. Your 490-byte payload would fit into one single bulk packet.
I’m going to repeat what I’ve said several times. Your device has a design flaw. You are using the control pipe in a way that it wasn’t designed for. Because of that, you have triggered behavior that was never expected to be a problem. I do not doubt that the root issue is scheduling within the Windows 7 EHCI driver, but THAT BEHAVIOR IS NEVER GOING TO BE CHANGED. The only way you can fix this problem is to change your device to transmit these blocks over a bulk endpoint.
—
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.
@Tim_Roberts said:
On Apr 27, 2019, at 7:52 PM, hong_zhong wrote:I mean in win 7 ，between send request packet and then receive device data， have 9 SOF , then send the next request packet , have 7 SOF,like this:
- send request packet
- 9 SOF
- receive device data ( 490 bytes ,include header)
- 7 SOF
- send next packet
- 9 SOF
- receive device data ( 490 bytes ,include header)
- 7 SOF
Are you using a hardware bus analyzer or a software one?
I use hardware bus analyzer?
Because that’s NOT what the bus traffic will look like. As I said, there will be 8 different request and receive cycles to satisfy your request. You should see send request, receive 64, send request, receive 64, send request, receive 64, etc., finally followed by a receive of 42. The fact that you mention 9 SOFs suggests that you’re getting one packet per frame on Windows 7.
Yes, i see send request ,receive 64, send request ,receive 64 etc, like this:
IN packet
Data1 packet
Ack packet
IN packet
Data0 packet
Ack packet and etc
but this doesn’t take too long. in our protocol. Time is consumed between different packages.
send request packet (include flash address and offset)
9 SOF
receive device data ( 490 bytes ,include header) // this doesn’t take too long
7 SOF
send request packet (include flash address and offset)
9 SOF
receive device data ( 490 bytes ,include header) // this doesn’t take too long
7 SOF
But, repeating what I said before, it is what it is. You can’t change the timing without switching to a bulk pipe.
—
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.
@Tim_Roberts said:
On Apr 28, 2019, at 2:54 AM, hong_zhong wrote:I found that the uvc protocol is the same， so i think it not our driver problem， it is an operating system issue? is the usb controller driver issue?
Hang on. Are you saying this a UVC camera? If so, then why do you have a driver at all? The WHQL specs require that a UVC camera be driven by usbvideo.sys alone.
No, this is a private protocol camera, but I use the uvc protocol camera for comparison.
Even if you have chosen to have your own private side channel for out of band information, it should have been done as a bulk endpoint. Your 490-byte payload would fit into one single bulk packet.
I’m going to repeat what I’ve said several times. Your device has a design flaw. You are using the control pipe in a way that it wasn’t designed for. Because of that, you have triggered behavior that was never expected to be a problem. I do not doubt that the root issue is scheduling within the Windows 7 EHCI driver, but THAT BEHAVIOR IS NEVER GOING TO BE CHANGED. The only way you can fix this problem is to change your device to transmit these blocks over a bulk endpoint.
yes, you are right, Recently we add a requirement and need to read a big data （about 200k to 500k）, if we change to bulk transfer, the device firmware need to change,and the protocol need change.
—
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.
@“Peter_Viscarola_(OSR)” said:
Are you using a hardware bus analyzer or a software one?
Please answer Mr. Roberts question.
i think it not our driver problem
Is that all this is about? Because, if so, it’s almost certainly not your drivers problem. We can be quite sure of that. All the rest of this thread is noise, if that’s all you care about.
Peter
thank you peter， Now I want to see if there is any way to solve this problem. Recently we add a requirement and need to read a big data (about 200k to 500k), because of change to bulk ,our device fireware need to change, and the protocol also need change.