Implement RS-485 with A20-SOM using hardware flow control

[WilPT]

Hello all!

I can't use hardware flow control on A20, maybe someone could help me.

We are using A20-SOM in one of our hardware projects and we need to implement RS-485 communication protocol between A20 and uC using the available hardware flow control.

I have configured the script.fex file properly to set UART2 with RTS and CTS:

[uart_para2]
uart_used = 1
uart_port = 2
uart_type = 4
uart_tx = port:PI18<3><1><default><default>
uart_rx = port:PI19<3><1><default><default>
uart_rts = port:PI16<3><1><default><default>
uart_cts = port:PI17<3><1><default><default>

I'm using SN65HVD75DR as RS-485 transceivers and the connections to the drivers on A20 and uC are:
RX  -> R
CTS -> RE
RTS -> DE
TX  -> D

Thank you for your time!

Regards,
Wilson

[dlombardo]

Hi, we are using mostly A20-MICRO.

I gave up on Debian7, did not try on Debian 8 as I think this is Kernel based and I am already using latest 103+ Kernel on both Debian FS.

My assumption is:

1. Kernel seems not to have included patches for the RS485 flow control - tried to find it in Kernel files with grep, did not find it and then I did not look deeper to find / patch it myself
* also when using code to enable RS485 mode in C code, obviously the code did not work, I reason because there is not proper support in Kernel

2. I tried to use GPIO DE control from userspace and it might be sufficient for some communications as timming can not be very well controlled (and slow), but for our aims with 2 char (9500bps) wait time between the reply/answer from uC ARM, this was unusable.


Our aim was to fix it, to add support in Kernel if needed but after we have tried the MAX13487 never looked back.
The production price for electronics with this or other RS485 drivers is neglectable.

Also because many Linux capable ARM CPUs do not have hardware DE support I think this is currently very good selection.


We are using SO4 MAX13487EESA+T in 9600bps and 115200bps for last year in all our production designs.

MAX 13487 is 5V, but also 3V3 levels are fine.

For optoisolated solution use 5V regulator to power a MAX13487.
The TX and RX lines are then fed from an ADUMxxxx bus isolator.

For "non isolating" use 5V from A20.
We add level shifter (resistor based) 5V->3V3 on TX->RX from MAX to A20.

For quick tests and maybe reference design you might use cheap module from china.

[WilPT]

Hi dlombardo, thank you for your reply.

Yes, we also support the idea that Kernel does not have patches for RS485 flow control.

At the moment we are controlling DE/RE from userspace and communicating at 38400bps but with only 2 devices on the BUS. We implemented a detection/correction code to handle the errors/collisions on the BUS and till now it is working nice. In the future we want to support several devices on the same BUS so we are looking for an alternative.

I took a look to the MAX13487EESA+T and yes it is a very good choice since it has the built in
AutoDirection Control. We will try to use it for sure. About the price it's almost the same, so, not a problem.

Thank you once again for sharing your solution.

Best regards,
Wilson