Code size report:

   bare-arm:    +0 +0.000% 
minimal x86:    +0 +0.000% 
   unix x64:    +0 +0.000% standard
      stm32:    +0 +0.000% PYBV10
     mimxrt:    +0 +0.000% TEENSY40
        rp2:  -108 -0.012% RPI_PICO_W[incl +68(bss)]
       samd:    +0 +0.000% ADAFRUIT_ITSYBITSY_M4_EXPRESS
  qemu rv32:    +0 +0.000% VIRT_RV32

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 98.57%. Comparing base (fa942d5) to head (51663b9).
Report is 31 commits behind head on master.

@@           Coverage Diff           @@
##           master   #15619   +/-   ##
=======================================
  Coverage   98.57%   98.57%           
=======================================
  Files         164      164           
  Lines       21336    21336           
=======================================
  Hits        21031    21031           
  Misses        305      305           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Pre-built firmware can be found here: https://micropython.org/download/RPI_PICO2/

work out why RPI_PICO_W build has increased so much

Build size, or build time? Do we need to set -DPICO_NO_COPRO_DIS=1?

Build size, or build time? Do we need to set -DPICO_NO_COPRO_DIS=1?

Build/firmware size.

Setting DPICO_NO_COPRO_DIS=1 does not seem to change anything (on RP2040 builds at least).

work out why RPI_PICO_W build has increased so much

It looks like this is due to the new always-on timer (aon timer) code, which calls localtime_r(), which subsequently pulls in timezone support and calls to large printf and scanf functions (from the C stdlib, newlib).

It doesn't look easy to remove all that code even though it's probably never used by MicroPython. So we may have to live with it.

Hmm so aon_timer_set_time() calls time_to_datetime() from pico_util.

It might be possible to provide our own pico_util with a more MicroPython-friendly alternative for that function, or just to shim localtime_r, eg:

target_link_options(${MICROPY_TARGET} PRIVATE "LINKER:--wrap=localtime_r")

struct tm* __wrap_localtime_r(time_t *time, struct tm *local_time) {
    return gmtime_r(time, local_time);
}

Which I think resolves to mbedtls_platform_gmtime_r

Edit: See: dpgeorge/micropython@rp2-add-rp2350...pimoroni:micropython:patch-localtime_r

It might be possible to provide our own pico_util with a more MicroPython-friendly alternative for that function, or just to shim localtime_r, eg:

Good idea.... but I tried your patch and it did not work, it only reduced firmware size by about 1k. We need to reclaim 17k.

Looking at firmware.elf for RPI_PICO, it still pulls in iswspace (for example, wide character handling), which is needed by siscanf, which is needed by _tzset_unlocked, which is needed by mktime, which is needed by datetime_to_time, which is needed by aon_timer_get_time.

Ah, yes, this might be a vote against using the aon_timer API on RP2040 after all - the POWMAN timer is not date based, but the RTC one is, so one of them takes the hit for a common API :-( ... we should probably add both forms for both though (and maybe a documentation warning)

Here's an extended version of @Gadgetoid's patch that gets the code size all the way down (PICO_W binary size is actually slightly smaller than the current master). I have verified this compiles and boots but I have not tested it further:
projectgus@debc0ad

(Two tips for anyone who is interested: 1. Linker wrap is actually not necessary for any symbol that is linked from a library, as any object provided on the linker command line will take precedence. Great blog post on the details. 2. The --cref linker option is worth its weight in gold for figuring this stuff out. I will submit a PR to add it either to pico-sdk or rp2 port linker command lines.)

Here's an extended version of @Gadgetoid's patch that gets the code size all the way down

I've said it once, I'll say it again, Open Source is just the formal version of posting the wrong answer on the internet to get the right one 😆 thank you!

I've just run our batteries-included builds against this branch and that extra 17k blows our flash budget 😬

Hey. I just wanted to chime in here to point out that one of our PGA2350 users (which uses the B chip) was not able to use PWM on the pins above 31. Checking this repo, it seems machine_pwm has no additions for the extra 8 channels yet.

Afacit PWM just needs this: pimoroni@7f1fcc7

I'll cut some builds to test it!

PGA builds here should include the fix: https://github.com/pimoroni/pga/actions/runs/10391381219
Plus PPP2 here: https://github.com/pimoroni/pimoroni-pico-rp2350/actions/runs/10385135105

Edit 2: Afaict this fix works. @dpgeorge if you don't mind casting your eye over it and cherry-picking into your RP2350 feature branch, I can rebase accordingly. Thank you!

Thanks @Gadgetoid . Looks like there's at least one hardcoded slice count left:

void machine_pwm_deinit_all(void) {
    for (int i = 0; i < 8; i++) {
        slice_freq_set[i] = false;
        pwm_set_enabled(machine_pwm_obj[i].slice, false);
    }
}

Good spot! Curse the magic numbers! Pushed a fix.

Edit: Updated the link above, but for clarity the patch is now: pimoroni@7f1fcc7

Our very own Hodgy has a PGA2350 set up with all of the PWM (it looks like an electronic mangrove) and confirmed this works.

Built RPI_PICO2 and deployed it to the Seeed XIAO RP2350; it boots and at least some basic operations appear to be working fine! 😄

> mpremote
Connected to MicroPython at /dev/ttyACM0
Use Ctrl-] or Ctrl-x to exit this shell
MicroPython v1.24.0-preview.203.gb9f6698d30.dirty on 2024-08-23; Raspberry Pi Pico2 with RP2350
Type "help()" for more information.
>>> from machine import Pin
>>> # Check user LED
>>> led = Pin(25, Pin.OUT)
>>> led.toggle()
>>> # Check RGB LED
>>> power_pin = Pin(23, Pin.OUT) # Provide power first
>>> power_pin.value(1)
>>> from neopixel import NeoPixel
>>> neo = NeoPixel(Pin(22), 1)
>>> neo[0] = (0, 0, 40)
>>> neo.write() # Blue LED

