search

bugst / go-serial

A cross-platform serial library for go-lang.
BSD 3-Clause "New" or "Revised" License
619 stars 189 forks source link

Feature rs485 #79

Closed cbrake closed 6 months ago

cbrake commented 4 years ago

First pass at implementing #78

Tested on a i.MX6UL embedded Linux system.

cmaglie commented 4 years ago

This implementation is for linux only, one of the goal of this library is to provide a serial implementation that is independent and (ideally) works 100% the same across all OS.

Is there any native support for rs485 on Windows and Mac too?

Also, I'm wondering: is the added API really needed? can't you control RTS/DTS yourself with the already exising API?

cbrake commented 4 years ago

The problem with controlling the RS485 direction control from the application layer is you don't know exactly when the serial driver buffer/fifo is empty. The idea behind the driver/hardware control is the direction of the bus is changed from tx to rx exactly when it is done sending so you are ready to receive the response. Otherwise, the receiver could start responding before you turn the bus around, and you might miss something. If the application is controlling the direction of the RS485 transceiver with RTS, you would have to put some type of worse case delay after sending to allow the TX to complete which is not optimal.

This is probably only applicable to processors for embedded Linux systems. Most USB RS485 adapters (what you would use with windows or MAC) have automatic direction control built into the device itself -- nothing is required at the driver/app level. However, embedded processors (like the i.MX6UL) are designed to do many different things with the UART, so if you want hardware flow control of a RS485 bus transceiver, that needs to be configured, as the RTS signal is also designed to do other things.

We could create another package that could just be used to configure hardware flow control for the port and perhaps other esoteric things. Perhaps we could open the port with this package, and then open it again with another package and configure the hardware flow control -- not sure offhand if that would work -- seems like a hack.

The current implementation does not affect the API much. Most users simply don't fill out the RS485 field when they create the Mode struct. It does bloat the struct some, but seems cleaner than adding more functions to the interface, which every implementation would have to implement.

AndreRenaud commented 7 months ago

This is a feature that I would also be quite keen on having available, for similar reasons (embedded systems with RTS-controlled RS485 ports). This functionality is also available on Windows if we wanted to try to make it more cross platform. This would be done using the dcbRTSControlToggle settings when we open the port. That would only cover the trivial case (ie: without the various delays etc... being usable). However I think this is the normal & most common behaviour.

cbrake commented 6 months ago

This PR was refreshed in #170, so closing. Thanks @AndreRenaud