libusb-devel

[libusb] libusb windows compiled/distrib by Orbbec Inc without attribution, license, source, or anything

[Dale P. <da...@hi...>]

During my initial work to add support for https://www.orbbec.com sensors to
my Windows plugin, I suspected they were using libusb but I didn't see the
libusb DLL anywhere.

Using dumpbin I discovered that they have compiled libusb directly into
their proprietary OrbbecSDK.DLL and are distributing that DLL under their
own closed license. It's distributed with almost all their sensors.
https://www.orbbec.com/developers/orbbec-sdk/

Two direct examples I found as I would use them in my Windows project
Orbbec SDK  https://github.com/orbbec/OrbbecSDK/tree/main/lib/win_x64
Orbbec K4A Wrapper SDK
https://github.com/orbbec/OrbbecSDK-K4A-Wrapper/tree/main/src/orbbec which
submodules'back to the above main Orbbec SDK

Pete Batard asked me to post here. Please redirect me elsewhere as needed.
My goal is to ensure fair play and license adherence/safety.

--Dale Phurrough

Re: [libusb] OT problem with PIC18F45K50 homebrew USB-stack

[Tim R. <ti...@pr...>]

On 6/10/24 9:41 AM, Kustaa Nyholm wrote:

>
> The messages (reports) are not buffered on the host side either way. 
> If this is the wrong
> assumption I have to think if there is a situation in which the above 
> message counter logic
> would fail and dead lock.
>
Schemes like that are rather delicate.  You have to be very careful to 
make sure you can handle a dropped packet. Theoretically, an interrupt 
pipe should retry if there is an error, but nothing is perfect.


> On other could be if the input reports are buffered and if poll() only 
> ‘returned true’ once
> for multiple buffered messages. I don’t see how that could happen 
> either, but again this
> smells.
>
> So I guess the questions I would like to know answer to are:
> 1) Are the input/output reports buffered on the host side?
> 2) Can poll indicate that there is data to read only once for multiple 
> input reports?
>
In general, there is no buffering anywhere in the USB stack.  If there 
are no outstanding requests from applications, then the device stays 
idle and is not given a chance to transmit/receive.

With HID devices, it's a little more complicated, because things are 
optimized for keyboards.  Depending on which request you use, the HID 
subsystem can read one entry ahead and keep it for you.


> Control requestsare handled in the USB interrupt and as they involve 
> only EP0
> they should not muck up the EP2 handling in the mainloop?
>
Yes, that's how it should to work.

-- 
Tim Roberts,ti...@pr...
Providenza & Boekelheide, Inc.

Re: [libusb] OT problem with PIC18F45K50 homebrew USB-stack

[Kustaa N. <Kus...@pl...>]

Thanks Tim for taking time to look at this.

I’ve now managed get my hands on to an old  Beagl 480 Analyzer so will try to hook that up.

Mean while couple thoughts your response raised in my mind.

From: Tim Roberts <ti...@pr...>
Date: Sunday, 9. June 2024 at 21.03
To: lib...@li... <lib...@li...>
Subject: Re: [libusb] OT problem with PIC18F45K50 homebrew USB-stack
Kustaa Nyholm wrote:
>
> The device enumerates fine and the HID descriptors are fetched and all
> that initial stuff works.
>
> I only use EP2 to talk to the device, I only send and received 64 byte
> reports.

So, EP02 and EP82 are both interrupt pipes?

These are my descriptors:

// http://lists.apple.com/archives/usb/2010/May/msg00007.html
__code usb_dev_desc_t device_descriptor = { //
                                sizeof(usb_dev_desc_t),                             // bLength
                                                                DSC_DEV,                // bDescriptorType
                                                                0x0200,                 // bcdUSB lsb, bcdUSB msb
#ifdef USE_IAD
                                                                0xEF,                   // bDeviceClass
                                                                0x02,                   // bDeviceSubClass
                                                                0x01,                   // bDeviceProtocl
#else
                                                                0x00,                   // bDeviceClass
                                                                0x00,// bDeviceSubClass
                                                                0x00,// bDeviceProtocl
#endif
                                                                8,                      // bMaxPacketSize
                                                                USB_VID,                                                            // idVendor
                                                                USB_PID,                                                            // idProduct
                                                                0x0100,                 // bcdDevice
                                                                0x01,                   // iManufacturer
                                                                0x02,                   // iProduct
                                                                0x03,                   // iSerialNumber
                                                                0x01                    // bNumConfigurations
                                };

typedef struct { //
                usb_cfg_desc_t cd01; //
                usb_intf_desc_t i01a00; //
                usb_hid_desc_t hid_01a00; //
                usb_ep_desc_t ep01i_i01a00; //
                usb_ep_desc_t ep02i_i01a00; //
} config_struct_t;

__code config_struct_t config_descriptor = { //
                                {
                                // Configuration Descriptor
                                                                0x09,// Size of this descriptor in bytes
                                                                DSC_CFG,                             // configurator descriptor type
                                                                sizeof(config_struct_t),                                // Total length of data for this configuration
                                                                1,                                                                                                                            // bNumInterfaces
                                                                1,                                                                                                                            // bConfigurationValue
                                                                0,                                                                                                                            // iConfiguration
                                                                0x80 | _SELF,                                                                     // bmAttributes
                                                                1,                                                                                                            // bMaxPower
                                                                }, {
                                                                // Interface Descriptor
                                                                                                sizeof(usb_intf_desc_t),                                              // Size of this descriptor in bytes
                                                                                                DSC_INTF,                                         // INTERFACE descriptor type
                                                                                                0,                                                                                                                            // Interface Number
                                                                                                0,                                                                                                                            // Alternate Setting Number
                                                                                                2,                                                                                                                            // Number of endpoints in this interfacee
                                                                                                HID_INTF,                                                                                           // Class code
                                                                                                0,                                                                                                                            // Subclass code
                                                                                                0,                                                                                                                            // Protocol code
                                                                                                0,                                                                                                                            // Interface string index
                                                                }, {
                                                                // HID Class-Specific Descriptor
                                                                                                sizeof(usb_hid_desc_t),                                              // Size of this descriptor in bytes
                                                                                                DSC_HID,                                                                                           // HID descriptor type
                                                                                                0x0111,                                                                                                               // HID Spec Release Number in BCD format (1.11)
                                                                                                0x00,                                                                                                     // Country Code (0x00 for Not supported)
                                                                                                1,                                                                                        // Number of class descriptors, see usbcfg.h
                                                                                                DSC_RPT,                                                                                           // Report descriptor type
                                                                                                sizeof(hid_rpt01),                                                           // Size of the report descriptor
                                                                }, {
                                                                // Endpoint Descriptor
                                                                                                sizeof(usb_ep_desc_t),                                                                // Size of this descriptor in bytes
                                                                                                DSC_EP,                                                 // Endpoint Descriptor
                                                                                                _EP02_IN,                                                                   // Endpoint Address
                                                                                                _INT,                                                                                         // Attributes
                                                                                                0x40,                                                                                         // size
                                                                                                0x01,                                                                                                     // Interval
                                                                }, {
                                                                // Endpoint Descriptor
                                                                                                sizeof(usb_ep_desc_t),                                                                // Size of this descriptor in bytes
                                                                                                DSC_EP,                                                 // Endpoint Descriptor
                                                                                                _EP02_OUT,                                                              // EndpointAddress
                                                                                                _INT,                                                                                         // Attributes
                                                                                                0x40,                                                                                         // size
                                                                                                0x01                                                                                                      // Interval
                                                                }

                                };

// HID report descriptor
__code unsigned char hid_rpt01[] = { // 28 bytes
                                0x06, 0x00, 0xFF,       // Usage Page = 0xFF00 (Vendor Defined Page 1)
                                                                0x09, 0x01,             // Usage (Vendor Usage 1)
                                                                0xA1, 0x01,             // Collection (Application)
                                                                0x19, 0x01,             //      Usage Minimum
                                                                0x29, 0x40,             //      Usage Maximum
                                                                0x15, 0x00,             //      Logical Minimum
                                                                0x26, 0xFF, 0x00,            //      Logical Maximum
                                                                0x75, 0x08,             //      Report Size: 8-bit field size
                                                                0x95, 0x40,             //      Report Count: Make sixty-four 8-bit fields
                                                                0x81, 0x02,             //      Input (Data, Array, Abs)
                                                                0x19, 0x01,             //      Usage Minimum
                                                                0x29, 0x40,             //      Usage Maximum
                                                                0x91, 0x02,             //      Output (Data, Array, Abs)
                                                                0xC0                   // End Collection
                                };



> When it fails I the read polls always timeout. Re-opening the device
> restores normal communication.
>
> Question: am I correct that apart from possible renumeration my device
> firmware cannot know
> if the device handle is closed or opened on the host side?

No.  The only thing it will notice is that it stops getting IN or OUT
tokens during its scheduled slot time -- it no longer gets a chance to
send or receive.

OK, as I had understood.


> My question is if it is ok to just rely on the assumption that when
> ever the SIE in the MCU
> signals for the EP2 that the buffer is available not owned by the
> firmware
> there is a new output report (out EP) or I can fill in the buffer with
> next input report (in EP)?

That's a question that is very specific to the PIC 18F4550, which has a
rather primitive interface.  However, the input and output sides of an
endpoint are completely unrelated.  Activity on one should not impact
the other in any way.  That's a common misconception in USB.
Right. But started a train of though in my mind:

Because the input and output are unrelated my protocol always sends (in output report)
a message counter (one byte), that is incremented for each message sent.
The device always sends (in input report) the last counter value it has received.

On the host side I send on output report and the read back messages (input reports) until I get
a message that has the same value as the last sent message.

I have written the code  under the following assumptions:

The messages (reports) are not buffered on the host side either way. If this is the wrong
assumption I have to think if there is a situation in which the above message counter logic
would fail and dead lock.

One scenario would be if I manage to send two or more messages before I get a message back,
then message I get back would not have the counter value of the last sent message. I don’t
see how this could happen but this smells.

On other could be if the input reports are buffered and if poll() only ‘returned true’ once
for multiple buffered messages. I don’t see how that could happen either, but again this
smells.

So I guess the questions I would like to know answer to are:
1) Are the input/output reports buffered on the host side?
2) Can poll indicate that there is data to read only once for multiple input reports?




> I have assumed that the USB SIE takes care of the communication up to
> the transfer level,
> transmitting, re-transmitting and ACKing as necessary or NACK:in if my
> main loop has
> not have time processes the previous transfer.
>
> Is this correct?

In general, yes.  The 18F4550 hardware should be handling the wire-level
interface, even if your loop is mucked up.  Have you done any packet
tracing, as suggested on the PIC mailing list?
I’m going to now that I have the Beagle available.

> I do have an interrupt service that handles all the EP0 control stuff.
> But once the
> communication with the EP2 has started I should not see any of that
> stuff anyway
> unless the device gets enumerated?

