Hello,
I’m working on Neutrino 2.1 Beta2.
I wrote a USB client driver using USB DDK provided with your USB stack
Here are some problems i encountered during development :
the “usbd_disconnect” function kills my client when i call it. I set the
“struct usbd_connection *pConnection” parameter with the one returned
by “usbd_connect” function… The problem occurs even if i call the
disconnect funtion just after the connect function.
Do we have to use “usbd_io” function when making transfert across the
default control pipe ? How do we use usbd_setup_vendor and
usbd_setup_control commands ? What’s the difference with usbd_descriptor ?
It seems that it’s impossible to close a pipe if a reading thread is in a
blocking state.
So how is it possible to close a pipe if theres’s nothing to read from it
and if we
our read function is waiting for datas ?
Thanks for reply.
“Thierry Chantry” <tchantry@free.fr> writes:
Hello,
salut.
I’m not from qnx, but I’ve been having some of the same ‘problems’ as
you are. Hopefully, my empirical evidence can be of some use.
Do we have to use “usbd_io” function when making transfert across
the default control pipe ?
This works for me. I, however, am having problems dealing w/ bulk
transfers. (I guess I should get a bus analyzer, but they don’t
actually seem to make it to the device).
How do we use usbd_setup_vendor and usbd_setup_control commands ?
I don’t have setup_control in my version of the library (even though
its documented). I was told by someone at qnx (in response to a
previous posting of mine) that setup_vendor does the same thing and i
should be using that. However, my device requires that my commands for
the default control pipe go to the class rather than the endpoint.
It seems that it’s impossible to close a pipe if a reading thread is
in a blocking state. So how is it possible to close a pipe if
theres’s nothing to read from it and if we our read function is
waiting for datas ?
I’m not sure if I’m having the same problem, but I basically call
usbd_abort on the pipe. My input callback gets called w/ 0 data and
the status appears to be ok.
Anyway, my problem is that the usbd_disconnect sometimes deadlocks
where devu-uhci and my resource manager are both in hte reply state
waiting on the same object (if pidin can be trusted).
I hope this helps et bonne chance.
\p
ATTENTION, all abducting aliens! you DON’T need to RETURN them!
— Erik Naggum (c.l.l)
Thierry Chantry <tchantry@free.fr> wrote:
Hello,
I’m working on Neutrino 2.1 Beta2.
I wrote a USB client driver using USB DDK provided with your USB stack
Here are some problems i encountered during development :
the “usbd_disconnect” function kills my client when i call it. I set the
“struct usbd_connection *pConnection” parameter with the one returned
by “usbd_connect” function… The problem occurs even if i call the
disconnect funtion just after the connect function.
Are you calling disconnect from the insertion routine? Can you post
a small example?
Do we have to use “usbd_io” function when making transfert across the
default control pipe ? How do we use usbd_setup_vendor and
usbd_setup_control commands ?
usbd_setup_control is not in the library. usbd_setup_vendor allows you
to send control transfers. Take a look at the prn_device_id function
in the printer class driver for an example.
What’s the difference with usbd_descriptor ?
Are you asking what the difference is between sending a control transfer
(via usbd_setup_vendor/usbd_io) to get a descriptor and the usbd_descriptor
function? Both methods will achieve the same result. The usbd_descriptor
routine is just a convenience function.
It seems that it’s impossible to close a pipe if a reading thread is in a
blocking state.
So how is it possible to close a pipe if theres’s nothing to read from it
and if we
our read function is waiting for datas ?
Take a look at the usbd_reset_pipe function.