I am writing a C++ Linux userspace driver for a USB device using the C library libusb. I have two copies of the same device (same vendor ID and product ID) and would like to know how to handle this case.
Here are the possibilities I can think of:
libusb_get_device_list() returns only devices that are not currently in use
I can differentiate the used vs. unused devices using information of the device descriptor, using libusb_get_device_descriptor()
libusb_open() on the currently in-use device will fail, by returning either LIBUSB_ERROR_ACCESS or LIBUSB_ERROR
How should I deal with this? Which of the preceding options, if any, is the behaviour of libusb when dealing with many of the same devices? How can I differentiate between the in-use device and the idle one?
As #fiscblog said in his answer, "Identification is done via the device descriptor (use the serialnumber which should always be unique)". My problem here is that, in order to do so, the two drivers should communicate to know which instance is handling which device (using, for instance, a file), and I would like to avoid this. I also would like to avoid having to introduce multithreading and manage two devices with one driver, as I don't have the skills to do so in an efficient and well-controlled way (nasty race conditions ... !)
The correct handling is:
enumerate all devices (get device list)
identify the requested device and open it
Identification is done via the device descriptor (use the serialnumber which should always be unique), as you discovered yourself.
How to know if a device is in use?
If a device is open, the endpoints will be bound and configured for I/O. Therefore you cannot open it again but will get the error codes you mentioned.
According to the documentation on libusb_claim_interface():
Interface claiming is used to instruct the underlying operating system that your application wishes to take ownership of the interface.
so you should be able to call libusb_claim_interface() on each device and it should only succeed on the unclaimed one:
It is legal to attempt to claim an already-claimed interface, in which case libusb just returns 0 without doing anything.
libusb is written in C and follows the same basic general guidelines for accessing devices, file descriptors, streams, etc.
1 - Connect to de device
2 - Check the connection, if there's an error, inform and return
3 - There's no error!! Interact
Following this basic flow, the solution in your case IMHO is as simple as:
Identify the devices
Iterate througth them trying to connect until one throws no failure
do something
close
Related
On my STM32F7 I have to connect a 3G modem using serial port.
I can communicate with the modem using AT commands.
I would like to use PPPos (PPP over serial) library from LWIP to enter in PPP mode. So I take a long look at the official documentation
http://lwip.wikia.com/wiki/PPP
and
https://github.com/tabascoeye/lwip/blob/master/doc/ppp.txt
I understand the guideline but I'm really surprise there is no implementation example with serial port. Indeed, I think there is a lot of modems that have a serial interface, so I thought i can easily find an example of use.
Anyone have already done that or has an example ?
While I cannot publish my example, the general idea when it comes to integrating TCP/IP stack of your choice with its PPP driver is the same among all serial modems and all TCP/IP stacks that I've worked with.
Generally as you've mentioned, you start with configuring the modem using AT commands - things like checking whether SIM card is present, whether it requires PIN, specifying PIN if needed, checking if it has successfully registered in the network. Possibly reading additional information data such as IMEI, IMSI as well as diagnostic data: signal quality, BER etc. Once you're done, you switch the modem to "data" mode (see ATD*99), wait for the modem to respond to that command and pass the responsibility to the TCP/IP stack, as at this point the modem starts talking PPP.
When it comes to integrating your modem with the stack so it can communicate with it, the implementations I've encountered all require implementing some form of low-level API functions for the stack. For LwIP, the wiki page you've linked in the "PPP over serial" section, it is described quite well how those functions should behave. Because TCP/IP stacks are just a software library not tied to specific hardware and they can be run on almost anything (assuming sufficient resources), specific API implementations such as the one discussed are not always provided - there would have to be a ton of examples for it to provide any value. Although if you google around for it, you might find someone having done it for the MCU that you use personally. Assuming you've already done the part where you successfully comminicate with your modem using AT commands, it shouldn't be much more other than using the send/receive functions you already have. Some slight changes may be required, such as adjusting their behavior (synchronous->asynchronous or vice versa) or redirecting received data to the TCP/IP API receive function instead of your AT command parser. Nonetheless, most of the necessary hard work should be done already.
Once the TCP/IP stack takes over, you continue with the modem using provided stack PPP API. For LwIP see functions such as: pppSetAuth, pppOverSerialOpen. Those will cause the stack to internally handle the necessary communication with the modem over PPP: LCP, PAP/CHAP, IPCP. Once that part is done (you retrieve IP configuration data from the network) it becomes transparent how this operates - it becomes one (of possibly multiple) network interfaces and you use it just as any other one, for example using socket API.
I have a device without knowing the used gatt profile, I only know that is something "homemade" and not anything known on the bluetooth-database.
In Linux the command
gatttool -i hci0 -b xx:xx:xx:xx:xx:xx --char-read --handle=42
returns the value as expected (with the target device mac at xx:xx:xx:xx:xx:xx).
In Qt I am using the Heartbeat-Example from http://doc-snapshot.qt-project.org/qt5-5.4/qtbluetooth-heartlistener-example.html
there they connect using a gattprofile, QBluetoothUuid::HeartRate and QBluetoothUuid::HeartRateMeasurement
I wasn't able to modify the example code in a way to read handle 42.
Can you explain where I have to put which values, that it connects to the "standard profile" as the gattool command does? If I use gatttool in interactive mode and ask primary it returns two uuids, but using them instead of the QBluetoothUuid::HeartRate did not work.
It doesn't appear that the Qt Bluetooth Low Energy API provides means for obtaining access to characteristics based on their handle value. (Neither does the Windows 8 BLE API.) You should use the UUID. Even if it's a homemade device, all services and characteristics are required by the GATT protocol to have UUIDs. The lowenergyscanner demo app can discover and display both the UUIDs and handles of all of the device's services and characteristics. I've used lowenergyscanner to deal with BLE devices I'm developing.
device discovering is by uuid, even if you create a new profile with a new service and a new characteristic, you have to give the new characteristic uuid in setup.
But i dont know, how to add multiple characteristics to one service, it does not work with me.
have fun
How do I most properly use libusb to talk to connected USB devices?
Specifically, how do I transfer data to the USB devices, receive information from the devices, find out the name of the connected device, if they have storage, etc.
More specifically, I will be running this on a Mac OS X machine, so I know I can't just use Windows header files.
If there is a good explanation on libusb and USB devices, that would be helpful too.
Here is a post on a similar question that might be useful to you. I include plenty of links.
But maybe you'd rather see it here. So in that case, here it goes!
Libusb allows you to enumerate devices and select the one you want based on a specific Vendor/Product id (V/P Id). If you don't know this and can't find it online with the product's description then you can easily find it.
If it is not online you will need to use an app similar to lsusb on Linux. (I don't believe it is on Mac.) When you run lsusb it lists connected devices and their V/P Ids. You can easily find your device by unplugging, running lsusb, and plugging the device back in and comparing. It's a piece of cake. Any usb list app on Mac will hopefully display the V/P ID like lsusb does.
Then once you have this V/P ID you will use libusb (if using 0.1) to enumerate all devices and find the device that matches that id. (I support using libusbx which happens to have a single find device function based on V/P id - in fact, libusbx is a whole lot more concise all around.)
After selecting your device you will send a packet using either Feature or Output Reports. This is the most complicated part because the packet you send is dependent on the individual device I believe. It is 8 bytes of data and only one of which is a single character you wish to send to the usb device. (If you wanted to send 8 characters, you would have to loop through an array of chars and send a feature or output report for each character.)
As an example feel free to reference a rather specific terminal example I wrote for controlling two LEDS. If it's helpful, great! It contains a libusbx and libusb-0.1 example.
I hope this helps!
The official site for libusb 1.0 (the newer and recommended version) is https://libusb.info/. The API documentation is at http://api.libusb.info. Click on the Modules section to walk through the different function areas. The source is at https://github.com/libusb/libusb and you can see some working examples at https://github.com/libusb/libusb/tree/master/examples. Hope that helps!
The article from #user2469202 is a good basic intro also.
The process that you can follow is:
Get the VID, PID for the device that you want to communicate using lsusb
Try to open the device and read the device descriptor
If you want name of the device use string descriptor to get that
Check if any kernel driver is attached. If it is, then detach it and do some raw data transfer
After getting the response again re-attach the driver.
I have a feature request on a project I work on, it is to integrate with a Paylife CC handheld, which has a USB connector to connect with the computer. I have the docs, and am reading up on it.
When I searched on google how to read/write to a usb device on linux, it said, use libusb.
I was wondering, is there another possibility? Can't I just open it like a file and write a stream to it, and read a stream from it?
I don't actually need to do anything fancy. I just need to write a string of control codes to the device, and it would be mildly nice to read back the ACK and Error codes. But since those are already displayed on the device screen, I don't have to do much with it, just deliver the total required for payment.
So my question is, what are my options?
The connected computer is a regular ol ubuntu linux box.
It is definitely possible when the device complies with one of the USB device classes -- drivers for them are universal.
If that's not the case, then you may stick with a manufacturer-provided or a third-party driver, given there is one and you possess enough of it's documentation.
If that's also not the case, libusb-1.0 is your resort, unless you want to write a kernel driver youself :)
I read some questions here but couldn't really find the specific problem I'am faced with here...
I need to implement a "DeviceCache" in a particular project which caches all device-names found in /proc/net/dev .
The Language is C/++
So I thought about a seperate thread looking every X seconds in the directory mentioned above but was encouraged to find a more direct way.
How can I register a method of my process to the device manager of linux?
Is there a similar way like events/signals?
I looked in other sites but couldn't find any helpful code... Im relatively new to Linux-programming but willing to learn new things :)
Based on your comments, what you really want is to track which network interfaces are operational at any given time.
The only true way to determine if a network interface is up is to test it - after all, the router on the other end may be down. You could send pings out periodically, for example.
However, if you just want to know if the media goes down (ie, the network cable is unplugged), take a look at these SO questions:
Linux carrier detection notification
Get notified about network interface change on Linux
If you just want to be notified of the actual hardware-level registration of interfaces (eg, when a USB NIC is plugged in), you can use udev events if your platform has udev; otherwise, I believe there's another netlink category for hardware addition/removal events.