Hi, With RS485-modbus-converters the timing of the RTS pin is CRUCIAL. Software toggling (GPIO toggling) of this pin (in the RS485/libmodbus library someone added this capability) have shown (on oscilloscope) to not be repeatable or works 1 in 30 attempts. I think we used the stock standard bone-debian-8.7-lxqt-4gb-armhf-2017-03-19-4gb.img and the RS485 branch of libmodbus library. And hardware toggling of RTS pin with dedicated RTS pin.
I think if you check the stock standard image name i provided it will answer your questions: I believe OMAP is not loaded from some version onwards On Mon, Nov 20, 2017 at 9:39 PM Jeff Andich <[email protected]> wrote: > A couple of things you may want to investigate before you use the OMAP > driver vs. the 8250: > > > 1) According to an older Wiki from TI, the OMAP serial driver doesn't use > DMA in serial transfer, but 8250 does. Not sure if this is still the case?? > > > http://processors.wiki.ti.com/index.php/Sitara_Linux_UART_-_Switching_to_8250_Driver#Overview > > > 2) For this experiment, we coupled an unrelated GPIO signal (for the RTS > signal) with a given UART through the device tree and found that Python can > only toggle the RTS line when connected to an OMAP driver as opposed to > 8250 driver. Note: We didn't try picking a pinmux/IOSET which already has > an RTS/CTS signal defined for a given UART. The 8250 driver might allow > that use case to work.... Will let you know what we find out.. > > > Thanks! > > Jeff > > > On Thursday, November 16, 2017 at 5:19:25 PM UTC-6, Jeff Andich wrote: >> >> I'm fairly confident the answer to my question about whether the 8250 >> driver implements "partial 485 capability", (allowing Python or a C#/.net >> application to manually control the RTS line for a given UART via the >> driver) is NO. But the OMAP driver DOES appear to allow this. >> >> When I toggle the serial driver defines in kernel 4.4.y's defconfig file >> ( see below), re-build the kernel, and deploy to my target (along with the >> device tree which couples a given GPIO on my custom board to UART5) I'm >> only able to toggle the RTS line from within Python (to enable/disable the >> 485 chip's transmit) when I open the /dev/ttyO4 device in Python, but not >> with the /dev/ttyS4 device. >> >> Additionally, the device tree containing the fragment below appears to be >> successfully coupling gpio5_8 and UART5, so this appears to be a driver >> issue rather than a device tree user error issue. >> >> >> I built the RCN 4.4.y kernel both ways: >> >> In paches/defconfig: >> >> (1) {CONFIG_SERIAL_8250_OMAP=n, CONFIG_SERIAL_OMAP=y} >> (2) {CONFIG_SERIAL_8250_OMAP=y, CONFIG_SERIAL_OMAP=n} >> >> *** Also worth noting is I lost my serial console until I enabled, >> CONFIG_SERIAL_OMAP_CONSOLE=y *** >> >> Ironically enough, my current build (built using configuration (1) above) >> appears to have BOTH the OMAP and 8250 devices which isn't what I would >> expect.. I've only tried writing to /dev/ttyO4 at this point. There maybe >> some other defines which need to be changed in the defconfig to switch off >> the 8250, named serial device files in the /dev/ directory. Film at 11 on >> that one.. >> >> >> ****************** >> Listing of serial devices with kernel 4.4.y built with configuration (1) >> ****************** >> >> debian@BeagleBoard-X15:~$ ls -l /dev/ttyO* >> crw-rw---- 1 root dialout 248, 0 Nov 16 19:28 /dev/ttyO0 >> crw------- 1 debian tty 248, 2 Nov 16 19:28 /dev/ttyO2 >> crw-rw---- 1 root dialout 248, 4 Nov 16 19:28 /dev/ttyO4 >> crw-rw---- 1 root dialout 248, 7 Nov 16 19:28 /dev/ttyO7 >> >> debian@BeagleBoard-X15:~$ ls -l /dev/ttyS* >> crw-rw---- 1 root dialout 4, 64 Nov 16 19:28 /dev/ttyS0 >> crw-rw---- 1 root dialout 4, 65 Nov 16 19:28 /dev/ttyS1 >> crw-rw---- 1 root dialout 4, 66 Nov 16 19:28 /dev/ttyS2 >> crw-rw---- 1 root dialout 4, 67 Nov 16 19:28 /dev/ttyS3 >> crw-rw---- 1 root dialout 4, 68 Nov 16 19:28 /dev/ttyS4 >> crw-rw---- 1 root dialout 4, 69 Nov 16 19:28 /dev/ttyS5 >> >> >> ***************** >> Python snippet and brief description of test results >> ***************** >> ser = serial.Serial('/devlttyO4') >> ser.ctsrts = False >> ser.write(b'I wish the BeagleBone folks would produce a pocket Beagle >> with an am5728') >> >> I see Tx data from my 2 wire 485 chip on the scope. >> >> ser.ctsrts = True >> I see nothing from my 2 wire 485 chip on the scope. >> >> >> *************** >> Build Configuration >> *************** >> Started from the console build for BB-X15 with debian 8.9 on elinux >> Robert referred me to a few weeks ago. >> Followed the instructions on eewiki for rebuilding BB-X15 kernel, but >> checked out branch origin/4.4.y, and built kernel using build_kernel.sh. >> >> debian@BeagleBoard-X15:~$ uname -r >> 4.4.83-ti-r119 >> debian@BeagleBoard-X15:~$ cat /etc/dogtag >> BeagleBoard.org Debian Image 2017-10-02 >> debian@BeagleBoard-X15:~$ >> >> Regards and thanks! >> >> Jeff >> >> >> On Tuesday, November 14, 2017 at 6:44:22 PM UTC-6, Jeff Andich wrote: >>> >>> Hi, >>> >>> Will the 8250 driver still allow "manual" control of the RTS line for a >>> given UART from an application like Python or C# (where the application >>> toggles the state of the RTS line, rather than driver, after sending a >>> request message in order to toggle the 485 XCVR), or is the OMAP driver (in >>> place of the 8250 driver) needed for this as well? >>> >>> I've attempted to associate the RTS line for UART5 with GPIO5_8 (which >>> is connected to the DE toggle on a 485 chip) via the device tree (kernel >>> 4.4.y), followed by calling setRTS(True/False) from Python, but that >>> doesn't appear to be switching the 485 XCVR. However, I can still use >>> sysfs commands to toggle the GPIO5_8 connected to the 485 chip to control >>> the direction of transmission. >>> >>> In order to help differentiate between an incorrect device tree >>> configuration vs. needing to recompile the kernel with the OMAP driver >>> instead of the 8250 driver, I'm wondering if you know whether the 8250 >>> driver will support what we're trying here. Everything I've read (including >>> https://groups.google.com/forum/#!msg/beagleboard/nMtRpdWSJu0/EDSXqGpiBAAJ) >>> seems to suggest that the 8250 doesn't yet handle toggling the RTS/CTS >>> lines on its own based on delays between characters, but I haven't seen >>> anything about manual control. >>> >>> >>> Following is a snippet/fragment from my device tree. ***LATE >>> DISCLOSURE*** From UART5_8, you can see that this is for the BB-X15, but I >>> believe the same issue pertains to both the BBB and the BB-X15: >>> >>> &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; >>> }; >>> >>> Thanks!!! >>> >>> On Monday, November 13, 2017 at 3:04:51 PM UTC-6, Rnd Mpt wrote: >>>> >>>> We used the rs485 version/branch of the modbus on github. Sorry i meant >>>> to say rts instead of cts. >>>> >>>> I used my github as notes. Follow readmes and see if it helps. Its been >>>> a while since we did this. Let me know if more help is needed >>>> >>>> https://github.com/rwdutoit/beaglebone?files=1 >>>> >>>> On Mon, 13 Nov 2017, 16:33 , <[email protected]> wrote: >>>> >>>>> https://github.com/RobertCNelson/bb-kernel/issues/38 >>>>> >>>>> >>>>> 2017. november 10., péntek 20:33:49 UTC+1 időpontban >>>>> [email protected] a következőt írta: >>>>> >>>>>> Did you ever get this to work >>>>>> >>>>>> I am using the Nelson yakbuild kernel 4.9.45 and disabled the 8250 >>>>>> and enabled omap serial in kernel configuration >>>>>> >>>>>> using same rs485 dtso overkay I can not get RTS to work >>>>>> and nothing transmits. >>>>>> >>>>>> I can not find anything on web to solve this. >>>>>> Do you have a solution procedure? >>>>>> >>>>>> >>>>>> dennis >>>>>> >>>>> [email protected] >>>>> >>>>> -- >>>>> 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/JGIm0Ej6jDI/unsubscribe. >>>>> To unsubscribe from this group and all its topics, send an email to >>>>> [email protected]. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/d/msgid/beagleboard/702f3cd1-c887-4003-9993-aa70998a5b1a%40googlegroups.com >>>>> <https://groups.google.com/d/msgid/beagleboard/702f3cd1-c887-4003-9993-aa70998a5b1a%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> -- > 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/JGIm0Ej6jDI/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/beagleboard/0112ef50-5fae-4e13-844f-01866d28ea1a%40googlegroups.com > <https://groups.google.com/d/msgid/beagleboard/0112ef50-5fae-4e13-844f-01866d28ea1a%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CANPM5qWOey2gZjNb%2BcubfWc%3DbOb3Zny_%2BV%2Bmt5tFkxw5wwGM4Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
