SerialPort Support on Windows

[shaggygi]

Just wondering if SerialPort namespace will be included at some point?

---

Execution plan

• [x] 1. @JeremyKuhne to seed the sources in CoreFX (from full .NET Framework) - add source code (sanitized, with licenses), the source won't build
• [x] 2. Make the code build
  • CC: @JeremyKuhne @karelz on PRs
  • Note: We will not take any functional changes to the implementation, architecture, or API surface at this point unless they are absolutely necessary to make the code compile on .NET Core. Please give heads up on this issue as soon as you discover cases like that.
• [x] 3. Add tests - tracking progress in dotnet/corefx#15752
  • [x] @JeremyKuhne to find out if we can leverage full .NET Framework tests
  • We need to design the test environment - we need ability to test the code in CI (ideally without heavy modification of CI machines)
  • We need to set goal for code coverage

If anyone is working on any step, please mention it & coordinate here to avoid duplicated effort. @karelz will co-assign the issue to you as well.

[Maxwe11]

:+1: for supporting communication over serial line in corefx. It could be existing SerialPort class however I'd prefer new more reliable api based directly on Stream.

[sawilde]

There are a few nuget packages that already provide this capability as there are such a small number of downloads it makes you wonder what the demand is.

[shaggygi]

@sawilde could you provide a link for those? I would like to try them out. Thx

[sawilde]

http://www.nuget.org/packages?q=serial

[shaggygi]

Thx

[ellismg]

My general feeling is that Serial Port is not a good long term fit when you think about foundational libraries of .NET Core, and hence we wouldn't include it in the CoreFX project. The current SerialPort class source is MIT licensed now, as part of the .NET Reference Source project, so folks are free to take it an run with it.

In general, I think we'd like CoreFX to be a set of libraries that are useful across the entire .NET ecosystem. That includes devices like Phones, Severs, Tablets where a serial port library is unlikely to be useful.

[Maxwe11]

Serial Port is not a good long term fit when you think about foundational libraries of .NET Core

.NET ecosystem. That includes devices like Phones, Severs, Tablets where a serial port library is unlikely to be useful.

What the problems to use SerialPort on server? It's a powerful "tool" like pipes or sockets. .NET ecosystem now includes Linux and Mac, but Win32.Registry presented in corefx.

[ellismg]

@Maxwe11, I'm interested in understanding more about how serial pots would be used in server scenarios. I can see how both pipes and sockets are useful in general for IPC, what sorts of uses does serial port have?

You're right about CoreFX containing some Win32isms, However, we are doing our best to minimize the set of types that pull in Win32 concepts. The desire to be able to run stacks like ASP.NET vNext requires that we bring in some components that are windows centric and will be hard to support on Linux and Mac, but when possible we are trying to be explicit in the surface area we add to the core, to make sure it's suited for a wide range of platforms and devices.

[shaggygi]

@ellismg I can see your point of view on this topic as there were several discussions why serial port capability was not provided out-of-box for WinRT. However, this feature is needed all the time in some industries like building automation. In addition, if corefx is expected to be used with embedded devices, those type of applications use uarts quite a bit.

I would agree it might not need to be included as long as there is a package we can include and hopefully be cross plat as well. Thx

[shaggygi]

One other note... I've also seen cases where data cables were needed to connect between pc/tablet/phone via USB to devices for serial communications (232, 485). Having this feature would support these types of apps.

[Maxwe11]

I'm interested in understanding more about how serial pots would be used in server scenarios. I can see how both pipes and sockets are useful in general for IPC, what sorts of uses does serial port have?

As mentioned by @shaggygi: for communicating with embedded devices.

[shaggygi]

I don't recall adding anything about using with servers. If so, it must have been a typo.

[akoeplinger]

+1 for SerialPort, it is still widely used in industrial/embedded systems.

I'm not sure whether we need it in corefx though, having a separate package should be fine too (after all, better modularization is one of the benefits of the new model). Maybe it's time for dotnet/extendedfx :smile:

[Tragetaschen]

I don't really care if it's from corefx or any other repository as long as it's coming from Microsoft. In the past, that always meant a certain level of quality.

[kangaroo]

I agree with @ellismg, this isn't a corefx problem. This is a problem, that begs for a community contribution of a fantastic nuget package!

[Maxwe11]

I don't really care if it's from corefx or any other repository as long as it's coming from Microsoft. In the past, that always meant a certain level of quality.

Agree with it, but for now SerialPort not supported even in PCL

[sawilde]

@shaggygi

And not a third-rate quality package

did you check out the nuget packages that are currently available? If not suitable - why not? Could you improve on them?

To create a 'quality' serial port library requires a certain level of knowledge I suspect - who has that knowledge... well those that need a serial port library. There are not many of you out there so rather than wait for someone to build a library, whilst making all the mistakes you would expect from someone learning the domain, perhaps it is something the 'serial port user' community should do - create a github repo and share your knowledge to create the .NET serial port package.

[shaggygi]

@sawilde I believe my post was out of context, so I removed it. I'm really content with the API provided in .NET and I'm sure the other packages will probably work. I was just hoping what is provided to work with corefx will be easy to use similar to what I've always used in the past.

[terrajobst]

As @ellismg said above, the source is available. I've marked this as up-for-grabs. If anybody wants to take a stab, let us know!

[n8allan]

I was hoping that .NET on Linux would potentially give me a solution to the problem I'm having with the rather poor implementation of System.IO.SerialPort in Mono. I would note to Sawilde that all of those NuGet packages related to serial communications are either something else or built on top of the SerialPort class. I know of no comprehensive replacement.
My +1 on this, either as part of the core or as an add-on. Whomever works on this, please do not repeat the poor error handling job done by Mono on their implementation. See this bug report for example.

[ruben0909]

+1

[ghost]

Besides mono implementation, node.js community is having similar discussion: https://github.com/nodejs/node/issues/1546 as libuv's support is on its way: https://github.com/libuv/libuv/pull/484 (which would work on Linux, Windows, OSX and FreeBSD).

Once that is implemented, and libuv is an OK dependency to carry (perhaps @KrzysztofCwalina can verify), we can consume it via https://github.com/txdv/LibuvSharp or https://github.com/dotnet/corefxlab/tree/master/src/System.Net.Libuv. Otherwise, we would need to implement the native shims for serial port.

[n8allan]

As I recall, Silverlight added serial port comms at one point. If so, shouldn't there already be a portable implementation of serial comms out there for the taking?

[ghost]

But Silverlight is not open sourced. Either we can wait for it to get in open or we implement shims to cover the serial port API implementation. I think latter is more actionable and aligns with DIY philosophy of GitHubbies. :)

[JammersHammer]

I see serial port communications as being important. We have an app that talks to serial based equipment at asphalt plants and other areas of our business. The developers of those devices are slowly (real slow) moving toward other means of communications such as across an Ethernet cable but for the time being, serial communications is still quite important. If there are other outside libraries (hopefully free or Open Source), then they may be worth looking into but up until now, we've worked quite well with the libraries are part of the current .NET. This newer .NET CORE may not be an option for us to go to due to this library possibly being omitted from it. This hurts (not helps) our business.

[n8allan]

I see serial port communications as being important.

Absolutely true @JammersHammer, and especially true in the embedded space where serial communications–whether over TTL, bluetooth, or whatever–are still a primary means of inter-device communication.

[patryk9200]

It's must have library for all IoT development. For example, I need SerialPort for communication with Z-Wave, ZigBee etc. & other IoT communication related stuff.

[abdullah2993]

+1 for serialport My asp.net core app needs to communicate to a GSM modem over Serial

[darkurse]

+1

Some might not see this feature as useful or even too old fashion to be relevant. but like it or not many industries are still HEAVILY reliant on this old technology. And yes, these industries should probably move to more modern ways of communicating for all the reasons you can think about. But from experience - they probably won't. The first reason being the financial effort they would need to provide in order to renew all their h/w ! Writing s/w that can run on 1000 devices is always gonna be cheaper than buying 1000 new devices.

Regarding available alternatives on github/nuget, no offense but between Microsoft quality grade library and unknown 3rd part libraries quality grade, I am NOT thinking twice about what choice I am going to make ;)

Anyway, that's my 2 cents.

[ianhays]

@stephentoub @danmosemsft

[viniciusvillas]

+1 Scenarios where I can use serial port in a server: to send commands to GSM modems (a Web API service to send SMS text messages, for example) and to communicate to sensors and IoT devices (like *duino or ESP8266). This is a must have feature, IMHO. .NET Core is very appealing to me in my line of work (general automation) because of its portability, but is also useless to me without libraries to support communication via Serial/UART. The published open source SerialPort library is not portable as it is using native file access from the Windows APIs.

[danmoseley]

We would love to see SerialPort but don't have time to take this on right now on the Microsoft end. As Immo mentioned, this would be a great project for community to tackle.

[shaggygi]

I think the news of Samsung joining the Foundation and focusing on ARM should hopefully help in this area. http://www.dotnetfoundation.org/blog/samsung-join-tsg

Hope to see this support added at some point.

[ghost]

@danmosemsft, is taking dependency on another native lib an option? Or do we have to provide a custom native implementation in CoreCLR PAL?

[danmoseley]

We would rather avoid that. @stoub to comment also.

[ianhays]

We would rather avoid that. @stoub to comment also.

@stephentoub

[stephentoub]

Or do we have to provide a custom native implementation in CoreCLR PAL?

If we were to provide a custom native implementation, it would not be in the CoreCLR PAL. The SerialString managed code would be in its own assembly, and it would depend on native code defined in one of the corefx shims, likely either System.Native.so/dylib or a new one like System.IO.SerialPort.Native.so.

is taking dependency on another native lib an option?

It depends on a variety of factors. Is the license on that library amenable? Is it already available via the default package managers / package manager feeds for all of the relevant platforms so that n one is required to build anything from source? Has it been proven to be highly reliable? Is it the defacto standard for that area? Etc.

I would expect the native requirements here would be relatively minimal, though, relying on basic libc functionality, termios, etc.

[abdullah2993]

@jasonwilliams200OK Libuv can be an option if this makes its way to corefx and this is done by then.

[ghost]

@Abdullah2993: ditto https://github.com/dotnet/corefx/issues/984#issuecomment-193317146 :smile:

@stephentoub, thanks for the info. Agree that we can build on top of native libc and figure out the diffenreces which node.js guys are trying in libuv.

The other option could be this C++ library https://github.com/wjwwood/serial which has MIT license and FreeBSD, Linux, OS X and Windows ready. It encapsulate the platform differences. We can probably take it as a git-submodule dependency (at src/Native/dependencies/serial) and integrate it in src/Native/CMakeLists.txt (example of git-submodule dependency with cmake: https://github.com/Snaipe/Criterion/ see the .gitmodules, dependencies dir at root and CMakeLists.txt at root) .. and static compile this serial lib.

There is also a C libserialport, but it has bit restrictive license (GNU Lesser General Public License,) which no-gnu folks mind :) http://sigrok.org/wiki/Libserialport

[stephentoub]

We can probably take it as a git-submodule dependency

We would not want to do that. We'd effectively end up shipping code we have no control over.

static compile this serial lib

Nor that. For our official binaries, we do not want to statically link, for similar reasons.

The other option

I'm not clear on what problem we're trying to solve here. Is there a lot of code that would need to written? Doesn't seem like it. I suggest such discussions hold off until someone sees what's actually necessary. The first step is getting the Windows implementation brought into the corefx repo, getting it running with .NET Core on Windows, and putting tests in place. The second step is refactoring the library to introduce a managed PAL layer as we have in other libraries, with stubbed out Unix entry points to be implemented. Then comes the task of seeing what those entry points are and implementing them.

[shaggygi]

Hopefully it will have similarities to https://pypi.python.org/pypi/pyserial

[ItayGal2]

1+

[davidbitton]

+1. Serial is in use in the UAV sector.

[DanielMcAssey]

+1

[wangyanjun]

Since a lot of API brought back to netcore, is it the time to bring SerialPort back to netcore? when we develope IOT related apps the serial port is a very important .

[danmoseley]

We don't have this work scheduled right now so a community contribution would be welcome.

[mobidev111]

let's get together to prepare for e.g. a shared NuGet package

did anyone already do any work on this?

• what are your current findings to access the serial port?
• is https://github.com/dotnet/corefx/issues/984#issuecomment-76349671 still the starting point?

[gusmanb]

Hi.

This is just a thought, but for the community adding support for LibUSB should not be really difficult. Linux already has it bundled and I belive mac does too, so the only problem is with Windows where it must be installed as a filter, but except for that, bringing USB should not be very difficult to do, just a wrapper like LibUSBDotNet but on .net core.

That also would bring back serial device support as adding an USB to RS232/485 adapter is te usual way to support serial comm, nearly no mobo has serial ports today.

[mobidev111]

Sounds reasonable.

"LibUSBDotNetCore - .NET Core C# USB library for LibUSB. Using the common device classes, applications work with all operating systems and drivers without modification."

Who can help? How can we drum up support?

[shaggygi]

@gusmanb i like this, but seems a little limited. I have a few scenarios of using usb adapters (ftdi, etc.) for serial communications, but would be for usb devices. How would this solution help when connecting serial coponents directly to embedded (tx/rx) pins (beagle bone, RPi, etc.)?