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

[AndreRenaud]

Is there anything I could do to push this PR along? I'm still using RS485 on Go-based applications, and it appears to be functioning well.

Would adding the Windows support assist at all?

[cbrake]

Would adding the Windows support assist at all?

I don't think this is relevant on Windows as I can't imagine any deeply embeded SOCs with this RS485 hardware support in the UARTs running windows. Same with MAC.

It seems the RS485 field in the config can simply be ignored on these platforms that don't support it.

[cbrake]

Nice find!

[AndreRenaud]

Tragically not though - it causes build issues on other platforms. The constant is only defined for Linux builds. Possibly that's an argument (since we're doing a Linux ioctl here) for moving this code out of serial_unix.go and into serial_linux.go?