Usb libraries always support setting timeouts on operation with device. And this is important feature for soft which works with usb devices, because that's how you can understand that device don't answer to your command. I look through WebUSB Api and look's like it's not support timeouts at the moment.
Is it true? Is the only way is to manually start timeouts before every usb operation, and stop timeout after operation success?
WebUSB does not currently support transfer timeouts or aborting transfers because after surveying the various platform APIs for USB it did not seem possible to implement them in a consistent way. Ideally it would be possible to cancel a transfer by removing it from the USB controller's transfer schedule. This is possible on Linux with the USBDEVFS_DISCARDURB ioctl and timeouts are supported on macOS using ReadPipeAsyncTO() and similar functions. On Windows however the only way to cancel a transfers is to call WinUsb_AbortPipe() which affects all pending transfers on the pipe, not just the one that timed out.
If you need to react to a device not replying to a USB request in a timely fashion then doing so manually with setTimeout() and clearTimeout() is the best option. Keep in mind that USB transfer itself will remain active and could complete at a later time.
Related
I am doing some research on the WebUSB API for our company because we are going to start to manufacture devices in house.
Our current device manufacture comes with an application so the team can plug the device into a computer and diagnose it. Their application allows us to read outputs from the device, as well as pushing commands/configuration to the device over a wired connection.
Since this device is 100% ours, we are also responsible for building out the diagnostic tooling. We need some sort of interface that allows a user to read outputs and send commands/configuration to the device over a wired USB connection.
Is the webUSB the correct API? If not, what are some suggestions for accomplishing the requirement? Are we limited to building some sort of desktop or mobile application?
I would recommend resources below to read to help you understand if the WebUSB API fits your needs or not:
https://web.dev/devices-introduction/ helps you pick the appropriate API to communicate with a hardware device of your choice.
https://web.dev/build-for-webusb/ explains how to build a device to take full advantage of the WebUSB API.
From what you describe, WebUSB isn't strictly required but won't hurt either.
First and foremost, you will need to implement the USB interfaces reading data and sending configurations. It will be a custom protocol, and not one of the standard USB device classes such as HID, video or mass storage. The details of the protocol and if you use control, interrupt or bulk transfers is your choice.
I'm assuming you will connect the devices to Windows PCs, and you likely don't want to put money into writing device drivers. If so, the easiest approach is to add the required descriptors and control requests required for Microsoft OS 2.0 Descriptors. That way, the WinUSB driver will be installed automatically when the device is plugged in.
Using the WinUSB API, a Windows application will then be able to communicate with the USB device. No additional drivers are needed. (On macOS and Linux it's even easier as you don't need the Microsoft OS 2.0 Descriptors in the first place.)
On top of that you can implement the additional descriptors and control requests for WebUSB. It will provide the additional benefit that you can write a web application (instead of a native application) for communicating with the USB device. (Currently, you are restricted to the Chrome browser.) WebUSB devices should implement the WinUSB descriptors as the alternative (.INF files, manual installation process) is a pain.
The already mentioned web page https://web.dev/build-for-webusb/ is a complete example of how to implement it.
I would like to support multiple (at least 2) simultaneous BLE connections to Bluez as peripheral with one adapter. I believe it is technically possible since many embedded platforms support this (Silabs, Nordic).
Currently, with the first connection GATT advertisement stops altogether until the connection is dropped again. Is there some way to keep advertising?
Furthermore, if this is even possible, I currently don't see a way to use attribute notifications to a specific connection. One uses the dbus PropertyChanged method for emitting characteristic value notifications, though it seems as if there is no way to specify to which remote devices to send it to. Is there a way to notify only a specific connection of Value changes?
I can do the above on a Silabs EFR32 without issue but would like to get the same on embedded Linux.
Thank you kindly
I am writing a library in C/C++ for a Bluetooth low energy device. So far I have been using the D-Bus interface exposed by Bluez and been able to discover, connect and communicate with the device.
However, when the device disconnects either due to a link failure or it being out of range, reconnecting to it is not trivial. Ideally I would like to be able to create pending connections to all disconnected devices, but Bluez doesn't seem to support that. It seems that Bluez only supports one simultaneous connect call, which timeouts after 15-20 seconds.
A solution would thus be to listen for advertisement packages, and connect when a known device is detected. The good people on #bluez told me that this was already implemented, and the way to do it is to register an object that implements GattProfile1 with the GattManager1 RegisterProfile method. Trying this gave no result, the device stays disconnected after a link failure. It is also very poorly documented, so there is a good chance I have missed something.
My questions are: Is this the right solution? Will it provide a seamless and fast reconnections? If it is, what can be wrong?
If you wish to reconnect to a single bluetooth device, you can monitor the connection state by receiving org.freedesktop.DBus.Properties.PropertiesChanged, and calling org.bluez.Device1.Connect to reconnect when necessary. Since this will timeout, you can put Connect() inside a loop which you will exit only when the org.bluez.Device1.Connected property is true.
Has the original author managed to do this yet for multiple devices by implementing GattProfile1?
I'm working on various USB hardware devices, each of which implementing a serial port. I'd like to access such serial ports by multiple (Chrome and non-Chrome) applications running on the system in a pseudo-parallel fashion.
Basically I'd like to use some mutex-like atomic primitive so that I could make sure that one application has access to the serial port at the same time and the others are temporarily blocked, waiting for the mutex to be released.
I'm afraid that the Chrome API doesn't offer any such low-level primitives but please disprove me. Also, I'm open to any suggestions.
I've just finished reading the full Chrome packaged apps API and mutexes are definitely not supported but mutexes only work inside a process anyways so it's not what I'm looking for to begin with.
I could create a native app that could bind to multiple ports on the local loopback interface and proxy those connections towards the /dev/ttyACM* serial interface.
The other solution is implementing multiple serial ports for my USB device in the firmware so that multiple clients could connect to my device without interference.
I think I'll go with the latter solution because I don't want to have a daemon proxy running in the background all the time.
I started lately reading some articles about the kernel space and especially about device drivers. So I was wondering are there some minimal requirements for a device in order to make it easy to write a device driver for it?
A possibility to communicate with it from the kernel (PCI, USB, etc...) and documentation. Obviously a kind of hardware debugging process can improve things.
(This doesn't count as "minimal", but it does meet your desire to "make it easy".)
Some sort of testing mode, or device simulator, which allows you to
(a) see the messages that are being sent to it, so you can see when there is a bug in your code.
(b) stimulate events that cause communications to occur.
For example, if you are writing a driver for a burglar alarm, a way of triggering the device to send an alert from a window sensor, without having to actually throw a brick through a window.