Mity CPU Platforms » MityDSP-L138 (ARM9 Based Platforms)

The serial 8250 driver has an rs485 mode which we extended to allow using a gpio to generate a RS485 TX enable. However this was intended to be setup at runtime for a separate interface and not for the debug console. Though you may be able to tweak the driver to allow this mode to be set up in the baseboard file..

https://support.criticallink.com/redmine/boards/10/topics/1273?r=1276#message-1276
https://support.criticallink.com/gitweb/?p=linux-davinci.git;a=commit;h=685560d539688afc6bd5a735d4059c99eed24758

I'm not sure if I'd recommend this approach as you'll also need to modify the u-boot code to do something similar and possibly the UBL code, to see the whole boot process.

If this is not possible, are we able to change which UART is used by the system? UART0 with RTS enabled might be preferred for my application...

For similar reasons, I always push back on any design that tries to move the debug UART to a different port. A successful bring-up is very reliant on the debug UART working and making changes like this can add a ton of delays to development, when things don't work.
So yes it's possible but I would not want to bring up such a system.

Could you do an RS422 4-wire bus instead? You then wouldn't need the TXEN pin, so no software changes.

Hi Jonathan,

thanks for the quick response. I will look into the 8250 driver, it might be useful (if only for my runtime code). I expected a hesitant response with regard to this scheme, but half duplex RS485 is unfortunately the most suited interface we can implement (long distance, low power, and few wires). The primary motivation for getting UART1 access over the RS485 interface is the ability to reconfigure the SOM entirely while it is embedded in our system. For development we could work with UART1 conventionally and have RS485 setup on a different UART for interfacing with our software. This is likely what I will shoot for now, but the ability to reconfigure the SOM in its embedded state is very desirable. Any outside-of-the-box insight on how that could be accomplished over one RS485 link would be appreciated!

Thank you,
Michael

How long are you looking for?

The kernel documentation mentions getting extended distance for rs232 by using UTP cat 5 cable. Or using a shield low-capacitance wire. Also mentions using line drivers to get larger distances.
https://tldp.org/HOWTO/Remote-Serial-Console-HOWTO/serial-distance.html

We could also drop the data rate but that would require almost the same amount of code change.

I did come across this application note from TI: https://www.ti.com/lit/ug/tidubw6/tidubw6.pdf?ts=1719509747706
(if the link is broken in the future to others with this need, the article is titled: "TIDUBW6 - June 2016: TI Designs Automatic Direction Control RS-485")

I made some modifications of their example design to work with 3.3V and 115200 baud, 1 stop, no parity.I believe this should work quite well for the application.
Instead of a 555, I opted to use a LTC6993-3.

Seems like it could work. Good find.