cdsteinkuehler / beaglebone-universal-io

Device tree overlay and support scripts for using most available hardware I/O on the BeagleBone without editing dts files or rebuilding the kernel
GNU General Public License v2.0
127 stars 54 forks source link

change mode of dcan1_tx #25

Closed MartinVoelz closed 9 years ago

MartinVoelz commented 9 years ago

Hello, the mode of P9_26_can_pin is not correct, it must not have receive-mode and it would be nice to add config-pin support to the pins P9_19 and P9_20 in the cape-universal for custom capes that do not use cape-eeprom. I made some posts to this on https://eewiki.net/display/linuxonarm/BeagleBone+Black+Comments?focusedCommentId=41418755#comment-41418755

diff --git a/cape-universal-00A0.dts b/cape-universal-00A0.dts index 2c3fca7..9fbcd44 100644 --- a/cape-universal-00A0.dts +++ b/cape-universal-00A0.dts @@ -552,7 +552,7 @@ P9_24_uart_pin: pinmux_P9_24_uart_pin { pinctrl-single,pins = <0x184 0x30>; }; /* Mode 0, Pull-Up, RxActive */ P9_24_can_pin: pinmux_P9_24_can_pin {

cdsteinkuehler commented 9 years ago

Have you verified having the RxActive bit enabled causes problems with CAN? This bit does NOT control the direction of the I/O pin, it disables the pin's input buffer for minimal power consumption.

MartinVoelz commented 9 years ago

ok, you are right, it is also working with your setup 0x32 for both pins. Strange thing, I would have never come to the idea that RxActive means that Tx ist still possible.

cdsteinkuehler commented 9 years ago

I'm leaving things as-is for now, since the default for all pins in cape-universal is to leave the receiver active. This issue can be revisited if someone locates any sort of official recommendation from TI for pinmux settings for specific functions or if I ever test the theory that leaving the RxActive bit set lets the GPIO logic read the state of the pin when in special function modes.