Your emailer is line-wrapping the JNI trace...can you resend as an attachment?
I just want to verify with the JNI trace that the in-direction buffer is getting submitted before the out-direction buffer. It looked like, from the JNI trace you sent, that the out-direction buffer was getting sent out before the in-direction buffer. Remember that creating threads takes time, so if you're doing: inThread.start(); outPipe.syncSubmit(buffer); chances are the out-direction buffer will ALWAYS get to the device well before the in-direction buffer. If you're using a seperate Thread to manage the in-direction buffer(s), maybe you should add a 10ms (or more) delay to make sure the in-direction buffer(s) get to the device before submitting the out-direction buffer? On Mon, 9 May 2005, Dmitri Kostioukov wrote: >Quoting Dan Streetman <[EMAIL PROTECTED]>: > >> >> I have to assume the device is really not sending the first response you >> are expecting. Without knowing the device protocol, I have no idea why >> your device would skip that. > >At first I assumed it was a problem with a device itself. But like I mentioned >earlier - it happens with 3 different devices by 2 different manufacturers with >independent communication protocol. I can send pretty much and command and even >if the command itself is acknowledged by the device, I still do not the the >very >first 8 byte response. > > >> If you can get a USB bus trace, you could check if the device was actually >> sending the first response (and so show that javax.usb is dropping/losing >> the response). However I think it's much more likely the device just >> isn't sending that response. > >What's the easiest way to do it? I'll try. > >> On Mon, 2 May 2005, Dmitri Kostioukov wrote: >> >> >Quoting Dan Streetman <[EMAIL PROTECTED]>: >> > >> >> >> >> If it's an interrupt pipe then you have to submit your buffer before you >> >> send the command down. Interrupt pipes are only polled when you pass a >> > >> >I definitely do. >> > >> >> buffer to the USB subsystem to use (i.e. to put poll data in). You need >> >> to submit several buffers so the USb subsystem always has a buffer to put >> >> >> data in, and can thus maintain the spec-required polling interval for >> >> interrupt endpoints. >> > >> >What I do is start a separate threat which does nothing but submits the >> >in-buffer but just in case it could be the root of the problem, I modified >> it to >> >start multiple threads instead. The problem still exists. The output is >> below: >> > >> >Device found >> >Listening >> >Listening >> >Listening >> >Listening >> >Listening >> >Listening >> >Listening >> >Listening >> >Listening >> >Listening >> >Listening >> >Out: 8b 0 0 0 0 0 0 0 >> >Sent >> >In: 0 4 0 0 0 0 0 0 >> >Done >> >Out: 8b 0 0 0 0 0 0 0 >> >Sent >> >In: 0 0 3 0 0 1 1 2 >> >Done >> >In: 0 4 0 0 0 0 0 0 >> >Done >> > >> > > -- Dan Streetman [EMAIL PROTECTED] --------------------- 186,272 miles per second: It isn't just a good idea, it's the law! ------------------------------------------------------- This SF.Net email is sponsored by: NEC IT Guy Games. Get your fingers limbered up and give it your best shot. 4 great events, 4 opportunities to win big! Highest score wins.NEC IT Guy Games. Play to win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20 _______________________________________________ javax-usb-devel mailing list javax-usb-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/javax-usb-devel
