Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide or document how to create an asynchronous interface #4

Open
Sitin opened this issue Dec 25, 2024 · 4 comments
Open

Provide or document how to create an asynchronous interface #4

Sitin opened this issue Dec 25, 2024 · 4 comments

Comments

@Sitin
Copy link

Sitin commented Dec 25, 2024

This is a suggested improvement.

Right now the library has only synchronous interface but the nusb used under the hood is async-first. It would be nice to have an option to use this library in asynchronous environments with minimal (or no) overhead from extra threads.

It seeams that in order to provide such functionality we need to add AsyncReader / AsyncWriter and probably an asynchronous version of CdcSerial. The USB manager and intent checking part may also require some changes.

@wuwbobo2021
Copy link
Owner

"It seeams that in order to provide such functionality we need to add AsyncReader / AsyncWriter and probably an asynchronous version of CdcSerial."

I hadn't considered adding such feature because serialport and a few other crates don't provide it (except serial2-tokio). Do you have a realistic use case?

"The USB manager and intent checking part may also require some changes." I don't think so.

PS: busy fixing a bug in Slint UI (issue 7203), I will not implement the asynchronous interface for this crate soon.

@Sitin
Copy link
Author

Sitin commented Dec 30, 2024

There are several use cases that comes into my mind. The Rinf for Flutter is asynchronous by default and Tauri has async option. Both of them can use asynchronous API for Android serial connection.

As far as I am concerned, my own library for MavLink provides both sync and async interfaces and I want to support Android out of the box for both API flavours.

Still, I do understand why you may not want to go into this direction. Supporting two types of API is extremely labourious.

@wuwbobo2021
Copy link
Owner

I've released a new version of my crate which allows taking nusb transfer queues from the serial handler. AsyncReader / AsyncWriter will probably be added after the release of nusb 0.2.0.

@wuwbobo2021
Copy link
Owner

A reminder of existing problems in the released version 0.2.2:

The possible crate-level open function can return a result of Vec<Box<dyn UsbSerial>> instead of Box<dyn UsbSerial> to support multiple serial interfaces of the USB device.

The UsbSerial trait sealer should be changed to make it dyn compatible after supporting other serial adapters. Also note that CdcSerial::set_config can be marked as deprecated.

Trait UsbSerial should have a required function take_queues(&mut self) aside from into_queues(self), to reserve the possiblility of hardware flow control after turning it into a possible Box<dyn AsyncUsbSerial>. SyncReader and SyncWriter should be wrapped by Option in serial driver implementations.

I can't find any implementation in the original usb-serial-for-android that uses hardware flow control within synchronous read and write, though.

Struct AsyncUsbSerialImpl<T: UsbSerial> (should it be private?) which implements trait AsyncUsbSerial can be added to be used by the possible crate-level open_async(dev_info: &DeviceInfo) -> Result<Box<dyn AsyncUsbSerial>, Error>. Convertion from T: UsbSerial to AsyncUsbSerialImpl will be possible.

@wuwbobo2021 wuwbobo2021 reopened this Jan 10, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants