Hello,
We developed our own USB host driver which works fine for Bulk Mode. But in
Isochoronous mode, data corruption problem occurs.
We are supposed to receive 376 bytes of data with packet size 64 bytes. But
the received data is not the one which we are expecting for…
Is there anything particularly we must take care for Isochronous Mode?
Thanks in advance…
SeethaRam G.
SEETHARAM GOVINDASWAMY wrote:
We developed our own USB host driver which works fine for Bulk Mode.
Why did you develop a USB host driver?
But in Isochoronous mode, data corruption problem occurs.
We are supposed to receive 376 bytes of data with packet size 64
bytes. But the received data is not the one which we are expecting for…Is there anything particularly we must take care for Isochronous Mode?
There’s not nearly enough information here to address your question.
Isochronous requests work very differently from bulks requests. With
bulk, the buffer just continues to fill up as new packets arrive, no
matter how long the gap between them.
With isochronous, each packet in the request corresponds exactly to one
interval. If no data is not received during an interval, the
corresponding packet will have 0 bytes.
So, lets say you submit an isochronous request with 8 packets of 64
bytes, on an endpoint with an interval of 1 microframe. The URB will be
finished after 8 microframes, regardless of how much data was received.
So, if the device can only prepare 64 bytes every 3 microframes, the 8
packets will have 64 bytes, 0 bytes, 0 bytes, 64 bytes, 0 bytes, 0
bytes, 64 bytes, 0 bytes.
Also remember that the data are not packed together. The resulting
buffer will have 64 good bytes, then 128 bytes of garbage (because 2
packets were not filled), then 64 good bytes, then 128 bytes of garbage,
then 64 more good bytes.
376 is not a multiple of 64. Did you mean 384?
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Hello TIM,
I appreciate you providing me lucid information about USB isochronous mode.
Let me tell you a brief about the necessity of USB driver as below:
As a part of the system flow, it starts by receiving broadcasting signal by
LPC XXXX board. After parsing the data, the LPC board sends the necessary
information to PC host.
As per the received data from PC,LPCXXXX does essential data processing and
finally sends A/V data stream to PC host.
To process the above, we need 6 tasks in LPC client application in which 2
tasks are dedicated to 2- USB endpoints. One is for bulk and other one is
for isochronous endpoint.
For bulk endpoint we use timeout of 1000ms.
Earlier we used 2 bulk endpoints and it works fine. But I wonder if we can
get better performance by using isochronous endpoint for A/V data stream.
Frankly speaking, I am not very sure whether switching to isochronous mode
would be the better approach in my above mentioned scenario.
So, please advice me about the best approach.
Thanks in advance.
SeethaRam G.
On Wed, Oct 15, 2008 at 1:54 AM, Tim Roberts wrote:
> SEETHARAM GOVINDASWAMY wrote:
> >
> > We developed our own USB host driver which works fine for Bulk Mode.
>
> Why did you develop a USB host driver?
>
>
> > But in Isochoronous mode, data corruption problem occurs.
> >
> > We are supposed to receive 376 bytes of data with packet size 64
> > bytes. But the received data is not the one which we are expecting
> for…
> >
> > Is there anything particularly we must take care for Isochronous Mode?
>
> There’s not nearly enough information here to address your question.
> Isochronous requests work very differently from bulks requests. With
> bulk, the buffer just continues to fill up as new packets arrive, no
> matter how long the gap between them.
>
> With isochronous, each packet in the request corresponds exactly to one
> interval. If no data is not received during an interval, the
> corresponding packet will have 0 bytes.
>
> So, lets say you submit an isochronous request with 8 packets of 64
> bytes, on an endpoint with an interval of 1 microframe. The URB will be
> finished after 8 microframes, regardless of how much data was received.
> So, if the device can only prepare 64 bytes every 3 microframes, the 8
> packets will have 64 bytes, 0 bytes, 0 bytes, 64 bytes, 0 bytes, 0
> bytes, 64 bytes, 0 bytes.
>
> Also remember that the data are not packed together. The resulting
> buffer will have 64 good bytes, then 128 bytes of garbage (because 2
> packets were not filled), then 64 good bytes, then 128 bytes of garbage,
> then 64 more good bytes.
>
> 376 is not a multiple of 64. Did you mean 384?
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
SEETHARAM GOVINDASWAMY wrote:
I appreciate you providing me lucid information about USB isochronous
mode.
Let me tell you a brief about the necessity of USB driver as below:
By the way, allow me to apologize for one comment. When you said you
wrote a “USB host driver”, in my brain I read that as “USB host
controller driver”. That’s not what you said at all, so I had no
business questioning why you wrote such a driver. You’re fine.
As a part of the system flow, it starts by receiving broadcasting
signal by LPC XXXX board. After parsing the data, the LPC board sends
the necessary information to PC host.
What do you mean by “LPC”?
As per the received data from PC,LPCXXXX does essential data
processing and finally sends A/V data stream to PC host.
To process the above, we need 6 tasks in LPC client application in
which 2 tasks are dedicated to 2- USB endpoints. One is for bulk and
other one is for isochronous endpoint.
For bulk endpoint we use timeout of 1000ms.
Earlier we used 2 bulk endpoints and it works fine. But I wonder if we
can get better performance by using isochronous endpoint for A/V data
stream.
Frankly speaking, I am not very sure whether switching to isochronous
mode would be the better approach in my above mentioned scenario.
That depends entirely on what you mean by “better performance”. The raw
maximum performance of a bulk pipe is nearly twice the raw maximum
performance of an isochronous pipe. We’ve sustained 45 MB/s on a bulk
pipe for days at a time, whereas an isochronous pipe is limited to 24 MB/s.
However, the high bulk data rate is only possible on a relatively idle
bus. If you have other devices active, that impacts the bulk data
rate. With an isochronous pipe, the bandwidth is guaranteed. It is
reserved strictly for your pipe. The tradeoff is that there are no
retries; if you miss a packet, it is lost forever. A bulk transfer will
retry until it succeeds.
Audio/video data is commonly sent by isochronous, because retries re not
helpful in a real-time stream.
How much data do you need to transmit?
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.