I'm trying to connect a serial device with Webusb, under linux.
I have been able to list the device and open it, but I can't claim the interface. Chrome complains that the device is busy, and to fix that I need to unregister the CDC-ACM driver.
Is there a way to prevent the CDC-ACM driver from loading the device, without changes on the destkop? maybe I can change the USB descriptors?
If you can change the device descriptors then modify the protocol, class and sub-class reported by the CDC-ACM interface so that it is marked as vendor-specific (0xff). The CDC-ACM driver will no longer recognize the interface and bind to it.
Just for completeness, if you could make changes to the desktop then you can either blacklist the usb-serial driver entirely in /etc/modprobe.d/blacklist or you could write a udev rule which runs for that device in particular (recognized be either bus path or vendor and product ID) and executes a script to unbind the driver.
Related
I seem to only be able to access physical ports. I do want to access virtual ones like ones created with virtual null modem or virtual serial port driver.
Does anyone know if this is possible.
Chrome enumerates serial ports by calling SetupDiGetClassDevs with GUID_DEVINTERFACE_SERENUM_BUS_ENUMERATOR. As I discovered when implementing this enumeration logic there are a surprisingly large number of ways to ask Windows for a list of all available COM ports. The advantage of this approach being that it provides device information which can be used to get the human-readable name of the device and USB product identifiers if it is a USB device. It is likely that a virtual COM port driver may be creating the device in a way which prevents it from being discovered this way.
I've created https://bugs.chromium.org/p/chromium/issues/detail?id=1238369 to track this as a Chrome bug. Please comment on whether you are using a different virtual serial port driver than the one mentioned there.
I managed to get Chrome to see the virtual serial ports using com0com on Windows 10 21H1 (OS Build 19043.1110). Chrome connects to the port successfully and it works as expected:
I cannot get OTA updates to work on my ESP32 using the Arduino IDE (and I've also tried PlatformIO in VS code).
I'm using the standard sketch from this site (and many identical others).
When I try to update using OTA, here's what I get:
Sending invitation to 10.0.0.245
Authenticating...OK
12:12:49 [ERROR]: No response from device [after a short while]
If I connect the device to a USB/serial terminal, here's what I get:
Start updating sketch
Progress: 0% [never proceeds beyond 0%]
Error[2]: Connect Failed [after a short while]
Error[4]: End Failed
My partition table has two OTA partitions, so this is not the problem.
I've tried with and without my firewall, with and without my anti-virus, with and without the USB connected, with and without a password, with and without setting the port, with and without a manual reset after loading the sketch - always the same.
It's not an initial WiFi connection problem - the device IP is recognized as a port, the password is verified if I use one and the initial connection is made.
Any ideas?
Thanks
I had exact same problem although with ESP8266, it didn't work when I disabled firewall either. But, after I created a New Rule in "Windows Defender Firewall with Advanced Security" for the python located in: C:\Users\Erfan\AppData\Local\Arduino15\packages\esp8266\tools\python3\3.7.2-post1\python3.exe
and Allowed its connection, my problem was solved.
Note1: Try creating New Rule in your antivirus firewall if you have one.
Note2: I found the location of the ...\3.7.2-post1\python3.exe in Arduino IDE. If you try to upload Over The Air, the path to python.exe will appear in the outputs.
I'm working on a project that involves connecting a single-board computer (either a BeagleBone Black, or a BeagleBoard X15) to a Mac via USB OTG, and then delivering basic mouse/touch input (pointer coordinates and left/right-click events).
This process should be technically very similar to connecting a mouse (or, more accurately, a touchscreen-style device that receives precise mouse coordinates) and passing some ordinary HID input to MacOS. So I don't need most of the complexity of IOKit - I don't think I need to create a kernel extension; I should just be able to create an instance of a HID for which MacOS already has generic kernel extensions.
So I'm delving into IOKit to figure out how to create the device instance and provide input. However, nearly everything I'm reading about IOKit involves creating and registering new kernel extensions, services, etc. - none of which is germane to my project.
So far, the only relevant leads I've got are the I/O Registry Explorer and the contents of /System/Library/Extensions. Several items in there look promising, such as AppleDHIDMouse.kext. However, I cannot find any examples of code to bridge the gap: how my USB-connected device can connect with the kernel extension, create an instance for itself, and send commands.
Any help? Thanks in advance.
Either your device is fully USB HID compliant, in which case you shouldn't need any code at all on the Mac side, or you'll need to create a kernel extension.
How far have you got? What does your device look like in ioreg/IORegistryExplorer? (The latter is from the "Additional Tools for Xcode", downloadable from https://developer.apple.com/download/more/ )
Does your USB device's interface report as HID? (bInterfaceClass 3) The device itself normally reports as a composite device (bDeviceType 0). bInterfaceProtocol and bInterfacSubClass also have defined meanings in the context of HID, and should probably both be 0 for a "tablet" style device. With that in place, macOS should pick up your device as a HID device and try to drive it with one of its built in HID device drivers.
The way HID devices work is through "reports" - event data structures with a flexible format/layout, which is defined via the device's "report descriptor". What buttons, input axes, etc. your device has is defined there.
For an example of a USB "tablet" device (absolute coordinate pointing device) that works with macOS, check out the code for the USB Tablet device that Qemu emulates. That might be a good starting point for the report descriptor of your own device.
If your device doesn't conform to general USB HID conventions and uses some custom protocol, you'll need a custom kext (up to macOS 10.14) or dext (from macOS 10.15 onwards) which will most likely implement a IOHIDDevice subclass. An example of such a driver is the open source Mac driver for the Xbox 360's game controller, which doesn't behave like a standard USB HID device.
Target: In our embedded Linux system, we want to use Qt to detect the insertion of a USB storage device, to inform the system when the USB storage device is plugged in or out, then we can mount its file system. Later we can access the files on the USB storage device.
I searched a little, it seems there are two solutions: libusb and dbus. But I still don't know how to use it. Does anyone have some examples?
The typical way to auto-mount USB storage is via udev. Udev can notify you when a device is added/mounted. You could talk to udisks via dbus to be notified of storage addition/removal as well.
libusb is only tangentially related, you shouldn't be using it unless you wish to reimplement a lot of already existing code.
I have an Arduino-based device which connects through USB.
I'd like to detect it from my Qt 4 application, using QExtSerialPort (or whatever necessary), when it's plugged in.
If this weren't possible, I thought I could somehow get a list of the system's port names and just try all of them in search for my Arduino (where I'd implement some kind of handshaking procedure for it to detect it correctly). My concern in this approach is that I'm not sure if a device (for example, printer) would get damaged if I send some kind of handshaking ack at a different baud rate.
So, I don't really know where to start for any of them. Which would be the best approach? How would I implement it?
I believe you can find list of serial ports on Windows by looking into
HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\SERIALCOMM
registry key
Each serial port on a UNIX system has one or more device files (files in the /dev directory) associated with it:
System Port 1 Port 2
IRIX® /dev/ttyf1 /dev/ttyf2
HP-UX /dev/tty1p0 /dev/tty2p0
Solaris®/SunOS® /dev/ttya /dev/ttyb
Linux® /dev/ttyS0 /dev/ttyS1
Digital UNIX® /dev/tty01 /dev/tty02
more details on serial programing on POSIX systems here
Since your device is USB, your UART port will be emulated by some kind of conversor in his hardware. So first you must understand what driver is being used on your system.
The most common SERIAL->USB conversor uses PL2303/PL2301 chip, so it would create a path on /dev, if its the first device, it will appear as "/dev/ttyUSB0", but you may also see the list reading the proc path (like "cat /proc/bus/usb/devices").
Under Windows it usually creates a virtual "COM", just go to device manager and check the port.
When you are sure about how the HW talks to your system, you may use QExtSerialPort for wrapping the system API and talk to the device.
Way too hard and too platform specific, using weird Windows Registry keys or rely on hard wired device nodes on Linux.
You are on the right way. Get QextSerialPort or QSerialDevice (which I preffer in my projects, because it got integrated in Qt5), have a look at the examples and simply use it. In both libraries you get some kind of port enumerator class which returns you a list of all configures serial ports. Only platform/device specific settings you will have to do manually (like getting RS485 in half-duplex mode on my current embedded project), but "standard" problems are perfectly encapsulated in a QIODevice implementation.
You can use both QextSerialPort and QSerialDevice like a file. Open it (instead of a filename you specify the device name ie. "COM1" on Windows or "/dev/tty0" on Linux, depending on your configuration) and then read or write like you are doing it with an ordinary QFile, QBuffer, Qwhatever-inherits-from-QIODevice.
If you have any problems opening the port and communicating, don't hesitate to ask! :)