Here's an extended version of @Gadgetoid's patch that gets the code size all the way down (PICO_W binary size is actually slightly smaller than the current master).

Thanks for that, I've now added that commit to this PR.

decide on board name: RPI_PICO2 vs RPI_PICO_2 (latter matches RPI_PICO_W, and officially it's Pico 2)

The decision is to stick with RPI_PICO2, and then also RPI_PICO2_W (eventually), because that matches the pico-sdk header file names: pico.h, pico_w.h, pico2.h and pico2_w.h

Looks like I have some PSRAM rebasing to do! Will sure make it easier to play with the new UART/PPP stuff 😁

(I know you’re probably still working your way down here, but don’t miss the PWM patch above! - pimoroni@7f1fcc7 )

Might be my board config, but I run into this when trying to build for RP2350B or PICO_NUM_GPIOS=48-

/home/runner/work/pimoroni-pico-rp2350/pimoroni-pico-rp2350/micropython/ports/rp2/rp2_pio.c: In function 'rp2_pio_gpio_base':
/home/runner/work/pimoroni-pico-rp2350/pimoroni-pico-rp2350/micropython/ports/rp2/rp2_pio.c:411:48: error: 'pin_GPIO0' undeclared (first use in this function)
  411 |     return pio_get_gpio_base(self->pio) == 0 ? pin_GPIO0 : pin_GPIO16;
      |                                                ^~~~~~~~~

Edit: Might need to include pins.h for these?

Edit2: Looks like nrf uses #include "genhdr/pins.h" but doing this on RP2 causes:

genhdr/pins.h:2:21: error: 'machine_pin_obj_table' undeclared (first use in this function)
    2 | #define pin_GPIO0 (&machine_pin_obj_table[0])
      |                     ^~~~~~~~~~~~~~~~~~~~~

Since this table is defined in <BOARD_NAME>_pins.c (included in the CMakeLists) but not declared anywhere. machine_pin.c kinda fudges around this by including extern const machine_pin_obj_t machine_pin_obj_table[NUM_BANK0_GPIOS]; but that doesn't make pins accessible elsewhere...

Oh also:

micropython/ports/rp2/rp2_pio.c: In function 'rp2_pio_gpio_base':
micropython/ports/rp2/rp2_pio.c:415:58: error: return discards 'const' qualifier from pointer target type [-Werror=discarded-qualifiers]
  415 |     return pio_get_gpio_base(self->pio) == 0 ? pin_GPIO0 : pin_GPIO16;

The following heinous patch gets things building for me again:

diff --git a/ports/rp2/CMakeLists.txt b/ports/rp2/CMakeLists.txt
index 5e69da4b8..9dc5dbc94 100644
--- a/ports/rp2/CMakeLists.txt
+++ b/ports/rp2/CMakeLists.txt
@@ -538,6 +538,12 @@ set_source_files_properties(
     COMPILE_OPTIONS "-O2"
 )
 
+set_source_files_properties(
+    rp2_pio.c
+    PROPERTIES
+    COMPILE_OPTIONS "-Wno-error=discarded-qualifiers"
+)
+
 set_source_files_properties(
     ${PICO_SDK_PATH}/src/rp2_common/pico_double/double_math.c
     ${PICO_SDK_PATH}/src/rp2_common/pico_float/float_math.c
diff --git a/ports/rp2/rp2_pio.c b/ports/rp2/rp2_pio.c
index 8e91c1d8f..0d8854715 100644
--- a/ports/rp2/rp2_pio.c
+++ b/ports/rp2/rp2_pio.c
@@ -32,11 +32,15 @@
 #include "py/mphal.h"
 #include "shared/runtime/mpirq.h"
 #include "modrp2.h"
+#include "machine_pin.h"
+#include "genhdr/pins.h"
 
 #include "hardware/clocks.h"
 #include "hardware/irq.h"
 #include "hardware/pio.h"
 
+extern const machine_pin_obj_t machine_pin_obj_table[NUM_BANK0_GPIOS];
+
 typedef struct _rp2_pio_obj_t {
     mp_obj_base_t base;
     PIO pio;

This is finally merged! Thanks to everyone here who contributed/helped/tested/reviewed.