Possibility to choose the Serial port to work with

[dl1com]

Currently (1.0.0), the library automatically creates a RS485 object running on the SERIAL_PORT_HARDWARE serial port (https://github.com/arduino-libraries/ArduinoRS485/blob/master/src/RS485.cpp#L181).
Although it might be idiomatic for Arduino libraries to automatically create an object to work with, for this library it causes trouble on some platforms and use cases:

• If you want to use a different Serial port than Serial, you still have to live with the automatically created RS485 object on Serial, which is a waste of memory.
• On some platforms (e.g. some STM32), Serial is of type USBSerial. As the RS485 constructor only accepts HardwareSerial, and you cannot set another Serial port, this causes that the library cannot be compiled for these platforms. Workaround is to remove L181 of RS485.cpp.

So actually, I propose two changes:

• Use Stream as interface type for the RS485 constructor, so it can be created with HardwareSerial as well as with USBSerial interfaces.
• Do not create a RS485 object on SERIAL_PORT_HARDWARE, but rather require the user to actively chose the desired port as a parameter in the begin method (I guess it is ok to have SERIAL_PORT_HARDWARE as the default value for the port parameter.) Drawback: This change is not backwards-compatible. Current users of the library will have to add a line to create the RS485 object manually.

[larsvankleef]

@chris007de What would be the workaround for now? I would like to use SoftwareSerial.h and pass that to the RS458 Class would that be possible?

[danielmcmillan]

I'm using a fork as a workaround for now which changes the HardwareSerial parameter to a Stream danielmcmillan@0193f4e
I otherwise kept the interfaces the same, but it is not backwards compatible since whatever serial port is being used has to be manually configured (provided baud rate and config is ignored), and the default RS485 object no longer works (replaced with null dereference macro to save memory while retaining compatibility with libraries that use it as a default).

It is compatible with the ArduinoModbus library so long as a custom RS485 object is provided, so it can be used for Modbus over software serial.

[romainreignier]

This issue also prevents the use of this library on the M4 core of the Portenta H7 board that does not define SERIAL_PORT_HARDWARE
But it also prevents to build the MachineControl library for the M4 core as tracked here: arduino-libraries/Arduino_MachineControl#85

For me this solution would be the best:

Do not create a RS485 object on SERIAL_PORT_HARDWARE, but rather require the user to actively chose the desired port as a parameter in the begin method (I guess it is ok to have SERIAL_PORT_HARDWARE as the default value for the port parameter.) Drawback: This change is not backwards-compatible. Current users of the library will have to add a line to create the RS485 object manually.

[rlstrand]

This issue also fails on Raspberry Pi Pico as it does not define SERIAL_PORT_HARDWARE.

[bobemoe]

I'm trying to get this working on STM32 which is a platform that uses USBSerial rather than HardwareSerial.

The workarounds sound promising but L181 link above is to master which I now think is the wrong line number?

Tempted to try the fork but that is some commits behind now too.

What is the current workaround/solution to this?

Thanks

[bobemoe]

So I'm using the @danielmcmillan fork. Its allowed me to use this lib on STM32. Thanks.

Would really love to see this (or similar) added to the official package here as it would improve compatibility vastly.