RS485 support for BBB

[Taceant Omnes]

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?

[Robert Nelson]

On Fri, Feb 12, 2016 at 9:33 AM, Taceant Omnes <tac...@gmail.com> wrote:
> 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,

--
Robert Nelson
https://rcn-ee.com/

[arsi]

Hi,

Use MAX13487EESA+ It has an automatic direction control..

Arsi

---

[Taceant Omnes]

On 12 February 2016 at 16:04, arsi <ar...@chello.sk> wrote:
> Hi,
>
> Use MAX13487EESA+ It has an automatic direction control..

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.

[Taceant Omnes]

Thanks, Robert.

[Richard Krehbiel]

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.

[Richard Krehbiel]

(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...)

[Micka]

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 ^^

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Taceant Omnes]

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).

[Jan Kinkazu]

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

[evilwulfie]

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

--

For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/50692f39-69e3-4454-b8ba-ec03e4d86101%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Virus-free. www.avast.com

[Artur Festyn]

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.

You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/nMtRpdWSJu0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/571E7751.2020206%40gmail.com.

[Artur Festyn]

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

[William Hermans]

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 . . .

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CAAPjYCaM58KxhqX_s1DwsdJ7z2tdemEoCVHjZj0D780CpxQTug%40mail.gmail.com.

[Artur Festyn]

Honestly I don't know. I though this might be useful info :)

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CALHSORrEpSMUET0monBs3YB-qonsfYPzCjQex%3DZdhZ-KMskn%2BA%40mail.gmail.com.

[evilwulfie]

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/

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CAAPjYCawdcQZ1%2BOvszmEj0Zp4yPfS7qDfMfOn-R1OZZ1u29KmQ%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

Virus-free. www.avast.com

[Artur Festyn]

It is easy and already disabled.

My question is about RS485 and custom gpio to drive DE pin of RS485 chip.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/571E98A0.8090608%40gmail.com.

[Micka]

Can you show me what this command show : 

dmesg|grep ttyO*

I repeat only omap driver work for rs485

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CAAPjYCaFgpxq0Q7z65%3DU1Go7qMoP9%2BwN-YHq7C7VBYOTFV3C0A%40mail.gmail.com.

[Artur Festyn]

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

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CAF%2BMRtkTxXFNPH-NSpyvhtsi0NfPdnG4tbsXBbbe0DnX3sN5qg%40mail.gmail.com.

[Micka]

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,

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CAAPjYCZMq4bxGCnakRvU1ae9Mderaki%3DbuxYKCnbgjP1Sxia8g%40mail.gmail.com.

[Artur Festyn]

Thank you very much Micka.

I am not in rush, can play with 8250 if it works.

I assume my .dtb is wrong or some kernel option is not selected.

Let's wait for somebody who has got this working.

4.6 rc behaves the same. 

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CAF%2BMRt%3DYmja3vKCtcaMzMmr1Xo5ydNhtGG9kBQfXXGtt%3Dpr-fA%40mail.gmail.com.

[Peter Hurley]

On 04/25/2016 10:54 PM, Micka wrote:
> I repeat only omap driver work for rs485

RS485 support was added to the 8250 driver for 4.6

It does not support gpio RTS.
Some preliminary patches for gpio RTS support have been
submitted by not accepted.

[Robert Nelson]

On Tue, Apr 26, 2016 at 8:18 PM, Peter Hurley <pe...@hurleysoftware.com> wrote:

On 04/25/2016 10:54 PM, Micka wrote:
> I repeat only omap driver work for rs485

RS485 support was added to the 8250 driver for 4.6

and i've been evil, syncing's

/drivers/tty/serial/8250/

and parts of:

/drivers/tty/serial/

from mainline, back to our v4.4.x-ti & v4.5.x-bone kernel's. ;)

 

It does not support gpio RTS.
Some preliminary patches for gpio RTS support have been
submitted by not accepted.

I've been following that and including those too..  We did have one user who was successful, haven't heard much from him since he submitted the working overlay..  (so i'm assuming it's still working. ;) )

[Peter Hurley]

On 04/26/2016 06:26 PM, Robert Nelson wrote:

