Did you come right? Sorry, this account-email is not read frequently On Tue, Nov 21, 2017 at 5:25 PM Jeff Andich <[email protected]> wrote:
> 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]> 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 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/a62c44fd-9133-4057-bee1-53a127febdb5%40googlegroups.com > <https://groups.google.com/d/msgid/beagleboard/a62c44fd-9133-4057-bee1-53a127febdb5%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/CANPM5qV6zoP98AC5XTcNAm3txzMucZwgHD-xHUU_FCPFxmCOiA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
