Thanks,
Sanjay Gupta<p> </p><p> </p>
------- Original Message -------
Sender : Dan Streetman<ddstr...@ieee.org>
Date : Oct 07, 2013 21:37 (GMT+09:00)
Title : Re: [javax-usb-devel] Hang problem with UsbPipe.syncSubmit(byte[])
On Mon, Oct 7, 2013 at 1:48 AM, SANJAY GUPTA <gupta.san...@samsung.com> wrote:
> Reposting the query after removing formatting...
>
> Thanks for your great support.
> I tried below as suggested:-
>
> int maxPacketSize =
> outUsbPipe.getUsbEndpoint().getUsbEndpointDescriptor().wMaxPacketSize( );
> log("Max Packet Size: " + maxPacketSize);
> final byte[] buffer = new byte[8192];
> for (int offset=0; offset<buffer.length; offset+=maxPacketSize) {
> final UsbIrp usbIrp = outUsbPipe.createUsbIrp( );
> usbIrp.setData(buffer, offset, maxPacketSize);
Well I don't think I suggested splitting the output data into max
packet sized irps, that's certainly unnecessary and will drastically
cut down on your throughput. I think I said use "reasonable" buffer
sizes. I'm pretty sure 8k is ok to send in a single irp.
==> If I transmit the whole buffer of 8K in single submission using
asyncSubmt() and wait for it to complete, the submission never gets completed
and stucks on waitUntilComplete(). The same thing happens while using
syncSubmit(). I do wait for the asynSubmit() to complete because my purpose is
to capture the completion time for the submission for different sized buffers.
Also, please not that the hang happens only when the buffer is uninitialized.
If I initialize the buffer then the UsbStallException is thrown.
for (int index=0; index<buffer.length; index++) {
buffer[index] = (byte) index;
}
>
> //Asynchronously submit the UsbIrp to UsbPipe
> log("==> Asynchronously submitting the UsbIrp to UsbPipe ...");
> outUsbPipe.asyncSubmit(usbIrp);
>
> //Wait for the UsbIrp to complete
> log("Waiting for the UsbIrp to complete ...");
> usbIrp.waitUntilComplete();
>
> log("!!! Successfully submitted the UsbIrp to UsbPipe ...");
> }
>
> But after successfully executing the loop for 3 times, it goes stuck on
> waitUntilComplete() as below-
>
> Max Packet Size: 512
> ==> Asynchronously submitting the UsbIrp to UsbPipe ...
> Waiting for the UsbIrp to complete ...
> !!! Successfully submitted the UsbIrp to UsbPipe ...
> ==> Asynchronously submitting the UsbIrp to UsbPipe ...
> Waiting for the UsbIrp to complete ...
> !!! Successfully submitted the UsbIrp to UsbPipe ...
> ==> Asynchronously submitting the UsbIrp to UsbPipe ...
> Waiting for the UsbIrp to complete ...
> !!! Successfully submitted the UsbIrp to UsbPipe ...
> ==> Asynchronously submitting the UsbIrp to UsbPipe ...
> Waiting for the UsbIrp to complete ...
>
>
> I even put a UsbPipeListener before the above code to poll the
> UsbPipeDataEvent on Input UsbPipe but failed to receive any event.
did you actually submit one or more buffers to the input pipe? You
obviously will never get anything if you don't submit a buffer to be
filled.
==> My mistake. But I have a feeling that if the status data from the Input
pipe is not read then further submission gets stuck. So, how to know that there
is some data to be read on the input pipe?
>
> final UsbPipeListener listener = new UsbPipeListener() {
> @Override
> public void errorEventOccurred(UsbPipeErrorEvent event) {
> // TODO Auto-generated method stub
> }
> @Override
> public void dataEventOccurred(UsbPipeDataEvent event) {
> final int transferLength = event.getActualLength();
> log("UsbPipeDataEvent occurred on IN UsbPipe with data size " +
> transferLength);
>
> //Asynchronously read the status in byte[] from IN UsbPipe
> log("Asynchronously reading the status in byte[] from IN UsbPipe
> ...");
> UsbIrp irp = inUsbPipe.asyncSubmit(new byte[transferLength]);
you shouldn't be using getActualLength to size the next buffer to send
- it should be consistent, or at least based on the device's protocol,
and the actual length is simply how many bytes this irp returned.
>
> //Wait for the UsbIrp to complete
> log("Waiting for the reading to complete ...");
> irp.waitUntilComplete();
um...what is the point of asyncSubmit() and then immediately in the
same thread waiting for it to complete? Additionally, your listener
callback is supposed to be quick, since calls will come sequentially.
And what is the point of waiting for the irp to complete right before
you exit the method?
> }
> };
> inUsbPipe.addUsbPipeListener(listener);
>
> ------- Original Message -------
> Sender : Dan Streetman<ddstr...@ieee.org>
> Date : Oct 02, 2013 22:31 (GMT+09:00)
> Title : Re: [javax-usb-devel] Hang problem with UsbPipe.syncSubmit(byte[])
>
> On Wed, Oct 2, 2013 at 6:23 AM, SANJAY GUPTA <gupta.san...@samsung.com> wrote:
>> Hi All,
>>
>> Please look below the sample scenario:-
>>
>> final byte[] outData = new byte[] {
>> (byte) 0x00, (byte) 0x01, (byte) 0x02, (byte) 0x03,
>> (byte) 0x04, (byte) 0x05, (byte) 0x06, (byte) 0x07,
>> (byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x00,
>> (byte) 0x08, (byte) 0x09, (byte) 0x0A, (byte) 0x01B,
>> (byte) 0x0C, (byte) 0x0D, (byte) 0x0E, (byte) 0x0F,
>> (byte) 0x00, (byte) 0x01, (byte) 0x02, (byte) 0x03,
>> (byte) 0x04, (byte) 0x05, (byte) 0x06, (byte) 0x07,
>> (byte) 0x00, (byte) 0x00, (byte) 0x00, (byte) 0x00 }
>> final byte[] inData = new byte[13];
>>
>> log("Synchronously submitting the byte[] to UsbPipe ...");
>> outUsbPipe.syncSubmit(data);
>>
>> //Synchronously read the status from IN UsbPipe
>> log("Synchronously reading the status from IN UsbPipe ...");
>> inUsbPipe.syncSubmit(inData);
>>
>> This code is working fine but I am facing problem if I want to change
>> (reduce/reduce/modify) the outData.
>> The control gets hang on reading the status data from the Input UsbPipe.
>> Any suggestion on below points will be helpful:-
>> 1. Is there any specific data format (may be starting header) in the actual
>> data being transferred?
>
> Data formats are entirely up to the device, unless the device
> implements a higher level spec (like HID, mass storage, etc) that
> itself contains the API for the data format. USB doesn't specify any
> data format at all, except for the control pipe 8-byte setup packet
> that must preface each control transfer, and the various default
> control pipe standard requests (set interface, clear stall, etc).
>
>
> ===> Thanks A lot. I am using a mass-storage device and BULK type UsbEndpoint
> for data transfer.
> But the problem is, suppose I keep the value of outData[8] as non-zero with
> all other things intact, the submission gets hanged which never completes.
> And then I have no choice but the unplug the device.
>
>
>
>> 2. What is the data size which can be transferred using single invocation of
>> syncSubmit()?
>
> it's been a while, but IIRC there's no limit in java, although I think
> the platform may enforce limits. I don't really remember the details
> though. For interrupt pipes, you of course should usually submit
> exactly the pipe size (wMaxPacketSize).
>
> ===> Mass-storage device and BULK type UsbEndpoint.
>
>> 3. What is the status data size which is received on Input Pipe as a result
>> of out data transfer?
>
> it's entirely dependent on your device. although if your input pipe
> is an interrupt pipe, it should be the wMaxPacketSize from the
> endpoint descriptor.
>
> Also, assuming your input pipe is interrupt type, it's probably better
> for you to keep a buffer on it, which will cause continuous polling of
> the device, as required by spec when the device is in use. You can do
> that either with a separate Thread that does nothing except
> syncSubmit() a buffer or irp to the pipe, then passes the returned
> data off somewhere else to process and immediately syncSubmit() a new
> buffer, or you can use asyncSubmit() with either a listener on the
> pipe or a separate Thread to waitUntilComplete() for the irp, and then
> also hand off the returned data to process somewhere else and
> immediately sync or async submit again a new buffer. With
> asyncSubmit(), you can submit multiple buffers, which is better
> because it keeps the low level platform queued up with buffers so that
> the device polling never stops, and you don't have to try to be quite
> so fast at resubmitting a new buffer.
>
> ===> Mass-storage device and BULK type UsbEndpoint.
>
>
>>
>> Thanks in Advance..
>> Sanjay Gupta
>>
>> ------------------------------------------------------------------------------
>> October Webinars: Code for Performance
>> Free Intel webinars can help you accelerate application performance.
>> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
>> the latest Intel processors and coprocessors. See abstracts and register >
>> http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
>> _______________________________________________
>> javax-usb-devel mailing list
>> javax-usb-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/javax-usb-devel
>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
> _______________________________________________
> javax-usb-devel mailing list
> javax-usb-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/javax-usb-devel
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk
_______________________________________________
javax-usb-devel mailing list
javax-usb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/javax-usb-devel
