Pre-built UF2 explanations, Manual build files?

[thestumbler]

(this is cross-posted from a post I made on the Discord a couple days back...)

I have a few Pimoroni Pico Plus 2 boards for a project, and one Pico Plus 2W that I got just to experiment with. Today I'm bringing up a second prototype using one of the (not W) modules, and noticed something different in a runtime error. Tracking it down, I see that I'm using a UF2 intended for the 2W board on a 2:

os.uname()
(sysname='rp2', nodename='rp2', release='1.25.0-preview', version='feature/psram-and-wifi, pico_plus2_rp2350 v0.0.12 on 2025-02-28 (GNU 13.3.1 MinSizeRel)', machine='Pimoroni Pico Plus 2 (PSRAM + LTE + WiFi) with RP2350')

is there now just one build for both boards?

pimoroni_pico_plus2-v0.1.0-micropython.uf2
2.49 MB
Apr 15

The association between the UF2 and the hardware modules isn't clear, and the naming / descriptions aren't 100% clear, either. The links on each board’s (2 and 2W) page takes you to different places on GitHub. The one for Pico 2 takes you to a table which suggests that one file is used for both. The link for the Pico 2W takes you to a slightly different page with a file whose name suggests it’s only for the 2 -- but if you load that file and do os.uname(), you’ll see it’s built for the 2W (or possibly both).

Looking to sort this out by reading the custom build files, I also ran into a dead end. I can’t find the board configuration files associated with either of these files. If they're posted, it's not obvious where. For sure the 1.25 preview dated 15 Apr isn’t included in the RP2350 MicroPython repo, because the most recent commit isn’t that new. I checked the Pimoroni RP2040 repo, wondering if maybe the RP2040 and RP2350 were merged. But that repo clearly said only for RP2040, not 2350. Adding to the confusion is that there are Pimoroni MicroPython builds targeting the Raspberry Pi Pico, Pico2 and Pico2W.

(1) Request some more explanation regarding the prebuilt UF2 files. The big table in the repo looks like a great approach, but it is not clear since the file name and uname() are different, and the Pico 2 product page takes you to a different, and newer, build.

(2) Please point to the Pimoroni custom build directories (that normally would go in the ports/rp2/boards/ folder. I normally prefer to build my own firmware, anyway, avoiding much of the above confusion.

Note: the underlying problem that got me digging into the UF2 version numbers is descibed at the end of this GitHub issue about custom USB descriptors.

[Gadgetoid]

As of the changes introduced in #18 - which includes experimental, to-be revised support for RM2 wireless modules - the 2 and 2W builds are the same because you can connect an RM2 to a 2 and effectively get a 2W (it's a little more complicated, but either way both ports need wireless support.)

Everything else is an unholy mess because that's simply the state of the ecosystem at the moment (and, well, and to be fair this repository is in dire need of revisiting.)

We're not just shipping MicroPython builds, but actively participating in its development and releasing products with features that aren't merged, or even finalised in MicroPython. It's all somewhat confusing. We're getting there. Mostly by splitting out RP2350-compatible boards into their own succinct repositories where it's easier to clearly communicate what does what.

As for builds, the source of truth for some of the RP2350 builds is here: https://github.com/pimoroni/pimoroni-pico-rp2350/tree/feature/wireless

And the board definitions are here: https://github.com/pimoroni/pimoroni-pico-rp2350/tree/feature/wireless/boards

(Plasma, notably, has been obsoleted by one of those separate repositories: https://github.com/pimoroni/plasma)

And all the build steps are enshrined in ci/micropython.sh here: https://github.com/pimoroni/plasma/blob/main/ci/micropython.sh

Usually I do something like this for local builds:

• git clone https://github.com/pimoroni/pimoroni-pico-rp2350 -b feature/wireless
• cd pimoroni-pico-rp2350
• mkdir build
• cd build
• source ../ci/micropython.sh
• ci_prepare_all
• ci_cmake_configure pimoroni_pico_plus2

Then to rebuild:

• ci_cmake_build pimoroni_pico_plus2

One day I'll migrate this bash tedium into CMake itself, but this takes care of the dependencies (custom MicroPython versions, and some filesystem packaging and post processing tools) our average build now relies on.

[helgibbons]

I've updated the table in #42 so it should hopefully be a bit less confusing. I'll take a look at the Pico Plus 2 shop page links too!

[thestumbler]

Thanks. I'll try that out. Usually I build from the appropriate ports directory in my local clone of the MicroPython repo. Is there anything about these Pimoroni build steps that precludes doing it that way?

[Gadgetoid]

Is there anything about these Pimoroni build steps that precludes doing it that way?

Basically everything. In a sense they are to MicroPython what Ubuntu is to Debian.

[thestumbler]

That analogy helps a lot. So, one can use the Pimoroni "fork", if you will, of MicroPython to build binaries for both Pimoroni- and Raspberry Pi-based RP2 modules. Is the opposite true also, using main MicroPython, one can also build binaries for Pimoroni boards?

Are the differences / features that Pimoroni MicroPython brings to the table summarized anywhere? Somehow I have completely missed this distinction between the two over the last few years.

[Gadgetoid]

Are the differences / features that Pimoroni MicroPython brings to the table summarized anywhere?

Currently no, but the main difference is our batteries-included approach where we have drivers for many of our own modules built in to the firmware. This includes display drivers and graphics libraries that differ significantly from what's available in MicroPython and take a fundamentally different approach to that of Adafruit's CircuitPython DisplayIO.

For specific products, such as Plasma, we will have board definitions and drivers that fit that product, and for things such as Badger our customisations run deep, diverging from MicroPython into a custom firmware with features that aren't easy or suitable to upstream back into MicroPython.

Sometimes we'll exploit our builds to be a little more agile- pulling in MicroPython fixes/improvements before official releases - or less agile - tracking behind the latest MicroPython to avoid unnecessary busywork updating products. Sometimes we'll outright fork and patch MicroPython for some feature that isn't quite ready or reasonable for upstream.

In all cases, where something can be upstreamed I will make every effort to make sure we do so.

When Pico first dropped we were new to the MicroPython ecosystem. We opted to write libraries in C++ and wrap them up in bindings for MicroPython to avoid having to write every library twice (C++ for C++ users, Python for MicroPython users). In hindsight I don't particularly like this approach (it's difficult to maintain, makes for bloated builds, doesn't allow users of other MicroPython boards to use our drivers, doesn't play well to the strengths of each language, and so on) and am trying to move us toward pure-MicroPython drivers where it makes sense.

I'd like our custom Pico and Pico 2 builds to be obsolete, or at least reduced down to the customisations that really matter.

[kocouj1]

As of the changes introduced in #18 - which includes experimental, to-be revised support for RM2 wireless modules - the 2 and 2W builds are the same because you can connect an RM2 to a 2 and effectively get a 2W (it's a little more complicated, but either way both ports need wireless support.)

Everything else is an unholy mess because that's simply the state of the ecosystem at the moment (and, well, and to be fair this repository is in dire need of revisiting.)

We're not just shipping MicroPython builds, but actively participating in its development and releasing products with features that aren't merged, or even finalised in MicroPython. It's all somewhat confusing. We're getting there. Mostly by splitting out RP2350-compatible boards into their own succinct repositories where it's easier to clearly communicate what does what.

As for builds, the source of truth for some of the RP2350 builds is here: https://github.com/pimoroni/pimoroni-pico-rp2350/tree/feature/wireless

And the board definitions are here: https://github.com/pimoroni/pimoroni-pico-rp2350/tree/feature/wireless/boards

(Plasma, notably, has been obsoleted by one of those separate repositories: https://github.com/pimoroni/plasma)

And all the build steps are enshrined in ci/micropython.sh here: https://github.com/pimoroni/plasma/blob/main/ci/micropython.sh

Usually I do something like this for local builds:

• git clone https://github.com/pimoroni/pimoroni-pico-rp2350 -b feature/wireless
• cd pimoroni-pico-rp2350
• mkdir build
• cd build
• source ../ci/micropython.sh
• ci_prepare_all
• ci_cmake_configure pimoroni_pico_plus2

Then to rebuild:

• ci_cmake_build pimoroni_pico_plus2

One day I'll migrate this bash tedium into CMake itself, but this takes care of the dependencies (custom MicroPython versions, and some filesystem packaging and post processing tools) our average build now relies on.

Hi @Gadgetoid,
Thank you very much for this "tutorial". I was able to use it to build Micropython with Pimoroni libs for RISC-V target (Raspberry Pico 2W). This build is normally not available.

If somebody would like to know the steps, I can describe... Only downside is that you have to modify some configuration files every time you pull from Git.

Jakub