libusb-devel Mailing List for libusb

I see

I am not use libusb to operate the file on USB disk device, I am only use
libusb to open the device, claim the interface, pass the USB
transfer packets to the up-level progrems, and the other low-level
communication with USB device.
I can run my program successfully on Windows, but when I move the program
to the macOS, I get this claim_interface error.

I think the major problem is hard to detach the device from kernel USB mass
storage driver, am I correct?

Xiaofan Chen <xia...@gm...> 于2019年12月11日周三 下午10:18写道：

> On Wed, Dec 11, 2019 at 10:54 AM Hongyu Lai <lai...@gm...> wrote:
> >
> > hello,
> > I am trying run libusb on macOS, and I met a problem,
> > I run the fxload example, try to load a USB flash disk device, and I got
> this error:
> >
> > libusb: error [darwin_claim_interface] USBInterfaceOpen: another process
> has
> > device opened for exclusive access
> >
> > the libusb version I used is 1.0.23,
> > the macOS version is 10.14.6 Mojave
> >
> > Is there any other ways to fix this problem?
>
> Please do not use a disk with a flash driver with libusb.
>
> If you want to learn about USB, use a proper USB demo boards from popular
> MCU vendors, for example, Microchip, ST Microelectronics, etc.
>
> https://github.com/libusb/libusb/wiki/FAQ#Can_I_use_libusb_to_open_a_file_on_an_USB_storage_device
>
> Particularly for macOS, there is no practical way for you to detach the
> kernel
> USB mass storage driver.
>
> --
> Xiaofan
>
>
> _______________________________________________
> libusb-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libusb-devel
>

On Wed, Dec 11, 2019 at 10:54 AM Hongyu Lai <lai...@gm...> wrote:
>
> hello,
> I am trying run libusb on macOS, and I met a problem,
> I run the fxload example, try to load a USB flash disk device, and I got this error:
>
> libusb: error [darwin_claim_interface] USBInterfaceOpen: another process has
> device opened for exclusive access
>
> the libusb version I used is 1.0.23,
> the macOS version is 10.14.6 Mojave
>
> Is there any other ways to fix this problem?

Please do not use a disk with a flash driver with libusb.

If you want to learn about USB, use a proper USB demo boards from popular
MCU vendors, for example, Microchip, ST Microelectronics, etc.
https://github.com/libusb/libusb/wiki/FAQ#Can_I_use_libusb_to_open_a_file_on_an_USB_storage_device

Particularly for macOS, there is no practical way for you to detach the kernel
USB mass storage driver.

-- 
Xiaofan

hello,
I am trying run libusb on macOS, and I met a problem,
I run the fxload example, try to load a USB flash disk device, and I got
this error:

libusb: error [darwin_claim_interface] USBInterfaceOpen: another process
has device opened for exclusive access

the libusb version I used is 1.0.23,
the macOS version is 10.14.6 Mojave

Is there any other ways to fix this problem?

On Dec 1, 2019, at 4:36 PM, Michael Deng <Den...@ou...> wrote:
> 
> I have another question building onto 3. Say I want to send a bulk_transfer() of some variable length x, what’s the best way to store a data of that variable length, before casting it into a unsigned char *? An array?

Whatever is most convenient for your program.  It’s exactly like reading and writing data from files.  You need a buffer of some kind.  The smartest way is to use something like std::vector<uint8_t>, and in that case the .data() return is already a pointer to byte; no cast is necessary.
— 
Tim Roberts, ti...@pr...
Providenza & Boekelheide, Inc.

Thanks Roberts, your answers were really helpful.

I have another question building onto 3. Say I want to send a bulk_transfer() of some variable length x, what’s the best way to store a data of that variable length, before casting it into a unsigned char *? An array?

From: Tim Roberts<mailto:ti...@pr...>
Sent: 30 November 2019 00:45
To: lib...@li...<mailto:lib...@li...>
Subject: Re: [libusb] bulk_transfer always timeouts and other questions

On Nov 29, 2019, at 3:34 PM, Michael Deng <Den...@ou...<mailto:Den...@ou...>> wrote:

I’m using libusb in some code on a Ubuntu guest and I have some questions (code is at the very bottom):


  1.  When I run my code without sudo my program libusb_open() returns -3 so I have no permission. Is this fine?

By default, yes.  You can use udev rules to change the permissions to allow non-root access to your device.



  1.  I’m using Wireshark to look over my packets whilst running my code – I thought libusb_claim_interface() would send a SET_INTERFACE packet to my device but it doesn’t. Is my understanding of the function wrong or am I using it wrong?

No.  libusb_claim_interface is basically a lock; it gives you ownership of the interface.  If you need a set interface request, use libusb_set_interface.



  1.  What’s the proper way to send a hexadecimal code like the one I send below through the bulk_transfer()? Currently I’m using an unsigned short then casting it into a unsigned char * in the actual bulk_transfer(), is this fine? Are there any better ways?

This is generally fine, as long as the device expects the bytes in the same order that your processor stores them.  If you’re using an Intel-architecture processor, as almost all of us are these days, then your processor is little-endian, which means your 0x4001 constant is stored in memory as  0x01 0x40.  If that’s the order that your hardware wants, then you’re golden.  If the hardware wants them in the other order, then you’re going to need to swap them.



  1.  When I reach the bulk_transfer() my code timeouts (or hangs when it’s 0), when would it not timeout and why does it timeout in my code?

That’s a device issue; your device did not accept the command.  None of us know your device.  I see it’s from Netchip, but we don’t know the details.  Are you sure it wants commands on the bulk output pipe?  Commands like that are often sent over the control endpoint.  Can it handle a short packet, or do you need to pad it out?
—
Tim Roberts, ti...@pr...<mailto:ti...@pr...>
Providenza & Boekelheide, Inc.