Build environment - Ubuntu (WSL)

Development
1

Working: Steps for initial setup, clone, CMake config, and command-line build (with PICO_SDK_FETCH_FROM_GIT).

Nota Bene: Avoid the Rapsberry Pi Pico VSCode extension.

Working

Install pre-requisites

  • Update apt: sudo apt update
  • Upgrade installed libs: sudo apt upgrade
  • Install git: sudo apt install git
  • Install CMake: sudo apt install cmake
  • Install gcc-arm: sudo apt install gcc-arm-none-eabi libnewlib-arm-none-eabi libstdc++-arm-none-eabi-newlib
sudo apt update
sudo apt upgrade
sudo apt install git cmake gcc-arm-none-eabi libnewlib-arm-none-eabi libstdc++-arm-none-eabi-newlib
Initial Clone

Note that this is from my fork… if you’re not making your own branches / PRs, modify the git clone to use the upstream URL, and skip the git remote add command.

cd ~/
git clone https://github.com/henrygab/BusPirate5-firmware bp5
cd ~/bp5
git remote add upstream https://github.com/DangerousPrototypes/BusPirate5-firmware
git pull --all
Initial CMake Configuration

Here, I set this to pull the SDK directly from GIT. Thus, everything remains local to each enlistment.

mkdir ~/bp5/build
cd ~/bp5/build
PICO_SDK_FETCH_FROM_GIT=1 cmake ..
Build From Command Line

cd ~/bp5/build
make clean
make all
Build from VSCode

Manual cleanup of `Raspberry Pi Pico` VSCode Extension

Having this extension installed, even when it’s fully disabled, causes no end of problems. Worse, the extension refuses to uninstall. The following will remove this extension:

  1. In VSCode, in the add-ons, select the Raspberry Pi Pico extension, and choose to disable it (globally). (This is selected only because the uninstall option does not work.)
  2. Shut down all instances of VSCode.
  3. In Windows, goto %USERPROFILE%\.vscode\extensions\. For example, this may be C:\users\john\.vscode\extensions\
  4. delete any subdirectory for the extension. e.g., raspberry-pi.raspberry-pi-pico-0.15.1, raspberry-pi.raspberry-pi-pico-0.15.2, …
  5. In WSL, goto ~/.vscode-server/extensions/
  6. Just like in Windows, delete any subdirectory for the exension.
  7. Load VSCode … it will notice that the extensions were modified offline, and indicate you should reload the window.
  8. Shutdown all VSCode windows
  9. Finally, start VSCode again and the extension should be gone.

Which add-ons needed for VSCode?

… To be added …

Now the building works, the only remaining thing to document is what VSCode extensions should be loaded. Here’s a (partial) list:

… To be added …

1 Like
2

Same here. However I’m not sure how else to get picotool running under windows. Maybe there is a compiled version now.

Under WSL, the last time I had to rebuild everything, cmake took care of most of it. I just had to check out pico tool and the sdk and then cmake … in the Bus Pirate build folder.

This, from the pico github page, is basically what I did:

Install CMake (at least version 3.13), and a GCC cross compiler

sudo apt install cmake gcc-arm-none-eabi libnewlib-arm-none-eabi libstdc++-arm-none-eabi-newlib

Set up your project to point to use the Raspberry Pi Pico SDK

  • Either by cloning the SDK locally (most common) :
    1. git clone this Raspberry Pi Pico SDK repository
    2. Copy pico_sdk_import.cmake from the SDK into your project directory
    3. Set PICO_SDK_PATH to the SDK location in your environment, or pass it (-DPICO_SDK_PATH=) to cmake later.
    4. Setup a CMakeLists.txt like:
1 Like
3

UPDATE:
It was the Raspberry Pi Pico extension. I don’t know how, or why, but I finally uninstalled it by manually deleting all traces from both Windows (%USERPROFILE%\.vscode\extensions\) and WSL (~/.vscode-server/extensions/).

Now the CMake extension is happily showing the targets, and building from the status bar “just works” again.

I’ll update my final steps above.

4

So something is still failing related to the picotool build on windows. It looks like a seg fault – can anyone get me the output actually dying there as opposed to the --quiet option that’s being passed?

5

If you tell me how, I will do it :slight_smile:

I clicked yes when VScode offered to bring up the container. Build tools descended like magic.

After that though, I couldn’t figure out how to actually build anything.

6

If you don’t get connected, you should be able to type ctrl+shift+p for the command pallet. In there, there should be an option to connect. It should the be the same as opening a new terminal. You’ll find yourself at a /project folder, which is mounted to your git repo. At that point it’s the standard mkdir -p build; cd build; cmake ../; make and you should be off to the races, even in windows.

My above comment though is actually related to the Windows build server on the Github. It seems to be failing because of (maybe) the length of arguments executed on the command line, which I find to be dumb, but that’s as best as I can understand for why it would report that it “worked” but then “failed” in the same build context.

7

I really like the idea of using a devcontainer.

I took a quick look, and the docker-compose.yml includes:

network_mode: host
privileged: true

As a quick first pass at getting a devcontainer working, where you created the container, this makes sense.

Is this following best practices?

I ask because, long ago, I was taught that privileged: true was only for very specific use cases, such as nested docker, and that individual capabilities should be added as needed. This seems to still be true: docker - Privileged containers and capabilities - Stack Overflow

8

You’re correct that it’s supposed to be used with care. I will never profess to be a docker pro but I did this with intent because I shamelessly didn’t want to fight getting specific USB device mappings on Linux distributions as well as the other comment here
General | Docker Docs

If you have settings you think are compatible I’m happy to try them but those were the hurdles I hit when I started and figured the risk level was low for the 90% of people who just want to spin up and throw away a container for building.