You can't rely on that.  Since you are a HID device, the HID driver gets
involved here.  It might be sending status requests to your control
endpoint on its own.  I'm just making that up, however -- I don't know
whether it actually does.
Control requests are handled in the USB interrupt and as they involve only EP0
they should not muck up the EP2 handling in the mainloop?

I have now verified that as far as I can tell when the problem occurs the device
is not re-enumerated.
Wbr Kusti


--
Tim Roberts, ti...@pr...
Providenza & Boekelheide, Inc.
This e-mail may contain confidential or privileged information and is intended solely for the person to whom it is addressed. If you have received this e-mail in error, please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. We will not be liable for direct, indirect, special or consequential damages arising from the alteration of this e-mail, or as a result of any virus being passed on or as of transmission of this e-mail in general.

Re: [libusb] OT problem with PIC18F45K50 homebrew USB-stack

[Tim R. <ti...@pr...>]

Kustaa Nyholm wrote:
>
> The device enumerates fine and the HID descriptors are fetched and all 
> that initial stuff works.
>
> I only use EP2 to talk to the device, I only send and received 64 byte 
> reports.

So, EP02 and EP82 are both interrupt pipes?


> When it fails I the read polls always timeout. Re-opening the device 
> restores normal communication.
>
> Question: am I correct that apart from possible renumeration my device 
> firmware cannot know
> if the device handle is closed or opened on the host side?

No.  The only thing it will notice is that it stops getting IN or OUT 
tokens during its scheduled slot time -- it no longer gets a chance to 
send or receive.


> My question is if it is ok to just rely on the assumption that when 
> ever the SIE in the MCU
> signals for the EP2 that the buffer is available not owned by the 
> firmware
> there is a new output report (out EP) or I can fill in the buffer with 
> next input report (in EP)?

That's a question that is very specific to the PIC 18F4550, which has a 
rather primitive interface.  However, the input and output sides of an 
endpoint are completely unrelated.  Activity on one should not impact 
the other in any way.  That's a common misconception in USB.


> I have assumed that the USB SIE takes care of the communication up to 
> the transfer level,
> transmitting, re-transmitting and ACKing as necessary or NACK:in if my 
> main loop has
> not have time processes the previous transfer.
>
> Is this correct?

In general, yes.  The 18F4550 hardware should be handling the wire-level 
interface, even if your loop is mucked up.  Have you done any packet 
tracing, as suggested on the PIC mailing list?


> I do have an interrupt service that handles all the EP0 control stuff. 
> But once the
> communication with the EP2 has started I should not see any of that 
> stuff anyway
> unless the device gets enumerated?

You can't rely on that.  Since you are a HID device, the HID driver gets 
involved here.  It might be sending status requests to your control 
endpoint on its own.  I'm just making that up, however -- I don't know 
whether it actually does.

-- 
Tim Roberts, ti...@pr...
Providenza & Boekelheide, Inc.

[libusb] OT problem with PIC18F45K50 homebrew USB-stack

[Kustaa N. <ea...@ea...>]

Hi,

This is NOT libusb problem but I hope it is ok to try to fish for some 
help here:

I have a problem with my hobby project USB HID device, described more in 
more detail here:

https://forum.microchip.com/s/topic/a5CV40000001UVVMA2/t396565

The problem is rare but it is guaranteed to happen if let the system run 
for day(s).

I try to be brief and specific here.

The device enumerates fine and the HID descriptors are fetched and all 
that initial stuff works.

I only use EP2 to talk to the device, I only send and received 64 byte 
reports.

On the host side  (Linux/Raspberry Pi) the communication is with 
standard file system write/poll/read calls.

When it fails I the read polls always timeout. Re-opening the device 
restores normal communication.

Question: am I correct that apart from possible renumeration my device 
firmware cannot know
if the device handle is closed or opened on the host side?

On the device side all the communication happens in main loop which is 
very simple, see below.

My question is if it is ok to just rely on the assumption that when ever 
the SIE in the MCU
signals for the EP2 that the buffer is available not owned by the firmware
there is a new output report (out EP) or I can fill in the buffer with 
next input report (in EP)?

Or do I need to gather for some other situations?

I have assumed that the USB SIE takes care of the communication up to 
the transfer level,
transmitting, re-transmitting and ACKing as necessary or NACK:in if my 
main loop has
not have time processes the previous transfer.

Is this correct?

I do have an interrupt service that handles all the EP0 control stuff. 
But once the
communication with the EP2 has started I should not see any of that 
stuff anyway
unless the device gets enumerated?

I copied this behavior plus ten years ago from some code which I cannot 
re-call and I'm
now questioning every assumption.

wbr Kusti

The main loop:

while (1) {
         if (!(ep2_o.STAT & UOWN)) { // new data from host, so process it
             ... read output report from the USB RAM

             // turn the buffer over to SIE so we can get more data
             ep2_o.CNT = 64;
             if (ep2_o.STAT & DTS)
                 ep2_o.STAT = DTSEN;
             else
                 ep2_o.STAT = DTS | DTSEN;
             ep2_o.STAT |= UOWN;
         }


         if (!(ep2_i.STAT & UOWN)) {    // we own the USB buffer, so 
update data going to the host
             ... write data for the input report to the USB RAM

             // turn the buffer over to the SIE so the host will pick it up
             ep2_i.CNT = 64;
             if (ep2_i.STAT & DTS)
                 ep2_i.STAT = DTSEN;
             else
                 ep2_i.STAT = DTS | DTSEN;
             ep2_i.STAT |= UOWN;
         }
     }

[libusb] Test .. please ignore

