RS485 support for BBB

I would like to use RS485 with the BBB.

root@beaglebone:~/test# uname -a
Linux beaglebone 4.1.15-ti-r40 #1 SMP PREEMPT Thu Jan 7 23:32:17 UTC
2016 armv7l GNU/Linux

I am using the kernel above. Its source code is at
https://github.com/RobertCNelson/linux-stable-rcn-ee/tree/4.1.15-ti-rt-r40

... however it does not include the changes in this patch:
https://github.com/RobertCNelson/bb-kernel/blob/am33x-v3.8/patches/fixes/0007-omap-RS485-support-by-Michael-Musset.patch#L30

Which kernel should I use that includes the changes in the patch or
something similar?

I would like to use RS485 with the BBB.

root@beaglebone:~/test# uname -a
Linux beaglebone 4.1.15-ti-r40 #1 SMP PREEMPT Thu Jan 7 23:32:17 UTC
2016 armv7l GNU/Linux

I am using the kernel above. Its source code is at
https://github.com/RobertCNelson/linux-stable-rcn-ee/tree/4.1.15-ti-rt-r40

You need to rebuild and swap these two configs:

disable: CONFIG_SERIAL_8250_OMAP

enable: CONFIG_SERIAL_OMAP

... however it does not include the changes in this patch:
https://github.com/RobertCNelson/bb-kernel/blob/am33x-v3.8/patches/fixes/0007-omap-RS485-support-by-Michael-Musset.patch#L30

485 is pretty much built-in to CONFIG_SERIAL_OMAP

It's the last thing still being talked about for integration into
CONFIG_SERIAL_8250_* for possibly 4.6.x

Which kernel should I use that includes the changes in the patch or
something similar?

and use this overlay as reference, as it's been reported to work with
that config chanage above..

https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BB-UART4-RS485-00A0.dts

Regards,

Hi,

Use MAX13487EESA+ It has an automatic direction control…

Arsi

Thanks, Arsi. That is interesting.

I am using a prototype board designed by our hardware department that
uses another Maxim RS485 driver which is pin compatible with the one
you suggested except for two pins (RE and SHDBN).

I will ask the hardware engineer what he thinks about it.

Thanks, Robert.

USE KERNEL 3.8.13. I spent days trying to figure out why 4.4.1/2/3-bone-rt-5 wasn’t working. Selecting the omap-serial driver (rather than the 8250-omap driver) won’t work because some of the rs485 patches didn’t get included in later kernels.

Since last Thursday, my job was getting RS485 working on BBB.

I used a MikroElectrinika MikroBUS cape*, and an RS485 Click** plugged into mikroBUS socket 1. I actually rather like this setup.

*http://www.mikroe.com/click/mikrobus-cape/
**http://www.mikroe.com/click/rs485-3.3v/

For mikroBUS socket 1, RX and TX pins are routed to the Sitara uart2, and the data direction control connects to J9 pin 14 (a.k.a gpio1[18], a.k.a. “echo 50 >/sys/class/gpio/exports”). It’s only necessary to load the BB-UART2 overlay (“echo BB-UART2 >/sys/devices/capemgr.*/slots” or “capemgr.enable_partno=BB-UART2” in the uEnv.txt boot file) and do your programming.

Use this for the RS485 setup structure:

struct omap_serial_rs485 {
__u32 flags; /* RS485 feature flags /
#define OMAP_SER_RS485_ENABLED (1 << 0) /
If enabled /
#define OMAP_SER_RS485_RTS_ON_SEND (1 << 1) /
Logical level for
RTS pin when
sending /
#define OMAP_SER_RS485_RTS_AFTER_SEND (1 << 2) /
Logical level for
RTS pin after sent*/
#define OMAP_SER_RS485_RTS_BEFORE_SEND (1 << 3)
#define OMAP_SER_RS485_USE_GPIO (1 << 5)
__u32 delay_rts_before_send; /* Delay before send (milliseconds) /
__u32 delay_rts_after_send; /
Delay after send (milliseconds) /
__u32 gpio_pin; /
GPIO Pin Index /
__u32 padding[4]; /
Memory is cheap, new structs
are a royal PITA … */
};

… because the omap-serial rs485 patches slightly enhanced the regular struct serial_rs485 you find in sys/serial.h

Here’s my rs485 setup code (error checking omitted):

struct omap_serial_rs485 rs485;
i = ioctl(m_fd, TIOCGRS485, &rs485); // whats’ the current setup?
rs485.flags |= OMAP_SER_RS485_ENABLED; // Enable RS485 mode
rs485.flags |= OMAP_SER_RS485_USE_GPIO; // use a GPIO pin for
// direction control
rs485.flags &= ~(OMAP_SER_RS485_RTS_AFTER_SEND|OMAP_SER_RS485_RTS_ON_SEND);
rs485.delay_rts_before_send = 0; // No delay from RTS-assert before xmit
rs485.delay_rts_after_send = 0; // No delay after xmit until RTS-negate
rs485.gpio_pin = m_pin; // select the direction control pin

i = ioctl(m_fd, TIOCSRS485, &rs485); // establish

I built and installed kernel 3.8.13-bone79 this morning. Finally I’m working well.

