It would be greatly appreciated if someone could provide an example code to 
poll the input pipe to read buffer.

I tried a thread as shown below but no help:-

final Thread thread = new Thread(new Runnable() {
        @Override
        public void run() {
                //Asynchronously read the status in list of UsbIrps from IN 
UsbPipe
                log("Asynchronously reading the status in list of UsbIrps from 
IN UsbPipe ...");
                final List<UsbIrp> list = new ArrayList<UsbIrp>();

                final UsbIrp usbIrp1 = inUsbPipe.createUsbIrp();
                usbIrp1.setAcceptShortPacket(true);
                usbIrp1.setData(new byte[maxPacketSize]);
                list.add(usbIrp1);

                final UsbIrp usbIrp2 = inUsbPipe.createUsbIrp();
                usbIrp2.setAcceptShortPacket(true);
                usbIrp2.setData(new byte[maxPacketSize]);
                list.add(usbIrp2);

                try {
                        inUsbPipe.asyncSubmit(list);
                } catch (UsbNotActiveException e) {
                        // TODO Auto-generated catch block
                        e.printStackTrace();
                } catch (UsbNotOpenException e) {
                        // TODO Auto-generated catch block
                        e.printStackTrace();
                } catch (IllegalArgumentException e) {
                        // TODO Auto-generated catch block
                        e.printStackTrace();
                } catch (UsbDisconnectedException e) {
                        // TODO Auto-generated catch block
                        e.printStackTrace();
                } catch (UsbException e) {
                        // TODO Auto-generated catch block
                        e.printStackTrace();
                }
        }
});
thread.start();

I don't know how to keep buffers ready for reading the data from input pipe. 
And after reading the buffer, how should I resubmit another buffer. I event 
kept a listener on Input pipe to get notification of a data event but no event 
is received while I am submitting the input buffer in the thread.

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);
        }
};
inUsbPipe.addUsbPipeListener(listener);


Thanks,
Sanjay Gupta

------- Original Message -------
Sender : SANJAY GUPTA<gupta.san...@samsung.com>  S5/Senior 
Engineer/Architecture Analysis Lab./Samsung Electronics
Date   : Oct 10, 2013 12:09 (GMT+09:00)
Title  : Re: Re: [javax-usb-devel] Hang problem with UsbPipe.syncSubmit(byte[])

Thanks,
Sanjay Gupta<p>&nbsp;</p><p>&nbsp;</p>

------- Original Message -------
Sender : Dan Streetman<ddstr...@ieee.org> 
Date   : Oct 08, 2013 21:28 (GMT+09:00)
Title  : Re: [javax-usb-devel] Hang problem with UsbPipe.syncSubmit(byte[])

On Tue, Oct 8, 2013 at 3:51 AM, SANJAY GUPTA <gupta.san...@samsung.com> wrote:
> Thanks,
> Sanjay Gupta<p>&nbsp;</p><p>&nbsp;</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;
> }

This sounds like you don't understand the protocol of your device.

###==> I noticed that the maxPacketSize which the UsbEndpoint of my device can 
transfer is 512 bytes and the maximum buffer size which I can transfer to the 
out UsbPipe is 1536 bytes (which is exactly 3 times the maxPacketSize).
After transmitting this size of buffer, I cannot transfer any more byte to the 
pipe.
Even after closing the pipe & releasing the interface, and again claim() and 
open() the next time, the data transfer gets stuck.
I feel sorry bothering you but I am unable to understand whats the issue with 
the trasnfer data size.

It is also to be noted that, the I am able to transfer only 1536 bytes, no 
matter in what sequece.
Either I send all bytes at the same time or by splitting them in different 
exececutions (close pipe and again open), the extra data transfer gets stuck.
And I have to unplug the device and plug it again to execute.

>
>>
>>         //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?

When you get a buffer back (i.e. a completed IRP), either when
syncSubmit() returns or waitUntilComplete() returns or your listener
gets triggered, the device has already sent data back, that is now in
the buffer you provided.

Knowing that there is data "to be read" on the pipe isn't possible
(except predicting that there *should* be data sent back from the
device based on the specific device protocol, of course).  Generally
you should just keep buffer(s) "pending" on any input pipe, since most
specs describe actions that the driver (you) should take when the
device sends any data in.  The pending buffer will then just return to
you immediately with the data (and you should then resubmit another
buffer - it's good to keep multiple buffers pending so there's never
any gap in device polling).

Keep in mind that using javax.usb isn't high level programming.
You're doing very low level device communication, and it's
complicated, because the usb spec is very complicated.

###==> Can you please provide a example code to poll the input pipe to read 
buffer.

>
>>
>> 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
------------------------------------------------------------------------------
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
------------------------------------------------------------------------------
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

Reply via email to