Add rudimentary support for serial port i/o to dart:io

[muth02446]

A chrome extension has access to serial port i/o and this is well supported in dart. But a command line application does not.

It would be nice if dart:io could be augmented to support this. Hopefully most of the existing file support can be reused and only functionality for setting baud rates, etc. needs to be added.

Why is this useful? A ton of devices still use serial ports for communication, e.g. Arduino style devices, home automation controllers, etc.

There is an existing library "serial_port" but it does not work very well on Linux and the fact that it needs to make native calls and provides its own shared libs makes it hard to work with.

[zoechi]

https://pub.dartlang.org/packages/serial_port

[muth02446]

@zoechi yes that is the library my last paragraph was referring to.

[zoechi]

IMHO that's a generic problem with native support in pub packages. I'd suggest an tcp-RS232 converter. Many PCs don't have RS232 anymore anyway.

[muth02446]

@zoechi, I agree that native support in pub packages is painful which is why I am lobbying to make enough functionality part of the sdk that no additional native code is needed.

WRT the suggestion of using a tcp-RS232 converter: many serial devices these days actually have a usb connector and use serial via USB.

[mrmcq2u]

would be nice to have a bridge for the ble flutter plugin

[altera2015]

For flutter there is the usb_serial https://pub.dartlang.org/packages/usb_serial

[robertmuth]

It is good to see some movement in this space but usb_serial seems to be written in and/or depending on Java which is a heavy dependency and I doubt it would work well with the dart:io env.

[altera2015]

Yeah not intended for dart:io integration. It targets Flutter on Android.

[zoechi]

34452 hopefully will make it easy to implement that as a package

[robertmuth]

Nice to see that coming along as well. My preference would be to have syscall bindings available in dart possible implemented using ffi and then implement the usb library on top of that.

[vinicentus]

+1, this would be really useful for a project of mine...

[Piero512]

Hey, today on the r/FlutterDev discord we were thinking about this issue, and I think the best compromise is for the File class to return a FD that we can use to call termios functions (and their equivalents in Windows) through the now stable Dart FFI. You might want to add any warnings on what functions not to call through the FFI from the returned file descriptor

[maks]

Given the existence of the libserial based package which covers all Dart platforms except web, this issue could probably be closed now?

[robertmuth]

I would prefer a pure dart implementation. How does linking with native libraries work? Can you statically link or do you have to go through sharedlib hell?

[maks]

@robertmuth I simply posted it as a working solution you can use now. That library uses FFI. There can't be any "pure dart implementation" as the DartVM would need to end up needing to bundle (mostly likely a FFI based) access to native OS API's, basically reinventing the libserial wheel so not sure what the benefit would be outside of it being able to be statically linked into the DartVM. And that should answer your last question, FFI use currently is shared libs only, static I believe is being tracked in this issue.

[robertmuth]

It is nice to have the option to use libserial - do not get me wrong. But I feel this is a subpar solution, at least for Linux, where in theory you could have static linking into single binary that you then deploy.

I also feel this belongs in a "std lib". Otherwise, this will rot like the serial_port library I mentioned in the issue description.

Related question: does the current "std lib" expose all the primitives to even attempt a pure dart solution (on Linux), e.g. bindiungs for os calls including ioctl?