usb questions?

So it has been suggested that i forward my questions about the usb ddk
to this forum (rather than sending mail directly). I haven’t seen
anything else on it so maybe I’m just dumber (or less capable of
reading documentation) than the rest of you all.

I installed from a package labelled 000714.

  • The entry usbd_setup_control is marked as being in flux in the
    documentation, but is completely missing from the headers and libs
    (at least if you check its exports w/ objdump). It appeared as if
    usbd_setup_vendor was doing what I wanted, but I’m no longer sure
    since I may have other issues. This leads to the next question…

  • The usbd_setup_xxx functions appear to setup the urb w/ data about
    the physical address etc. Can I call these once when I attach to
    the device and then just use usbd_io to re-chain the urb when I
    need to?

The sample code re-sets up each time, but it is unclear what these
functions actually do and I would like to understand this a little
better. I’ve got generic queues w/ several different types of
urb’s (input and output). For the input’s I would like for the
setup to set the max size etc and just have to deal w/ re-queing
generic urb’s in the actual input completion proc.

  • When I detach from a device the input completion procs get called
    w/ all zero data which i’m definitely not expecting from the
    device. The urb_status doesn’t say anything interesting about the
    packet so I’ve just special cased these, but I am wondering what
    the deal w/ these is.

\p

Es ist nichts schrecklicher als eine taetige unwissenheit.
— Johann Wolfgang Von Goethe

d p chang <dpc@redjade.com> writes:

I installed from a package labelled 000714.

I should mention that I’m currently doing this on rtp not qnx4 which
seems to have some other things in the accessable by
my-boss-who’s-not-here-right-now-but-not-me section of qdn so that I
can’t tell what it really is.

\p

I have often thought upon death, and I find it the least of all evils
— Francis Bacon

d p chang <dpc@redjade.com> wrote:

So it has been suggested that i forward my questions about the usb ddk
to this forum (rather than sending mail directly). I haven’t seen
anything else on it so maybe I’m just dumber (or less capable of
reading documentation) than the rest of you all.

I installed from a package labelled 000714.

  • The entry usbd_setup_control is marked as being in flux in the
    documentation, but is completely missing from the headers and libs
    (at least if you check its exports w/ objdump). It appeared as if
    usbd_setup_vendor was doing what I wanted, but I’m no longer sure
    since I may have other issues. This leads to the next question…

usbd_setup_control isn’t in the usbdi lib. The usbd_setup_vendor function
allows you to send control transfers to a device.

  • The usbd_setup_xxx functions appear to setup the urb w/ data about
    the physical address etc. Can I call these once when I attach to
    the device and then just use usbd_io to re-chain the urb when I
    need to?

Yes.

The sample code re-sets up each time, but it is unclear what these
functions actually do and I would like to understand this a little
better. I’ve got generic queues w/ several different types of
urb’s (input and output). For the input’s I would like for the
setup to set the max size etc and just have to deal w/ re-queing
generic urb’s in the actual input completion proc.

  • When I detach from a device the input completion procs get called
    w/ all zero data which i’m definitely not expecting from the
    device. The urb_status doesn’t say anything interesting about the
    packet so I’ve just special cased these, but I am wondering what
    the deal w/ these is.

Can you describe this a little more? Are you disconnecting the device or
calling usbd_detach?

Thanks for the response.

Kevin Chiles <kchiles@qnx.com> writes:

d p chang <> dpc@redjade.com> > wrote:

  • When I detach from a device the input completion procs get
    called w/ all zero data which i’m definitely not expecting from
    the device. The urb_status doesn’t say anything interesting
    about the packet so I’ve just special cased these, but I am
    wondering what the deal w/ these is.

Can you describe this a little more? Are you disconnecting the
device or calling usbd_detach?

I do something like this:

while(allocated urbs) free data associated w/ them
while(open pipes) close pipes

→ at this point my interrupt/bulk in callbacks are called
w/ 0 data. my input procs deal w/ this and just realize
that they shouldn’t re-chain themselves.

usbd_detach
usbd_disconnect

Interestingly (or more accurately unfortunately for me), sometimes the
usbd_disconnect hangs forever. Doing a pidin (I’m not quite sure if
I’m reading this right) show that devu-uhci and my device are both
blocked on the same object (the blocked column has the same value in
it).

Running in verbose mode doesn’t seem to show that its unhappy about
anything, but I’m not sure if it just didn’t get flushed or something.

\p

I’m complicated, sentimental, lovable, honest, loyal, decent,
generous, likable, and lonely. My personality is not split; it’s
shredded. — Jack Paar

To follow up on my original posting:

I’ve been rooting around in hte sample source and found that prn.c
expects taht its io callback function get called for completion (or at
least when the io has been actually issued).

I, however, don’t see this when I talk to the default control endpoint
nor when I send out bulk urb’s. The commands via the control endpoint
appear to be happy since I get responses back from the device. However
(until I get a usb analyzer) it is unclear whether the bulk writes are
going out since I neither get replies nor completion callbacks.

The prn.c source also writes a 0 length urb to terminate the
transfer. I don’t know whether or not this is some special printer
protocol?

Anyway, I’m on rtp running something labelled 000714. Is there
anything newer? (I’d have to bug my boss for getting fixes since I’m
not nearly important enough to have any passwords or anything, ).

\p

My body doesn’t believe a word my brain is saying. — Calvin