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 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/3f06372a-8fbb-42d2-840c-d2ca485c6954%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
