Questions about BeagleBone AI

Hello everyone,

My name is Corentin, and I am a member of a team participating each year to the French robotics cup https://www.coupederobotique.fr/.

So we are making robots from scratch, mechanics, electronics and coding.
A robot for the cup is an autonomous with motors to move, actuators to make actions on the match table, sensors to see the environment and electronics/code to run everything.

This year, we want to change our electronic architecture because the current one is a bit old.

After looking at many board with an embedded Linux, we thought that the BeagleBone AI was the good one.

So here is a little explanation of what we want of the board :

  • An embedded Linux to run our high level code
  • A microprocessor to run low level code as motors controls or actuators controls
  • A lot of GPIOs to plug everything we need (sensors, actuators, etc …).

So here is our hardware needs for the board :

  • Encoder inputs for the odometry of the robots

  • PWMs or one I2C bus for the control of the motors

  • Another I2C bus for sensors

  • 5GhZ Wifi (already present)

  • One Ethernet port (already present)

  • One USB port (already present)

  • Interface for a touchscreen

  • Interface for a camera

  • 2 serials (debug, and actuators control)

  • 1 JTAG (debug)

  • Analogs pins

  • GPIOs pins

Do you think the board is providing these needs at the same time ?
In the contrary, do you think the BeagleBone Black will do the job ?

The next questions are more general.

Since Linux is running on the board, what is the state of the support of Linux ?
What’s left to do ?

Will you continue the support of the board in the long run ?
New versions of the board will be make ?

Thank you a lot,

After looking at many board with an embedded Linux, we thought that the
BeagleBone AI was the good one.

  Tends to run hot, you'll likely need to add a fan.

  The pin-muxing has to be set up in the device tree, it can not be
modified after boot. Be ready for lots of device tree modifying as you
debug.

  Unless you disable the DSP processors (2x C66x DSP and maybe also the
4x EVE) and reconfigure the RAM, the RAM available to the main processor is
only about 650MB -- DSP reserves the other 300+ MB.

So here is a little explanation of what we want of the board :
- An embedded Linux to run our high level code

  Beagles run an ARM compatible build of Debian (current standard image
being Debian 10.3 "Buster"). Don't know if that qualifies as "embedded
Linux" to you).

- A microprocessor to run low level code as motors controls or actuators
controls

  There are the PRUs. BBB has one module with two PRUs, BB AI has two
modules -> four PRUs. I'm not sure if the supposed 2x M4 Cortex
microcontrollers are actually usable by client code.

- A lot of GPIOs to plug everything we need (sensors, actuators, etc ...).

  I'm not sure if the BB AI has as many available (even after device tree
modification) as the BB Black.

So here is our hardware needs for the board :
- Encoder inputs for the odometry of the robots

  eQEP module(s) -- check the TI SoC documentation for the AM5729 (BB AI)
and AM3358 (BB Black).

- PWMs or one I2C bus for the control of the motors

  Again, check the SoC documentation (I think I've read that the BBB
supports up to 8 PWM. The BB AI [artificial intelligence] was aimed at
running the TI deep learning classification stuff, and less at hardware
control).

- Another I2C bus for sensors

  I think the second I2C is tied up controlling the power management
chip...

- 5GhZ Wifi (already present)

  You'll need an add-on for the BBB (I think the BBB wireless replaces
the Ethernet cable port with the WiFi stuff).

- One Ethernet port (already present)
- One USB port (already present)

- Interface for a touchscreen
- Interface for a camera

  None native (well, they do have LCD pins which also feed the HDMI
framer, but may not be touchscreen compatible) -- you'll have to either
have USB, I2C, or SPI, OR USE UP a lot of GPIOs (The BBB LCD takes up 20
pins, disable HDMI and LCD in device tree to make them available as GPIO)

- 2 serials (debug, and actuators control)

  Depending upon pinmux, there are up to four on the BBB and BB AI

- 1 JTAG (debug)

  You'll have to solder to the SMT pins on the bottom of the board(s) to
make this available. The BBB (and BB AI) does have a dedicated boot console
serial UART (vs the others which don't become active until the OS is
running).

- Analogs pins

  Appear to be 7 on the BBB, maybe configurable on the BB AI

- GPIOs pins

  Again, configurable at some stage (on a BBB if you choose to run only
from SD card, you can disable the onboard eMMC and assign the MMC1 pins to
other GPIO uses).

Do you think the board is providing these needs at the same time ?
In the contrary, do you think the BeagleBone Black will do the job ?

  Evaluation of suitability is up to your research (I can only state that
a Raspberry-Pi 4B probably won't suffice -- even though quad core and
faster processor, it lacks analog capabilities, coprocessors, and much
fewer GPIO)

Since Linux is running on the board, what is the state of the support of
Linux ?
What's left to do ?

  See above comments

Will you continue the support of the board in the long run ?
New versions of the board will be make ?

  I can't speak for this -- but I believe the Beagle organization targets
something like 6 year life cycle (unlike Raspberry-Pi which seems to
release a new model every year). Also, the Beagles are open-sourced designs
-- anyone can procure the parts and commission a board manufacture.

   Unless you disable the DSP processors (2x C66x DSP and maybe also the
4x EVE) and reconfigure the RAM, the RAM available to the main processor is
only about 650MB -- DSP reserves the other 300+ MB.

How do you go about disabling the DSP and EVE cores?

The device tree would be the starting point, cf message:
<a12120f9-9320-4ac4-bf27-deae6ca956c4@googlegroups.com>
(and maybe provide "do nothing" firmware images for the cores)

John
in older similar processors(omapk178) to halt ( not sure about disabling) DSP we poked a value in a register from ARM side before calling the RTOS not sure where this needs to be done in Linux our code wasn’t in user space.
The TRM and maybe some sample code will point you to the register and hopefully a description of freeing up that DSP memory. Typically a gel script needs to do the same thing when loading either core over JTAG but it’s doubtful finding that script
will be easy.

Mark