Jetson Nano Half Duplex UART (For RS485)

Good day,

I am trying to run RS485 comms with the Jetson Nano as a slave on this line. I am using the max485 as a transceiver chip (I know this is a 5V chip but it seems to work at low range with 3V). I’ve tested comms by manually switching the Receive and transmit enable on the transceiver, so this part works. However, I need to control the enable pins in hardware. I’ve tried the RS485 driver with help from here :, but I get errno (25): Inappropriate ioctl for device, which leads me to believe that this config isn’t possible?

Is it possible to run half duplex uart for driving 485 on the Jetson Nano? I’ve seen graphics online with RS485/RS232 labeled on a Nano but I’ve yet to come across an implementation that works.

Please advise

I communicated with PLC on RS485. You can find the manual below. I hope it helps you. It is Turkish, but if it is something you searching for, you can ask me.

PLC-Jetson Nano RS485 Serial Communication Simple Manual

Thank you @mubarstugan. From the looks of that document, you’re using a usb interface to 485? Is this correct? I need to talk to the 485 transceiver over uart, which would be ttyTHS1 on the nano. The end goal is to configure this serial driver to run in half duplex and drive the the enable line of the 485 transceiver at the driver/hardware level. From what I can tell, with the 485 drivers, it achieves this by using the RTS line as the transmit enable.

Yes, I used USB-RS485 converter. I used RX and TX, which is ttyTHS1 on the nano, but I could not communicate. So, I tried USB converter and it worked.

Thank you. I shall try such a solution if all else. For now though I’m chasing down any solution that would work of the UART, probably in a half duplex mode.

1 Like

I can’t help with most of this, but you should know that the above error is an attempt to use a feature of a driver which does not exist. Most access to kernel features will occur through a file (such as something in “/dev”, e.g., “/dev/ttyS3” or “/dev/ttyTHS3” as an example), and will use ordinary file read and/or write operations. Operations which are custom to the driver, and not possible with just a simple file read and/or write, require an IOCTL call. The software you are using is looking for features the driver does not support.

Thank you, that was helpful. Would you happen to know if this would be a hardware limited issue or merely an unimplemented feature in the driver? Or would you know of a way to modify this driver to attempt to do this?

Most of the time if the driver is wrong for given hardware, then the driver will fail to load. This is only a wild guess and very likely wrong, but it “feels” like you are using software which expects different hardware…in other words, the driver is probably correct for the hardware present, but the end user software is expecting something else.

It could just be another kernel feature has to be added, and what follows is just a general idea and not specific to your case…

Often there are drivers for access to the specific hardware. Sometimes there are optional functions which not everyone will use, and so the optional functions might be an “add-on” kernel feature which can only load if the actual hardware driver is first loaded. This is a dependency example, where a software function is dependent upon a hardware prerequisite.

I don’t know if any such “add-on” software feature is possible for that hardware. The given driver works, but so far I’ve only seen the UART used with RS232. Perhaps there is an add-on RS485 kernel feature required before the IOCTL would be recognized. The software using the UART is apparently expecting such a feature.

Not all UARTs will be able to use RS485, and I do not know if the particular UART can work with RS485 or not, but it is apparent that if the hardware is capable of working with RS485, then the kernel needs “something more”. I don’t use RS485, but basically your next step is to find out what Linux kernel config might be needed in support of RS485. If it is supported, then this will be a feature on top of the UART driver (think in two phases: Drivers to access hardware function, and a feature which understands the protocol.

If you find such a feature, then you would start with kernel source configured to match the current running system, and then enable that extra feature in addition to the current configuration. If you find this feature, and if the feature is available for build as a module, then compiling and installing the module is simple. If the feature must be integrated into the kernel, then you can work with this, but life is a bit more complicated for that case. If an RS485 feature depends on hardware not present, then you are out of luck. If you cannot find RS485 driver/feature information, then you must research the end software you are using and find out what it wants (which isn’t a bad idea anyway to see what prerequisites this end user software wants).

Thank you for the detailed response. It is much appreciated. I have realised that the RTS line, which would be needed here, is not enabled by default on the dev kit. So I’ve gone down the rabbit hole of modifying that and reflashing my device with the new device tree. My thinking is that the ioctl fails because the hardware isn’t configured right, which makes sense with what you’ve said. Hopefully this works. Thank you for taking the time to help.

Unfortunately this did not work… Still get the ioctl error. @kayccc would it be possible to get confirmation that this is possible on the Jetson Nano Dev Kit?

hello Vernon.Naidoo,

Nano’s hardware is used a duplex UART; you may check if your chip had RX/TX auto switch.
if there’s auto direction control in the chip, it’ll need UART TX/RX only.
please also refer to similar discussion thread, Topic 124848 for RS485 configuration.

@JerryChang, Thank you for the response. I’ve seen that thread, I’ve configured my RTS and CTS pins using the UI in the newer jetpack. I’ve also tried using that exact UART test app, from their github page. It gets the same ioctl error as me when trying to config UART. Just to clarify, are you saying that the Nano’s UART cannot natively do half duplex in hardware? Please let me know if this is the case so I can move onto finding a chip that will do the flow control externally instead of trying to find a way to get this working. Thank you

hello Vernon.Naidoo,

yes, Nano’s hardware is used a duplex UART instead of half duplex UART.

we had some similar approaches,
for example, you’ll need some reworks to configure RS485 transceiver to add RX/TX auto switch circuit into the board;
hence, Nano side will only need UART TX/RX for this.