am335x-boneblack-custom.dts am335x-boneblack-roboticscape.dts的副本 更改了模型以使新设备树可识别更改了 #include 使其指向 am335x-custom.dtsi ，而不是 am335x-roboticscape.dtsi am335x-custom.dtsi am335x-roboticscape.dtsi的副本 删除了我以为不再需要的一堆东西将P9_25(而不是P8_16)路由到PRU0 之前 /* PRU编码器输入*/0x03c 0x36/* P8_15，PRU0_r31_15，MODE6 */0x038 0x36/* P8_16，PRU0_r31_14，MODE6 */ 之后 /* PRU编码器输入*/0x03c 0x36/* P8_15，PRU0_r31_15，MODE6 */0x1ac 0x36/* P9_25，PRU0_r31_7，MODE6 */ 在编译并安装修改后的设备树( make ， sudo make install BeagleBoard-DeviceTrees 回购)，我修改了/boot/uEnv.txt 来调用新的自定义设备树 uname_r = 4.19.94-ti-r42dtb = am335x-boneblack-custom.dtbcmdline = coherent_pool = 1M 我能够在没有安装斗篷的情况下启动BeagleBone，将编码器直接插入所需的引脚在P8_和P9上运行(包括P9_25上的enc4a)，并使用 sudo rc_test_encoders 读取所有四个编码器.我以为我赢了就去睡觉... 摩托车斗篷无法启动经过一夜安眠后，我将Motor Cape插入了BeagleBone，期待自此以后一切都不会改变我只是将编码器信号直接通过P8和P9标头传递.我以为下一步是对一些pwm方向引脚进行类似的调整.但是，BeagleBone拒绝在安装了MotorCape的情况下引导我的自定义设备树.我回到标准" am335x-boneblack-roboticscape.dtb 设备树，并观察到它也无法启动安装了Motor Cape.我还怀疑工厂"的存在.机器人斗篷的安装可能有毕竟一直在使用叠加层从一开始，我就因为是否应该从Robotics Cape设备树中开始并删除而感到困惑为了消除资源冲突，我不需要做任何事情，而从裸"开始做起.BeagleBone设备树并添加我确实需要的东西.不管准确与否，在我看来，这种映射都映射为尝试指定完整的设备树，而不是提供覆盖以应用在基本设备树的顶部.后者似乎从概念上讲是更正确的路径，因此一旦Motor Cape无法使用源自机器人技术的设备树引导，我决定硬着头皮，尝试找出设备树的覆盖层.未回答的问题 []为什么在安装了电动机斗篷的情况下，BB无法从 am335x-boneblack-roboticscape.dtb 引导?实际错误是什么? []执行正常"操作吗?安装 librobotcontrol 或在上方安装简化的 uEnv.txt 还是使用覆盖?能行吗?我还没有USB-to-TTL串行电缆可以装在安装好的斗篷下，所以我对这件事了解得很少为什么或如何无法启动.最终工作的部分-设备树覆盖我最终发现设备树覆盖的集合在两个位置都是可用的 https://github.com/beagleboard/bb.org-overlays 并在 v4.19.x-ti-overlays 分支位于 https://github.com/beagleboard/BeagleBoard-DeviceTrees .我怀疑这可能是正在进行迁移，但是有更多与 bb.org-overlays 相关的文档存储库，这就是我选择使用的存储库.我希望早些时候可以找到一些文档链接: https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Overlays https://github.com/cdsteinkuehler/beaglebone-universal-io https://vadl.github.io/beagleboneblack/2016/07/29/setting-up-bbb-gpio 我创建了分叉的，克隆的和分支的 bb.org-overlays 存储库，并在通过将来自 BBORG_MOTOR-00A2.dts 和 RoboticsCape-00A0.dts 的片段合并在一起，从而 src/arm/CustomCape-00A0.dts /**设备树覆盖图，用于尝试重复使用机器人控制库的自定义斗篷*读取4倍光学编码器.*//*pinmux控制字节图由http://beaglebone.cameon.net/提供位5:1-输入，0-输出位4:1-向上拉，0-向下拉位3:1-禁止上拉，0-允许上拉位2位1 |-模式位0/*//dts-v1/;/插入/;/{兼容="ti，beaglebone-black"；/* 鉴别 */部件号="CustomCape"；/* 版本 */版本="00A0&";专用="P8.11"，/* QEP_2B */"P8.12"，/* QEP_2A */"P8.16"，/* PRU_ENCODER_A */"P8.33"，/* QEP_1B */"P8.35"，/* QEP_1A */"P9.27"，/* QEP_0B */"P9.41"，/* MOT_STBY */"P9.42"；/* QEP_0A *//**帮助程序可在以下位置显示已加载的叠加层:/proc/device-tree/chosen/overlays/*/片段@ 0 {target-path ="/"；__over____ {选择{重叠广告{CustomCape-00A0 = __TIMESTAMP__;};};};};片段@ 1 {target =<& am33xx_pinmux> ;;__over____ {/********************************************* Pinmux助手********************************************/mux_helper_pins:引脚{pinctrl-single，pins =</* EQEP */0x1A0 0x31/* P9_42，EQEP0A，MODE1 */0x1A4 0x31/* P9_27，EQEP0B，MODE1 */0x0D4 0x32/* P8_33，EQEP1B，MODE2 */0x0D0 0x32/* P8_35，EQEP1A，MODE2 */0x030 0x34/* P8_12，EQEP2A_in，MODE4 */0x034 0x34/* P8_11，EQEP2B_in，MODE4 *//* PRU编码器输入*/0x03c 0x36/* P8_15，PRU0_r31_15，MODE6 */0x1ac 0x36/* P9_25，PRU0_r31_7，MODE6 */> ;;};};};/********************************************Pinmux助手激活pinmux助手模式的针脚模式********************************************/片段@ 2 {target =<& ocp> ;;__over____ {test_helper:助手{兼容=骨-松木助剂"；pinctrl-names =默认"；pinctrl-0 =<& mux_helper_pins> ;;状态=确定"；};};};/**从针孔辅助器上松开斗篷使用的针脚.*/片段@ 3 {target =<& ocp> ;;__over____ {P8_11_pinmux {status ="disabled";};/* enc3b */P8_12_pinmux {status ="disabled";};/* enc3a */P8_15_pinmux {status ="disabled";};/* enc4b */P8_33_pinmux {status ="disabled";};/* enc0 */P8_35_pinmux {status ="disabled";};/* enc0 */P9_25_pinmux {status ="disabled";};/* enc4a */P9_27_pinmux {status ="disabled";};/* enc1b */P9_92_pinmux {status ="disabled";};/* enc1a */};};/********************************************编码器********************************************/片段@ 9 {目标=<& eqep0> ;;__over____ {count_mode =< 0> ;;/* 0-正交模式，正常90度相位偏移cha&chb.1-方向模式.通道输入=时钟，通道输入=方向*/swap_inputs =< 0> ;;/*通道A和通道B是否互换?(0-否，1-是)*/invert_qa =< 1> ;;/*我们应该反转通道A的输入吗?*/invert_qb =< 1> ;;/*我们应该反转通道B的输入吗?之所以将它们反转，是因为我的编码器输出的驱动晶体管会拉低引脚*/invert_qi =< 0> ;;/*我们应该反转索引输入吗?*/invert_qs =< 0> ;;/*我们应该反转选通输入吗?*/状态=确定"；};};片段@ 10 {target =<& eqep1> ;;__over____ {count_mode =< 0> ;;/* 0-正交模式，正常90度相位偏移cha&chb.1-方向模式.通道输入=时钟，通道输入=方向*/swap_inputs =< 0> ;;/*通道A和通道B是否互换?(0-否，1-是)*/invert_qa =< 1> ;;/*我们应该反转通道A的输入吗?*/invert_qb =< 1> ;;/*我们应该反转通道B的输入吗?之所以将它们反转，是因为我的编码器输出的驱动晶体管会拉低引脚*/invert_qi =< 0> ;;/*我们应该反转索引输入吗?*/invert_qs =< 0> ;;/*我们应该反转选通输入吗?*/状态=确定"；};};片段@ 11 {目标=<& eqep2> ;;__over____ {count_mode =< 0> ;;/* 0-正交模式，正常90度相位偏移cha&chb.1-方向模式.通道输入=时钟，通道输入=方向*/swap_inputs =< 0> ;;/*通道A和通道B是否互换?(0-否，1-是)*/invert_qa =< 1> ;;/*我们应该反转通道A的输入吗?*/invert_qb =< 1> ;;/*我们应该反转通道B的输入吗?之所以将它们反转，是因为我的编码器输出的驱动晶体管会拉低引脚*/invert_qi =< 0> ;;/*我们应该反转索引输入吗?*/invert_qs =< 0> ;;/*我们应该反转选通输入吗?*/状态=确定"；};};/********************************************保诚********************************************/片段@ 31 {target =<& pruss> ;;__over____ {状态=确定"；};};}; 我将自定义叠加层添加到/boot/uEnv.txt 中，并禁用了视频和音频叠加层 uname_r = 4.19.94-ti-r42#uuid =#dtb =### U-Boot覆盖######文档:http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Overlays### Master启用enable_uboot_overlays = 1######其他自定义披肩uboot_overlay_addr4 =/lib/firmware/CustomCape-00A0.dtbo######自定义披风#dtb_overlay =/lib/firmware/< file8> .dtbo######禁用自动加载虚拟斗篷(emmc/video/wireless/adc)#disable_uboot_overlay_emmc = 1disable_uboot_overlay_video = 1disable_uboot_overlay_audio = 1#disable_uboot_overlay_wireless = 1#disable_uboot_overlay_adc = 1###### PRUSS选项### pru_rproc(4.19.x-ti内核)uboot_overlay_pru =/lib/firmware/AM335X-PRU-RPROC-4-19-TI-00A0.dtbo###### Cape Universal Enableenable_uboot_cape_universal = 1###### U-Boot覆盖###cmdline = coherent_pool = 1M net.ifnames = 0 lpj = 1990656 rng_core.default_quality = 100安静 我不主张最佳性或正确性，但是无论是否装有Motor Cape，此配置都会启动安装后，我可以使用 rc_test_encoders 读取所有四个编码器.安装了Motor Cape后，uBoot正确地拾取并应用了 BBORG_MOTOR-00A2 叠加层.老实说，我还需要更多配置PRU以使机器人控制库中的基于PRU的编码器计数器工作，但这似乎做到这一点.我欢迎任何关于我应该如何做到这一点，或者如何改进目前的状况的反馈.有用的提示:观看串行终端！很尴尬的是，我什至没有先安装串行终端就尝试调试设备树启动问题打开长骨，这样我就可以观察启动顺序了.在大约5分钟的环氧树脂的帮助下，我最终能够制作一个90度接头，以将JTAG端口从已安装的斗篷下拔出. https://elinux.org/Beagleboard:BeagleBone_Black_Serial How should I go about modifying and/or compiling the Robot Control Library for use with a different beaglebone cape that uses slightly different pin assignments?My primary reason for wanting to re-use the Robot Control Library is the ability to read a fourth encoder via the PRU. Beyond that, I only need access to the encoder and pwm modules. 解决方案 TL;DRModifying the PRU firmware to read the encoder signal from a different pin was easy. Figuring out how to assemble a working device tree for the combination of features I needed was way harder.I would welcome any feedback on how I should have done this, or how I could improve upon what I currently have.Robot Control Library + Motor CapeThe Robotics Cape and the BeagleBone Blue provide a turnkey solution for servo controlling four motors,IFF you are satisfied with driving them at 8V (e.g. a 2S LIPO battery). The Motor Cape can handle ahigher drive voltage (and more current), but does not include encoders. Plugging encoders into the P8 & P9headers on the Motor Cape is simple enough, but the BeagleBone itself only has 3 encoder counters (eQEP).The Robot Control Library solves this problem by reading the fourth encoder with PRU0. However, some of thepins conflict between the Motor Cape and what the Robot Control Library expects on the Robotics Cape.So, how hard could it be to use the Robot Control Library to read encoders and drive motors with a slightlydifferent pinout on the Motor Cape? Probably not difficult at all if you are already competent with BeagleBonedevice tree overlays, which I am not...It all starts with a plan -- Pin SelectionP8_1515Enc 4B--P8_1614Enc 4AM2 DirP9_257IMU--The Robot Control Library expects the fourth encoder to show up on P8_15 and P8_16, but theMotor Cape has P8_16 wired as a direction signal. There are only 12 pins than be configuredas inputs to PRU0 and I eventually selected P9_25 because I did not need the IMU functionality.The best reference I found for what pins can be used for what purposes were these pdfs:https://ofitselfso.com/BeagleNotes/BeagleboneBlackP8HeaderPinMuxModes.pdfhttps://ofitselfso.com/BeagleNotes/BeagleboneBlackP9HeaderPinMuxModes.pdfThe Easy Part -- Modifying the PRU CodeThe Robot Control Library defines the encoder signal input bits in pru_firmware/src/pur0-encoder.asm as; Encoder counting definitions; these pin definitions are specific to SD-101D Robotics Cape .asg r0, OLD ; keep last known values of chA and B in memory .asg r1, EXOR ; place to store the XOR of old with new AB vals .asg 14, A .asg 15, BThis can be modified to look for the A channel on bit 7 (of register 31, which is used for all inputs) as; Encoder counting definitions; these pin definitions are specific to SD-101D Robotics Cape .asg r0, OLD ; keep last known values of chA and B in memory .asg r1, EXOR ; place to store the XOR of old with new AB vals .asg 07, A .asg 15, BN.B. The PRU firmware has to be separately compiled by by running make and sudo make installinside the pru_firmware directory. It is not compiled automatically as part as part of building the restof the library from the top-level Makefile.Helpful Tip: What version am I actually running?There are instructions on modifying the repored version of librobotcontrol inlibrary/version_updating_howto.txt. I followed these instructions to create my own"private" version number so that I could confirm that I was actually running my modifiedversion of the libray. This version is reported by rc_test_drivers.However... as noted above, the PRU firmware was not getting compiled by the top-level Makefile,so for a while I was running my "new" version of librobotcontrol with "old" firmware in the PRU.The Part that Almost Worked -- The Device TreeI found references in both the documentation and code for librobotcontrol that device tree overlayswere no longer needed because the Robotics Cape used its own device tree.I also observed that running the recommended configure_robotics_dt.sh replaced /boot/uEnv.txt withthe following simplified version that loads a single device tree binary (.dtb)uname_r=4.19.94-ti-r42dtb=am335x-boneblack-roboticscape.dtbcmdline=coherent_pool=1MMy favorite reference that I found for general information about the device tree, pinmux, etc washttp://www.ofitselfso.com/BeagleNotes/AboutTheDeviceTree.pdf However, I now realize that some of thedetails are a bit out of date, so be careful.Because I had very little idea of where else to start, I set out to modify the robotics cape device treejust enough to eliminate the conflicts with the Motor Cape. I forked and clonedhttps://github.com/beagleboard/BeagleBoard-DeviceTrees and created two new filesam335x-boneblack-custom.dtscopy of am335x-boneblack-roboticscape.dtschanged model to make the new device tree recognizablechanged #include to point to am335x-custom.dtsi instead of am335x-roboticscape.dtsiam335x-custom.dtsicopy of am335x-roboticscape.dtsideleted a whole bunch of stuff I thought I didn't need anymorerouted P9_25 (instead of P8_16) to PRU0Before /* PRU encoder input */ 0x03c 0x36 /* P8_15,PRU0_r31_15,MODE6 */ 0x038 0x36 /* P8_16,PRU0_r31_14,MODE6 */After /* PRU encoder input */ 0x03c 0x36 /* P8_15,PRU0_r31_15,MODE6 */ 0x1ac 0x36 /* P9_25,PRU0_r31_7,MODE6 */After compiling and installing the modified device trees (make, sudo make install in theBeagleBoard-DeviceTrees repo), I modified /boot/uEnv.txt to call my new custom device treeuname_r=4.19.94-ti-r42dtb=am335x-boneblack-custom.dtbcmdline=coherent_pool=1MI was able to boot the BeagleBone with no cape installed, plug encoders directly into the desired pinson P8_and P9 (including enc4a on P9_25) and read all four encoders using sudo rc_test_encoders.I thought I had won and went to bed...Motor Cape Won't BootAfter a good night's sleep, I plugged the Motor Cape onto the BeagleBone expecting nothing to change sinceI was only passing encoder signals directly through the P8 and P9 headers. I thought the next step would beto make similar tweaks to a few of the pwm direction pins.However, the BeagleBone refused to boot my custom device tree with the MotorCape installed. I went back tothe "standard" am335x-boneblack-roboticscape.dtb device tree and observed that it would not boot either withthe Motor Cape intalled. I also became suspicious that the "factory" installation of the Robotics Cape might havebeen using overlays after allI had been torn from the beginning about whether I should be starting from the Robotics Cape device tree and removingthings I did not need in order to eliminate resource conflicts, versus starting with the "naked" BeagleBone device treeand adding the things that I did need. Whether accurate or not, in my mind that kind-of mapped into trying to specifya full device tree versus providing an overlay to apply on top of the base device tree. The latter seemed likethe conceptually more correct path, so once the Motor Cape failed to boot with the robotics-cape-derived device tree,I decided to bite the bullet and try to figure out device tree overlays.Unanswered Questions[ ] Why won't the BB boot from am335x-boneblack-roboticscape.dtb with the motor cape installed? What is the actual error?[ ] Does a "normal" installation of librobotcontrol install the simplified uEnv.txt above or does it use an overlay? Does it work?I did not yet have USB-to-TTL serial cable that could fit under an installed cape, so I know very little aboutwhy or how this was failing to boot.The Part that Finally Worked -- Device Tree OverlaysI eventually figured out that the collection of device tree overlays is avialable both athttps://github.com/beagleboard/bb.org-overlays and in the v4.19.x-ti-overlays branch athttps://github.com/beagleboard/BeagleBoard-DeviceTrees. I suspect that this might be anin-progress migration, but there was more documentation associated with the bb.org-overlaysrepository so that is what I chose to use.A few documentation links that I wish I had found earlier:https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Overlayshttps://github.com/cdsteinkuehler/beaglebone-universal-iohttps://vadl.github.io/beagleboneblack/2016/07/29/setting-up-bbb-gpioI created forked, cloned, and branched the bb.org-overlays repo and created a new overlay atsrc/arm/CustomCape-00A0.dts by hacking together pieces from BBORG_MOTOR-00A2.dts and RoboticsCape-00A0.dts/* * Device Tree Overlay for custom cape trying to reuse Robot Control Library's * reading of 4x optical encoders. *//*pinmux control byte map courtesy of http://beaglebone.cameon.net/Bit 5: 1 - Input, 0 - OutputBit 4: 1 - Pull up, 0 - Pull downBit 3: 1 - Pull disabled, 0 - Pull enabledBit 2 \Bit 1 |- ModeBit 0 / *//dts-v1/;/plugin/;/ { compatible = "ti,beaglebone-black"; /* identification */ part-number = "CustomCape"; /* version */ version = "00A0"; exclusive-use = "P8.11", /*QEP_2B*/ "P8.12", /*QEP_2A*/ "P8.16", /*PRU_ENCODER_A*/ "P8.33", /*QEP_1B*/ "P8.35", /*QEP_1A*/ "P9.27", /*QEP_0B*/ "P9.41", /*MOT_STBY*/ "P9.42"; /*QEP_0A*/ /* * Helper to show loaded overlays under: /proc/device-tree/chosen/overlays/ */ fragment@0 { target-path="/"; __overlay__ { chosen { overlays { CustomCape-00A0 = __TIMESTAMP__; }; }; }; };fragment@1 { target = <&am33xx_pinmux>; __overlay__ { /**************************************** * pinmux helper ****************************************/ mux_helper_pins: pins { pinctrl-single,pins = < /* EQEP */ 0x1A0 0x31 /* P9_42,EQEP0A, MODE1 */ 0x1A4 0x31 /* P9_27,EQEP0B, MODE1 */ 0x0D4 0x32 /* P8_33,EQEP1B, MODE2 */ 0x0D0 0x32 /* P8_35,EQEP1A, MODE2 */ 0x030 0x34 /* P8_12,EQEP2A_in, MODE4 */ 0x034 0x34 /* P8_11,EQEP2B_in, MODE4 */ /* PRU encoder input */ 0x03c 0x36 /* P8_15,PRU0_r31_15,MODE6 */ 0x1ac 0x36 /* P9_25,PRU0_r31_7,MODE6 */ >; }; };};/**************************************** Pinmux Helper activates the pinmux helper list of pin modes****************************************/fragment@2 { target = <&ocp>; __overlay__ { test_helper: helper { compatible = "bone-pinmux-helper"; pinctrl-names = "default"; pinctrl-0 = <&mux_helper_pins>; status = "okay"; }; };}; /* * Free up the pins used by the cape from the pinmux helpers. */ fragment@3 { target = <&ocp>; __overlay__ { P8_11_pinmux { status = "disabled"; }; /* enc3b */ P8_12_pinmux { status = "disabled"; }; /* enc3a */ P8_15_pinmux { status = "disabled"; }; /* enc4b */ P8_33_pinmux { status = "disabled"; }; /* enc0 */ P8_35_pinmux { status = "disabled"; }; /* enc0 */ P9_25_pinmux { status = "disabled"; }; /* enc4a */ P9_27_pinmux { status = "disabled"; }; /* enc1b */ P9_92_pinmux { status = "disabled"; }; /* enc1a */ }; };/**************************************** Encoders****************************************/fragment@9 { target = <&eqep0>; __overlay__ { count_mode = <0>; /* 0 - Quadrature mode, normal 90 phase offset cha & chb. 1 - Direction mode. cha input = clock, chb input = direction */ swap_inputs = <0>; /* Are channel A and channel B swapped? (0 - no, 1 - yes) */ invert_qa = <1>; /* Should we invert the channel A input? */ invert_qb = <1>; /* Should we invert the channel B input? I invert these because my encoder outputs drive transistors that pull down the pins */ invert_qi = <0>; /* Should we invert the index input? */ invert_qs = <0>; /* Should we invert the strobe input? */ status = "okay"; };};fragment@10 { target = <&eqep1>; __overlay__ { count_mode = <0>; /* 0 - Quadrature mode, normal 90 phase offset cha & chb. 1 - Direction mode. cha input = clock, chb input = direction */ swap_inputs = <0>; /* Are channel A and channel B swapped? (0 - no, 1 - yes) */ invert_qa = <1>; /* Should we invert the channel A input? */ invert_qb = <1>; /* Should we invert the channel B input? I invert these because my encoder outputs drive transistors that pull down the pins */ invert_qi = <0>; /* Should we invert the index input? */ invert_qs = <0>; /* Should we invert the strobe input? */ status = "okay"; };};fragment@11 { target = <&eqep2>; __overlay__ { count_mode = <0>; /* 0 - Quadrature mode, normal 90 phase offset cha & chb. 1 - Direction mode. cha input = clock, chb input = direction */ swap_inputs = <0>; /* Are channel A and channel B swapped? (0 - no, 1 - yes) */ invert_qa = <1>; /* Should we invert the channel A input? */ invert_qb = <1>; /* Should we invert the channel B input? I invert these because my encoder outputs drive transistors that pull down the pins */ invert_qi = <0>; /* Should we invert the index input? */ invert_qs = <0>; /* Should we invert the strobe input? */ status = "okay"; };};/**************************************** PRU****************************************/fragment@31 { target = <&pruss>; __overlay__ { status = "okay"; };};};I added my custom overlay to /boot/uEnv.txt and disabled the video and audio overlaysuname_r=4.19.94-ti-r42#uuid=#dtb=###U-Boot Overlays######Documentation: http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Overlays###Master Enableenable_uboot_overlays=1######Additional custom capesuboot_overlay_addr4=/lib/firmware/CustomCape-00A0.dtbo######Custom Cape#dtb_overlay=/lib/firmware/<file8>.dtbo######Disable auto loading of virtual capes (emmc/video/wireless/adc)#disable_uboot_overlay_emmc=1disable_uboot_overlay_video=1disable_uboot_overlay_audio=1#disable_uboot_overlay_wireless=1#disable_uboot_overlay_adc=1######PRUSS OPTIONS###pru_rproc (4.19.x-ti kernel)uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-19-TI-00A0.dtbo######Cape Universal Enableenable_uboot_cape_universal=1######U-Boot Overlays###cmdline=coherent_pool=1M net.ifnames=0 lpj=1990656 rng_core.default_quality=100 quietI make no claims of optimality or even correctness, but this configuration boots with or without the Motor Capeinstalled and I can read all four encoders with rc_test_encoders. When the Motor Cape is installed, uBootis correctly picking up and applying the BBORG_MOTOR-00A2 overlay. I honestly thought that I would need a lot moreconfiguration of the PRU to get the PRU-based encoder counter from the Robot Control Library working, but this seeemsto do the trick.I would welcome any feedback on how I should have done this, or how I could improve upon what I currently have.Helpful Tip: Watch the serial terminal!I am embarrassed that I even attempted to debug device tree booting issues without first having a serial terminalopen to the beaglebone so that I could observe the boot sequence. With the help of some 5-minute epoxy, I waseventually able to make a 90-degree header to bring the JTAG port out from under an installed cape.https://elinux.org/Beagleboard:BeagleBone_Black_Serial 这篇关于针对不同的beaglebone斗篷编译机器人控制库的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！ 上岸，阿里云！