[Kustaa N. <ea...@ea...>]

Have not been able to send to the list twice.

Re: [libusb] LibUSB C library use in Andoid Studio

[Tim R. <ti...@pr...>]

hacka thon wrote:
> Thanks for your response,
>                                          You are absolutely right, 
> that Operating systems will automatically mount USB devices, However, 
> I tried this in my mobile application where I received an events for 
> USB attach and detach, but USB Mass storage not displayed in Mobile's 
> default File Manager, Then I found that most of the smart phones are 
> only supporting FAT32 systems, but I have FAT16 USB mass storage 
> device which is not supported by some latest phones like Redmi, some 
> series of Samsung phones,etc.
> So, how can I use your library to  communicate with USB 
> FAT16/32 devices as you mentioned on your libusb Info page.

You don't want to do this.  Really.

The USB Mass Storage Class specification is a very low-level 
specification.  The communication is in SCSI commands -- essentially 
"read this sector", "write this sector".  Those are absolute sector 
numbers; the Mass Storage spec knows nothing at all about files.  You 
will need to download and understand this specification.

Even if you could figure out how to communicate with the device using 
those SCSI commands, you would THEN have to have a complete 
implementation of the FAT16 file system.  FAT16 is not terribly 
complicated, especially if you're only interested in reading, but in the 
end it's just not going to be worth the trouble.

Do you see these devices get exposed as /dev devices, like /dev/sdc?  If 
you can talk to the raw device, you may be able to bypass the USB Mass 
Storage commands and just do the FAT16 part using raw bytes.

-- 
Tim Roberts, ti...@pr...
Providenza & Boekelheide, Inc.

Re: [libusb] LibUSB C library use in Andoid Studio

