Can't build it: Error

/home/robert/Downloads/MicroPython/micropython/ports/rp2/main.c:11:10: fatal error: tusb.h: No such file or directory
 #include "tusb.h"
          ^~~~~~~~
compilation terminated.

It's the include path to lib/tinyusb/src, which is missing. Where to add?

OK. Adding that path as a hot fix to flags.make, the next build error comes up:

/home/robert/Downloads/MicroPython/micropython/ports/rp2/mphalport.c: In function 'mp_hal_stdout_tx_strn':
/home/robert/Downloads/MicroPython/micropython/ports/rp2/mphalport.c:112:21: error: 'CFG_TUD_CDC_EP_BUFSIZE' undeclared (first use in this function); did you mean 'CFG_TUD_CDC_TX_BUFSIZE'?
             if (n > CFG_TUD_CDC_EP_BUFSIZE) {
                     ^~~~~~~~~~~~~~~~~~~~~~
                     CFG_TUD_CDC_TX_BUFSIZE

It's the include path to lib/tinyusb/src, which is missing. Where to add?

I was able to build this -- all I did was run:

git submodule update --init --recursive lib/tinyusb lib/pico-sdk

You can probably avoid the full recursive clone (also note that lib/pico-sdk itself has tinyusb as a submodule) but that's the easiest thing that works.

Fails:
Klone nach '/home/robert/Downloads/MicroPython/micropython/lib/pico-sdk/lib/tinyusb' ...
git@github.com: Permission denied (publickey).

I can update the submodules w/o the --recursive option.

Fails:
Klone nach '/home/robert/Downloads/MicroPython/micropython/lib/pico-sdk/lib/tinyusb' ...
git@github.com: Permission denied (publickey).

I can update the submodules w/o the --recursive option.

It looks like the pico-sdk has the tinyusb submodule set to use an ssh (rather than http) URL.

They just fixed this a couple of hours ago upstream. raspberrypi/pico-sdk@493ed00

As a temporary workaround (until this PR is updated to change the revision for the pico-sdk submodule), you can do

cd lib/pico-sdk
git fetch origin
git checkout 493ed00
git submodule update --init --recursive lib/tinyusb

(Or set up ssh auth for github)

No joy. I wait until this PR has been fixed (and the boards arrive).

The rp2 port now builds under CI. If you look at the ci_rp2_build function in tools/ci.sh that will tell you how to get it to build.

Hopefully we can eventually use the local tinyusb (ie lib/tinyusb) instead of the nested one (ie instead of lib/pico-sdk/lib/tinyusb).

Thanks. Now building works. And yes - ssh auth for github is just another PITA to come.

Works and builds run on the target. Very fine port! Which options are required for mpy-cross? I can embed files as frozen bytecode, but for manually compiled files the device complains about an incompatible version.

Which options are required for mpy-cross? I can embed files as frozen bytecode, but for manually compiled files the device complains about an incompatible version.

Ah, it's because MICROPY_PY_BUILTINS_STR_UNICODE wasn't enabled and mpy-cross defaults to targets that support this feature. Not enabling that option was an oversight and it's now enabled in the latest commit in this PR.

Thanks. Now it works.

The CMake build system added for this port isn't quite at feature parity with the Makefile approach used elsewhere-

As near as I can tell, the fixes here are missing - https://github.com/raspberrypi/micropython/pull/3 - and user C/C++ module support in general is lacking. IE I cannot:

make USER_C_MODULES=../../../../pimoroni-pico/micropython/modules/ -C ports/rp2

With the fixes in my PR, and the additions to the CMake build system in the feature branch that it's targeting... I can. And, in fact, do:

https://github.com/pimoroni/pimoroni-pico/blob/2a7f8f47817ed8c7f404301cb73ad10fab085e52/.github/workflows/micropython.yml#L62-L76

Edit: In fact, porting MicroPython to CMake seems like rather a more elaborate exercise than simply including the relevant Pico SDK files into a regular MicroPython Makefile so that there remains only one way of including/building USER_C_MODULES (which is already a documented process). Am I missing something here? CircuitPython seem to be taking this approach - https://github.com/adafruit/circuitpython/blob/45b3c9ae4213008da092d5bb35e8602e1e90bca2/ports/raspberrypi/Makefile#L159-L184

Referring to raspberrypi/micropython/issues/9 - the API for the machine.Pin class is different in this port than in the standard API.

Given the API at https://docs.micropython.org/en/latest/library/machine.Pin.html (specifically the methods mode(), pull(), on(), and off()),
On the RP2040 these functions have been replaced:

• init() replaces both mode() and pull(),
• high() replaces on()
• low() replaces off()

Presumably this is deliberate - what's the rationale? Will this change be documented somewhere? As of this moment the only way to realize this change has occurred is to stumble into it and then read the source code trying to find out why the API functions are missing, unless I'm missing something obvious (always a possibility)

pull() and mode() are supported in the stm32 port (only). They return the respective pull and mode setting. Setting of pull and mode had to be done with init() or as part of the object construction.
high() and low() were used before the introduction of on() and off() and are definitely better than these, on89 and off() were often misleading, because with a typical LED connection for instance on() would switch the LED off and the opposite.

Fair enough. It sounds like this might be a documentation/consistency issue - why doesn't the website list that those functions are only for STM32? (Also, I note that it doesn't appear that it's only the ST family that use these, the ESP chips also appear to use on()/off(), at least according to their respective machine_pin.c files). To be clear, I don't really mind, I just thought it might have been an oversight. Is there a different docs website for the RP2040 implementation of MicroPython?

More undocumented incompatibilities in the machine module doesn't sound good :-(

Port specific variation is a can of worms for those of us who try to write cross-platform code. The purpose of the machine module (as I understand it) was to facilitate port-independence.

Another hiccups I ran into:
const() is not available by default. It has to be imported from micropython. A trial build shows, that including it costs 400 bytes, or ~0.1% of the image. Still quite large.
The ure module is also not included (many other modules too I assume), but that may be less important than difference e.g. in the machine module. Keeping the firmware small is a valid objective.

The ure module is also not included

I don’t know how useful or widespread things like ure or ujson are in the micro world, but I’m including them both in our build at the request of a user. It looks like there’s a fair amount of headroom and that module choice is pretty conservative. From a vendor perspective the 2MB flash on Pico is already very conservative and I don’t see many RP2040-based boards shipping with less. Indeed they seem to be targeting 16MB and at least some of these (probably ours) will be compatible with an unmodified MicroPython binary.

I don’t know how useful or widespread things like ure or ujson are in the micro world

Very (IMO). For object serialisation ujson uses less RAM and is more efficient than pickle. From forum posts I would say that ure is also widely used.

Is there a stable link that would go to the latest UF2 file that I could point the "Download UF2" button at on the Pico Landing page?

Hmm... not at the moment, I'd have to set something up. It would be good for it to point to a truly stable release version, eg the upcoming v1.14 release, rather than daily (unstable) builds. Would you agree?

Ping @aivarannamaa also, as he might find a stable link useful for Thonny too?
(Aivar: I believe you can get the version of MicroPython in the UF2 using the https://github.com/raspberrypi/picotool/ command, which might be more reliable than trying to get the version from the filename?)

I'd have to set something up. It would be good for it to point to a truly stable release version, eg the upcoming v1.14 release, rather than daily (unstable) builds. Would you agree?

Agreed.

Hopefully this can get clarified in the documentation at some point?

See #6822 for docs clarification of machine.Pin.

@lurch

I believe you can get the version of MicroPython in the UF2 using the https://github.com/raspberrypi/picotool/ command, which might be more reliable than trying to get the version from the filename?

I'd rather avoid adding another dependency. Also, I chose to introduce my own web resource for directing Thonny to the recommended MicroPython for Pico (which would be the latest stable unless it is known to have problems in Thonny).

@aivarannamaa Cool, I didn't realise you already had your own system in place 🙂 (but FYI you'll want to update that to use https://github.com/micropython/micropython/releases instead of https://github.com/raspberrypi/micropython/releases once Damien has released v1.14)

I'd have to set something up. It would be good for it to point to a truly stable release version, eg the upcoming v1.14 release, rather than daily (unstable) builds. Would you agree?

Agreed.

@dpgeorge While I'm waiting for this — since the nightly with the V1.0.1 SDK should fix the GP19 problem — should I pull in today's nightly build and link to this from the Getting Started page, rather than the UF2 that was build for release day?

should I pull in today's nightly build

Yes. There's now a v1.14 stable release available which you can link to: https://micropython.org/resources/firmware/rp2-pico-20210202-v1.14.uf2

Did you want that to be a permanent version-agnostic link that automatically pointed to the latest stable, something like micropython.org/resources/firmware/rp2-pico/latest.uf2 ?

Did you want that to be a permanent version-agnostic link that automatically pointed to the latest stable, something like micropython.org/resources/firmware/rp2-pico/latest.uf2 ?

Yes please, that would be optimal. Then I can link to it directly from the "Download UF2" button on the Getting Started page.

micropython_latest.uf2 (or rp2_micropython_latest.uf2) might be a more useful filename than just latest.uf2 ? 😉 (I'm thinking of the poor confused user who finds a latest.uf2 in their Downloads folder and has no idea what it is!)

micropython_latest.uf2 (or rp2_micropython_latest.uf2) might be a more useful filename than just latest.uf2 ? 😉 (I'm thinking of the poor confused user who finds a latest.uf2 in their Downloads folder and has no idea what it is!)

Maybe it's even better to set up a redirect or Content-Disposition header with a different filename, so that the downloaded file has version number in its name?

Maybe it's even better to set up a redirect or Content-Disposition header with a different filename

Yes that could work. I can do:

Content-Disposition: attachment; filename="rp2-pico-v1.14.uf2"

Yup. That'd work for me I think.

Ok, the redirect is here: https://micropython.org/download/rp2-pico/rp2-pico-latest.uf2

Ok, the redirect is here: https://micropython.org/download/rp2-pico/rp2-pico-latest.uf2

Cool, in Chromium on my Ubuntu laptop that link gives me a rp2-pico-20210202-v1.14.uf2 file 👍

Thanks @dpgeorge. I've swapped out the link on the Getting Started page and other places to point to that URL.