Problems with BOARD_HARDWARE_PATH

Programming
1

When I build on Linux (Ubuntu 16.04 LTS), I constantly have to define the environment variable BOARD_HARDWARE_PATH for the correct hardware path to be detected, e.g. as

cd <my_hardware_path>/keyboardio/x86/libraries/Model01-Firmware
BOARD_HARDWARE_PATH=<my_hardware_path> make

if I don’t do that, the Kaleidoscope build system will always set BOARD_HARDWARE_PATH to <home>/Arduino/hardware.

Am I doing something fundamentally wrong? In theory it should be possible for the firmware build system to determine the hardware path when the $PWD points to somewhere below the hardware path (e.g. <my_hardware_path>/keyboardio/x86/libraries/Model01-Firmware), same as git does with its commands by always searching for the root .git directories first.

2

Without making the system “smarter” (keep in mind kaleidoscope-builder is a brittle shell script I threw together, and it suffers from all kinds of weird issues, so making it smarter is rarely the best approach), you can set BOARD_HARDWARE_PATH up in ~/.kaleidoscope-builder.conf too, and then you won’t have to add it to every make command you run in libraries/Model01-Firmware.

3

Ok, thanks. I just thought, I might have overlooked something. And I know how complex this is and am happy to have any kind of command line based solution availabe that can be integrated in a regression testing setup.

Do you mean the .kaleidoscope-builder.conf in my copy of Model01-Firmware?

4

That works too, but you can create a file in your home directory, with the same name, and put config options there, too. The builder will read both.

1 Like
5

For me, just export BOARD_HARDWARE_PATH=<my_hardware_path> in my ~/.profile works. That’s another option.

2 Likes
6

It sounds like the specific use case here is to support the virtual hardware core. I think that it should be possible to reorganize the code for that such that it would be a core and a couple libraries inside the same directory structure as our AVR code. This has the added advantage of being able to use the ‘regular’ mechanisms to select the build platform, rather than having to hack around them.

7

I’m pretty sure we are using the ‘regular’ mechanisms to select the build platform for virtual builds - ‘virtual’ is set up as an available “board” in the Arduino build system. That said, it doesn’t appear as an option in the IDE (at least on my system), and I’m not sure why. (Not that we really want it exposed in the IDE - this is more of a feature than a bug, albeit an unintentional one.)

I’m also not sure how Hardware-Virtual is handling this differently than normal builds; all builds use BOARD_HARDWARE_PATH? @noseglasses, do you observe this problem for all builds or just virtual ones?

8

I will test and report back ASAP.

9

As of now, the core and hardware definitions (boards.txt and platform.txt) are inside a library, which means you can’t easily put it in one of the locations the Arduino toolchain expects to look for these things. kaleidoscope-builder gives us hooks to hack around that. It might be enough to add the right paths to our ‘global’ boards.txt and platform.txt files.

BOARD_HARDWARE_PATH is a kaleidoscope-ism to make it a little easier to override Arduino’s defaults for our commandline builds and our automated build infrastructure. If we can massage the work you’ve done to make -Hardware-Virtual go, all you ought to need to do to change the build to compile for the virtual hardware from the command-line is to pass in a $FQBN. That’d be equivalent to making a selection from the menus in the Arduino IDE.

Looking at the current code in kaleidoscope-builder.conf:

if [ "${BOARD}" = "virtual" ]; then
  FQBN="${FQBN:-keyboardio:x86:${BOARD}}"
else
  FQBN="${FQBN:-keyboardio:avr:${BOARD}}"
fi

This is a place where I think we could refactor just a little bit so that we don’t need to hardcode a test for the virtual board. We ought to be letting the caller set the arch and vendor. That would make the code more flexible.

10

With proper symlinks from installation, boards.txt and platform.txt appear in $BOARD_HARDWARE_PATH/keyboardio/x86 which I thought was the right place?

Completely agreed.

11

Ah! I suck. I missed the installation procedure in the docs. I think we can lift the boards.txt and platform.txt content up into the Arduino-Boards versions. I think that the avr and x86 tags in the path names are not actually used by code, but I’d need to experiment more.

And, um, the path is dependent on whether it’s installed by hand or installed by the boards manager. (No, this answer does not make me happy. Nor do I know the rationale ;/ )

1 Like
12

Just checked with a freshly cloned Arduino-Boards.
When I run make with pwd set to .../hardware/keyboardio/avr/libraries/Model01-Firmware BOARD_HARDWARE_PATH is not determined correctly, both for virtual and non-virtual builds.

Edit 1: I am doing this on Ubuntu 16.04 and with Arduino 1.8.5

1 Like
13

What path do you have Arduino-Boards cloned into? To have autodetect work, it needs to be in one of the two places that Arduino sets out as a possible location for a hardware support package.

14

Those interested might check out Kaleidoscope-CMake. It solves some of the problems mentioned above.

2 Likes