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.
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.
> 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. )
Regards,
Ah, ok, good to know. 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.
Okay thanks! I'll revert that last one and keep watching the serial
mainline list for updates..
Regards,
So the answer is: not now, but soon?
Seems to me, the answer is: Not until you write your own driver.
Or you go on the driver omap which work very well !
Micka,
Thanks Micka
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
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.
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
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
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?
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.
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).
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;
};
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…