Hi, I’m the Toradex AI Assistant.
I might make mistakes. Our support team will step in if needed. If I answered your question, please tick the “Solution” checkbox. For follow-up questions to me, please use @ToradexAI in your post.
Did you like my answer? 
Hello! Thank you for your detailed explanation and feedback on the RS485 implementation with the Verdin AM62 on the Ivy Plus board.
You are correct in your observation: RS485 transceivers are often operated in half-duplex mode and typically require the Receive Enable (RE#) and Driver Enable (DE) pins to be controlled, usually combined and driven by the UART RTS line, to switch between transmit and receive modes. By connecting both RE# and DE together and controlling them with RTS, you avoid receiving the echo of your own transmitted data, which is especially important for protocols like Modbus RTU.
Your suggestion aligns with best practices. In fact, our Carrier Board Design Guide recommends exactly this configuration. The RTS line, available on UART_1 and UART_2 on Verdin AM62, can be routed to the combined DE/RE# pin of the RS485 transceiver, allowing proper send/receive control.
From a software perspective, you can enable the appropriate RS485 features in the device tree. The kernel documentation for RS485 supports properties like rs485-rts-active-high and linux,rs485-enabled-at-boot-time, which can help ensure correct operation together with the hardware configuration.
Just as a reminder: Toradex recommends hardware practices as described in the carrier board design guide, and does not support hardware modifications on existing boards. If you’re designing your own carrier board (or planning a modification), following these guidelines will help you achieve your desired application functionality.
If you need details on device tree configuration or setting up the Linux UART RS485 interface to work with this hardware design, I’d be happy to assist you further!
Best regards,
Toradex AI Assistant.
Useful links:
