Build environment - Ubuntu (WSL)

Development
21

Of course! I’m not going to yolo it (most times) :slight_smile:

Do let me know if you run into some success. I’ve hit the same types of “life happens” :tm: stuff so I get it. My hope is that it’s at least significantly faster since now it’ll pull by default instead of building by default (2min from 15min on my old local desktop).

I’ve been looking through seeing if I could port over parts of your OpenOCD items and haven’t gotten to yet since I’m still waiting on the RP debugger to arrive.

1 Like
22

After the extension suddenly stopped working under windows with seemingly no fix, I followed the above to install WSL and get VSCode. I also took bits and pieces from elsewhere. Here’s my attempt to document the install:

WSL

  • wsl --install in Windows Power shell run as admin
  • Restart Windows
  • Run the ubuntu app in Windows
  • Give it a user name and password to complete the install
  • sudo apt update && sudo apt upgrade to update the ubuntu install

Source

pico-sdk

This happens in WSL/ubuntu

  • sudo apt install git cmake gcc-arm-none-eabi libnewlib-arm-none-eabi build-essential libstdc++-arm-none-eabi-newlib ninja-build gdb-multiarch to install a bunch of stuff
  • git clone https://github.com/raspberrypi/pico-sdk.git to get the sdk repo
  • cd pico-sdk && git submodule update --recursive --init to init the sub modules like tinyUSB
  • export PICO_SDK_PATH=~/pico-sdk to set the system environment variable, replace ~/pico-sdk if you didn’t install it in the home directory.

From here and here.

picotool

This also happens in WSL/ubuntu

  • git clone https://github.com/raspberrypi/picotool clone into your home directory
  • sudo apt install build-essential pkg-config libusb-1.0-0-dev cmake install a bunch of stuff
  • cd picotool && mkdir build && cd build && cmake .. to run cmake
  • make to build picotool
  • In ~/picotool add udev roles to run without sudo: sudo cp udev/99-picotool.rules /etc/udev/rules.d/

Source

VSCode

This also happens in WSL/Ubuntu

  • git clone https://github.com/DangerousPrototypes/BusPirate5-firmware.git to get the source
  • Change into the source directory (BusPirate5-firmware if not specified above
  • code . to launch VSCode from WSL
  • Install VSCode extensions:
    – Remote – WSL
    – C/C++
    – CMake Tools
    – Coretx Debug
  • VScode detected the installed compilers from here and I was able to configure and build

Source

Catches

The only catch is that I needed to add the location of the SDK to the top of the CMakeLists.txt file in ./ (not ./src/):

set(PICO_SDK_PATH ~/pico-sdk)

I guess the exported environmental variable is not persistent. This could also be configured in the bowels of VSCode.

It also rebuilt picotool and did not detect my compiled version. I’m sure this is my fault, I did manage to get it working on the build server.

Todo

I have not setup debug, which requires configuring USB for WSL with USBIPD which is covered above and here.

These tutorials are a few years old, I think the standard OpenOCD supports pico now so a custom version is no longer needed?

1 Like
23

FYI: Installation of the pico SDK is optional. It can be pulled automagically during build (-DPICO_SDK_FETCH_FROM_GIT=TRUE when configuring cmake … as decribed in /readme.md) … which I recommend for most folks, because RPi doesn’t seem to like side-by-side installs).

OpenOCD supports RP2040 natively.

If you find a release that supports RP2350 natively, do post here. The pico SDK includes a pre-release version that supports RP2350.

1 Like
24

Good point about the 2350, I had forgotten that.

Things seem to be stabilizing and I was productive across two repos today. There is some added ugliness of WSL. For example to upload dirtyjtag I had to drag the file into a Windows folder, click a warning, and then I could zip and upload it.

On the flip side, the toolchain makes a whole lot more sense to me on Linux. The build server is easy enough to setup and debug. Under Windows it’s black magic with the installer (or the new VSCode extension).

1 Like
25

You are right, if you use windows Explorer to update via UF2…

You can also just copy directly from a windows windows command prompt, which avoids that warning.

Of course, I recommend having SWD hooked up, and if the debug prove is in WSL2 (via USBIPD), then the firmware files never even have to touch the Windows side.

You are right about the build tools. That is the main reason I think it’s worth the cost of setting up WSL2 (or a VM) for development. Debuggers too! With VSCode’s remote mode, it is fairly seamless.

Glad you got stuff back to a point where you can be productive again!

1 Like