On Tue, Apr 26, 2016 at 8:18 PM, Peter Hurley <pe...@hurleysoftware.com> wrote:

On 04/25/2016 10:54 PM, Micka wrote:
> I repeat only omap driver work for rs485

RS485 support was added to the 8250 driver for 4.6

and i've been evil, syncing's

/drivers/tty/serial/8250/

and parts of:

/drivers/tty/serial/

from mainline, back to our v4.4.x-ti & v4.5.x-bone kernel's. ;)

Ah, ok, good to know.

It does not support gpio RTS.
Some preliminary patches for gpio RTS support have been
submitted by not accepted.

I've been following that and including those too..  We did have one user who was successful, haven't heard much from him since he submitted the working overlay..  (so i'm assuming it's still working. ;) )

Ok, but you should know there's zero chance of that last patch going into mainline in its current form because it breaks console on everything else.

[Robert Nelson]

Okay thanks!  I'll revert that last one and keep watching the serial mainline list for updates..

Regards,

[Artur Festyn]

So the answer is: not now, but soon?

--

For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/nMtRpdWSJu0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CAOCHtYh6Ox9-_kMwbQm2t05SKzWFQXQTp14Z1enRE9h8Mw0PtA%40mail.gmail.com.

[William Hermans]

Seems to me, the answer is: Not until you write your own driver.

You received this message because you are subscribed to the Google Groups "BeagleBoard" group.

To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CAAPjYCYxfmuPpG6-y1BQ%2BdXUtxc_72n7AWmh1KMA5PP%2Bq_9igg%40mail.gmail.com.

[Micka]

Or you go on the driver omap which work very well ! 

Micka,

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CALHSORq%3D5cgOsAy7mPxZU4JjE7gQQLiphktQTWRNVUHSnO3y7g%40mail.gmail.com.

[Artur Festyn]

:) Thanks Micka

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CAF%2BMRtme3T29Ny2ZuRyZ30EiR20KpNTMpMGgg6ZOCfK-Hns3MQ%40mail.gmail.com.

[Artur Festyn]

Hi all.

It looks like mctrl_gpio is added to 4.7-rc1.

Does it mean that compiled 4.7-rc4 kernel using bb-kernel will have this applied?

Kind Regards

[Artur Festyn]

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=e10abc629f38efd9b6936cf3612583cc846104d9

[Matthew Bezuidenhout]

Hi Micka,

Sorry for the necro-bump. I need to enable RTS on uart for rs485, and as far as I've read the only wat to do so is to use OMAP drivers as opposed to 8250. How do I go about disabling 8250 and enabling OMAP?

uname -r returns:

4.4.30-ti-r64

Thanks for your time.

[Matthew Bezuidenhout]

Dear Robert,

Sorry to necro bump the issue.

I'm trying to enable RTS for UART4 on the Beaglebone Black, where uname -r informs me that I'm running 4.4.30-ti-r64.

I build the dtbo correctly from UART4-RS485-00A0.dts. After correctly implementing the dtb (echo BB-UART4-RS485 > /sys/devices/platform/bone_capemgr/slots, as well as attempting to enable through /boot/uEnv.txt), the RTS functionality is still not enabled:
cat /proc/tty/driver/serial:
0: uart:8250 mmio:0x44E09000 irq:158 tx:407 rx:0 RTS|CTS|DTR|DSR
1: uart:unknown port:00000000 irq:0
2: uart:unknown port:00000000 irq:0

3: uart:unknown port:00000000 irq:0

4: uart:8250 mmio:0x481A8000 irq:184 tx:0 rx:0 CTS|DSR

5: uart:unknown port:00000000 irq:0

 showing the RTS for UART4 is not enabled.

Furthermore, cat /sys/devices/platform/bone_capemgr/slots:
 0: PF----  -1
 1: PF----  -1
 2: PF----  -1
 3: PF----  -1
 4: P-O-L-   0 Override Board Name,00A0,Override Manuf,BB-UART4-RS485

