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...
On Tuesday, March 6, 2018 at 10:42:37 AM UTC-6, Jeff Andich wrote:
>
> 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;
> };
>
> On Tuesday, March 6, 2018 at 8:12:41 AM UTC-6, Jeff Andich wrote:
>>
>> 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).
>>
>> On Monday, March 5, 2018 at 9:12:06 AM UTC-6, Jeff Andich wrote:
>>>
>>> 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.
>>>
>>> On Monday, March 5, 2018 at 7:12:50 AM UTC-6, erc...@gmail.com wrote:
>>>>
>>>> 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?
>>>>
>>>> On Tuesday, April 26, 2016 at 10:00:19 AM UTC+3, Micka wrote:
>>>>>
>>>>> 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,
>>>>>
>>>>>
>>>>>
>>>>> Le mar. 26 avr. 2016 08:05, 'Artur Festyn' via BeagleBoard <
>>>>> beagl...@googlegroups.com> a écrit :
>>>>>
>>>>>> 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
>>>>>>
>>>>>>
>>>>>> 2016-04-26 6:54 GMT+01:00 Micka <micka...@gmail.com>:
>>>>>>
>>>>>>> Can you show me what this command show :
>>>>>>>
>>>>>>> dmesg|grep ttyO*
>>>>>>>
>>>>>>> I repeat only omap driver work for rs485
>>>>>>>
>>>>>>> Le mar. 26 avr. 2016 00:40, 'Artur Festyn' via BeagleBoard <
>>>>>>> beagl...@googlegroups.com> a écrit :
>>>>>>>
>>>>>>>> It is easy and already disabled.
>>>>>>>> My question is about RS485 and custom gpio to drive DE pin of RS485
>>>>>>>> chip.
>>>>>>>>
>>>>>>>>
>>>>>>>> 2016-04-25 23:22 GMT+01:00 evilwulfie <evilw...@gmail.com>:
>>>>>>>>
>>>>>>>>> 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/
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 4/25/2016 2:09 PM, 'Artur Festyn' via BeagleBoard wrote:
>>>>>>>>>
>>>>>>>>> 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.
>>>>>>>>>
>>>>>>>>> 2016-04-25 21:56 GMT+01:00 William Hermans <yyr...@gmail.com>:
>>>>>>>>>
>>>>>>>>>> *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 . . .
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Mon, Apr 25, 2016 at 1:14 PM, 'Artur Festyn' via BeagleBoard <
>>>>>>>>>> beagl...@googlegroups.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> 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
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 2016-04-25 21:12 GMT+01:00 Artur Festyn <fes...@googlemail.com>:
>>>>>>>>>>>
>>>>>>>>>>>> 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.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> 2016-04-25 21:00 GMT+01:00 evilwulfie <evilw...@gmail.com>:
>>>>>>>>>>>>
>>>>>>>>>>>>> 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
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 4/25/2016 12:24 PM, 'Jan Kinkazu' via BeagleBoard wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> 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
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Friday, 12 February 2016 15:33:40 UTC, Taceant Omnes 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>
>>>>>>>>>>>>>> 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>
>>>>>>>>>>>>>> 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?
>>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> For more options, visit <http://beagleboard.org/discuss>
>>>>>>>>>>>>> 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>
>>>>>>>>>>>>> https://groups.google.com/d/msgid/beagleboard/50692f39-69e3-4454-b8ba-ec03e4d86101%40googlegroups.com
>>>>>>>>>>>>> .
>>>>>>>>>>>>> For more options, visit <https://groups.google.com/d/optout>
>>>>>>>>>>>>> https://groups.google.com/d/optout.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=icon>
>>>>>>>>>>>>> Virus-free.
>>>>>>>>>>>>>
>>>>>>>>>>>>> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=link>
>>>>>>>>>>>>> www.avast.com
>>>>>>>>>>>>> --
>>>>>>>>>>>>> For more options, visit <http://beagleboard.org/discuss>
>>>>>>>>>>>>> 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 <a href="
>>>>>>>>>>>>> https://groups.google.com/d/topic/beagleboard/nMtRpdWSJu0/unsubscribe";
>>>>>>>>>>>>>
>>>>>>>>>>>>> rel="nofollow" target="_bla
>>>>>>>>>>>>
>>>>>>>>>>>>
--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/beagleboard/28e7d730-ac39-4e38-9e1c-6eba42dd5c75%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
