sorry. I saw the question about Waveshare RS485 / CAN Cape (and I did not read the question carefully) and because it was wrong made I decided to share.
br harry On Saturday, April 20, 2019 at 11:13:49 PM UTC+3, Rnd Mpt wrote: > > Yes, Dont solder Rx-serial to Rx-CAN-bus. The email/posts above are > concerning the RTS pin and allocating another BeagleBone to it: the DMA one > and not GPIO one > > On Thu, Apr 18, 2019 at 6:46 PM <[email protected] <javascript:>> wrote: > >> Hello >> may be there is wrong hardware design with Waveshare RS485/CAN Cape. I >> don't think is good idea to connect RS485 driver RX pin to CAN driver TX >> pin. if you desolder can driver rs485 should work fine. >> >> br >> harry >> >> On Tuesday, March 28, 2017 at 3:52:07 PM UTC+3, Matthew Bezuidenhout >> wrote: >>> >>> Hi all, >>> >>> For days now, I've been attempting to get the Waveshare RS485/CAN Cape >>> to work on Beaglebone black. >>> >>> I've used kernels 4.4.x and 4.9.x-ti mainline, and encountered the same >>> problem. >>> >>> The cape can use any UART (have been trying with one), and requires the >>> use of pin P9_42 (0x164) as an RTS pin. >>> >>> The dtbo (standard from https://github.com/beagleboard/bb.org-overlays >>> which uses pin P9_27) loads fine using >>> >>> echo BB-UART4-RS485 > /sys/devices/platform/bone_capemgr/slots >>> >>> A "cat /sys/devices/platform/bone_capemgr" reveals the slot has been >>> loaded correctly. >>> >>> The HDMI has successfully been disabled. >>> >>> Three problems arise: >>> >>> PROBLEM 1: >>> The wavheshare cape requires the pulldown of both UART pins (I used >>> UART4), as it leaves the pins floating through the RS485 transceiver if >>> left standard. Now, the tricky thing is, if I enable BB-UARt4-RS485 in the >>> /boot/uEnv.txt file, it loads the cape fine, but will not do pulldowns. If >>> I allow the beaglebone to boot, then echo the BB-UART.... at slots, the >>> pulldown works and the transceiver can send a signal through, which is >>> curious as it is exactly the same dtbo it loads, whether from uEnv.txt or >>> echo. >>> >>> PROBLEM 2: >>> Once loaded using echo after start, if I "cat /proc/tty/driver/serial" >>> immediately after loading UART RS485 overlay, the flags I'm presented with >>> are as below: >>> >>> 0: uart:8250 mmio:0x44E09000 irq:158 tx:8304 rx:0 RTS|CTS|DTR|DSR >>> 1: uart:unknown port:00000000 irq:0 >>> 2: uart:unknown port:00000000 irq:0 >>> 3: uart:unknown port:00000000 irq:0 >>> 4: uart:8250 mmio:0x481A8000 irq:198 tx:0 rx:0 CTS|DSR >>> 5: uart:unknown port:00000000 irq:0 >>> >>> >>> Showing UART4 (the one I'm using) has not loaded the CTS and RTS flags >>> appropriately. However, if, before performing the cat, I screen into ttyS4 >>> or ttyO4 or echo some characters at the port, and then I perform the "cat" >>> as above, the RTS and DTR flags are both raised on 4. Thereafter, if I >>> screen in on ttyO4, and then quit, the RTS flag disappears after a cat. >>> Weird. >>> >>> However, regardless of these results, I'm left with the following main >>> problem, >>> >>> PROBLEM 3: >>> Regardless of the flag position or whether I use the default >>> BB-UART4-RS485-00A0.dtbo from the source, the RTS pin does not switch (both >>> P9_27 and P9_42 are unresponsive to any efforts to communicate on the >>> UART4, where the UART transmits as evidenced by the oscilliscope, but the >>> oscilliscope shows that the RTS pin P9_42/27 does not move at all). I need >>> to get pin 9_42 to switch for RTS during uart, else this cape (and the >>> beaglebone) are useless to me. >>> >>> After copious amounts of time reading up on this, it seems that its a >>> common problem, and something to do with the OMAP serial driver vs the 8250 >>> driver malfunctioning? If someone could provide some insight to the >>> problem, or a guide on how to get RTS working on this Beaglebone I'd be >>> very appreciative. >>> >>> Kind regards, >>> Matt. >>> >>> >>> -- >> 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/0ef1a012-13ed-4a33-9443-6b0cbefc322a%40googlegroups.com >> >> <https://groups.google.com/d/msgid/beagleboard/0ef1a012-13ed-4a33-9443-6b0cbefc322a%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/f73b3eea-c0c3-4df9-be6e-58ec1200861d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