(Oh, BTW, Robert: I thought perhaps your site at https://eewiki.net/display/linuxonarm/BeagleBone+Black might add a couple lines about kernel 3.8.13. It explains 4.1, 4.4, and RT versions of those, but 3.8.13 is still being maintained and some things still only work there. Just a suggestion…)

Hi,

I was the one that create the patch for the kernel 3.8 ^^ .

And I figure it out how to make rs485 work on kernel 4.1 . It’s rather simple :

uart1_pins: pinmux_uart1_pins {
pinctrl-single,pins = <
0x184 0x20 /* P9.24 uart1_txd.uart1_txd OUTPUT OK*/
0x180 0x20 /* P9.26 uart1_rxd.uart1_rxd INPUT OK*/
0x1a4 0x07 /* Uart1_Txen → GPIO3_19 OK*/

;
};

&uart1 {
pinctrl-names = “default”;
pinctrl-0 = <&uart1_pins>;
status = “okay”;
rts-gpio = <&gpio3 19 GPIO_ACTIVE_HIGH>;
rs485-rts-active-high;
rs485-rts-delay = <1 1>;
linux,rs485-enabled-at-boot-time;
};

and of course disable 8250 and enable omap driver.

to test it ? echo “test test test” > /dev/ttyO1

that work for me ^^

Thanks for the feedback, it is good to know. Hopefully in a few months
the 485 patches will land in the mailine kernel (in the 8250 driver).

So i compiled (bb-kernel, all patches) and installed 4.5.2-bone4
I have modified am335-boneblack.dts and compiled it.

#include “am335x-peripheral-ttyS1.dtsi”
#include “am335x-bone-pinmux-ttyS1.dtsi”

&am33xx_pinmux {
uart1_pins: pinmux_uart1_pins {
pinctrl-single,pins = <
/* P9_23: uart1_de */
BONE_P9_23 (PIN_OUTPUT_PULLDOWN | MUX_MODE7)

;
};
};

&uart1 {
pinctrl-names = “default”;
pinctrl-0 = <&uart1_pins>;
status = “okay”;
rts-gpios = <&gpio1 17 GPIO_ACTIVE_HIGH>;
rs485-rts-active-high;
rs485-rx-during-tx;
rs485-rts-delay = <1 1>;
linux,rs485-enabled-at-boot-time;
};

RS485 doesn’t work, what do I do wrong?

Kind regards

any reason you want to use uart1 ?

if you use uart4 you can use the whole uart tx rx and rts. trying to
bitbang rts for rs485 on uart1 sounds hard

I can’t use RTS/CTS pins on UART4 because I need HDMI.
New RS485 patches suppose to help to use any gpio as RS485 RTS and in fact any gpio for any UART as RTS/CTS.

cat /proc/tty/driver/serial

serinfo:1.0 driver revision:
0: uart:8250 mmio:0x44E09000 irq:158 tx:2451 rx:0 RTS|CTS|DTR|DSR
1: uart:8250 mmio:0x48022000 irq:159 tx:24 rx:0 CTS|DSR|CD|RI
2: uart:8250 mmio:0x48024000 irq:160 tx:0 rx:0 CTS|DSR
3: uart:unknown port:00000000 irq:0
4: uart:8250 mmio:0x481A8000 irq:161 tx:2 rx:1 brk:1 CTS|DSR
5: uart:unknown port:00000000 irq:0

cat /proc/tty/driver/serial

serinfo:1.0 driver revision:
0: uart:8250 mmio:0x44E09000 irq:158 tx:2451 rx:0 RTS|CTS|DTR|DSR
1: uart:8250 mmio:0x48022000 irq:159 tx:24 rx:0 CTS|DSR|CD|RI
2: uart:8250 mmio:0x48024000 irq:160 tx:0 rx:0 CTS|DSR
3: uart:unknown port:00000000 irq:0
4: uart:8250 mmio:0x481A8000 irq:161 tx:2 rx:1 brk:1 CTS|DSR

5: uart:unknown port:00000000 irq:0

What is this supposed to mean ? That says UART0 has RTS, CTS, etc, but they’re not connected to anything. So the CTS on UART1 means nothing. Because it’s connected to I2C-2, which I’m sure you would have all kinds of fun disabling I2C-2 . . .

Honestly I don’t know. I though this might be useful info :slight_smile:
Three is no problem to disable I2C-2, but I am using those pins for CAN0.
That is why I want to use custom gpio to drive RS485 DE which doesn’t work.

read this. disabling I2C2 is not as easy as using an overlay
if you are not using capes sure but IMHO is always best to leave the
default things enabled and just work with overlays

http://www.embedded-things.com/bbb/enable-canbus-on-the-beaglebone-black/

It is easy and already disabled.
My question is about RS485 and custom gpio to drive DE pin of RS485 chip.

Can you show me what this command show :

dmesg>grep ttyO*

I repeat only omap driver work for rs485

Hi Micka.
no ttyO, its 8250 driver.
shouldn’t 4.5 kernel work after these patches are applied or is it still too early?

-rw-r–r-- 1 root root 1440 Apr 21 12:26 0001-tty-serial-8250-fix-RS485-half-duplex-RX.patch
-rw-r–r-- 1 root root 8243 Apr 21 12:26 0002-tty-serial-8250-make-UART_MCR-register-access-consis.patch
-rw-r–r-- 1 root root 2743 Apr 21 12:26 0003-serial-mctrl_gpio-add-modem-control-read-routine.patch
-rw-r–r-- 1 root root 1347 Apr 21 12:26 0004-serial-mctrl_gpio-add-IRQ-locking.patch
-rw-r–r-- 1 root root 7924 Apr 21 12:26 0005-tty-serial-8250-use-mctrl_gpio-helpers.patch

the last one clearly states that use of any gpio as rts should be possible

I dont know about 8250, but omap work well. I’m more confident about omap handling the gpio than the driver 8250.

I’ve been using omap for rs485 since the driver 3.8 and I’ve nothing to complain about.

I will also switch to the driver 8250 when it will be ready ( a lot of test need to be done )

Micka,