Thank you! ?? Are you saying that lib modbus (which we haven't tried) has issues with reliably toggling the RTS line??
One clarification with what I meant by "manual toggling of the RTS line." By manual software toggling, we specifically mean toggling the RTS line in the protocol as follows: 1) Set RTS line high to switch 485 chip to allow us to transmit to the other party on the 2-wire, half-duplex, 485 interface. 2) Transmit out the multi-byte MODBUS register request to the other party. 3) Set the RTS line low to switch the 485 chip to allow the other party to transmit to us on the 2-wire interface. 4) The other party replies to us with a multi-byte packet consisting of the MODBUS register(s) we're requesting. We're not talking about toggling the RTS line around individual characters in the multi-byte messages. That's something the driver would have to handle (and I understand that the OMAP driver does handle this toggling). I wouldn't THINK application software would be fast enough to toggle RTS lines at the character rate, especially at higher baud rates. One question: If the 8250 driver utilizes a DMA buffer by default, how is the driver then able to toggle RTS/CTS lines in real time at the character rate? Seems like the driver would still have to monitor data directly coming in from or going out of the UART which would defeat the purpose of the DMA, right?? It seems like you or the driver would have to switch off the DMA if hardware flow control is used Hmmm, does this seem like a task for the PRU?? On Tuesday, November 21, 2017 at 6:48:35 AM UTC-6, Rnd Mpt wrote: > 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] > <javascript:>> 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] <javascript:>. >> 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/a62c44fd-9133-4057-bee1-53a127febdb5%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
