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;
};

On Tuesday, March 6, 2018 at 8:12:41 AM UTC-6, Jeff Andich wrote:
>
> 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).
>
> On Monday, March 5, 2018 at 9:12:06 AM UTC-6, Jeff Andich wrote:
>>
>> 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.
>>
>> On Monday, March 5, 2018 at 7:12:50 AM UTC-6, erc...@gmail.com wrote:
>>>
>>> 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?
>>>
>>> On Tuesday, April 26, 2016 at 10:00:19 AM UTC+3, Micka wrote:
>>>>
>>>> I dont know about 8250, but omap work well. I'm more confident about 
>>>> omap handling the gpio than the driver 8250.
>>>>
>>>> I've been using omap for rs485 since the driver 3.8 and I've nothing to 
>>>> complain about. 
>>>>
>>>> I will also switch to the driver 8250 when it will be ready ( a lot of 
>>>> test need to be done )
>>>>
>>>>
>>>> Micka,
>>>>
>>>>
>>>>
>>>> Le mar. 26 avr. 2016 08:05, 'Artur Festyn' via BeagleBoard <
>>>> beagl...@googlegroups.com> a écrit :
>>>>
>>>>> Hi Micka.
>>>>> no ttyO, its 8250 driver.
>>>>> shouldn't 4.5 kernel work after these patches are applied or is it 
>>>>> still too early?
>>>>>
>>>>> -rw-r--r--  1 root root 1440 Apr 21 12:26 
>>>>> 0001-tty-serial-8250-fix-RS485-half-duplex-RX.patch
>>>>> -rw-r--r--  1 root root 8243 Apr 21 12:26 
>>>>> 0002-tty-serial-8250-make-UART_MCR-register-access-consis.patch
>>>>> -rw-r--r--  1 root root 2743 Apr 21 12:26 
>>>>> 0003-serial-mctrl_gpio-add-modem-control-read-routine.patch
>>>>> -rw-r--r--  1 root root 1347 Apr 21 12:26 
>>>>> 0004-serial-mctrl_gpio-add-IRQ-locking.patch
>>>>> -rw-r--r--  1 root root 7924 Apr 21 12:26 
>>>>> 0005-tty-serial-8250-use-mctrl_gpio-helpers.patch
>>>>>
>>>>> the last one clearly states that use of any gpio as rts should be 
>>>>> possible
>>>>>
>>>>>
>>>>> 2016-04-26 6:54 GMT+01:00 Micka <micka...@gmail.com>:
>>>>>
>>>>>> Can you show me what this command show : 
>>>>>>
>>>>>> dmesg|grep ttyO*
>>>>>>
>>>>>> I repeat only omap driver work for rs485
>>>>>>
>>>>>> Le mar. 26 avr. 2016 00:40, 'Artur Festyn' via BeagleBoard <
>>>>>> beagl...@googlegroups.com> a écrit :
>>>>>>
>>>>>>> It is easy and already disabled.
>>>>>>> My question is about RS485 and custom gpio to drive DE pin of RS485 
>>>>>>> chip.
>>>>>>>
>>>>>>>
>>>>>>> 2016-04-25 23:22 GMT+01:00 evilwulfie <evilw...@gmail.com>:
>>>>>>>
>>>>>>>> read this. disabling I2C2 is not as easy as using an overlay
>>>>>>>> if you are not using capes sure but IMHO is always best to leave 
>>>>>>>> the default things enabled and just work with overlays
>>>>>>>>
>>>>>>>>
>>>>>>>> http://www.embedded-things.com/bbb/enable-canbus-on-the-beaglebone-black/
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 4/25/2016 2:09 PM, 'Artur Festyn' via BeagleBoard wrote:
>>>>>>>>
>>>>>>>> Honestly I don't know. I though this might be useful info :) 
>>>>>>>> Three is no problem to disable I2C-2, but I am using those pins for 
>>>>>>>> CAN0.
>>>>>>>> That is why I want to use custom gpio to drive RS485 DE which 
>>>>>>>> doesn't work.
>>>>>>>>
>>>>>>>> 2016-04-25 21:56 GMT+01:00 William Hermans <yyr...@gmail.com>:
>>>>>>>>
>>>>>>>>> *cat /proc/tty/driver/serial*
>>>>>>>>>
>>>>>>>>> *serinfo:1.0 driver revision:*
>>>>>>>>> *0: uart:8250 mmio:0x44E09000 irq:158 tx:2451 rx:0 RTS|CTS|DTR|DSR*
>>>>>>>>> *1: uart:8250 mmio:0x48022000 irq:159 tx:24 rx:0 CTS|DSR|CD|RI*
>>>>>>>>> *2: uart:8250 mmio:0x48024000 irq:160 tx:0 rx:0 CTS|DSR*
>>>>>>>>> *3: uart:unknown port:00000000 irq:0*
>>>>>>>>> *4: uart:8250 mmio:0x481A8000 irq:161 tx:2 rx:1 brk:1 CTS|DSR*
>>>>>>>>>
>>>>>>>>> *5: uart:unknown port:00000000 irq:0*
>>>>>>>>>
>>>>>>>>> What is this supposed to mean ? That says UART0 has RTS, CTS, etc, 
>>>>>>>>> but they're not connected to anything. So the CTS on UART1 means 
>>>>>>>>> nothing. 
>>>>>>>>> Because it's connected to I2C-2, which I'm sure you would have all 
>>>>>>>>> kinds of 
>>>>>>>>> fun disabling I2C-2 . . .
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Mon, Apr 25, 2016 at 1:14 PM, 'Artur Festyn' via BeagleBoard <
>>>>>>>>> beagl...@googlegroups.com> wrote:
>>>>>>>>>
>>>>>>>>>> cat /proc/tty/driver/serial 
>>>>>>>>>> serinfo:1.0 driver revision:
>>>>>>>>>> 0: uart:8250 mmio:0x44E09000 irq:158 tx:2451 rx:0 RTS|CTS|DTR|DSR
>>>>>>>>>> *1: uart:8250 mmio:0x48022000 irq:159 tx:24 rx:0 CTS|DSR|CD|RI*
>>>>>>>>>> 2: uart:8250 mmio:0x48024000 irq:160 tx:0 rx:0 CTS|DSR
>>>>>>>>>> 3: uart:unknown port:00000000 irq:0
>>>>>>>>>> 4: uart:8250 mmio:0x481A8000 irq:161 tx:2 rx:1 brk:1 CTS|DSR
>>>>>>>>>> 5: uart:unknown port:00000000 irq:0
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 2016-04-25 21:12 GMT+01:00 Artur Festyn <fes...@googlemail.com>:
>>>>>>>>>>
>>>>>>>>>>> I can't use RTS/CTS pins on UART4 because I need HDMI. 
>>>>>>>>>>> New RS485 patches suppose to help to use any gpio as RS485 RTS 
>>>>>>>>>>> and in fact any gpio for any UART as RTS/CTS.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 2016-04-25 21:00 GMT+01:00 evilwulfie <evilw...@gmail.com>:
>>>>>>>>>>>
>>>>>>>>>>>> any reason you want to use uart1 ?
>>>>>>>>>>>>
>>>>>>>>>>>> if you use uart4 you can use the whole uart tx rx and rts. 
>>>>>>>>>>>> trying to bitbang rts for rs485 on uart1 sounds hard 
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On 4/25/2016 12:24 PM, 'Jan Kinkazu' via BeagleBoard wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> So i compiled (bb-kernel, all patches) and installed 
>>>>>>>>>>>> 4.5.2-bone4  
>>>>>>>>>>>> I have modified am335-boneblack.dts and compiled it.
>>>>>>>>>>>>
>>>>>>>>>>>> #include "am335x-peripheral-ttyS1.dtsi"
>>>>>>>>>>>> #include "am335x-bone-pinmux-ttyS1.dtsi"
>>>>>>>>>>>>
>>>>>>>>>>>> &am33xx_pinmux {
>>>>>>>>>>>>         uart1_pins: pinmux_uart1_pins {
>>>>>>>>>>>>                 pinctrl-single,pins = <
>>>>>>>>>>>>                         /* P9_23: uart1_de */
>>>>>>>>>>>>                         BONE_P9_23 (PIN_OUTPUT_PULLDOWN | 
>>>>>>>>>>>> MUX_MODE7)
>>>>>>>>>>>>                 >;
>>>>>>>>>>>>         };
>>>>>>>>>>>> };
>>>>>>>>>>>>
>>>>>>>>>>>> &uart1 {
>>>>>>>>>>>>         pinctrl-names = "default";
>>>>>>>>>>>>         pinctrl-0 = <&uart1_pins>;
>>>>>>>>>>>>         status = "okay";
>>>>>>>>>>>>         rts-gpios = <&gpio1 17 GPIO_ACTIVE_HIGH>;
>>>>>>>>>>>>         rs485-rts-active-high;
>>>>>>>>>>>>         rs485-rx-during-tx;
>>>>>>>>>>>>         rs485-rts-delay = <1 1>;
>>>>>>>>>>>>         linux,rs485-enabled-at-boot-time;
>>>>>>>>>>>> };
>>>>>>>>>>>>
>>>>>>>>>>>> RS485 doesn't work, what do I do wrong?
>>>>>>>>>>>>
>>>>>>>>>>>> Kind regards
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Friday, 12 February 2016 15:33:40 UTC, Taceant Omnes wrote: 
>>>>>>>>>>>>>
>>>>>>>>>>>>> I would like to use RS485 with the BBB. 
>>>>>>>>>>>>>
>>>>>>>>>>>>> root@beaglebone:~/test# uname -a 
>>>>>>>>>>>>> Linux beaglebone 4.1.15-ti-r40 #1 SMP PREEMPT Thu Jan 7 
>>>>>>>>>>>>> 23:32:17 UTC 
>>>>>>>>>>>>> 2016 armv7l GNU/Linux 
>>>>>>>>>>>>>
>>>>>>>>>>>>> I am using the kernel above. Its source code is at 
>>>>>>>>>>>>>
>>>>>>>>>>>>> <https://github.com/RobertCNelson/linux-stable-rcn-ee/tree/4.1.15-ti-rt-r40>
>>>>>>>>>>>>> https://github.com/RobertCNelson/linux-stable-rcn-ee/tree/4.1.15-ti-rt-r40
>>>>>>>>>>>>>  
>>>>>>>>>>>>>
>>>>>>>>>>>>> ... however it does not include the changes in this patch: 
>>>>>>>>>>>>>
>>>>>>>>>>>>> <https://github.com/RobertCNelson/bb-kernel/blob/am33x-v3.8/patches/fixes/0007-omap-RS485-support-by-Michael-Musset.patch#L30>
>>>>>>>>>>>>> https://github.com/RobertCNelson/bb-kernel/blob/am33x-v3.8/patches/fixes/0007-omap-RS485-support-by-Michael-Musset.patch#L30
>>>>>>>>>>>>>  
>>>>>>>>>>>>>
>>>>>>>>>>>>> Which kernel should I use that includes the changes in the 
>>>>>>>>>>>>> patch or 
>>>>>>>>>>>>> something similar? 
>>>>>>>>>>>>>
>>>>>>>>>>>> -- 
>>>>>>>>>>>> For more options, visit <http://beagleboard.org/discuss>
>>>>>>>>>>>> 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 beagleboard...@googlegroups.com.
>>>>>>>>>>>> To view this discussion on the web visit 
>>>>>>>>>>>> <https://groups.google.com/d/msgid/beagleboard/50692f39-69e3-4454-b8ba-ec03e4d86101%40googlegroups.com>
>>>>>>>>>>>> https://groups.google.com/d/msgid/beagleboard/50692f39-69e3-4454-b8ba-ec03e4d86101%40googlegroups.com
>>>>>>>>>>>> .
>>>>>>>>>>>> For more options, visit <https://groups.google.com/d/optout>
>>>>>>>>>>>> https://groups.google.com/d/optout.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=icon>
>>>>>>>>>>>>  Virus-free. 
>>>>>>>>>>>>
>>>>>>>>>>>> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=link>
>>>>>>>>>>>> www.avast.com 
>>>>>>>>>>>> -- 
>>>>>>>>>>>> For more options, visit <http://beagleboard.org/discuss>
>>>>>>>>>>>> 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/nMtRpdWSJu0/unsubscribe>
>>>>>>>>>>>> https://groups.google.com/d/topic/beagleboard/nMtRpdWSJu0/unsubscribe
>>>>>>>>>>>> .
>>>>>>>>>>>> To unsubscribe from this group and all its topics, send an 
>>>>>>>>>>>> email to beagleboard...@googlegroups.com.
>>>>>>>>>>>> To view this discussion on the web visit 
>>>>>>>>>>>> <https://groups.google.com/d/msgid/beagleboard/571E7751.2020206%40gmail.com?utm_medium=email&utm_source=footer>
>>>>>>>>>>>> https://groups.google.com/d/msgid/beagleboard/571E7751.2020206%40gmail.com.
>>>>>>>>>>>>  
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> For more options, visit <https://groups.google.com/d/optout>
>>>>>>>>>>>> https://groups.google.com/d/optout.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> -- 
>>>>>>>>>> For more options, visit <http://beagleboard.org/discuss>
>>>>>>>>>> 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 beagleboard...@googlegroups.com.
>>>>>>>>>> To view this discussion on the web visit <a href="<a href="
>>>>>>>>>> https://groups.google.com/d/msgid/beagleboard/CAAPjYCaM58KxhqX_s1DwsdJ7z2tdemEoCVHjZj0D780CpxQTug%40mail.gmail.com?utm_medium=email&utm_source=footer";
>>>>>>>>>>  
>>>>>>>>>> rel="nofollow" target="_blank" onmousedown="this.href='
>>>>>>>>>> https://groups.google.com/d/msgid/beagleboard/CAAPjYCaM58KxhqX_s1D
>>>>>>>>>
>>>>>>>>>

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/8c99df00-91d4-42a1-bbff-1f157c37a115%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to