Re: USB Status Pipe Strategy

Tech-Archive recommends: Speed Up your PC by fixing your registry

Hi Marc,
Thanks for your comments.
I guess what concerns me is how fast the host may actually poll. The way I
read it, the time specification that is put on an interrupt endpoint is
really a guaranteed maximum latency, not a specified rate. There doesn't
seem to be any guarantee that the polling wont occur at a much higher rate.
I don't want that. I need a somewhat controlled 100ms update rate.
You're right in that this could be done as a Bulk Endpoint. I suppose the
device could control the rate. I could continuously send an URB from the
host. The device would NAK until it's time to send the data.
I'm just a bit insecure about choosing a method that will work well across
multiple platforms.
Best regards,
Dennis

"Marc Reinig" <Marco@xxxxxxxxxxxxxxxxx> wrote in message
news:u18vg5iFGHA.2444@xxxxxxxxxxxxxxxxxxxxxxx
>> Perhaps a better approach is to implement an Interrupt IN endpoint with a
>> much lower latency, say 10 msec, and control the polling rate by how
>> often I submit the URB.
>
> If you are going to do that, then why not just make it a bulk endpoint?
> However, I really can't see any practial reason not to make it an
> interrupt endpoint with a time of 100 msec.
>
> --
> Marco
> ________________________
> Marc Reinig
> UCO/Lick Observatory
> Laboratory for Adaptive Optics
>
>
> "db_from_mn" <dburns@xxxxxxxxxxxxxxxx> wrote in message
> news:bYudnU-ZZ9AgiFneRVn-hA@xxxxxxxxxxxxxx
>>I have a USB device, that implements 4 USB endpoints: 1 Control, 1 Bulk
>>IN, 1 Bulk OUT and a fourth TBD type. This last one is for general device
>>status reporting. I'd like to transfer 64 bytes of data from the device to
>>host roughly every 100 msec. This endpoint should have much less priority
>>in terms of bandwidth allocation than the Bulk Endpoints.
>> My first instinct was to implement an Interrupt IN endpoint, with a 100
>> ms latency. I would then maintain a URB requesting data at all times. But
>> I'm not sure that will achieve the desired result. This may result in
>> widely variant polling rates, depending on the platform.
>> Perhaps a better approach is to implement an Interrupt IN endpoint with a
>> much lower latency, say 10 msec, and control the polling rate by how
>> often I submit the URB.
>>
>> Can someone offer suggestions?
>> Thanks in advance,
>> Dennis
>>
>>
>
>


.

Relevant Pages

  • Re: assessing winusb potential
    ... So it appears in the USB interrupt handler that there is an event ... sent by the host. ... My device writes data to the IN endpoint. ... USB hardware sends the data. ...
    (microsoft.public.development.device.drivers)
  • USBEHCI.SYS bug with high-bandwidth interrupt endpoints
    ... I was investigating USB 2.0 high-bandwidth interrupt ... three transactions per microframe with a maximum packet size of 1024 ... bytes in the endpoint descriptor. ...
    (microsoft.public.development.device.drivers)
  • Re: USB Status Pipe Strategy
    ... > I guess what concerns me is how fast the host may actually poll. ... the time specification that is put on an interrupt endpoint is ... > You're right in that this could be done as a Bulk Endpoint. ...
    (microsoft.public.development.device.drivers)
  • Re: USB RNDIS Debug with USB Chief
    ... "one is that the INTERRUPT IN endpoint, used to notify the HOST of a new ... RndisMessage, is shows as not completed in the USB Chief. ... When XP send out RNDIS Write message through endpoint 0, ...
    (microsoft.public.windowsce.platbuilder)
  • Re: Castle USB API: Interrupt endpoints
    ... >> Under the Castle USB API, how does one send bytes to an interrupt ... >> The output stream to the endpoint opens fine; I get a handle, ... >> I haven't found any code examples for interrupt endpoints anywhere, ... This code works well for reading from a mouse: ...
    (comp.sys.acorn.programmer)