Showing that the overlay is functioning. The UART itself is fully functional, but the RTS pin P9_27 (or any one that I change it to) is unaffected by UART transmissions of any kind through UART4 (/dev/ttyO4), as checked with an oscilliscope.

After researching for a fair amount of time, I haven't seen an update relevant to this thread concerning the 8250 drivers vs the OMAP drivers for RTS not working, and as of yet have no idea if there has been a recent patch, or if I should revert to disabling 8250 and enabling OMAP. If this is the case, could you please provide some insight into how this is done on the recent kernel 4.4.30? And if a later kernel is available that includes the correct patches, could you please enlighten me as to how to get that to work, as you seem to be the most informed person concerning all things Beaglebone.

Any of your guidance would be greatly appreciated.

Kindest regards,
Matthew Bezuidenhout

[bmel...@gmail.com]

Hello,

I would like to get RS485 to work on my BBB which has kernel 3.8.13-bone79. The steps are not clear to me especially since I have little experience with embedded linux.  I hit a wall when trying to load a modified version of Robert Nelson's BB-UART4-RS485--00A00 overlay. I noticed that if I commented out any variables that have reference RS485 (e.g. rts-gpio, rs485-rts-delay etc) the overlay loads fine.

How should I proceed? Am I supposed to apply a patch to omap-serial.c which I can not even find on my BBB?

Please help!

Bolek

--

[erc...@gmail.com]

Hi Micka,

We are having lots of trouble with RS485 with Kernel 4.4.x or kernel 3.8.13.

Is there any guideline about how to use OMAP rather than 8250 or can you please explain the steps how can we do that?

[Jeff Andich]

Hi,

There have been a number of posts on here on how to switch between the 8250 and OMAP drivers.  Above in this same thread, Robert showed which defines within the kernel defconfig file to change, and I experimented with this and was able to see and use /dev/ttyO* instead of /dev/ttyS*.  I had to search for and swtich additional defines, as initially, I ended-up losing my console and still had /dev/ttyS*..  If you look through the following post, you can see how I switched from the 8250 to the OMAP driver.   Someone else on here proposed a way to have a mixture of OMAP and 8250 serial drivers, but I haven't been brave enough to try that yet.

https://groups.google.com/forum/#!topic/beagleboard/JGIm0Ej6jDI

I never attempted to get full-blown hardware flow control up and running, since our hardware board has RS485 chips which only have the DE pin connected.  RTS and CTS lines don't interconnect the different parties on the MODBUS network in our case, only the RS485 differential signals (e.g. TXp, TXn).  

Initially we connected GPIO lines to the DE pins, but then more recently, our hardware engineer swapped out GPIO lines for the  "dedicated RTS" line for a given UART.  

One thing that's really interesting, IMO, is if you use a dedicated RTS line (e.g. UART5 RTSn), you can still toggle RTS from the application layer **using the 8250 driver**.  Whereas when I attempted to use  a GPIO line and couple that to the UART through the UART device tree fragment (refer to the above thread for an example), I was not able to toggle the RTS line with the 8250 serial driver, but only the OMAP serial driver.  So as a test I installed python-serial on my beagleBoard-X15.  When I issued serial_object.setRTS(False/True) which was connected to DE on the 485 chip, I would see the chip transmit and not transmit using the 8250 driver.  But when using the GPIO line for RTS, I could only switch between transmit and receive on the 485 chip when I compiled in and used the OMAP drivers.

To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/beagleboard/CAAPjYCaM58KxhqX_s1DwsdJ7z2tdemEoCVHjZj0D780CpxQTug%40mail.gmail.com?utm_medium=email&utm_source=footer" target="_blank" rel="nofollow" onmousedown="this.href='https://groups.google.com/d/msgid/beagleboard/CAAPjYCaM58KxhqX_s1DwsdJ7z2tdemEoCVHjZj0D780CpxQTug%4

[Jeff Andich]

p.s. - I'm currently running a patched version of kernel version 4.4.110... for the BB-X15, but I believe the underlying principles are the same between the BBB and BB-X15 with respect to UART (except for the pinmux which is more straight forward to configure in BBB world).

