Starting this topic for discussion and keeping logs of the work going on for introducing librobotcontrol compatibility for the BBAI+RC. Current an open issue can be found issue#173.
A pull request #203: BeagleBone AI support) also seems to be open as of 13th April, by @jkridner which tries to bring BeagleBone AI support.
I have commented on the issue as well as PR asking few doubts, so far awaiting any response from the maintainers.
The currently active repo is forked by @jkridner here , I have forked it from there, and will be borking on the bbai branch. I will try to keep commits very regular inorder to have proper documentation and records of all the changes made throughout.
My GSoC’21 proposal can be found here
I will try to keep this topic in sync with any important discussions related to this project on IRC.
I haven’t seen comments on the pull request.
Can you please explain these comments?
- add version and model changes, TODO: real model name in future · beagleboard/librobotcontrol@6bd8293 · GitHub
- add version and model changes, TODO: real model name in future · beagleboard/librobotcontrol@6bd8293 · GitHub
if I am not wrong, this commit seems to be behind this model.h where you have done the proper naming like MODEL_BB_AI_RC and MODEL_BB_AI. is that so?
Also, should I start development on the PWM.c file?
planning to start by including this macro: (as explained in my proposal)
#define PWM2AI(x) (x=1?3:(x=2?2:-1))
and then going ahead to create if-else statements ahead for BBAI/ BBB specific pin configs. (This may include some channel number–>file descriptors edits)
Recent comment from @jkridner and a conversation with @lorforlinux revealed that I should be working on the official beagle org’s repo which means I have to fork this.
Here I quote @lorforlinux word-to-word:
That could be the case but then, he should merge those changes back to the main repo. Ask him to do that and create your PRs for the BeagleBoard’ repo only
And here is @jkridner’s comment reply:
You don’t need to be assigned to work on it. Take a look at my draft pull request and look for gaps that need to be filled. You can make your own pull request and pull in some or all of my changes thusfar.
You should fork and provide pull requests to the main beagleboard repo, but that doesn’t mean you cannot pull in changes from my fork to include in your fork and pull request.
Look at git remote add and git cherry-pick as well as git merge.
When you merge them, you should initially try to keep my commits intact to preserve the history. I the end, we can squash-commit if it’ll make it easier to follow the patch.
You can mark comments on github and point to those here to make things a bit easier to follow.
James started work on adding BeagleBone AI work in parallel, but I got a lot farther. I got the PRU stuff working, which is what I needed to get working for BlueDonkey. I also got the ADC working.
update: Tried to fix I2C drivers in the robot control library. The commit can be seen here
I have written a macro to remap the I2C numbers to match with those of the BBB. But I am not sure if this is right approach.
I have remote added your repo/bbai as upstream and ran a fetch such that all your changes are integrated into my v1.1 branch.
I got the PRU stuff working, which is what I needed to get working for BlueDonkey. I also got the ADC working.
Yes, I did go through the entire commit history and that is where I am trying to learn from of how I can move ahead with the implementation.
No, please don’t use macros, which are resolved at compile time. This needs to be resolved at runtime.
okay then should I write proper functions itself instead of macros that do the same thing more or less? Or do we have something else in mind?
(Can you explain why compile time resolved are discouraged?) Inline functions also basically just get converted to functions (ie. at syntax text level) at compile time and then are pushed forwards to runtime, but they look much cleaner and concise in code right?
The paths should be variables that get set as the environment is detected and detection should happen automatically, if it hasn’t already been done.
The symlinks provided by the cape compatibility layer should be used if they exist.
The old paths on AM3358 should be used if the symlinks don’t exist.
I don’t think support on AM5729 without the cape compatibility layer is required.
They won’t work. The librobotcontrol binaries are the same no matter what board they are run on. Please don’t try to figure out what environment the executable is being run on based on what environment the compiler is being run on.
The paths should be variables that get set as the environment is detected and detection should happen automatically, if it hasn’t already been done.
Okay
The symlinks provided by the cape compatibility layer should be used if they exist
Yes, most of them are already in place and I found them here
I don’t think support on AM5729 without the cape compatibility layer is required.
Right, we should harness the bone-buses BeagleBone cape interface in place already.
But I was only trying to apply what I saw here and is mentioned as WIP: adc working hence I thought that was the way ahead…
But the comment you made on github
This wouldn’t enable the cape compatibility layer to be used.
We are trying to make librobotcontrol a good example for how programs can be written in a binary-compatible format to run on both AM3358 and AM5729 using Beagleboard:BeagleBone cape interface spec - eLinux.org.
Instead,/dev/bone/i2c/Xshould work on either board as long as the compatibility layer symlinks are installed.
This code does need a fall-back to run on older systems without the compatibility layer as well. That will need to be resolved at run-time and not in macros. Further, with the compatibility layer, the macro adds no value as there is already a common path,/dev/bone/i2c/X, between the boards.
clarifies what doubts I had in mind… and why you discourage macros.
I am unable to clearly understand why this issue is there and how exactly I can help solve it, I feel lost as to if already beagleboneai-roboticscape.dts is in place, and if most GPIOs and UARTs are able to load correctly, then why might the I2C, eqep and PWM fail?
My question is really more finding where exactly should I try to apply the fix? Is it to be written in the DTS file? Is it in the librobot libraries? Please help me understand where exactly is the driver breaking?
I added some more comments: Support for the Beaglebone AI · Issue #173 · beagleboard/librobotcontrol · GitHub
For most things, the overlay just turns the right device drivers on, but it does a few other things.
// SPDX-License-Identifier: GPL-2.0-only
/*
* Copyright (C) 2012 Texas Instruments Incorporated - https://www.ti.com/
*/
#include "am5729-beagleboneai.dts"
Note that the above makes this a base device tree, not an overlay. This is to be used in-place of the standard device tree.
For the most part, I think we should eliminate swapping out the device tree if it can be avoided. Because librobotcontrol uses userspace drivers for most things, I think this shouldn’t be a problem. Also, the default beaglebone-ai device tree is often compatible with the pinmuxes needed for the robotics-cape. However, there will need to be an overlay to at least fix-up a few pinmuxes that need to be outputs. I’d say an overlay is a better approach than replacing the whole device tree, though it can be more of a hassle to setup, which is why I initially did things as a new base tree.
/ {
chosen {
base_dtb = "am5729-beagleboneai-roboticscape.dts";
base_dtb_timestamp = __TIMESTAMP__;
};
The below chunk does load a kernel driver for LEDs. However, if @Deepak_Khatri’s approach of assigning gpio-leds driver to every cape header pin mostly eliminates the need for that specific tasks.
This below chunk also gives labels to the LEDs that are specific to the cape, so maybe those should go in here to make the interface clean.
What is important is documenting these decisions, more than what the decisions actually are.
I think since we’ll have an overlay for the pinmux settings, we should go ahead and load drivers with the right labels. Any conflicts in the base tree would need to be addressed, ie., if it already tries to load a gpio-leds driver, we’d either need to change the label or disable the attempt.
rcleds {
compatible = "gpio-leds";
pinctrl-names = "default";
pinctrl-0 = <&cape_pins_rc>;
red_led {
label = "red";
gpios = <&gpio6 5 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
green_led {
label = "green";
gpios = <&gpio6 6 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
batt_1_led {
label = "bat25";
gpios = <&gpio8 18 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
batt_2_led {
label = "bat50";
gpios = <&gpio4 9 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
batt_3_led {
label = "bat75";
gpios = <&gpio4 28 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
batt_4_led {
label = "bat100";
gpios = <&gpio4 13 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
};
};
The below chunk is for PRUs and I think should be in a standard overlay that is included by default now.
&ocp {
pruss1_shmem: pruss_shmem@4b200000 {
status = "okay";
compatible = "ti,pruss-shmem";
reg = <0x4b200000 0x020000>;
};
pruss2_shmem: pruss_shmem@4b280000 {
status = "okay";
compatible = "ti,pruss-shmem";
reg = <0x4b280000 0x020000>;
};
};
The below chunk is the pinmux settings. We should shift to doing this as an overlay, rather than as a base tree.
&dra7_pmx_core {
cape_pins_rc: cape_pins_rc {
pinctrl-single,pins = <
DRA7XX_CORE_IOPAD(0x379C, MUX_MODE15) /* AB8: P8.3: mmc3_dat6.off */
DRA7XX_CORE_IOPAD(0x37A0, MUX_MODE15) /* AB5: P8.4: mmc3_dat7.off */
DRA7XX_CORE_IOPAD(0x378C, MUX_MODE15) /* AC9: P8.5: mmc3_dat2.off */
DRA7XX_CORE_IOPAD(0x3790, MUX_MODE15) /* AC3: P8.6: mmc3_dat3.off */
DRA7XX_CORE_IOPAD(0x36EC, PIN_OUTPUT | MUX_MODE14) /* G14: mcasp1_axr14.gpio6_5 - P8_7 - RED */
DRA7XX_CORE_IOPAD(0x36F0, PIN_OUTPUT | MUX_MODE14) /* F14: mcasp1_axr15.gpio6_6 - P8_8 - GREEN */
DRA7XX_CORE_IOPAD(0x3698, PIN_INPUT_PULLUP | MUX_MODE14) /* E17: P8.9: xref_clk1.gpio6_18 - PAUSE */
DRA7XX_CORE_IOPAD(0x36E8, PIN_INPUT_PULLUP | MUX_MODE14) /* A13: P8.10: mcasp1_axr13.gpio6_4 - MODE */
DRA7XX_CORE_IOPAD(0x3510, PIN_INPUT | MUX_MODE10) /* AH4: P8.11: vin1a_d7.eQEP2B_in - QEP2B */
DRA7XX_CORE_IOPAD(0x350C, PIN_INPUT | MUX_MODE10) /* AG6: P8.12: vin1a_d6.eQEP2A_in - QEP2A */
DRA7XX_CORE_IOPAD(0x3590, PIN_OUTPUT | MUX_MODE10) /* D3: P8.13: vin2a_d10.ehrpwm2B - PWM2B */
DRA7XX_CORE_IOPAD(0x3598, PIN_OUTPUT | MUX_MODE14) /* D5: vin2a_d12.gpio4_13 - P8_14 - BAT100 */
DRA7XX_CORE_IOPAD(0x3570, MUX_MODE15) /* D1: P8.15a: vin2a_d2.off */
DRA7XX_CORE_IOPAD(0x35B4, PIN_INPUT | MUX_MODE12) /* A3: P8.15b: vin2a_d19.pr1_pru1_gpi16 - QEP4B */
DRA7XX_CORE_IOPAD(0x35BC, PIN_INPUT | MUX_MODE12) /* B4: P8.16: vin2a_d21.pr1_pru1_gpi18 - QEP4A */
DRA7XX_CORE_IOPAD(0x3624, PIN_OUTPUT | MUX_MODE14) /* A7: vout1_d18.gpio8_18 - P8_17 - BAT25 */
DRA7XX_CORE_IOPAD(0x3588, PIN_OUTPUT | MUX_MODE14) /* F5: vin2a_d8.gpio4_9 - P8_18 - BAT50 */
DRA7XX_CORE_IOPAD(0x358C, PIN_OUTPUT | MUX_MODE10) /* E6: P8.19: vin2a_d9.ehrpwm2A - PWM2A */
DRA7XX_CORE_IOPAD(0x3780, MUX_MODE15) /* AC4: P8.20: mmc3_cmd.off */
DRA7XX_CORE_IOPAD(0x377C, MUX_MODE15) /* AD4: P8.21: mmc3_clk.off */
DRA7XX_CORE_IOPAD(0x3798, MUX_MODE15) /* AD6: P8.22: mmc3_dat5.off */
DRA7XX_CORE_IOPAD(0x3794, MUX_MODE15) /* AC8: P8.23: mmc3_dat4.off */
DRA7XX_CORE_IOPAD(0x3788, MUX_MODE15) /* AC6: P8.24: mmc3_dat1.off */
DRA7XX_CORE_IOPAD(0x3784, MUX_MODE15) /* AC7: P8.25: mmc3_dat0.off */
DRA7XX_CORE_IOPAD(0x35B8, PIN_OUTPUT | MUX_MODE14) /* B3: vin2a_d20.gpio4_28 - P8_26 - BAT75 */
DRA7XX_CORE_IOPAD(0x35D8, MUX_MODE15) /* E11: P8.27a: vout1_vsync.off */
DRA7XX_CORE_IOPAD(0x3628, PIN_OUTPUT | MUX_MODE13) /* A8: P8.27b: vout1_d19.pr2_pru0_gpo16 - SVO1 */
DRA7XX_CORE_IOPAD(0x35C8, MUX_MODE15) /* D11: P8.28a: vout1_clk.off */
DRA7XX_CORE_IOPAD(0x362C, PIN_OUTPUT | MUX_MODE13) /* C9: P8.28b: vout1_d20.pr2_pru0_gpo17 - SVO2 */
DRA7XX_CORE_IOPAD(0x35D4, MUX_MODE15) /* C11: P8.29a: vout1_hsync.off */
DRA7XX_CORE_IOPAD(0x3630, PIN_OUTPUT | MUX_MODE13) /* A9: P8.29b: vout1_d21.pr2_pru0_gpo18 - SVO3 */
DRA7XX_CORE_IOPAD(0x35CC, MUX_MODE15) /* B10: P8.30a: vout1_de.off */
DRA7XX_CORE_IOPAD(0x3634, PIN_OUTPUT | MUX_MODE13) /* B9: P8.30b: vout1_d22.pr2_pru0_gpo19 - SVO4 */
DRA7XX_CORE_IOPAD(0x3614, MUX_MODE15) /* C8: P8.31a: vout1_d14.off */
DRA7XX_CORE_IOPAD(0x373C, MUX_MODE15) /* G16: P8.31b: mcasp4_axr0.off */
DRA7XX_CORE_IOPAD(0x3618, MUX_MODE15) /* C7: P8.32a: vout1_d15.off */
DRA7XX_CORE_IOPAD(0x3740, MUX_MODE15) /* D17: P8.32b: mcasp4_axr1.off */
DRA7XX_CORE_IOPAD(0x3610, MUX_MODE15) /* C6: P8.33a: vout1_d13.off */
DRA7XX_CORE_IOPAD(0x34E8, PIN_INPUT | MUX_MODE10) /* AF9: P8.33b: vin1a_fld0.eQEP1B_in - QEP1B */
DRA7XX_CORE_IOPAD(0x3608, PIN_OUTPUT | MUX_MODE14) /* D8: P8.34a: vout1_d11.gpio8_11 - MDIR2B */
DRA7XX_CORE_IOPAD(0x3564, MUX_MODE15) /* G6: P8.34b: vin2a_vsync0.off */
DRA7XX_CORE_IOPAD(0x360C, MUX_MODE15) /* A5: P8.35a: vout1_d12.off */
DRA7XX_CORE_IOPAD(0x34E4, PIN_INPUT | MUX_MODE10) /* AD9: P8.35b: vin1a_de0.eQEP1A_in - QEP1A */
DRA7XX_CORE_IOPAD(0x3604, PIN_OUTPUT | MUX_MODE14) /* D7: P8.36a: vout1_d10.gpio8_10 - SERVO_EN */
DRA7XX_CORE_IOPAD(0x3568, MUX_MODE15) /* F2: P8.36b: vin2a_d0.off */
DRA7XX_CORE_IOPAD(0x35FC, MUX_MODE15) /* E8: P8.37a: vout1_d8.off */
DRA7XX_CORE_IOPAD(0x3738, PIN_OUTPUT | MUX_MODE3) /* A21: P8.37b: mcasp4_fsx.uart8_txd - UART5_TX */
DRA7XX_CORE_IOPAD(0x3600, MUX_MODE15) /* D9: P8.38a: vout1_d9.off */
DRA7XX_CORE_IOPAD(0x3734, PIN_INPUT | MUX_MODE3) /* C18: P8.38b: mcasp4_aclkx.uart8_rxd - UART5_RX */
DRA7XX_CORE_IOPAD(0x35F4, PIN_OUTPUT | MUX_MODE13) /* F8: P8.39: vout1_d6.pr2_pru0_gpo3 - SVO5 */
DRA7XX_CORE_IOPAD(0x35F8, PIN_OUTPUT | MUX_MODE13) /* E7: P8.40: vout1_d7.pr2_pru0_gpo4 - SVO6 */
DRA7XX_CORE_IOPAD(0x35EC, PIN_OUTPUT | MUX_MODE13) /* E9: P8.41: vout1_d4.pr2_pru0_gpo1 - SVO7 */
DRA7XX_CORE_IOPAD(0x35F0, PIN_OUTPUT | MUX_MODE13) /* F9: P8.42: vout1_d5.pr2_pru0_gpo2 - SVO8 */
DRA7XX_CORE_IOPAD(0x35E4, PIN_OUTPUT | MUX_MODE14 ) /* F10: P8.43: vout1_d2.gpio8_2 - MDIR3B */
DRA7XX_CORE_IOPAD(0x35E8, PIN_OUTPUT | MUX_MODE14 ) /* G11: P8.44: vout1_d3.gpio8_3 - MDIR3A */
DRA7XX_CORE_IOPAD(0x35DC, PIN_OUTPUT | MUX_MODE14 ) /* F11: P8.45a: vout1_d0.gpio8_0 - MDIR4A */
DRA7XX_CORE_IOPAD(0x361C, MUX_MODE15) /* B7: P8.45b: vout1_d16.off */
DRA7XX_CORE_IOPAD(0x35E0, PIN_OUTPUT | MUX_MODE14 ) /* G10: P8.46a: vout1_d1.gpio8_1 - MDIR4B */
DRA7XX_CORE_IOPAD(0x3638, MUX_MODE15) /* A10: P8.46b: vout1_d23.off */
DRA7XX_CORE_IOPAD(0x372C, PIN_INPUT | MUX_MODE4) /* B19: P9.11a: mcasp3_axr0.uart5_rxd - UART4_RX */
DRA7XX_CORE_IOPAD(0x3620, MUX_MODE15) /* B8: P9.11b: vout1_d17.off */
DRA7XX_CORE_IOPAD(0x36AC, PIN_OUTPUT | MUX_MODE14) /* B14: P9.12: mcasp1_aclkr.gpio5_0 - MDIR1A */
DRA7XX_CORE_IOPAD(0x3730, PIN_OUTPUT | MUX_MODE14) /* C17: P9.13: mcasp3_axr1.off - MDIR1B */
DRA7XX_CORE_IOPAD(0x35AC, PIN_OUTPUT | MUX_MODE10) /* D6: P9.14: vin2a_d17.ehrpwm3A - PWM1A */
DRA7XX_CORE_IOPAD(0x3514, PIN_OUTPUT | MUX_MODE14) /* AG4: P9.15: vin1a_d8.gpio3_12 - MDIR2A */
DRA7XX_CORE_IOPAD(0x35B0, PIN_OUTPUT | MUX_MODE10) /* C5: P9.16: vin2a_d18.ehrpwm3B - PWM1B */
DRA7XX_CORE_IOPAD(0x37CC, PIN_INPUT | MUX_MODE14) /* B24: P9.17a: spi2_cs0.gpio7_17 */
DRA7XX_CORE_IOPAD(0x36B8, PIN_INPUT_PULLUP | SLEWCONTROL | MUX_MODE10) /* F12: P9.17b: mcasp1_axr1.i2c5_scl - I2C1_SCL */
DRA7XX_CORE_IOPAD(0x37C8, PIN_INPUT | MUX_MODE14) /* G17: P9.18a: spi2_d0.gpio7_16 */
DRA7XX_CORE_IOPAD(0x36B4, PIN_INPUT_PULLUP | SLEWCONTROL | MUX_MODE10) /* G12: P9.18b: mcasp1_axr0.i2c5_sda - I2C1_SDA */
DRA7XX_CORE_IOPAD(0x3440, PIN_INPUT | MUX_MODE7) /* R6: P9.19a: gpmc_a0.i2c4_scl - I2C2_SCL */
DRA7XX_CORE_IOPAD(0x357C, PIN_INPUT | MUX_MODE12 ) /* F4: P9.19b: vin2a_d5.pr1_pru1_gpi2 */
DRA7XX_CORE_IOPAD(0x3444, PIN_INPUT | MUX_MODE7) /* T9: P9.20a: gpmc_a1.i2c4_sda - I2C2_SDA */
DRA7XX_CORE_IOPAD(0x3578, PIN_INPUT | MUX_MODE12) /* D2: P9.20b: vin2a_d4.pr1_pru1_gpi1 */
DRA7XX_CORE_IOPAD(0x34F0, MUX_MODE15) /* AF8: P9.21a: vin1a_vsync0.off */
DRA7XX_CORE_IOPAD(0x37C4, PIN_OUTPUT | MUX_MODE1) /* B22: P9.21b: spi2_d1.uart3_txd - UART2_TX */
DRA7XX_CORE_IOPAD(0x369C, MUX_MODE15) /* B26: P9.22a: xref_clk2.off */
DRA7XX_CORE_IOPAD(0x37C0, PIN_INPUT | MUX_MODE1) /* A26: P9.22b: spi2_sclk.uart3_rxd - UART2_RX */
DRA7XX_CORE_IOPAD(0x37B4, PIN_OUTPUT | MUX_MODE14) /* A22: P9.23: spi1_cs1.gpio7_11 - SPI1_SS2 */
DRA7XX_CORE_IOPAD(0x368C, PIN_OUTPUT | MUX_MODE3) /* F20: P9.24: gpio6_15.uart10_txd - UART1_TX */
DRA7XX_CORE_IOPAD(0x3694, PIN_INPUT | MUX_MODE14) /* D18: P9.25: xref_clk0.gpio6_17 - IMU_INT */
DRA7XX_CORE_IOPAD(0x3688, PIN_INPUT | MUX_MODE3) /* E21: P9.26a: gpio6_14.uart10_rxd - UART1_RX */
DRA7XX_CORE_IOPAD(0x3544, MUX_MODE15) /* AE2: P9.26b: vin1a_d20.off */
DRA7XX_CORE_IOPAD(0x35A0, PIN_INPUT | MUX_MODE10) /* C3: P9.27a: vin2a_d14.eQEP3B_in - QEP0B */
DRA7XX_CORE_IOPAD(0x36B0, MUX_MODE15) /* J14: P9.27b: mcasp1_fsr.off */
DRA7XX_CORE_IOPAD(0x36E0, PIN_OUTPUT | MUX_MODE3) /* A12: P9.28: mcasp1_axr11.spi3_cs0 - SPI1_SS1 */
DRA7XX_CORE_IOPAD(0x36D8, PIN_INPUT | MUX_MODE3) /* A11: P9.29a: mcasp1_axr9.spi3_d1 - SPI1_MISO */
DRA7XX_CORE_IOPAD(0x36A8, MUX_MODE15) /* D14: P9.29b: mcasp1_fsx.off */
DRA7XX_CORE_IOPAD(0x36DC, PIN_OUTPUT | MUX_MODE3) /* B13: P9.30: mcasp1_axr10.spi3_d0 - SPI1_MOSI */
DRA7XX_CORE_IOPAD(0x36D4, PIN_OUTPUT | MUX_MODE3) /* B12: P9.31a: mcasp1_axr8.spi3_sclk - SPI1_SCK */
DRA7XX_CORE_IOPAD(0x36A4, MUX_MODE15) /* C14: P9.31b: mcasp1_aclkx.off */
DRA7XX_CORE_IOPAD(0x36A0, PIN_OUTPUT | MUX_MODE14) /* C23: P9.41a: xref_clk3.gpio6_20 - MOT_STBY */
DRA7XX_CORE_IOPAD(0x3580, MUX_MODE15) /* C1: P9.41b: vin2a_d6.off */
DRA7XX_CORE_IOPAD(0x36E4, MUX_MODE15) /* E14: P9.42a: mcasp1_axr12.off */
DRA7XX_CORE_IOPAD(0x359C, PIN_INPUT | MUX_MODE10) /* C2: P9.42b: vin2a_d13.eQEP3A_in - QEP0A */
>;
};
};
The below fragments simply turn on the drivers. I think the new approach is to have them on already in the base tree, so these may not be needed. All of these approaches need to be documented and discussed with the community.
&i2c5 {
status = "okay";
clock-frequency = <100000>;
};
&epwmss0 {
status = "okay";
};
&epwmss1 {
status = "okay";
};
&epwmss2 {
status = "okay";
};
&ehrpwm1 {
status = "okay";
};
&ehrpwm2 {
status = "okay";
};
&uart8 {
status = "okay";
};
&uart5 {
status = "okay";
};
&uart3 {
status = "okay";
};
&uart10 {
status = "okay";
};
&mcspi1 {
#address-cells = <1>;
#size-cells = <0>;
status = "okay";
cs-gpios = <0>, <&gpio7 11 0>;
channel@0 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "spidev";
reg = <0>;
spi-max-frequency = <24000000>;
};
channel@1 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "spidev";
reg = <1>;
spi-max-frequency = <24000000>;
};
};Note that the above makes this a base device tree, not an overlay. This is to be used in-place of the standard device tree.
If I am not mistaken, the syntax atleast for an overlay remains the same right? So the only difference according to here is that once we build this .dts file we have to Change the extension of the file to .dtbo and then copy Copy the dtbo file to the /lib/firmware directory.
Afterthis we have to add custom_cape = am5729-beagleboneai.dtbo in uenv.txt and Save and close the file.
Once the board reboots after this, everything should work as expected right?
All this can easily be achieved with the help of a simple sh script that the user runs at install time.
Am I correct in suggesting the above? Or are we looking for something else?
I’m not sure where to start really quick, but, no, .dtbo files are not just .dtb or .dts files renamed. They are .dts files compiled specifically for overlays.
I think the variable name is wrong for within uEnv.txt as well. Also, you wouldn’t do am5729-beagleboneai as an overlay as that is the base tree.
So, I’m not really sure where to start in suggesting corrections.
okay @jkridner , thank you for the suggestions so far! I will go over everything once again and will try to come up implement good approaches using trial and error and further community discussions.
I hadn’t been able to find a comprehensive guide to remapping pins so the RC would work with the BBAI but using this forum page, and many others, I was able to get the rc_test_dmp example to work for the Beaglebone AI + Robotics Cape with the following steps ( for the Debian 11 am5729 image):
Here’s how to modify the rc_test_dmp.c example so it will work:
-
make sure this image is installed: https://rcn-ee.com/rootfs/release/2023-08-05/bullseye-minimal-armhf/am57xx-debian-11.7-minimal-armhf-2023-08-05-2gb.img.xz
-
Look up the physical pin corresponding to chip 3 pin 21 (GPIO3_21; specified by default in rc_test_dmp.c) for the beaglebone black spec since it is presumably correct: Connectors — BeagleBoard Documentation. It is physical pin 9_25 (9 corresponds to the connector on the left side of the board per the link)
-
run sudo gpioinfo and look for P9_25 in the third column. It is at gpiochip7 line 17 (i.e. chip 7, pin 17):
gpiochip7 - 32 lines:
line 0: unnamed unused input active-high
line 1: unnamed unused input active-high
line 2: unnamed unused input active-high
line 3: unnamed unused input active-high
line 4: unnamed “P8_10” input active-high [used]
line 5: unnamed “P8_07” input active-high [used]
line 6: unnamed “P8_08” input active-high [used]
line 7: unnamed unused input active-high
line 8: unnamed unused input active-high
line 9: unnamed unused input active-high
line 10: unnamed unused input active-high
line 11: unnamed unused input active-high
line 12: unnamed “P9_13” input active-high [used]
line 13: unnamed unused input active-high
line 14: unnamed “P9_26” input active-high [used]
line 15: unnamed “P9_24” input active-high [used]
line 16: unnamed “interrupt” input active-high [used]
line 17: unnamed “P9_25” input active-high [used]
line 18: unnamed “P8_09” input active-high [used]
line 19: unnamed “P9_22” input active-high [used]
line 20: unnamed “P9_41” input active-high [used]
line 21: unnamed unused input active-high
line 22: unnamed unused input active-high
line 23: unnamed unused input active-high
line 24: unnamed unused input active-high
line 25: unnamed unused input active-high
line 26: unnamed unused input active-high
line 27: unnamed “cd” input active-low [used]
line 28: unnamed unused input active-high
line 29: unnamed “P8_21” input active-high [used]
line 30: unnamed “P8_20” input active-high [used]
line 31: unnamed “P8_25” input active-high [used] -
change chip 3, pin 21 to chip 7, pin 17 in rc_test_dmp.c
-
in the librobotcontrol source code, increase CHIPS_MAX from 6 to 9 in gpio.c and do make && make install
-
compile rc_test_dmp.c
-
run rc_calibrate_accel to calibrate accelerometer
-
run rc_test_dmp.c and you should see the accelerometer updating via the callback function.
Hopefully this helps someone get on the right track.