[Jörn M. [A. V. <Joe...@al...>]

Hi,

|>      I do not know if even the next level above that is universal i.e. if there is a universal way to read/right sectors/blocks in mass storage.

I would expect thumb/hard drives generally to utilize  the mass storage class (08h), so there should be a common standard for the protocol level.
https://www.usb.org/sites/default/files/Mass_Storage_Specification_Overview_v1.4_2-19-2010.pdf
On top of this you would need to implement the FAT16 file system driver.
https://academy.cba.mit.edu/classes/networking_communications/SD/FAT.pdf
As all this is going to be a ton of work just to support an outdated standard (defined in ´83 for DOS 3.0) I would rather recommend to investigate if there is really no way to reformat these drives to a more modern file system.

Kind regards,
Jörn

-----Ursprüngliche Nachricht-----
Von: Kustaa Nyholm <ea...@ea...>
Gesendet: Freitag, 31. Mai 2024 08:59
An: hacka thon <hac...@gm...>
Cc: lib...@li...
Betreff: Re: [libusb] LibUSB C library use in Andoid Studio

[Sie erhalten nicht häufig E-Mails von mailto:ea...@ea.... Weitere Informationen, warum dies wichtig ist, finden Sie unter https://aka.ms/LearnAboutSenderIdentification ]

On 31.5.2024 9.06, hacka thon wrote:
> Thanks for your response,
>                                          You are absolutely right,
> that Operating systems will automatically mount USB devices, However,
> I tried this in my mobile application where I received an events for
> USB attach and detach, but USB Mass storage not displayed in Mobile's
> default File Manager, Then I found that most of the smart phones are
> only supporting FAT32 systems, but I have FAT16 USB mass storage
> device which is not supported by some latest phones like Redmi, some
> series of Samsung phones,etc.
> So, how can I use your library to  communicate with USB
> FAT16/32 devices as you mentioned on your libusb Info page.


I'm no expert in this but I think you are heading for a lot of trouble/work.

libUSB just provides the low level access to the USB end points.

I do not know if even the next level above that is universal i.e. if there is a universal way to read/right sectors/blocks in mass storage.

If not then you will have to cope with emulating what the operating system driver does for every different type of mass storage you want to support.

Then above that you need to be able to do what the file system in the OS does.

Some almost 40 years ago I wrote a FAT16/32 file system component from scratch with minimal info (just reverse engineering).

Today you can probably find some code that does this, for example from the Linux sources, but that and the drivers are C-code.

You can access C-code from Java with JNI and more easily IMO using JNA (if supported on Android) but it will not be as trivial as just calling some Linux driver or file system calls.

So it is doable.

But I think it will not be a trivial few hours to apply that knowledge in Java.

In any case libUSB AFAIK just provides you with access to the end point descriptors and access to the end points, the rest is up to you.

wbr Kusti





_______________________________________________
libusb-devel mailing list
mailto:lib...@li...
https://lists.sourceforge.net/lists/listinfo/libusb-devel

Re: [libusb] LibUSB C library use in Andoid Studio

[Kustaa N. <ea...@ea...>]

On 31.5.2024 9.06, hacka thon wrote:
> Thanks for your response,
>                                          You are absolutely right, 
> that Operating systems will automatically mount USB devices, However, 
> I tried this in my mobile application where I received an events for 
> USB attach and detach, but USB Mass storage not displayed in Mobile's 
> default File Manager, Then I found that most of the smart phones are 
> only supporting FAT32 systems, but I have FAT16 USB mass storage 
> device which is not supported by some latest phones like Redmi, some 
> series of Samsung phones,etc.
> So, how can I use your library to  communicate with USB 
> FAT16/32 devices as you mentioned on your libusb Info page.


I'm no expert in this but I think you are heading for a lot of trouble/work.

libUSB just provides the low level access to the USB end points.

I do not know if even the next level above that is universal i.e. if 
there is a universal way to read/right sectors/blocks in mass storage.

If not then you will have to cope with emulating what the operating 
system driver does for every different type of mass storage you want to 
support.

Then above that you need to be able to do what the file system in the OS 
does.

Some almost 40 years ago I wrote a FAT16/32 file system component from 
scratch with minimal info (just reverse engineering).

Today you can probably find some code that does this, for example from 
the Linux sources, but that and the drivers are C-code.

You can access C-code from Java with JNI and more easily IMO using JNA 
(if supported on Android) but it will not be as trivial as just calling 
some Linux driver or file system calls.

So it is doable.

But I think it will not be a trivial few hours to apply that knowledge 
in Java.

In any case libUSB AFAIK just provides you with access to the end point 
descriptors and access to the end points, the rest is up to you.

wbr Kusti

Re: [libusb] LibUSB C library use in Andoid Studio

[hacka t. <hac...@gm...>]

Thanks for your response,
                                         You are absolutely right, that
Operating systems will automatically mount USB devices, However, I tried
this in my mobile application where I received an events for USB attach and
detach, but USB Mass storage not displayed in Mobile's default File
Manager, Then I found that most of the smart phones are only supporting
FAT32 systems, but I have FAT16 USB mass storage device which is not
supported by some latest phones like Redmi, some series of Samsung
phones,etc.
So, how can I use your library to  communicate with USB FAT16/32 devices as
you mentioned on your libusb Info page.

[image: image.png]

On Fri, 31 May 2024 at 04:16, Tim Roberts <ti...@pr...> wrote:

> hacka thon wrote:
> >
> > I want to implement LibUSB library in android application to mount
> > file system and copy USB device's files into mobile with user
> > permission but without filepicker or user interaction to select file.
> > Is this library convenient for me to fetch USB device's files?
>
> To follow up a bit, libusb is intended to provide drivers for devices
> that do not already have them.  Your USB drive already has a driver, and
> the operating system will automatically mount it. You access the files
> just like any other mounted file system
>
> --
> Tim Roberts, ti...@pr...
> Providenza & Boekelheide, Inc.
>
> _______________________________________________
> libusb-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libusb-devel
>

Re: [libusb] LibUSB C library use in Andoid Studio

[Tim R. <ti...@pr...>]

hacka thon wrote:
>
> I want to implement LibUSB library in android application to mount 
> file system and copy USB device's files into mobile with user 
> permission but without filepicker or user interaction to select file. 
> Is this library convenient for me to fetch USB device's files?

To follow up a bit, libusb is intended to provide drivers for devices 
that do not already have them.  Your USB drive already has a driver, and 
the operating system will automatically mount it. You access the files 
just like any other mounted file system

-- 
Tim Roberts, ti...@pr...
Providenza & Boekelheide, Inc.

Re: [libusb] LibUSB C library use in Andoid Studio

[Kustaa N. <ea...@ea...>]

No

On 30.5.2024 8.56, hacka thon wrote:
> I want to implement LibUSB library in android application to mount 
> file system and copy USB device's files into mobile with user 
> permission but without filepicker or user interaction to select file. 
> Is this library convenient for me to fetch USB device's files?
> If yes, then please provide me the example code or any 
> relevant document which helps me to do this task because I can't find 
> any documentation of code for implementing it in android studio.


No, LibUSB is not the library for that purpose.

What is wrong with accessing them the usual way in Java:

https://www.developer.com/mobile/android/working-with-files-and-the-file-system-in-android-apps/

wbr Kusti

[libusb] LibUSB C library use in Andoid Studio

[hacka t. <hac...@gm...>]

I want to implement LibUSB library in android application to mount file
system and copy USB device's files into mobile with user permission but
without filepicker or user interaction to select file. Is this library
convenient for me to fetch USB device's files?
If yes, then please provide me the example code or any relevant document
which helps me to do this task because I can't find any documentation of
code for implementing it in android studio.

Thanks and regards,

Re: [libusb] DOMException: Failed to execute 'controlTransferIn' on 'USBDevice': A transfer error has occurred.

[<jo...@be...>]

Hi,

>The above Wiki has a link to the following blog post which talks about the difficulties
> in enumerating the devices using web applications.
>https://web.dev/articles/porting-libusb-to-webusb#using-the-port

Thanks. After some more debug, I think the problem relates to the value of MAX_CTRL_BUFFER_LENGTH in emscripten_webusb.cpp. It's currently 4096. There's a comment that says transfers may fail if this is too big - and reducing it to 255 seems to enable the code to work on Windows.

>If that does not help, please create a new issue in libusb github.
>https://github.com/libusb/libusb/issues

Have added: https://github.com/libusb/libusb/issues/1493 with some more details.

Cheers,
Jon

[libusb] Seeking Assistance: Implementing USB Device Suspend/Resume in User Space Driver via libusb

[Muni S. <mun...@gm...>]

Hi all,

I hope this email finds you well. We are currently working on a USB
device driver in the Linux kernel space, which supports the
suspend/resume functionality for a USB device using the struct
usb_driver's .suspend and .resume callbacks.


In our driver code, we perform a check to determine if the device has
remote wakeup capability. If the device supports remote wakeup, we
enable the device's autosuspend mode by setting the struct
usb_device->dev.power.autosuspend_delay parameter and then calling
usb_enable_autosuspend().


Similarly, to resume the suspended device, we expose an API to user
space via IOCTL. In this process, we set struct
usb_device->dev.power.autosuspend_delay to -1 and then call
usb_disable_autosuspend().


While we have successfully converted most of the USB device driver
functionality from kernel space to user space using libusb, we are now
seeking guidance on how to implement USB device suspend/resume in user
space. Specifically, we would like to know if libusb provides support
for achieving the suspend/resume functionality mentioned above.
Additionally, any insights or suggestions on how to accomplish this
task would be greatly appreciated.


It's worth mentioning that our USB device driver also supports
Bulk\Coontrol I/O transfers and other functionalities.


Thank you in advance for any assistance you can provide. I look
forward to your valuable inputs and recommendations.

-- 
Thanks,
Sekhar

Re: [libusb] DOMException: Failed to execute 'controlTransferIn' on 'USBDevice': A transfer error has occurred.

[Xiaofan C. <xia...@gm...>]

On Sat, May 4, 2024 at 5:06 PM <jo...@be...> wrote:
>
> I’m trying to use libusb in a Qt WebAssembly app via the Emscripten port.
> It’s a port of driver that works under Linux & Windows. The first call to
>  libusb_get_device_list() is failing with the console message:
>
>     DOMException: Failed to execute 'controlTransferIn' on 'USBDevice':
> A transfer error has occurred.
>
> On Windows 11 using Chrome, Edge and Opera.
>
> Tracing through the code, in emscripten_webusb.cpp makeControlTransferPromise()
> calls controlTransferIn with "request_type”: “standard", "recipient”: “device", "request”: 6,
> "wValue”: 0x100, "wIndex”: 0, "wLength”: 0x12 before this error.
>
> Any idea why this might be failing? If I perform the same controlTransfer in
> JavaScript, it works OK.

As per libusb Wiki, the status of WebAssembly + WebUSB support is EXPERIMENTAL.
https://github.com/libusb/libusb/wiki

The above Wiki has a link to the following blog post which talks about the
difficulties in enumerating the devices using web applications.
https://web.dev/articles/porting-libusb-to-webusb#using-the-port

If that does not help, please create a new issue in libusb github.
https://github.com/libusb/libusb/issues

-- 
Xiaofan

Re: [libusb] uclinux

[Xiaofan C. <xia...@gm...>]

On Sat, May 4, 2024 at 11:30 AM Tim Roberts <ti...@pr...> wrote:
>
> On 5/3/24 7:04 AM, ck...@ut... wrote:
>>
>> Is it possible to have libusb run under an OS without MMU.
>> Like uclinux, RT-THREAD?
>
> ucLinux doesn't go beyond the 2.6 kernel.  That was a shaky time for
> USB support.

Looks like ucLinux has been integrated into the mainline Linux kernel.
https://en.wikipedia.org/wiki/%CE%9CClinux

>From libusb mailing list archive, it seems to me libusb will work under
ucLinux, at least for some distros.
https://libusb-devel.narkive.com/dv6mVKMx/libusb-1-0-16-rc10-without-udev#post15

As for RT-Thread, someone probably needs to carry out the hard work
of porting it.

-- 
Xiaofan

[libusb] DOMException: Failed to execute 'controlTransferIn' on 'USBDevice': A transfer error has occurred.

[<jo...@be...>]

Hi,

 

I'm trying to use libusb in a Qt WebAssembly app via the Emscripten port.
It's a port of driver that works under Linux & Windows. The first call to
libusb_get_device_list() is failing with the console message:

 

    DOMException: Failed to execute 'controlTransferIn' on 'USBDevice': A
transfer error has occurred.

 

On Windows 11 using Chrome, Edge and Opera.

 

Tracing through the code, in emscripten_webusb.cpp
makeControlTransferPromise() calls controlTransferIn with "request_type":
"standard", "recipient": "device", "request": 6, "wValue": 0x100, "wIndex":
0, "wLength": 0x12 before this error. 

 

Any idea why this might be failing? If I perform the same controlTransfer in
JavaScript, it works OK.

 

Thanks,

Jon

 

 

Re: [libusb] uclinux

[Tim R. <ti...@pr...>]

On 5/3/24 7:04 AM, ck...@ut... wrote:

> Is it possible to have libusb run under an OS without MMU. Like 
> uclinux, RT-THREAD?

ucLinux doesn't go beyond the 2.6 kernel.  That was a shaky time for USB 
support.

-- 

Tim Roberts,ti...@pr...
Providenza & Boekelheide, Inc.

[libusb] uclinux

[<ck...@ut...>]

Is it possible to have libusb run under an OS without MMU. Like uclinux, RT-THREAD?

Re: [libusb] Issues with low CDC_ACM throughput on STM32 USB-FS (sync/async)

[Jerri L. <Jer...@pr...>]

On Saturday, April 27th, 2024 at 7:51 AM, Xiaofan Chen <xia...@gm...> wrote:
> 
> Windows standard Serial API or Posix serial API.
> 

I'd prefer to avoid the nitty-gritty of using tty directly. They've stood the test of time, but the API is also 50+ (?) years old and it shows.

> You can even try a cross-platform library like libserialport.
> https://sigrok.org/wiki/Libserialport
> 

That indeed may be a good option, but that's not the issue I raised. Your solution to "I'm getting poor performance with libusb" is "don't use libusb"? It doesn't seem like libusb is actually the cause here, but still, in principle there's no reason why it shouldn't work.

> Sorry but no idea why dd is relevant here. That is probably only relevant if
> you use a USB mass storage device.

It's relevant because dd, as it happens, indirectly uses the serial API you suggest by talking to the device through /dev/ttyX. 

Incidentally, it's the way ST officially recommends for measuring CDC throughput.


> For a CDC-ACM device, the OS will assign the USB serial driver to the device.

Yes, I've mentioned that several times.

> If you want to use libusb, then do not use CDC-ACM at all

why?? why shouldn't I use libusb to talk to any USB endpoint I want to?

Using CDC has several big benefits, including default drivers on linux/win, and the convenience of using a terminal program during development. Also, dead simple code generation with the STM32 IDE.
All of that minimizes the amount of code I have to write, and maximizes flexibility. For me, it's a no-brainer that CDC is a good choice.

> You may also want to give libusbK kBench a try to see how fast you can get

Thank you for all the pointers and performance numbers - much appreciated. I'll go through the links you suggested and report back.

There's also an alternate FOSS USB stack for stm32, I've thought about trying that instead and seeing if the problem clears. I'm not sure how easy it would be to bring up, I don't really want to get bogged down with this.

> You can also use libusb based libusbdotnet benchmarkcon

For this and other suggested benchmark tools, it's worth notice that I've already benchmarked with dd and got near 1MB/s. The only interest is if they get significantly above 1MB/s (theoratical MX is 1.2MB/s IIRC), or if the performance varies among them, since then some tracing may offer clues as to the underlying issue.

Re: [libusb] Issues with low CDC_ACM throughput on STM32 USB-FS (sync/async)

[Xiaofan C. <xia...@gm...>]

I mean to say get rid of the Interrupt IN endpoint. You also need to change
the USB descriptors and a bit of the firmware source codes to make it a
generic USB device.

On Sat, Apr 27, 2024, 14:19 Xiaofan Chen <xia...@gm...> wrote:

> On Sat, Apr 27, 2024 at 1:54 PM Jerri Lipp via libusb-devel
> <lib...@li...> wrote:
> >
> >
> > ST's USB middleware supports double-buffering and enabled by default. I
> verified
> >  that the proper IFDEF branch is taken during compilation.
> >
> > Also, the issue is not that I'm not getting good throughput, but that in
> order to
> > approach that 1MB/s mark I have to add phantom IN transfers on one
> computer,
> > and (now that I've checked) that performance is actually worse on a much
> newer
> > and more powerful laptop.
>
> Get rid of the IN endpoint and make the device a generic USB device
> (with Bulk IN
> and Bulk OUT endpoint only), then use libusb again to see if that helps.
>
> You may also want to give libusbK kBench a try to see how fast you can get
> by testing the Bulk OUT endpoint only. Unfortunately there is no similar
> example for libusb yet.
>
> Reference:
> https://github.com/libusb/libusb/issues/962
> https://github.com/libusb/libusb/issues/951
>
> I have no issues to get >1000KB/sec for a full speed USB device
> (Microchip USB PIC) and >3Gbps with CyUSB FX3 SuperSpeed
> device
>
> I remember that Travis has done some benchmarks for STM32
> device as well and the result is also >1000KB/sec.
>
> FW source codes:
> https://github.com/mcuee/libusbk/tree/master/BmFW
>
> kBench source code
> https://github.com/mcuee/libusbk/tree/master/libusbK/src/kBench
>
> Reference discussion:
>
> https://community.osr.com/t/benchmarking-winusb-libusbk-and-cypress-cyusb-driver/57390/3
>
> 437,800 KB/sec for cyusb3.sys using Cypress Cystream application
> 437,700 KB/sec for libusb0.sys using libusbk kBench application
> 386,600 KB/sec for libusbk.sys using libusbk kBench application
> 385,300 KB/sec for WinUSB using libusbk kBench application
>
> You can also use libusb based libusbdotnet benchmarkcon example (v2
> branch only).
> https://github.com/LibUsbDotNet/LibUsbDotNet/issues/137
>
> I tested with Cypress USB FX2LP and CyUSB FX3 there. It works well for
> Bulk IN/OUT transfer, but not ISOC transfer.
>
>
> --
> Xiaofan
>

Re: [libusb] Issues with low CDC_ACM throughput on STM32 USB-FS (sync/async)

[Xiaofan C. <xia...@gm...>]

On Sat, Apr 27, 2024 at 1:54 PM Jerri Lipp via libusb-devel
<lib...@li...> wrote:
>
>
> ST's USB middleware supports double-buffering and enabled by default. I verified
>  that the proper IFDEF branch is taken during compilation.
>
> Also, the issue is not that I'm not getting good throughput, but that in order to
> approach that 1MB/s mark I have to add phantom IN transfers on one computer,
> and (now that I've checked) that performance is actually worse on a much newer
> and more powerful laptop.

Get rid of the IN endpoint and make the device a generic USB device
(with Bulk IN
and Bulk OUT endpoint only), then use libusb again to see if that helps.

You may also want to give libusbK kBench a try to see how fast you can get
by testing the Bulk OUT endpoint only. Unfortunately there is no similar
example for libusb yet.

Reference:
https://github.com/libusb/libusb/issues/962
https://github.com/libusb/libusb/issues/951

I have no issues to get >1000KB/sec for a full speed USB device
(Microchip USB PIC) and >3Gbps with CyUSB FX3 SuperSpeed
device

I remember that Travis has done some benchmarks for STM32
device as well and the result is also >1000KB/sec.

FW source codes:
https://github.com/mcuee/libusbk/tree/master/BmFW

kBench source code
https://github.com/mcuee/libusbk/tree/master/libusbK/src/kBench

Reference discussion:
https://community.osr.com/t/benchmarking-winusb-libusbk-and-cypress-cyusb-driver/57390/3

437,800 KB/sec for cyusb3.sys using Cypress Cystream application
437,700 KB/sec for libusb0.sys using libusbk kBench application
386,600 KB/sec for libusbk.sys using libusbk kBench application
385,300 KB/sec for WinUSB using libusbk kBench application

You can also use libusb based libusbdotnet benchmarkcon example (v2
branch only).
https://github.com/LibUsbDotNet/LibUsbDotNet/issues/137

I tested with Cypress USB FX2LP and CyUSB FX3 there. It works well for
Bulk IN/OUT transfer, but not ISOC transfer.



--
Xiaofan

Re: [libusb] Issues with low CDC_ACM throughput on STM32 USB-FS (sync/async)

[Jerri L. <Jer...@pr...>]

On 2024-04-23 Tim R. wrote:

Jerri Lipp via libusb-devel wrote:
>
> Undoubetdly true, though as it happens, I'm running this on an old
> junk box that is USB2/EHCI only, so that's not it at least in this case.
>
How old?  Many of the early non-Intel EHCI controllers were crap, and
had problems sustaining high bandwidths.

The motherboard uses an ICH9 chipset. at least 15 years old. I wrote about a laptop which is maybe 5 years old in my other reply. On ICH9, dd gets 960KB/s. on the newer laptop, only about 400KB/s.

On Friday, April 26th, 2024 at 6:45 AM, David Grayson <dav...@gm...> wrote:

> Yeah, it's probably going to turn out to be an issue on the STM32 side. If you want to make more progress, I'd recommend looking at the traffic with a hardware USB protocol analyzer like the Beagle USB 12 from Total Phase to see what's really going on.

I appreciate all the suggestions.

and I agree, since performance varies wildly between platforms, when using dd/linux driver, it's hardly likely that libusb is at fault. The common factor certainly looks to be the device.

I'm not ready to purchase new (even cheap) hardware to debug this. It's more of a mystery than a showstopper for me. I should note that a post on the ST community a week ago yielded no responses from anyone, ST or otherwise. Maybe I'm the only one experiencing this (Maybe I did something stupid with the code generator, I don't know).

On 2024-04-26 RisingEdgeIndustries <su...@ri...> wrote:

Also, check if you are double buffering your EPs

ST's USB middleware supports double-buffering and enabled by default. I verified that the proper IFDEF branch is taken during compilation.

Also, the issue is not that I'm not getting good throughput, but that in order to approach that 1MB/s mark I have to add phantom IN transfers on one computer, and (now that I've checked) that performance is actually worse on a much newer and more powerful laptop.

On 2024-04-26 michel <dia...@ya...> wrote:

You should get more than 500KB/Sec (up to some 800K) on pretty much any system  even using just synchronous request on PC side (use largest possible one).

That's good to know. However, "more than 500KB/s" is actually not that informative. I did get about 500KB/s with the sync API. however, the hardware is running at 150Mhz and is perfectly capable of achieving much higher throughout. The problem I described was that I wasn't getting better throughput even with (only) multiple large OUT transfers in fligh using the Async API. Throughput shot up to 960KB/s if I added a "useless" single one-time IN transfer at the start of the program on a very old computer. But on a much newer laptop, nothing helped and performance was even worse (though I should probably update the BIOS on it).

Try to tune the usb  h/w fifo to maximize the bulk in/out cdc data end point

Also if you have choice of using the FS or HS controller Pock the HS one even it operate at FS only (it still has much more fifo space)

umm... well, I tried all the ports, directly, via a USB2 hub, via xHCI on another system, via USB2 hub connected to the xHCI ports, to a USB-A port on the other system, to a USB-c port on the other system, etc' - the details vary, but it just doesn't seem like I'm getting sane behaviour overall. I've proven that the MCU can handle 960KB/s OUT, on a very old PC, so I expect to achieve that on every system if things are working properly.

Try to tune the usb  h/w fifo to maximize the bulk in/out cdc data end point .

The user-facing USB stack buffer size is maxed out at 64 bytes. and I twiddled with increasing transfer size, that makes no difference. The issue is that vague changes to the host side software/system halve/double the throughput.

Is there something specific, at the stm32 register level that you suggest I play with? I'm curious. Though at this point we're probably a bit off-topic for libusb-devel.

Thank you all for the suggestions.

Re: [libusb] Issues with low CDC_ACM throughput on STM32 USB-FS (sync/async)

[Xiaofan C. <xia...@gm...>]

On Sat, Apr 27, 2024 at 1:23 PM Jerri Lipp <Jer...@pr...> wrote:
>
> > On Friday, April 26th, 2024 at 4:59 PM, Xiaofan Chen <xia...@gm...> wrote:

> > You may want to use serial API
> > to try to see what is the throughput achieved first.
>
> What exactly do you mean by "Serial API"? can you be more specific? If you mean
>  talking to the tty from c using whatever posix interface, I find that much less pleasant.

Windows standard Serial API or Posix serial API.

You can even try a cross-platform library like libserialport.
https://sigrok.org/wiki/Libserialport

> As I mentioned in the original post and my previous one, I *did* use
> dd, to measure throughput directly to the tty device. Performance
> was good on one (very old) computer and bad on another (much newer).

Sorry but no idea why dd is relevant here. That is probably only relevant if
you use a USB mass storage device.

For a CDC-ACM device, the OS will assign the USB serial driver to the device.
You can not even use libusb on macOS with your USB CDC-ACM device since
there is no easy way to detach the kernel built-in driver.

If you want to use libusb, then do not use CDC-ACM at all, just program your
device as a generic USB device.

-- 
Xiaofan