BBGW Wifi Pin Conflict

[Andrewiski]

Beagle Bone Green Wireless has pin conflicts. I believe its reasonable to patch the code to detect BBGW and remove the 2 Encoders as most wheeled robot minus Mecanum drive configs use only two encoders.

Would need to drop the support in battery monitor for Batt LED1 and Batt LED2.

Assume would also need a way to flag the PRU code so not to access the PRU encoder pins code if BBGW.

Would need to edit the overlay to disable exclusive use.

Conflict Pins that I found are as follows p8 Pins BBWG Robotics Cap 11 WL_SDIO_D1 QEB2B 12 WL_SDIO_D0 QEB2A 15 WL_SDIO_D3 PRU ENC A 16 WL_SDIO_D2 PRU ENC B 17 WL_IRQ BATT LED 1 18 WL_SDIO_CLK BATT LED2

[jadonk]

@Andrewiski BeagleBone Green Wireless is also physically incompatible, so I'm not sure what you are trying to accomplish.

[Andrewiski]

I am trying to use Roboticscape Library using nothing but the BeagleBone Green Wireless and the IO Pin headers. IE directly wiring the encoders and PWM to my existing Motor Drivers and Motors. Mostly because motors draw over 6 amps and I already have 15 chassies and 6 BBGW. This is for are 6th grades join our FTC robotics club. We have been using Arduino but want to add wireless and web browser control via Node.js etc.

When you say physically incompatible I assume you are saying the USB headers are in the way for the roboticscape to fit on the BBGW. I just want to be able to use the existing library and source code base, plus give back to the community enhancements etc as Beagle Bone has PRU's which give it an advantage over other dev boards.

All I saw for pin conflict in the library and overlay where the above pins, is there anything else you know of.

Andy

[Andrewiski]

Jason, my Fork is here https://github.com/Andrewiski/Robotics_Cape_Installer Still need to patch the device_tree/configure_robotics_dt.sh to detect Green and apply the new overlay but the library compiles with the model detect of BBGW and avoiding the conflict pins.

Let me know if you see any other issues I may have missed.

Andy

[jadonk]

@Andrewiski yes, I was referring to the position of the USB headers.

Love to hear about your development as it is on-going at https://beagleboard.org/discuss

[Andrewiski]

My fork is located here. https://github.com/Andrewiski/Robotics_Cape_Installer

Library compiles and I think I have the model detected and the pins excluded even in the pru0 but stuck on compiling my new overlays so I can test.

Doing something stupid here I am sure but have never had to compile an overlay before.

in install.sh

echo "dts building the BBGW overlay" cp device_tree/am335x-roboticscape-bbgw.dtsi /opt/source/dtb-4.4-ti/src/arm/am335x-roboticscape-bbgw.dtsi cp device_tree/am335x-bonegreen-wireless-roboticscape.dts /opt/source/dtb-4.4-ti/src/arm/am335x-bonegreen-wireless-roboticscape.dts dtc -o "/boot/dtbs/$UNAME/$TREE_BBGW_RC" -O dtb -i "/opt/source/dtb-4.4-ti/src/arm" /opt/source/dtb-4.4-ti/src/arm/am335x-bonegreen-wireless-roboticscape.dts

keep getting error below from dtc even if I try to compile an existing dts in the /opt/source/dtb-4.4-ti/src/arm folder.

Error: am335x-bonegreen-wireless-roboticscape.dts:18.1-9 syntax error FATAL ERROR: Unable to parse input tree

Any thing jump out with the dtc command syntax?

Tried with -@ and -b 0 from other examples I foudn online but same result.

dtc -o "/boot/dtbs/$UNAME/$TREE_BBGW_RC" -O dtb -i "/opt/source/dtb-4.4-ti/src/arm" -b 0 -@ /opt/source/dtb-4.4-ti/src/arm/am335x-bonegreen-wireless-roboticscape.dts

I am missing something easy I am sure.

[RobertCNelson]

@Andrewiski use make:

debian@bborg-v6-16:/opt/source/dtb-4.4-ti$ make src/arm/am335x-bonegreen-wireless.dtb
  DTC     src/arm/am335x-bonegreen-wireless.dtb