To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/beagleboard/CAAPjYCaM58KxhqX_s1DwsdJ7z2tdemEoCVHjZj0D780CpxQTug%40mail.gmail.com?utm_medium=email&utm_source=footer" target="_blank" rel="nofollow" onmousedown="this.href='<a href="https://groups.google.com/d/msgid/beagleboard/CAAPjYCaM58KxhqX_s1DwsdJ7z2td

[Jeff Andich]

Hi there.  Got your PM..

Regarding the defconfig changes to enable the OMAP.

I THINK your prescribed changes to the defconfig file are correct, just please refer to the above thread, https://groups.google.com/forum/#!topic/beagleboard/JGIm0Ej6jDI.

You're going to need to tune the defconfig, and the re-build and deploy the kernel until you see /dev/ttyO*.  And then you'll need to check that the serial device of interest is enabled.  You can go into /sys/class/tty/ttyO* directory and start looking at things like irq #'s to make sure they're non-0.  Not sure how this changes if DMA is enabled.

 

One interesting thing.  If you want to enable UARTs (beyond #6), I found that with the OMAP driver, all you need to do is enable it in the device tree fragement.  But with the 8250 driver, you need to change another defconfig define to increase the total # of UARTs..

Regarding updating/building the kernel on the BBB (?? /opt/scripts/tools/update_kernel.sh??), I'm afraid I still haven't done this or used Robert's image Builder on target.  I hope to get some practice with that next-week.  Then I can hopefully speak more intelligently on that.

To build/re-build the kernel, I follow the instructions on how to fetch and build the kernel, here, https://eewiki.net/display/linuxonarm/BeagleBoard-X15.

And then, inintially I call root_kernel_build_dir/build_kernel.sh, 

allow makemenuconfig to run.

Set the defconfig options I need.

Then every subsequent build, I think you can call root_kernel_build_dir/tools/rebuild.sh which will leave your defconfig/.config file in tact.  

I promise I won't tell anyone if you modify, KERNEL/.config directly, but I think this is not the recommended procedure.

Regarding and updated OS for 485, I'm not aware of any.  If you compile in the OMAP serial driver, then the driver has a 485 interface, so you can add lines to the respective UART's fragment such as the following and the referenced gpio line in the fragement below will toggle when you do setRTS(True/False) in python-serial.  

This won't work with the 8250 serial driver.  However, what will work with the 8250 driver is if you allocate a dedicated uart5_rtsn line and then tie that to your DE input on a 485 chip, you will be able to call setRTS(True/False) from Python (and I assume C/C++/C#), and the line will actually change state.  But I don't think the 8250 driver will handle the automatic flow control with intercharacter timeouts needed for full hardware flow control.  I haven't tried this.

Also another question you need to ask is for 485, are you using 2-wire or 4-wire RS485 chips.  If 4-wire, then, depending on your application, you maybe able to tie the DE signal high and allow the 485 chip to operate in full-duplex mode.  If 2 wire, then presumably, someone will need to toggle the DE line to multiplex internally the BBB UART's Rxd vs Txd onto the differential signal end of the 485 chip.  For our purposes, since our application knows when its transmitting vs receiving, the application can toggle the RTS line around transmit and receive sentences/packets.

Another thing I don't yet know.  Say that your application program refuses to add toggling of the RTS line between transmit and receive packets and s/he wants you to handle this at the driver level (which is understandable given application software portability requirements).  What all do you need to implement for the OMAP serial driver and the UART to handle automatic toggling of the RTS line so that the driver "senses" when the transmitter is done transmitting and can then toggle RTS/CTS to allow the other party to speak on the half-duplex line?  Do you need to wire up DE to UARTn_RTS and DE_INV to UARTn_CTS or can you leave CTS floating (or tie it to a known state if your mux mode permits)?  If someone has tried this (granted hardware flow control is probably an anachronism), please chime in.  But the test data probably exists somewhere in this thread or a related thread on this forum.

 

&uart5 {

        pinctrl-names = "default";

        pinctrl-0 = <&uart5_pins>;

        status = "okay";

        rts-gpio = <&gpio5 8 GPIO_ACTIVE_HIGH>;

        rs485-rts-active-high;

        rs485-rts-delay = <0 0>;

        linux,rs485-enabled-at-boot-time;

};

To view this discussion on the web visit <a href="<a href="https://groups.google.com/d/msgid/beagleboard/CAAPjYCaM58KxhqX_s1DwsdJ7z2tdemEoCVHjZj0D780CpxQTug%40mail.gmail.com?utm_medium=email&utm_source=footer" rel="nofollow" target="_blank" onmousedown="this.href='https://groups.google.com/d/msgid/beagleboard/CAAPjYCaM58KxhqX_s1D

[Jeff Andich]

Note: For our custom hardware board based on the BB-X15, we ran into a potential timing issue with a C# application running in mon-runtime  handling toggling of the RTS line around sending and receiving packets, so we re-tried getting the OMAP serial driver to auto-toggle the RTS line.

We're running kernel 4.4.110-ti-r142. 

Initially the results look  promising when we transmit 10 characters at 9600 baud on the Oscilloscope, displaying 485_'+', 485_'-' and the signal for RTS. But I HOPE to post up more detailed results under BB-X15 once we get further along.

The one caveat is , from looking at the OMAP serial driver code, it LOOKS like you have to use a GPIO line for RS485 mode for the driver to automatically toggle the RTS line around transmitting a character out the respective serial port.  It doesn't LOOK like the version of the driver for the above uname -r supports auto toggling of UARTn_RTSn lines.  Wonder if this is due to the nature of RTS/CTS vs RS485??

Thus far, I've only been able to get the GPIO case to work. The neat thing is about the TI PINMUX, it appears like many of the pads on the Sitara 5728 that have 'UART' in the name for MUXMODE0, the RTS line can easily be swapped out for a GPIO pin.  But in our case, only 2 of our UARTs have this, and the rest have higher MUXMODES so the GPIO cannot be swapped out for RTS.  We may need to look further into this and MAY wish to hack the OMAP 

When I get further along with my testing, I HOPE to generate a new post under the BB-X15 which re-packages everything I did to get these results (including what options were configured in the kernel '.config' file and upload some scope shots that show transmit and receive on a 2-wire RS485 'bus.'

Here are some excerpts from our device tree for UART1:

        uart1_pins: pinmux_uart1_pins {

                pinctrl-single,pins = <

                        DRA7XX_CORE_IOPAD(0x37E0, (PIN_INPUT            | SLEWCONTROL| MUX_MODE0)) /* uart1_rxd.uart1_rxd */

                        DRA7XX_CORE_IOPAD(0x37E4, (PIN_OUTPUT           | SLEWCONTROL| MUX_MODE0))       /* uart1_txd.uart1_txd */

                        DRA7XX_CORE_IOPAD(0x37E8, (PIN_INPUT_PULLDOWN   | MUX_MODE14)) */ /* uart1_ctsn.gpio7_24 */

                        DRA7XX_CORE_IOPAD(0x37EC, (PIN_OUTPUT           | MUX_MODE14))  /* uart1_rtsn.gpio7_25 */

                >;

        };

.

.

.

&uart1 {

        pinctrl-names = "default";

        pinctrl-0 = <&uart1_pins>;

        status = "okay";

        rts-gpio = <&gpio7 25 GPIO_ACTIVE_HIGH>;

        rs485-rts-active-high;

        rs485-rts-delay = <0 0>;

        linux,rs485-enabled-at-boot-time;

};

Note 1: The driver appears to support the 2 configurable RTS delays with down to 1ms resolution.  For MODBUS timing, requiring 3.5 character time delay in the protocol between transmitting parties, the 1ms resolution won't be granular enough at all baudrates.  Going to try setting these delays to 0,0 

Note: Temporarily experimenting with changing the pinmux in the device tree as opposed to u-boot-spl, and am aware of the glitch errata.  When we're done testing, we'll update our pad configuration arrays in u-boot to keep the 5728 pinmux glitch monster at bay...

To unsubscribe from this topic, visit <a href="https://groups.google.com/d/topic/beagleboard/nMtRpdWSJu0/unsubscribe" rel="nofollow" target="_bla