Hello,

due to bug in Windows USB stack, I need implement replacement for
interrupt transfers by some self timed bulk transfer. Now are interrupt
transfers pooled with 4ms period (it's high speed device). Simulated
interrupt transfers may pool endpoint in 8ms period.
First idea is similar as normal handling of interrupt implementation in
driver - send URB, wait for completition, wait approximately 7-8ms and again
send URB. There are some difficulties starting from precise timing, increased
procesor time consuming and so on.
Second idea is schedule transfer at specified frame number.

Known somebody way how schedule trasfer at specified frame number? Or
suggest something other?

Slavo Tomascik

Re: How implement replacement for USB interrupt transfers. by Doron

Doron
Thu Feb 07 11:51:59 CST 2008

why do you need a specific frame? the device will send data when it has it.
to accomodate this, just pend a few URBS at the same time to make sure there
is always a transfer on the schedule. when the device has data, it will
send it to your driver

d

--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.


"Slavo Tomascik" <SlavoTomascik@discussions.microsoft.com> wrote in message
news:D8279FF0-0B3F-4833-881E-4542F9A09E85@microsoft.com...
> Hello,
>
> due to bug in Windows USB stack, I need implement replacement for
> interrupt transfers by some self timed bulk transfer. Now are interrupt
> transfers pooled with 4ms period (it's high speed device). Simulated
> interrupt transfers may pool endpoint in 8ms period.
> First idea is similar as normal handling of interrupt implementation in
> driver - send URB, wait for completition, wait approximately 7-8ms and
> again
> send URB. There are some difficulties starting from precise timing,
> increased
> procesor time consuming and so on.
> Second idea is schedule transfer at specified frame number.
>
> Known somebody way how schedule trasfer at specified frame number? Or
> suggest something other?
>
> Slavo Tomascik


Re: How implement replacement for USB interrupt transfers. by SlavoTomascik

SlavoTomascik
Fri Feb 08 06:03:00 CST 2008

Hi,

ok, litle more information... I have 4 high speed devices with important
throughput (in worst case 8 devices) plus hub connected to single host
controller. Each pending URB occupy some space in microframe, and devastate
throughput of devices, which. Therefore must be placing of URBS scheduled.
It's same state as bug for which one I need workaround - when more than 3
interrupts transfer are active at same time (for one host controller), then
interrupt transfer packet is sent to bus every microframe, and not at a time
(microframes count) as should be scheduled. In our worst case interrupt
transfers occupy more than 50% of bandwidth of host controller.

Thanks,
Slavo

"Doron Holan [MSFT]" wrote:

> why do you need a specific frame? the device will send data when it has it.
> to accomodate this, just pend a few URBS at the same time to make sure there
> is always a transfer on the schedule. when the device has data, it will
> send it to your driver
>
> d
>
> --
> Please do not send e-mail directly to this alias. this alias is for
> newsgroup purposes only.
> This posting is provided "AS IS" with no warranties, and confers no rights.
>
>
> "Slavo Tomascik" <SlavoTomascik@discussions.microsoft.com> wrote in message
> news:D8279FF0-0B3F-4833-881E-4542F9A09E85@microsoft.com...
> > Hello,
> >
> > due to bug in Windows USB stack, I need implement replacement for
> > interrupt transfers by some self timed bulk transfer. Now are interrupt
> > transfers pooled with 4ms period (it's high speed device). Simulated
> > interrupt transfers may pool endpoint in 8ms period.
> > First idea is similar as normal handling of interrupt implementation in
> > driver - send URB, wait for completition, wait approximately 7-8ms and
> > again
> > send URB. There are some difficulties starting from precise timing,
> > increased
> > procesor time consuming and so on.
> > Second idea is schedule transfer at specified frame number.
> >
> > Known somebody way how schedule trasfer at specified frame number? Or
> > suggest something other?
> >
> > Slavo Tomascik
>
>