but in your case:

make src/arm/am335x-bonegreen-wireless-roboticscape.dtb

edit: to make the source easier for developers, we are utilizing gcc's pre-processor..

Regards,

[Andrewiski]

Sorry for the delay was on spring break with the kids to Denver. So I ran into more pin conflict issues with BBGW as I dug deeper. Sheet 0 BBGW schematic. the pins with 3,9 means page 3 and 9, page 9 is 40 pin headers and are in conflict (https://github.com/SeeedDocument/BeagleBone_Green_Wireless/blob/master/resources/BeagleBone_Green%20Wireless_V1.0_SCH_20160314.pdf ). Having Conflicts on MDIR_1A means I am down to 3 motors but think I will remap in software to a different open pin so I still have 4 motors. I think P8_31 and P8_32 are open Uart5 CTS/RTS.

Updated List of Conflict Pins that I found are as follows Pin BBWG Robotics Cape P8_11 WL_SDIO_D1 QEB2B P8_12 WL_SDIO_D0 QEB2A P8_14 WL_EN BAT_LED_4 P8_15 WL_SDIO_D3 PRU_ENC_A P8_16 WL_SDIO_D2 PRU_ENC_B P8_17 WL_IRQ BATT_LED_1 P8_18 WL_SDIO_CLK BATT_LED_2 P8_26 WL_Level_Shifter_OE BATT_LED_3 P9_12 BT_EN MDIR_1A P9_28 BT_AUD_IN SPI1_CS0 P9_29 BT_AUD_FSYNC SPI1_D0 P9_30 BT_AUD_OUT SPI1_D1 P9_31 BT_AUD_CLK SPI1_SCLK P9_41 WL_SLOW_CLK MOT_STBY

[Andrewiski]

@RobertCNelson

My fork is located here. https://github.com/Andrewiski/Robotics_Cape_Installer

Still struggling with BBGW overlay, build of overlay compiles no errors that I see.

device_tree/build_bbgw_robotics_capes.sh

on boot I get

`[ 3.586792] bone_capemgr bone_capemgr: loader: failed to load slot-4 RoboticsCapeBBGW:00A0 (prio 0)

is there a way to get more debug info on why a cape failed to load? Should I be using the `uboot overlay's instead? See anything I did stupid in my overlay?

/boot/uEnv.txt looks like this

`cape_enable=bone_capemgr.enable_partno=RoboticsCapeBBGW

roboticscape this comment line needed to allow RoboticsCape Service to run using overlay only

`

Thanks

Andy

[Andrewiski]

@RobertCNelson . Missed a couple pinmux setups on SPI but moving forward now.

[Andrewiski]

So seem to be working now using just the RoboticsCapeBBGW-00A0.dts overlay and not am335x-bonegreen-wireless-roboticscape.dts. Is there a reason I should run am335x-bonegreen-wireless-roboticscape.dts other then being able to detect the device model? Also I tok away the pru0 pins but the pru0 firmware is still loading, I prevented any calls from being made to the pru encoders pins that are in conflict. If that assembly was some how ran but the pins were not available via an overlay as already in use by Wifi what happens does it error out, grab the pins anyways. Should I just build a pru firmware for the BBWG that doesn't use those pins and in the install load that to the pru? Any thoughts on that?

Andy

[Andrewiski]

OK I think I have all the conflicts resolved and to fix the PRU0 issue just made a bbgw version that does nothing other then declare the memory so calls to get the encoder value return zero.

Only thing weird was I had to run /opt/source/dtb-4.4-ti/dtc-overlay.sh before I ran ./install.sh else when I built the overlays I got an error the dtc was not found so not compiled which fired of an error in the configure.sh

"ERROR, can't find am335x-bonegreen-wireless-roboticscape.dtb for this kernel." "no changes made to uEnv.txt"

We will do some testing on our robots over the next couple of weeks make sure I didn't create any other issues but so far wifi and bluetooth work, I lost Batt Led, SPI and two of the encoders but wasn't using any of those for our rookie bots anyways. I will keep you posted.