Feature RS485

[AndreRenaud]

This is a simple rebasing of #79 (from the https://github.com/cbrake/go-serial-1/tree/feature-rs485) branch. Sorry, I wasn't sure what the best approach was - this isn't my code, but it does compile against the latest version of go-serial.

[AndreRenaud]

If anyone has a windows machine that can try this on, I believe this is the Windows change required for support. Unfortunately I cannot test it, so I don't know if it's a good idea for me to add it to this patch:

diff --git a/serial_windows.go b/serial_windows.go
index 2e8a4cc..ff4e272 100644
--- a/serial_windows.go
+++ b/serial_windows.go
@@ -468,6 +468,10 @@ func nativeOpen(portName string, mode *Mode) (*windowsPort, error) {
 	params.XoffLim = 512
 	params.XonChar = 17  // DC1
 	params.XoffChar = 19 // C3
+
+	if mode.RS485.Enabled {
+		params.Flags |= dcbRTSControlToggle
+	}
 	if setCommState(port.handle, params) != nil {
 		port.Close()
 		return nil, &PortError{code: InvalidSerialPort}
@@ -479,12 +483,3 @@ func nativeOpen(portName string, mode *Mode) (*windowsPort, error) {
 	}
 	return port, nil
 }
-
-// enableRS485 enables RS485 functionality of driver via an ioctl if the config says so
-func (port *windowsPort) enableRS485(config *RS485Config) error {
-	if !config.Enabled {
-		return &PortError{code: NoPlatformSupportForRS485, causedBy: nil}
-	}
-
-	return nil
-}

[cbrake]

@cmaglie is there any chance you will consider merging this?

I hear the argument that it is not cross-platform, but realistically, the only platforms that need this are embedded Linux platforms with SOCs that have hardware support for RS485 direction control in the UART.

Is there a better way this can be implemented so it would be accepted?

[cbrake]

Here are a few snippets from a i.MX6UL datasheet that illustrates what we are talking about:

Embedded processors from TI and others have similar features.

This is the relevant kernel API:

https://docs.kernel.org/driver-api/serial/serial-rs485.html?highlight=rs485

[bieli]

@AndreRenaud Maybe you could fix one CI/CD bug and it will be possible to merge your PR to master? I think ;-)

[AndreRenaud]

@AndreRenaud Maybe you could fix one CI/CD bug and it will be possible to merge your PR to master? I think ;-)

It's not obvious to me why that CI/CD issue is related to this PR to be honest. It is complaining about Error: enumerator/enumerator.go:31:9: undefined: nativeGetDetailedPortsList. But I haven't changed the enumerator code, or added/removed/altered the nativeGetDetailedPortsList function.

Also this PR has been sitting idle for a while - I don't think it's the CI/CD issue that is preventing it getting traction.

[AndreRenaud]

The workflow failure does appear to be unrelated to this PR. On MacOS/Darwin, the build requires CGO, and thus will fail unless it is built with CGO_ENABLED=1. I'm not clear why this has only just cropped up on this PR as it seems unrelated to this work. I assume it relates to the architecture of the GitHub runner perhaps changing recently from AMD64 to ARM64 for macos?

See arduino/yun-go-updater#1 for some more discussion on it.

[AndreRenaud]

I've investigated the workflow issue, and have submitted a separate PR to resolve it. #186