Feature serial port

[raffaeler]

This is the initial work to create a new SerialPort class as for #1832.
The initial phase is the following:

• Project structure
• Basic definitions (enums, classes)
• Messages definition
• Interop (Platform Invoke)

More to come.

Microsoft Reviewers: Open in CodeFlow

[Ellerbach]

Something to think about is a nothing of WatchChar we have introduced in nanoFramework: https://github.com/nanoframework/System.IO.Ports/blob/develop/System.IO.Ports/SerialData.cs.

See usage here: https://github.com/nanoframework/System.IO.Ports#case-of-watchchar

[raffaeler]

I see, this is substantially the same principle used in Win32 for watching a specific character.
Why did you rename the Eof=0x02 to WatchChar=0x02 in SerialData give they have the same meaning?
If I understand well this enum can be left as-is for compat reasons. Then we can add the WatchChar property to specify what is the character that will trigger the event.
Did I miss something?

[pgrawehr]

This enum should be reviewed. RequestToSendXOnXOff is probably never used (I can't think of a reason why you would use hw flow control and sw flow control at the same time), but instead RtsCts handshake (bidirectional full hardware flow control) should be added.

[raffaeler]

Totally agree, I also have never seen that mix

[raffaeler]

We will have to futher discuss what handshakes we want to support because I am reading an old book on the serial port and there are plenty variations.

[pgrawehr]

This description is wrong. Right would be: No parity bit is sent or expected.

[raffaeler]

Good catch, as I said many descriptions from the official docs are inaccurate.

[joperezr]

NIT: extra space.

[joperezr]

NIT: why do we need to use aliases?

[raffaeler]

I just got the code from the original SerialPort class, no particular reason.

[joperezr]

Thanks for starting to work on this @raffaeler and sorry for the delayed review. I added some comments but feel free to only address what you think you should for this first iteration. I'm fine if you decide to address some of those changes in a follow up PR.

[joperezr]

This looks good to me as a starting point. We should probably consider naming the library System.Device.Ports instead of System.Device.Ports.SerialPort, but no need to block the PR for that as we can continue to make progress and discuss naming and structure later in API Review.

[raffaeler]

After a brief discussion with @joperezr , I implemented the factory pattern to avoid separate builds for each platform.
I pushed almost all the shared code while the platform specific is just a NotImplementedException.
Also, I added the CsWin32 code generator to automatically add the interop declarations for Windows.
Of course there is still a lot of work, but given this is a separate branch I will merge it to provide the opportunity for anyone to give feedback.

I will first start implementing the Windows communication to see if there is the need to change something.

Next "experimental step":

• remove any read/write method from the serial port
• define an interface for pluggable readers/writers (streams)
• plug in a basic implementation for that interface exposing the read/write methods of the System.IO implementation.

The goal of the experimental step is to provide the following communication patterns without having to deal with the serial port specifics:

• single stream reading/writing
• separate read and write streams (as for @Ellerbach request)
• packet-oriented communication
• other kind of fixed/dynamic communication

[krwq]

I'd leave platform implementation details out of here

[raffaeler]

Agree. I just ported the class in the project to resolve other issues in the first place.

[krwq]

can you write a comment why this is commented out?

[raffaeler]

I am going to add this comment:

In the old implementation SetBreakState is set every time using platform specific code for this reason, this code is commented but I left it here because the old behavior is still to be confirmed.

[krwq]

should we have similar check everywhere?

[raffaeler]

I have to see as soon as something starts working.
I am trying to port the same behavior of the SerialPort even if the code is different.

[krwq]

I'd prefer we didn't depend on encoding (i.e. remove all string related helper methods and encourage people to use string writer)

[raffaeler]

As I wrote in my comment after the last push, I am willing to remove any read/write method from the SerialPort class.
Instead, I plan to add a sort of "plugin" (based on an interface) that allows to customize the typology of reads/writes.
For example Laurent asked to have separate streams for the read and write channels.