-
-
Notifications
You must be signed in to change notification settings - Fork 345
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
Serial support #549
Comments
Supporting serial in one way or another would be great, though unfortunately it's not something I'm super familiar with myself. My impression from PySerial is that the code to support this would be somewhat complicated and specialized, so it might be something that makes more sense to keep in a specialized library on top of trio, rather than adding an API directly to trio itself? Certainly it makes sense to make it as similar as possible to a using a socket, for users, and we should reuse the Looking at the code for Serial support isn't something that I anticipate having the time to work on soon myself, but if others want to then hopefully that gives some idea where to start, and of course please ask here or in chat if you need more information or get stuck anywhere. |
I got this link, this code use asyncio.get_event_loop() how can this run at the same with trio.open_nursery() ? |
What is different from socket other than setup?
|
@yanzixiang that code is very entangled with asyncio's way of doing things. I suppose you could probably use it with @imrn after setup, on Unix serial ports use |
@yanzixiang by the way, thanks for the link to pyserial-asyncio, I hadn't seen that one before. I just looked at its source code, and I think asyncserial is probably a better library to look at for inspiration. Pyserial-asyncio uses asyncio's complicated and low-level transport/protocol system, while asyncserial uses a much simpler stream API that's similar to trio's. |
@njsmith there is not DOC or DEMOCODE on asyncserial's site, |
@njsmith IIRC on Windows serial ports use |
@Joker-vD That's for synchronous read/write :-). In an async library, you have to use IOCP. |
@njsmith Well, you use them for starting asynchronous reads/writes too :-) The completion is reported via an IOCP. I reckon there also has to be some asynchronous API for watching for RTS/DTS/EOF/whatever other events happening with the COM port. |
Subscribed - I am interested in using serial streams within trio, at least on Linux |
Note that we do have the infrastructure to handle IOCP |
@bsdis has recently been having some adventures trying to get basic serial support working in trio by first configuring the port with pyserial, and then pulling out the fileno and using it in a trio stream = FdStream(os.dup(pyserial_object.fileno()) Along the way, we discovered a weird corner of the serial API: apparently posix serial ports have their own unique form of non-blocking mode, where "no data available" is signaled by As a workaround, I suggested: async def iterate_over_serial_fdstream(stream):
while True:
data = await stream.receive_some(65536) # arbitrary number; sets buffer size
if not data:
# spurious EOF, wait until the kernel says data is available and try again
await trio.hazmat.wait_readable(stream.fileno())
else:
yield data
# Usage:
async for data in iterate_over_serial_fdstream(stream):
print(data) Apparently this works, so that's great. I guess a more serious approach would be to either bake this into a References: |
Welcome to the wonderful world of General Terminal Interface. Behold the magnificent leftovers from the hectic '70s where talking to a device over a serial line was a special and unique experience, and each device had its own charming ideas about how bits and bytes related to each other. |
@Joker-vD Huh, yeah, it says it right there in the POSIX spec:
i.e.: |
@njsmith I suppose the semantics are somewhat like sematics of disk files: i.e., if you |
Hello, Docs: https://trio-serial.1e8.de/ |
did anyone look at libusb as an alternative to pyserial? |
Does libusb have an api for talking to serial drivers? Speaking usb is
definitely a useful thing that we might want bindings for, but I thought it
was a different thing from serial support.
…On Tue, Apr 13, 2021, 13:31 david eriksson ***@***.***> wrote:
did anyone look at libusb as an alternative to pyserial?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#549 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAEU42GLLBQO2YWW5VVDIQTTISS2LANCNFSM4FFLKYAA>
.
|
as far as I know, no CDC_ACM wrappers that comes with libusb. a good example might be when you need to interact with various hardware devices where some might run a proprietary (but documented) device class, being able to provide fairly low amount of glue. |
There are sufficiently many serial ports (e.g. embedded consoles, So why would you want to re-implement serial handling for a narrow subset of devices in userspace? |
the benefits of libusb is primarily that we have one way to discover (regardless of class-type) and talk to various usb device-classes by searching for VID and PID rather than a random port-name that is different on various OS'es. you also reach higher throughputs and better control over async behavious which is highly wanted for CDC or custom bulk transfers where speed is needed. last is that you don't need to rely on various fairly large libraries, i.e. pyserial (works, but has been fighting with port naming issues, especially on mac the way it uses corefoundation), rtmidi for usb-mid (large library for a simple thing), and of course a way to talk to devices that implement vendor-specific serial-ports over a custom bulk descriptor. |
If you want to access a usb2serial device through libusb, I think you'll need to disable the /dev/tty* driver for the device and give the user permissions for the usb device. And you'd have to implement the serial specific usb protocols. I think this might be quite a lot of effort. Having generic usb support for trio would be great, though. |
you can do that runtime, and CDC isn't much. I think it's a much better approach to keep a Trio implementation fully async and free from 3rd party libs. |
My
|
I'm confused. It seems like there is overlap between pyserial-supported-things and those that a theoretical libusb based library would support. Am I wrong and a libusb based system would support everything that pyserial could? If not, it seems straightforward that there are two different libraries to be had (or more, of course). One for serial (that would presumably support some USB devices) and one for USB (that would presumably support some serial devices). Or, have I misunderstood something? |
Yes, two libs are needed. USB support is a great idea, but it should be dealt with in a different GH issue. |
Is there any plan to support serial ?
I think UART can also treat as stream,
So can we manage it just as socket ?
The text was updated successfully, but these errors were encountered: