Arduino-Pico (Earlephilhower) support, PicoProbe Debugging

Massive upgrade.

Add support for building for https://github.com/earlephilhower/arduino-pico
As in the style of platform-ststm32, boards that can be used with both cores can be switched to the other core using board_build.core = earlephilhower
Integrates with my already merged builder script at https://github.com/earlephilhower/arduino-pico/blob/master/tools/platformio-build.py
Added all Arduino-Pico boards (Earle auto-gen'ed them through https://github.com/earlephilhower/arduino-pico/blob/master/tools/makeboards.py)
Arduino core must use toolchain and tools from https://github.com/earlephilhower/pico-quick-toolchain/releases, which are finally in the registry

no more platform_packages injection platformio.ini needed, all tools (except framework) sourced from registry

Replace outdated platformio/tool-openocd-raspberrypi (1 year old, before picoprobe merge) with earlephilhower/tool-openocd-rp2040-earlephilhower -- works for all frameworks and cores (also the mbed-os core)
Added support for LittleFS filesystem building + uploading through picotool and OpenOCD (picoprobe etc.); Arduino-Pico core supports LittleFS
Added and tested Picoprobe support for both ArduinoCore-mbed and Arduino-Pico, works great
Reduced default debugging and OpenOCD upload speed to 1000kHz, the 5000kHz was giving me verification errors
Add Arduino-Pico examples to CI
Reprogrammed upload_protocol = mbed to make more sense, it previously tried to upload the .bin file to the drive instead of the .uf2 file
Update SVD file with latest from https://github.com/raspberrypi/pico-sdk/blob/master/src/rp2040/hardware_regs/rp2040.svd

Test at will with
[env]
platform = https://github.com/maxgerhardt/platform-raspberrypi.git
framework = arduino
board_build.core = earlephilhower
board_build.filesystem_size = 0.5m

[env:pico]
board = pico
; if using picoprobe SWD upload / debugging
;upload_protocol = picoprobe
;debug_tool = picoprobe
; note: newer PicoProbe firmwares emulate a CMSIS-DAP, so you
; use "cmsis-dap" as upload_protocol and debug_tool.
; for more info see docs https://arduino-pico.readthedocs.io/en/latest/platformio.html

ToDo (all done at the moment of writing):

create PR for platformio-docs, previous docs at https://arduino-pico.readthedocs.io/en/latest/platformio.html are outdated
create PR for arduino-pico docs as docs is now outdated
fix https://github.com/earlephilhower/arduino-pico/issues/612
upload / make Earle upload framework-arduinopico package (after fix of course)

And please squash upon merge, otherwise you have more than 43 commits from me.

Build failed on maOS.

You are using an outdated platformio.ini. CLI ->  pio platform update https://github.com/maxgerhardt/platform-raspberrypi.git, then use the exact platformio.ini above.

Ok, I can now compile but I get some ugly warning and errors.

Can you Cmd+Shift+P -> Rebuild Intellisense and upload the .vscode/c_cpp_properties.json to pastebin.com/?

Here the cpp.json
// // !!! WARNING !!! AUTO-GENERATED FILE! // PLEASE DO NOT MODIFY IT AND USE "platformio.ini": // https://docs.platformio.org/page/projectconf/section_env_build.html#build-flags // {     "configurations": [         {             "name": "PlatformIO",             "includePath": [                 "/Users/sstaub/Dateien/Development/Raspberry Pico/blinky2/include",                 "/Users/sstaub/Dateien/Development/Raspberry Pico/blinky2/src",                 "/Users/sstaub/.platformio/packages/framework-arduinopico/cores/rp2040",                 "/Users/sstaub/.platformio/packages/framework-arduinopico/cores/rp2040/api/deprecated",                 "/Users/sstaub/.platformio/packages/framework-arduinopico/cores/rp2040/api/deprecated-avr-comp",                 "/Users/sstaub/.platformio/packages/framework-arduinopico/tools/libpico",                 "/Users/sstaub/.platformio/packages/framework-arduinopico/variants/rpipico",                 "/Users/sstaub/.platformio/packages/framework-arduinopico/libraries/EEPROM",                 "/Users/sstaub/.platformio/packages/framework-arduinopico/libraries/ESP8266SdFat/src",                 "/Users/sstaub/.platformio/packages/framework-arduinopico/libraries/FreeRTOS/src",                 "/Users/sstaub/.platformio/packages/framework-arduinopico/libraries/I2S/src",                 "/Users/sstaub/.platformio/packages/framework-arduinopico/libraries/Keyboard/src",                 "/Users/sstaub/.platformio/packages/framework-arduinopico/libraries/LittleFS/src",                 "/Users/sstaub/.platformio/packages/framework-arduinopico/libraries/Mouse/src",                 "/Users/sstaub/.platformio/packages/framework-arduinopico/libraries/PDM/src",                 "/Users/sstaub/.platformio/packages/framework-arduinopico/libraries/SD/src",                 "/Users/sstaub/.platformio/packages/framework-arduinopico/libraries/SDFS/src",                 "/Users/sstaub/.platformio/packages/framework-arduinopico/libraries/SPI/src",                 "/Users/sstaub/.platformio/packages/framework-arduinopico/libraries/Servo/src",                 "/Users/sstaub/.platformio/packages/framework-arduinopico/libraries/Wire/src",                 "/Users/sstaub/.platformio/packages/framework-arduinopico/libraries/rp2040",                 ""             ],             "browse": {                 "limitSymbolsToIncludedHeaders": true,                 "path": [                     "/Users/sstaub/Dateien/Development/Raspberry Pico/blinky2/include",                     "/Users/sstaub/Dateien/Development/Raspberry Pico/blinky2/src",                     "/Users/sstaub/.platformio/packages/framework-arduinopico/cores/rp2040",                     "/Users/sstaub/.platformio/packages/framework-arduinopico/cores/rp2040/api/deprecated",                     "/Users/sstaub/.platformio/packages/framework-arduinopico/cores/rp2040/api/deprecated-avr-comp",                     "/Users/sstaub/.platformio/packages/framework-arduinopico/tools/libpico",                     "/Users/sstaub/.platformio/packages/framework-arduinopico/variants/rpipico",                     "/Users/sstaub/.platformio/packages/framework-arduinopico/libraries/EEPROM",                     "/Users/sstaub/.platformio/packages/framework-arduinopico/libraries/ESP8266SdFat/src",                     "/Users/sstaub/.platformio/packages/framework-arduinopico/libraries/FreeRTOS/src",                     "/Users/sstaub/.platformio/packages/framework-arduinopico/libraries/I2S/src",                     "/Users/sstaub/.platformio/packages/framework-arduinopico/libraries/Keyboard/src",                     "/Users/sstaub/.platformio/packages/framework-arduinopico/libraries/LittleFS/src",                     "/Users/sstaub/.platformio/packages/framework-arduinopico/libraries/Mouse/src",                     "/Users/sstaub/.platformio/packages/framework-arduinopico/libraries/PDM/src",                     "/Users/sstaub/.platformio/packages/framework-arduinopico/libraries/SD/src",                     "/Users/sstaub/.platformio/packages/framework-arduinopico/libraries/SDFS/src",                     "/Users/sstaub/.platformio/packages/framework-arduinopico/libraries/SPI/src",                     "/Users/sstaub/.platformio/packages/framework-arduinopico/libraries/Servo/src",                     "/Users/sstaub/.platformio/packages/framework-arduinopico/libraries/Wire/src",                     "/Users/sstaub/.platformio/packages/framework-arduinopico/libraries/rp2040",                     ""                 ]             },             "defines": [                 "PLATFORMIO=60003",                 "ARDUINO_RASPBERRY_PI_PICO",                 "ARDUINO_ARCH_RP2040",                 "USBD_MAX_POWER_MA=500",                 "ARDUINO=10810",                 "ARDUINO_ARCH_RP2040",                 "F_CPU=133000000L",                 "BOARD_NAME=\"pico\"",                 "CFG_TUSB_MCU=OPT_MCU_RP2040",                 "USB_VID=0x2e8a",                 "USB_PID=0x000a",                 "USB_MANUFACTURER=\"Raspberry Pi\"",                 "USB_PRODUCT=\"Pico\"",                 "SERIALUSB_PID=0x000a",                 ""             ],             "cStandard": "c17",             "cppStandard": "c++17",             "compilerPath": "/Users/sstaub/.platformio/packages/toolchain-rp2040-earlephilhower/bin/arm-none-eabi-gcc",             "compilerArgs": [                 "-march=armv6-m",                 "-mcpu=cortex-m0plus",                 "-mthumb",                 "-iprefix/Users/sstaub/.platformio/packages/framework-arduinopico"<EMAIL_ADDRESS>                ""             ]         }     ],     "version": 4 }

Intellisense rebuild doesn't help.
I have seen the same problem some times ago on the MS Arduino plugin for VSC and also at the Arduino IDE 2.0

Can you, just as a test, add
build_flags = -I/Users/sstaub/.platformio/packages/framework-arduinopico/pico-sdk/src/rp2_common

to the platformio.ini and rebuild Intellisense again? Are all errors gone or does it show more nested errors..

Also that is what I get:

Windows has no problem here.

Only other thing I can test is on Linux since I don't have a Mac.

No changes.

I will look deeper inside tomorrow .

Compilation works because the include folders specified in https://github.com/earlephilhower/arduino-pico/blob/master/lib/platform_inc.txt are included in compilation with https://github.com/earlephilhower/arduino-pico/blob/578d3d2a768bff6b7d978c3eb271381c4a0fdc72/tools/platformio-build.py#L45-L46, but this does not show up in .vscode/c_cpp_properties.json since the builder script does not export it in CPPPATH. The problem is, if I do it there, then it's double in there with -iprefix. If I remove -iprefix,  I deviate from the Arduino compilation.

This is reproducable on Linux too. I will push a fix in the builder script for this.

This will be fixed by https://github.com/earlephilhower/arduino-pico/pull/615 (not an issue platform-raspberrypi or this PR).
@sstaub if you want to test it out, please replace the contents of /Users/sstaub/.platformio/packages/framework-arduinopico/tools/platformio-build.py with the new version and rebuild intellisense again.

Tested on Arch Linux, both the uf2 & picoprobe upload work great! Nice work!
I didn't test debugging.

The errors and warnings passed away. Now I have to check uploading. Thanks

@sstaub It seems the Intellisense issue is caused by Microsoft, not PlatformIO's builder script: See https://github.com/platformio/builder-framework-arduino-core-mbed/issues/4. Downgrading the C/C++ by Microsoft extension solved the error. Microsoft's stuff is buggy as hell.

@maxgerhardt I have added automatic Platform.IO publishing of core releases and uploaded the 2.1.1 version (under review).  If it works, then the Platform.IO release will happen automatically on a Arduino package release.  If not, please let me know what I broke and I'll try and correct it!

https://registry.platformio.org/tools/earlephilhower/framework-arduinopico/versions is visible now (thanks @earlephilhower!), I will work on getting a PR in for https://github.com/earlephilhower/arduino-pico/issues/612 and do more testing (possible Adafruit TinyUSB integration faults, recheck race conditions aagin), then I can reference the next stable version.

Hi @maxgerhardt ! Many thanks for an awesome PR. Please check my comments in the review. Does something make sense?

I'm waiting for https://github.com/earlephilhower/arduino-pico/pull/633 to be merged, then I'll merge https://github.com/maxgerhardt/platform-raspberrypi/pull/8 which should resolve the first round of review comments.

Second round of PR comments are worked in.

Thanks for the fixes. LGTM, one last thing is a proper package with the framework. Should we wait for a stable release with the latest changes to the build script?

Yes, we're currently investigating some issue with Multicore / thread safety things (https://github.com/earlephilhower/arduino-pico/issues/614) and TinyUSB (https://github.com/earlephilhower/arduino-pico/issues/630, I need to check the latter myself and the fix for the first thing might require a change to the builder script and toolchain package -- I would wait those two out, then reference the next stable framework version in the platform.json.

The multicore stuff looks to be fixed and I've just published the new toolchain and framework package.

@maxgerhardt are we good to go on this?  The core seems solid multicore (at least there are no known bugs :crossed_fingers: ) and the TinyUSB stuff seems to be upstream related and more of a "works, but is/always was awkward" than "is busted."
Only thing you might check, is that if you hardcoded any version numbers of packages.  There was a new toolchain built for the multicore fixes and there have been a couple framework updates (latest published today) from when this was initially proposed...

@earlephilhower I'd say when the Mac OS ARM64 toolchains are uploaded (or rather, reuploaded with just a different manifest) as discussed in https://github.com/earlephilhower/arduino-pico/issues/661#issuecomment-1168447394 then a new 2.0.2 should be released so that the PlatformIO fix https://github.com/earlephilhower/arduino-pico/pull/658 is integrated. Then I can reference fixed versions for both toolchain + framework and do a final and, then this would be good to merge.

I've updated the package.json to use the latest stable 2.0.2 release and the latest toolchain, the latter by fixed version (5.100300.220629). That is because as long as the underlying GCC version is 10.3.0, it will be using 5.100300.x, but still breaking changes can be made between two x versions but for a specific core version, the toolchain version should be exactly fixed.
@valeros I have no further things to add to this PR :)

Awesome, thanks!  (BTW, it's 2.2.2, not 2.0.2.  I double checked and you're good).
Apologies for my ignorance, but at this point if I do a new core release (which happens relatively frequently since there are quite a few new boards in the pipe for the RP2040), do I need to do any PR here or will this take the latest core version?  (i.e. only if I need to rev the toolchain do I need to do a PR)?

For the update process multiple scenarios are possible. Basically after this PR the core version and toolchain version and boards would be fixed, and no publishing of packages from your side would auto-update the available platforms here.
For updating the core or toolchain with a new version (after it was uplaoded to the registry), a PR would have to be made that updates these versions in the platform.json. For updating the boards, a PR would have to be made that copies the boards from json to boards.
However both of these actions can also be done by PlatformIO staff directly in this repo without outside PRs. (Though triggering it by PR would be faster in my opinion and experience). Maybe @valeros can propose something for future updates.

It's slightly concerning though that after the registry upload, older versions of the package are gone? Like in https://registry.platformio.org/tools/earlephilhower/framework-arduinopico/versions and https://registry.platformio.org/tools/earlephilhower/toolchain-rp2040-earlephilhower/versions, I could swear there were previous versions before that.

We'll want to make sure that when CI publishes a package the old ones don't get nuked o_o

All I did was pio package publish <file>.  I didn't unpublish anything.  I assumed the PIO guys did it, since this was a pre-release/merge set?

I assumed the PIO guys did it, since this was a pre-release/merge set?

Yes, we set 1 version per package. @maxgerhardt, please check your e-mail to discuss this PR.

Thanks to @earlephilhower's amazing work (❤), we now have Raspberry Pi Pico W support in its first version with a WiFi library in PlatformIO. See arduino-wifi-scan example and use board = rpipicow :)
(Example was also added to the CI here.)

I'm trying to upload a basic blink program using the wiznet_5500_evb_pico board within this PR and I keep getting an upload error. The upload works fine from the Arduino IDE. (Windows)
AVAILABLE: cmsis-dap, jlink, picoprobe, picotool, raspberrypi-swd
CURRENT: upload_protocol = picotool
BeforeUpload(["upload"], [".pio\build\wiznet_5500_evb_pico\firmware.elf"])
Auto-detected: COM4
Forcing reset using 1200bps open/close on port COM4
"C:\Users\Andrew\.platformio\packages\tool-rp2040tools\rp2040load" -v -D .pio\build\wiznet_5500_evb_pico\firmware.elf
rp2040load 1.0.1 - compiled with go1.15.8
.....................
*** [upload] Error 1

If I copy the file .pio\build\wiznet_5500_evb_pico\firmware.uf2 to the drive which opens it works fine. It also works fine if I manually run the following command instead:
"C:\Users\Andrew\.platformio\packages\tool-rp2040tools\rp2040load" -v -D .pio\build\wiznet_5500_evb_pico\firmware.uf2
It appears to be trying to upload the incorrect file but to be honest I'm not that well up on these Picos, PlatformIO and the  upload process in general. Am I doing something wrong or is this a bug for this board?

It could be the Arduino IDE uses a different port? What happens when you plug the board in with BOOTSEL pressed so that the flash drive appears? Does PIO then fail upload too? Did you load WinUSB drivers for the "RP2 Boot2 (Interface 1)" device using Zadig? (Device only appears when Pico is in bootloader mode).
Note that for the very first flash, you may need to manually put to the .uf2 file on the boot drive, for subsequent uploads the COM reset should work then properly.

It's using the same port - At first it couldn't detect it so I set the port manually but later the automatic detection also worked, I wasn't sure what changed for that to work but it might have been when I manually uploaded the uf2 file as you say. I've tried both the COM port and the drive letter.
I've tried with and without using BOOTSEL and have loaded the WinUSB drivers.
I've tried with more verbose logging but it doesn't show anything more that the "Error 1" line.

In the Arduino IDE, does it use rp2040load 1.0.1 - compiled with go1.15.8 too at this version? The

.....................
usually appears when the rp2040load can't find the Pico in bootloader mode or the correct drivers aren't installed so the program can't access it. When you open the Windows device manager, do you see the Pico ejecting and reappearing in bootloader mode?

The Arduino IDE doesn't appear to use rp2040load at all, here's the end of the logs from Arduino IDE:
Sketch uses 48972 bytes (2%) of program storage space. Maximum is 2093056 bytes.
Global variables use 7264 bytes (2%) of dynamic memory, leaving 254880 bytes for local variables. Maximum is 262144 bytes.
C:\Users\Andrew\AppData\Local\Arduino15\packages\rp2040\tools\pqt-python3\1.0.1-base-3a57aed/python3 -I C:\Users\Andrew\AppData\Local\Arduino15\packages\rp2040\hardware\rp2040\2.3.2/tools/uf2conv.py --serial COM4 --family RP2040 --deploy c:\Users\Andrew\Programming\Arduino\.build\GearDisplay/tower-controller-test.ino.uf2
Resetting COM4
Converting to uf2, output size: 104448, start address: 0x2000
Flashing I: (RPI-RP2)
Wrote 104448 bytes to I:/NEW.UF2

Using PlatformIO, it does indeed show up within device manager: (And a few seconds later, the volume opens in Windows Explorer - About 1/3 of the way through the ...)

It then continues waiting before eventually giving up:
<lambda>(["upload"], [".pio\build\wiznet_5500_evb_pico\firmware.elf"])
AVAILABLE: cmsis-dap, jlink, picoprobe, picotool, raspberrypi-swd
CURRENT: upload_protocol = picotool
BeforeUpload(["upload"], [".pio\build\wiznet_5500_evb_pico\firmware.elf"])
Auto-detected: COM4
Forcing reset using 1200bps open/close on port COM4
"C:\Users\Andrew\.platformio\packages\tool-rp2040tools\rp2040load" -v -D .pio\build\wiznet_5500_evb_pico\firmware.elf
rp2040load 1.0.1 - compiled with go1.15.8
.....................
*** [upload] Error 1
=================================================================================== [FAILED] Took 15.42 seconds ===================================================================================

But it shows up as libusb-win32 device, if WinUSB drivers were loaded it should show up under the USB device category (differently named). Can you double check to load WinUSB and not libusb-win32 drivers for the interface 1 device?
And yes I see, the Arduino IDE does a reset into bootloader (through the serial reset) and then copies the file onto the harddrive -- not through rp2040load which uses the boot USB interface. However, rp2040load should in general work still.

Apologies, I completely misread the driver when I looked earlier - I've uninstalled the libusb-win32 driver and re-installed the correct WinUSB and it now works correctly.
Thank you very much!

@maxgerhardt
Does this support logging via RTT?
For a point of comparison, I have another project written in Rust where I use probe-run to program my Pico as well as view debug output via RTT. I have one Pico I use as the debugger (running DapperMime, specifically this file), which connects to my other target Pico via the SWD pins. This lets me program, debug and view logs with just the three SWD pins, and I only need one command line invocation of probe-run to kick it all off. Also, because I power the target Pico through the debugger Pico (by tying the two VSYS together, ditto for GND), I only need the one USB cable to the debugger.
Presently, this is how I have my new Arduino Pico project setup in PIO:
[env:pico]
platform = https://github.com/maxgerhardt/platform-raspberrypi.git
board = pico
framework = arduino
board_build.core = earlephilhower
board_build.filesystem_size = 0m
upload_protocol = cmsis-dap
debug_tool = cmsis-dap

I can successfully program my Pico just as I described above, but when I click PlatformIO: Serial Monitor in VSCode that gives me this window:
 *  Executing task in folder arduino_pico_tests: platformio device monitor

--- Terminal on /dev/ttyACM1 | 9600 8-N-1
--- Available filters and text transformations: colorize, debug, default, direct, hexlify, log2file, nocontrol, printable, send_on_enter, time
--- More details at https://bit.ly/pio-monitor-filters
--- Quit: Ctrl+C | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H

I'm curious if there's any option provided by this work (or maybe its integral to PIO, and orthogonal to this PR -- in which case my apologies for asking here) that would allow me to view RTT output? (And I suppose that would need to use something like koendv/RTT Stream to do the printing, instead of the usual Serial.println)

Using the koendv/RTT Stream library, I've figured out how I can use pyocd to view RTT from another terminal:
$ pyocd rtt --target rp2040 --probe 'cmsisdap:0'
0000244 I Target type is rp2040 [board]
0000265 I DP IDR = 0x0bc12477 (v2 MINDP rev0) [dap]
0000279 I AHB-AP#0 IDR = 0x04770031 (AHB-AP var3 rev0) [ap]
0000299 I AHB-AP#0 Class 0x1 ROM table #0 @ 0xe00ff000 (designer=43b:Arm part=4c0) [rom_table]
0000305 I [0]<e000e000:SCS v6-M class=14 designer=43b:Arm part=008> [rom_table]
0000308 I [1]<e0001000:DWT v6-M class=14 designer=43b:Arm part=00a> [rom_table]
0000311 I [2]<e0002000:BPU v6-M class=14 designer=43b:Arm part=00b> [rom_table]
0000317 I CPU core #0 is Cortex-M0+ r0p1 [cortex_m]
0000322 I 2 hardware watchpoints [dwt]
0000325 I 4 hardware breakpoints, 0 literal comparators [fpb]
0000328 I RTT control block search range [0x20000000, 0x040000] [rtt_cmd]
0000491 I _SEGGER_RTT @ 0x20000e38 with 3 aUp and 3 aDown [rtt_cmd]
hello world!
hello world!
hello world!
hello world!
hello world!
hello world!
hello world!
hello world!
hello world!
hello world!
hello world!
hello world!

Though it would be really great if I could have this integrated into PIO: if I have pyocd printing RTT in another terminal, PIO upload fails from VSCode:
Configuring upload protocol...
AVAILABLE: cmsis-dap, jlink, picoprobe, picotool, raspberrypi-swd
CURRENT: upload_protocol = cmsis-dap
Uploading .pio/build/pico/firmware.elf
Open On-Chip Debugger 0.10.0+dev-ge3428fadb-dirty (2022-07-14-14:57)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
debug_level: 1

adapter speed: 1000 kHz

Error: unable to find CMSIS-DAP device
Error: No Valid JTAG Interface Configured.
*** [upload] Error 255
================================== [FAILED] Took 0.37 seconds ==================================

So I have to stop one to start the other.

if I have pyocd printing RTT in another terminal, PIO upload fails from VSCode:

Yes, one program claims the CMSIS exclusively.

Does this support logging via Real-Time Transfer (RTT)?

Making RTT logs show up in the PlatformIO device monitor would be more suited as a general request for the core: https://github.com/platformio/platformio-core/issues.
However, I think it's pretty trivial to add tool-pyocd (already existing) to platform-raspberrypi and add a custom platform target (just like "Upload Filesystem" is) that executes the pyocd rtt --target rp2040 --probe 'cmsisdap:0' command. I'll think about adding it in.

Signed OTA has been added to the latest release, so if we want to support that as well I think the script here needs to be updated to do the crypto-signing, in some sort of pre- and post-build process.  Plain OTA should work fine as long as a .BIN file is output from the standard processes.

I saw you already already added the ota.o object file to the builder script, I will take care to add the espota.py upload method to main.py like platform-espressif8266 does, with the added build logic to build the signed .bin file of course.

The first PlatformIO integration for regular and also signed OTA updates for the Pico W is working and tested now. Also comes with improved upload_protocol = mbed logic that resets the serial port to make the boot drive appear. Code not yet final, improvements pending, but it's a good working state for now.

Thank you for putting in the time to make this happen.  I am testing this out on a project I have and currently getting a linker error:
/Users/taf2/.platformio/packages/toolchain-rp2040-earlephilhower/bin/../lib/gcc/arm-none-eabi/10.3.0/../../../../arm-none-eabi/bin/ld: .pio/build/pico/src/main.cpp.o: in function `_Z13connectToWiFiPKcS0_':
main.cpp:(.text._Z13connectToWiFiPKcS0_+0x40): undefined reference to `_ZN9WiFiClass5beginEPKcS1_'
collect2: error: ld returned 1 exit status
*** [.pio/build/pico/firmware.elf] Error 1

Here is my platformio.ini file:
[env:pico]
platform = https://github.com/maxgerhardt/platform-raspberrypi.git
board = pico
framework = arduino
board_build.core = earlephilhower
board_build.filesystem_size = 0m
upload_protocol = cmsis-dap
debug_tool = cmsis-dap

build_flags = -D PICOW

Here's my project files that use this: https://github.com/taf2/tinypico-fridge-alarm
make pico

If you use the WiFi library, are you sure you don't want to use board = picow?

@maxgerhardt   aahh!   brilliant!  This worked! amazing :D

Looks good to me!
I have used the following platformio.ini.   So far, it was easy to build, upload (program), and monitor a second PICO using a picoprobe.
I'll try debugging next, but very happy to see so much working smoothly already!
platformio.ini
[env:pico]
platform = https://github.com/maxgerhardt/platform-raspberrypi.git
board = pico
framework = arduino
board_build.core = earlephilhower
board_build.filesystem_size = 0.5m
lib_deps =
    https://github.com/SimpleHacks/QDEC.git#dev-pio-rp2040

upload_protocol = picoprobe
debug_tool = picoprobe
debug_init_break = tbreak loop
debug_extra_cmds = thread 1

I do have one last question...
Q:  Does this already support compiling PIO assembly files using pioasm?  (I looked, but nothing caught my eye...)

Q: Does this already support compiling PIO assembly files using pioasm? (I looked, but nothing caught my eye...)

No it doesn't (yet). That means you have to do some preprocessing step (I'm not sure which tool) to directly generate the C code with the assembled instructions, like arduino-pico does.

The SDK docs have good descriptions of using pioasm, but basically it's just
pioasm -o c-sdk [path-to-source-file.pio] > [path-to-genrated-pio.h]

How to integrate that into an app is left as an exercise for the reader. :laughing:   (Actually, the SDK docs here are also very good!)

Yes, I have manually run the tool, and agree it's easy to use.
Since it seems like a source file, and the result is a generated file used in compiling a corresponding project, it seemed a natural fit.
Given the amazing work you've already done, I was just hopeful this was also included in your solution.   I now understand that it was not included in the current scope.  👍

Is this awaiting anything else? Looks to me like the requested changes are in and the outstanding issues resolved.

Regarding the pioasm integration, i have recently found a way to automate it using the platformio scriptiing, the procedure is explained in this gist:
https://gist.github.com/hexeguitar/f4533bc697c956ac1245b6843e2ef438
The script checks whether the pioasm package is installed, then scans the src directory for any .pio files and compiles them into header files.

Thanks for the script, I'll be looking to integrate this into the platform code.

Massive upgrade.

Add support for building for https://github.com/earlephilhower/arduino-pico

As in the style of platform-ststm32, boards that can be used with both cores can be switched to the other core using board_build.core = earlephilhower

Integrates with my already merged builder script at https://github.com/earlephilhower/arduino-pico/blob/master/tools/platformio-build.py

Added all Arduino-Pico boards (Earle auto-gen'ed them through https://github.com/earlephilhower/arduino-pico/blob/master/tools/makeboards.py)

Arduino core must use toolchain and tools from https://github.com/earlephilhower/pico-quick-toolchain/releases, which are finally in the registry

no more platform_packages injection platformio.ini needed, all tools (except framework) sourced from registry

Replace outdated platformio/tool-openocd-raspberrypi (1 year old, before picoprobe merge) with earlephilhower/tool-openocd-rp2040-earlephilhower -- works for all frameworks and cores (also the mbed-os core)

Added support for LittleFS filesystem building + uploading through picotool and OpenOCD (picoprobe etc.); Arduino-Pico core supports LittleFS

Added and tested Picoprobe support for both ArduinoCore-mbed and Arduino-Pico, works great

Reduced default debugging and OpenOCD upload speed to 1000kHz, the 5000kHz was giving me verification errors

Add Arduino-Pico examples to CI

Reprogrammed upload_protocol = mbed to make more sense, it previously tried to upload the .bin file to the drive instead of the .uf2 file

Update SVD file with latest from https://github.com/raspberrypi/pico-sdk/blob/master/src/rp2040/hardware_regs/rp2040.svd

Test at will with
[env]
platform = https://github.com/maxgerhardt/platform-raspberrypi.git
framework = arduino
board_build.core = earlephilhower
board_build.filesystem_size = 0.5m

[env:pico]
board = pico
; if using picoprobe SWD upload / debugging
;upload_protocol = picoprobe
;debug_tool = picoprobe

ToDo:

create PR for platformio-docs, previous docs at https://arduino-pico.readthedocs.io/en/latest/platformio.html are outdated
create PR for arduino-pico docs as docs is now outdated
fix Update PlatformIO builder script + docs earlephilhower/arduino-pico#612
upload / make Earle upload framework-arduinopico package (after fix of course)

Hello!
I receive the following error:
Linking /data/technical-room-pico-w/.pioenvs/technical-room-pico-w/firmware.elf
/data/cache/platformio/packages/toolchain-rp2040-earlephilhower/bin/../lib/gcc/arm-none-eabi/10.3.0/../../../../arm-none-eabi/bin/ld: /data/technical-room-pico-w/.pioenvs/technical-room-pico-w/src/main.cpp.o: in function setup': main.cpp:(.text.setup+0x814): undefined reference to _ZTVN7esphome18remote_transmitter26RemoteTransmitterComponentE'
/data/cache/platformio/packages/toolchain-rp2040-earlephilhower/bin/../lib/gcc/arm-none-eabi/10.3.0/../../../../arm-none-eabi/bin/ld: main.cpp:(.text.setup+0x81c): undefined reference to `_ZTVN7esphome18remote_transmitter26RemoteTransmitterComponentE'
collect2: error: ld returned 1 exit status
*** [/data/technical-room-pico-w/.pioenvs/technical-room-pico-w/firmware.elf] Error 1
The code in yaml:
remote_transmitter:
pin: GPIO2
carrier_duty_percent: 50%

There was no need to quote the entire PR description, it just takes up spaces.

undefined reference to `_ZTVN7esphome18remote_transmitter26RemoteTransmitterComponentE'

Is demangled

vtable for esphome::remote_transmitter::RemoteTransmitterComponent

I have no deep knowledge of ESPHome. Please open an issue in their repository.

Is this awaiting anything else? Looks to me like the requested changes are in and the outstanding issues resolved.

@valeros could you look into this? Would be incredible if the Earlephilhower Arduino RP2040 could be natively supported by PlatformIO

It looks to me like @maxgerhardt is just keeping this PR up to date in case it gets merged someday.
I have not followed the discussion, but this PR is flagged with "Changes requested". Has this been resolved?
If yes, are you @valeros planning to review this PR soon and hopefully merge it? After all, support for the "earlphilhower" RP2040 Arduino core is kind of a big deal!
Thank you for your work with this PR @maxgerhardt!

To reflect on  @MCUdude all the changes requested by @valeros have been implemented and updated on the same day as they were requested by @maxgerhardt. So why this patch is still blocked? is there any remaining work before we can merge this, how can we move this forward?

I doubt we will see movement in getting this patch merged soon, its been up for half a year.
Take into account there are only 2/3 core developers managing the whole of platformio and both are located in Ukraine. We have seen a strong stagnation across the board but we can't really blame them for it imo.

Dear @Dantali0n,
Thank you for bringing up the issue of missing official integration for PlatformIO and Raspberry Pi products. We understand that this is an important concern for many of our users.
We want to clarify that the current integration of RP2040-based products to the PlatformIO has a demonstrative character, and we do not recommend using it for production use. We have provided the link to the list of currently officially supported development platforms, and we encourage you to refer to this list for your project needs ( https://registry.platformio.org/search?t=platform ).
We want to assure you that we are working closely with the Raspberry Pi company to add official support for their products to the PlatformIO ecosystem, and provide the best developer experience in the market for their customers. We will keep you updated on any developments regarding this matter.
In the meantime, we encourage you to refer to the Raspberry Pi documentation and use their officially supported tools and IDEs.
Thank you for your understanding, and we appreciate your continued support of PlatformIO.
Best regards,
Your friends at PlatformIO.
cc: @ghollingworth

@ivankravets Sorry Ivan, I know that you are under extreme stress to do your job in Ukraine and I'm also understand that your business need to generate money. But the world is not only AI, Zephyr, RISC-V  and iOT and your company get more and more away from the claim to create a universal platform for all type of users. I'm working maybe for more than 8 years with your platform and every year I get more and more frustrated how PIO developed from an open source platform to a commercial company. To ignore the most popular microcontroller for the open source community is unintelligible.
Wish you the best for the unknown future.
Stefan Staub

Hi @sstaub ,
Thank you for sharing your thoughts and feedback regarding PlatformIO's support for microcontrollers. We appreciate your loyalty and the time you've invested in our platform.
We understand that PlatformIO has evolved over the years, but we want to assure you that our commitment to open source remains strong. Our solutions for end developers are free and licensed under the Apache 2.0 license. Additionally, we invest in community OSS development platforms every month, even if they are not our official technology partners.
However, we do face challenges when it comes to providing support for certain microcontrollers. Many silicon vendors do not see the value in open source and communities, which can make it difficult for us to add support for their products. This is especially true if they already have their own proprietary tools and IDEs.
That being said, we do not want to compromise the quality of our support by adding all development platforms and architectures. If a silicon vendor does not officially support PlatformIO, it's unlikely that customers will use it for production or commercial products. We believe in following official recommendations to ensure the best user experience for our customers.
We suggest reaching out to silicon vendors directly to discuss their vision for open source communities like PlatformIO. We've seen success with companies like Espressif, who value the importance of open source and have demonstrated this financially. If you have any ideas on how we can solve this issue, we are open to discussion.
Once again, thank you for your support and feedback. We will continue to work towards creating a universal platform for all types of users while staying committed to open source and vibrant communities.
Best regards,
The PlatformIO Team

I read this as a "Raspberry does not want you to include a much better core into our system, because they don't want concurrency in their own property".
Given this fact, you fail to be a support for the open source community any longer.
Under this circumstances platformio sooner or later must be replaced by independent structures.

@ivankravets  There is a nearly 2 years old issue requesting support of the official sdk, but also nothing happens.

Dear @Riffer ,
Thank you for your comment. I understand that the decision to not include a particular core in the current development platform may have been misconstrued as a lack of support for the open source community.
If you do not require official support from Raspberry Pi Ltd., please feel free to refer to the instructions provided by @maxgerhardt in the original post of this PR. However, it is important to note that we at PlatformIO Labs currently do not recommend using this development platform for commercial or production purposes due to integration and functionality limitations (missed official Raspberry Pi Pico SDK support, etc).
As you mentioned, we are actively engaged in conversations with Raspberry Pi Ltd. to find a solution to this issue. We appreciate your patience and continued support of the open source community.
Best regards,
The PlatformIO Team

@ivankravets
As others have said, I understand that the situation in your country is very difficult, and my greatest sympathies for that. However, I don't understand why you're answering everything except the actual question people are asking. These corporate sounding responses are part of why you're getting a negative reaction. We are talking about this specific PR for arduino-pico support. I have been using the arduino-pico support from Max's fork for almost a year and it works extremely well, and makes cross-platform support very easy. It's pretty much objectively better in every way than the MBed core that you officially support (even if you only consider that "demonstrative"). But from what you're saying, it seems like you are only willing to work with companies and have no intention of merging these fantastic contributions from independent individuals? That does not seem in the spirit of open source to me if that is the case.

We want to assure you that we are working closely with the Raspberry Pi company to add official support for their products to the PlatformIO ecosystem, and provide the best developer experience in the market for their customers.

I'm pretty sure everyone here is a customer of theirs... shouldn't we have a say in what developer experience we would like, or does it not count because we aren't business owners?

We suggest reaching out to silicon vendors directly to discuss their vision for open source communities like PlatformIO.

Does the company's "vision" of a community matter more than the community itself who is putting in the work?
I wouldn't have thought the Raspberry Pi foundation would actually pay you to not support other platforms/cores for their microcontrollers, so I am really confused why this PR was reviewed and Max was requested to make changes, which he has made, and then after that the work just gets ignored. Maybe eventually you get an official primary platform to replace your MBed core, but even then it may not be what a lot of the community wants. And for people who are already maintaining projects using this platform, it may not be worth the effort to switch. I totally understand that you want to have an official platform that is officially supported/endorsed by Raspberry Pi foundation, and I don't think that's a bad thing, but I fail to see why that cannot coexist with unofficial community platforms.
Sorry if I come across blunt/harsh, and obviously I don't know all sides of the issue, but I find it quite frustrating to see high quality work, done for free, being neglected just because it doesn't align with some company's ideal.

Dear @ivankravets,
Thank you for these clarifications, I understand that as a commercial entity adding support for platforms from different vendors without their approval raises political tensions that is not within the best interest of your company. However, I do think that such barriers can be better communicated to contributors as it seems to be the first time this is being put forward when this patch has been up for roughly half a year.
While we can not add support to official repositories for platforms without vendors approval. many third party libraries that can be integrated using the method described by @maxgerhardt here as well exist. Maybe as a community we can create an list of such repository, describe the method to integrate them into platformio-core and warn about it being unofficially supported and the limitations that arise from that.
This list can either be created in a GitHub repository or ideally is maintained as a separate website that also runs an extended instance of the documentation repository as to provide documentation for these unofficially supported boards.
Using this methodology contributors can create support for their boards, thinkers can try out these new boards knowing risks and limitations and PlatformIO can continue as a business without tension by supporting boards without vendor approval / agreements.
Does this seem like a workable solution to you?
Kind regards,
Dantali0n

I wouldn't have thought the Raspberry Pi foundation would actually pay you to not support other platforms/cores for their microcontrollers

Please refrain from such nonconstructive discussion based on nothing but assumption as it doesn't contribute to anything.

Hi guys,
I feel a little sorry as I didn't expect my "bump" to go this way. I do personally think it's up to platformio guys to take this sort of decision, and I think we should respect it.
As @Dantali0n said, and because platformio is well developed (to me), we can already use it with very little effort in a non official way, thanks to all platformio dev and @maxgerhardt, and we should be thanks full for that, no need to enter in a long argument fight.

My 2 cents as a beginner who is just moving past official Arduinos with the Arduino-IDE (and I haven't used Platformio before):
I understand that you want something official. However, the current raspberrypi platform already is not official. (No official tag in the registry.) So why not replace something unofficial with something (still unofficial) but way better?
Maybe I'm misunderstanding what the "Community" Tag on the registry means. I guess that the earlephilhower core with maxgerhardts Platformio integration would fall under the Community tag.
You write that you're working with the Raspberry Pi company to add official support. As far as I know, only the "bare metal" C/C++ SDK is official from the Raspberry Pi company. And while official C/C++ SDK support would be great, it would not replace the earlephilhower arduino-core, especially for beginners and hobbyists.
Your comment is the first time that I'm reading "that the current integration of RP2040-based products to the PlatformIO has a demonstrative character, and we do not recommend using it for production use".
Sure, there is no "official" or "verified" label on the registry, just a "top 10"-hearth. From looking at the registry, I honestly expected way more. Maybe not something production-ready. But I kind of expected being able to blink the built-in LED on the one year old and pretty popular Raspberry Pi pico w board.
If you don't want to add the earlephilhower core to the registry, I would suggest to at least write "the current integration of RP2040-based products to the PlatformIO has a demonstrative character, and we do not recommend using it for production use" on the platformio registry page. And I would add a link to the earlephilhower core, too.
I know that I can (and do) just use the earlephilhower core without it being in the official platformio registry. But actually warning people not to use the "demonstrative character" version and making the better version easier to find really reduces unnecessary frustrations.
Don't understand me wrong, I really like Platformio in general.
With the earlephilhower core, making a simple program was just as easy as in the Arduino IDE except Platformio+VS Code is way better.
Best Regards

@ivankravets  I don't understand the term "official" support by the vendors. Many of your supported frameworks and platforms  started at an open source community project like STM32duino.
What about Arduino? Are they official by the vendors? Their NanoRP2040 is also not official supported by Mbed(ARM),
they forked the repository and made an own solution. Official??? Arduino don't want that their product will supported by Mbed officially.

Many silicon vendors do not see the value in open source and communities, which can make it difficult for us to add support for their products.

The DNA from Raspberry Pi is open source.
PIO is focused on the silicon vendors and this one of the problem.

If inclusion criteria is official commercial vendor support, perhaps you
need to remove this key point from platformio.org website.
A place where Developers and Teams have true Freedom! No more vendor
lock-in!
On Sat, Apr 15, 2023 at 9:48 AM Stefan Staub @.***>
wrote:

@ivankravets https://github.com/ivankravets I don't understand the term
"official" support by the vendors. Many of your supported frameworks and
platforms started at an open source community project like STM32duino.
What about Arduino? Are they official by the vendors? Their NanoRP2040 is
also not official supported by Mbed(ARM),
they forked the repository and made an own solution. Official??? Arduino
don't want that their product will supported by Mbed officially.
Many silicon vendors do not see the value in open source and communities,
which can make it difficult for us to add support for their products.
The DNA from Raspberry Pi is open source.
PIO is focused on the silicon vendors and this one of the problem.
—
Reply to this email directly, view it on GitHub
https://github.com/platformio/platform-raspberrypi/pull/36#issuecomment-1509837833,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AECUW5ITPS4T56LAGIUYL43XBKRL5ANCNFSM5YLJED5Q
.
You are receiving this because you commented.Message ID:
@.***>

@Dantali0n I am not making any assumption one way or the other, just voicing my thoughts and trying to understand the situation. As I said previously, I don't know every side of the situation nor the complex relationships between entities involved. But I am having trouble understanding why the unofficial and demonstrative mbed core is fine, but the much better arduino-pico core cannot be included as a community/unofficial core, as others have also suggested. There appears to be plenty of other precedent as well, so that doesn't seem unreasonable. I don't believe anyone is suggesting it should be considered official, or the primary supported core for Raspberry Pi hardware.
I do feel you took that phrase from my previous comment out of context and dismissed the rest, but I can understand if you think I did not communicate my thoughts clearly enough. No insinuation was intended, and it was merely an oversimplified way of phrasing my thought process. I have no desire to mislead or offend anyone, and am simply hoping to reach mutual understanding through openness and transparency. I see others still have the exact same questions I do, so it would seem that more communication is needed.

@ivankravets
I just want you to know i ONLY use Platformio because of windows rp2040 debug capabilities without extra hardware. If by chance this stops working i will leave Platformio for good.
I guess there are many developers like me, who need such capabilities. Which are the best way to get into microcontroller development. If "platform = https://github.com/maxgerhardt/platform-raspberrypi.git" ever stops working many people will jump out.
Regards.

official Pico Windows installer

Not bad, but it's not arduino, shrinks software compatibility, just not "the best" option 4 me.

@ghollingworth
Not bad, but it's not Arduino, shrinks software compatibility, just not "the best" option 4 me.

Ah, so not the 'ONLY' reason then!

Hi there, my 5 cents as one of the developers. We would like to clarify that as maintainers, we have a responsibility to carefully consider the features that are added to the community development platforms. Adding new functionality can bring additional burden for maintaining it, which can result in increased costs and resources which we reserved for OSS investment.
We want to emphasize that our ecosystem is vendor-agnostic and open to any architecture, hardware, or software commercial products. We do not have any lock-ins to specific companies or products.  We also would like to clarify that as a company, we use an open core business model, which allows us to offer additional features and services to enterprise clients such as Raspberry Pi (Trading) Ltd for a fee. See https://registry.platformio.org/pricing
We would like to encourage you to kindly suggest to RPi to reach out to us to inquire about the possibility of adding the functionality you need. This would allow us to engage in a conversation with RPi about their specific requirements and explore the feasibility of incorporating these features in our open source project.
Thank you for your understanding.
Regards,
Your friends at PlatformIO

I've been following the discussion around this pull request for a while. I understand the complexity of the issue and see that official support from silicon vendors is crucial for the stability of PlatformIO.
However, I, along with many others, have found the contributions made in this PR to be highly beneficial and more usable than the current Mbed solution. The work done here aligns well with the spirit of open source, which is all about community contributions and collaboration.
Given this, I would greatly appreciate it if you could provide an update on the current status of this PR. Has there been any progress in your discussions with Raspberry Pi Ltd? Additionally, could you please elaborate on the reasons for this PR being left unmerged for such an extended period of time, despite its apparent advantages over the existing solution?
Your transparency and communication on this matter would be appreciated by everyone involved.

Last week I was contacted by a high level C-suite of the Raspberry Pi foundation to get this resolved, I replied back, but the conversation hasn't gone on yet.

@maxgerhardt, thank you for bringing this information to my attention. I must admit, I was taken aback by the situation involving Raspberry Pi Trading Ltd. I had previously held a different perspective on the Raspberry Pi company and its relationship with the open-source community. It is crucial for us to address this issue promptly and allow the community to voice their concerns regarding a commercial entity leveraging PlatformIO for their business interests, using the Raspberry Pi Foundation as a guise to evade technology licensing fees.
At PlatformIO Labs, we firmly believe in upholding the principles of transparency and fairness within the open-source ecosystem. While many silicon vendors often consider open-source communities as entities they can freely benefit from, it is important to recognize that open source does not equate to "free." We have adopted an open-core business model at PlatformIO Labs, which means that most solutions for embedded developers are licensed under the highly permissive Apache 2.0 license. Our intention is to provide access to professional embedded software without charging developers directly.
To ensure the smooth operation of our business and to continue investing in innovative solutions for embedded development, we charge licensing fees to silicon vendors seeking access to our ecosystem. This approach enables us to sustainably scale the PlatformIO business. It is critical to emphasize that leveraging the PlatformIO community as a means to avoid these licensing fees is not a viable strategy. Please note that any attempts by commercial entities to integrate their packages without adhering to our licensing requirements will not be approved, as clearly outlined on our pricing page (https://registry.platformio.org/pricing).
Maximilian, I kindly request you to direct the attention of "Raspberry Pi Foundation" to the actual entity behind the commercial activities, namely "Raspberry Pi Trading Ltd." We are currently engaged in ongoing discussions with "Raspberry Pi Trading Ltd." and eagerly await their response to our business proposal.
Thank you once again for bringing this matter to our attention. We appreciate your support in upholding the integrity of the PlatformIO community and ensuring fair and transparent practices within the open-source ecosystem 🙏

The email was actually signed with the company name "Raspberry Pi Limited", so I think it's the right entity. But still no further response-- eagerly awaiting.

Thank you for the prompt update. I have made the necessary amendment to my comment, removing any mention of the "Raspberry Pi Foundation," as they are not implicated.

First off, I'd like to express our gratitude to Max for his amazing work. It's exciting that people have the opportunity to use a high-quality integration of PlatformIO with Raspberry Pi silicon.
We received a proposal from PlatformIO Labs in October 2022. While we absolutely empathise with the challenges of funding open-source projects, we were unable to justify paying the very substantial recurring fees involved. We indicated that we would not be proceeding, and have subsequently made some investments elsewhere, notably in the Raspberry Pi Pico Windows Installer.
As it has been made clear that this PR will not be accepted in the absence of a commercial agreement between Raspberry Pi and PlatformIO Labs, I think it would be best to close it.

@ebenupton Your comment is very poor, it seems Raspberry have only interest in commercial not in the spirit of open source.

As an outsider, reading this on Hacker News, this looks like rent-seeking behavior from PlatformIO, looking for a piece of the Raspberry Pi (hah!)
Can PlatformIO provide succinct points for the reasoning against this?

As an outsider, reading this on Hacker News, this looks like rent-seeking behavior from PlatformIO, looking for a piece of the Raspberry Pi (hah!)
Can PlatformIO provide succinct points for the reasoning against this?

I second this, I don't think either Microchip or ST is paying PlatformIO to support their chips, yet here we are.

To ensure the smooth operation of our business and to continue investing in innovative solutions for embedded development, we charge licensing fees to silicon vendors seeking access to our ecosystem. This approach enables us to sustainably scale the PlatformIO business. It is critical to emphasize that leveraging the PlatformIO community as a means to avoid these licensing fees is not a viable strategy. Please note that any attempts by commercial entities to integrate their packages without adhering to our licensing requirements will not be approved, as clearly outlined on our pricing page (https://registry.platformio.org/pricing).

I think some of the confusion here is due to seemingly contradicting terminology in various places, if your ecosystem is only open to hardware vendors that have commercial licensing agreements with PlatformIO that would appear to contradict statements such as this on your homepage "A place where Developers and Teams have true Freedom(Use favorite OS, IDE, Hardware and Software tools)! No more vendor lock-in!" which implies developers are free to use and contribute support for new vendor hardware platforms to the open source areas of PlatformIO regardless of whether or not a hardware vendor has made a licensing agreement with PlatformIO.
If I'm understanding the situation correctly you might want to clarify somewhere that PlatformIO is only supported with hardware produced by hardware vendors that have licensing agreements with PlatformIO and that developers need to choose amongst those supported hardware platforms.
It's also unclear what would happen if a hardware vendor were to say stop paying recurring licensing fees/terminate a licensing agreement with PlatformIO or go out of business. Would that mean that PlatformIO would also drop support for the hardware platform as soon as the hardware vendor stopped paying for PlatformIO support?

At PlatformIO Labs, we firmly believe in upholding the principles of transparency and fairness within the open-source ecosystem. While many silicon vendors often consider open-source communities as entities they can freely benefit from, it is important to recognize that open source does not equate to "free." We have adopted an open-core business model at PlatformIO Labs, which means that most solutions for embedded developers are licensed under the highly permissive Apache 2.0 license. Our intention is to provide access to professional embedded software without charging developers directly.

Isn't an open-core business model just one where the closed source components of a project have license fees/restrictions while the open source components on their own do not(aside from any of the usual open source license requirements for a particular component)? It seems odd to use open-core business model as a reason for gatekeeping external contributions to the open source components of a project like in this case.
Many companies build non-opensource applications that run on top of the Linux kernel, however it would be unusual if vendors or community contributors were required to pay licensing fees to say the Linux Foundation or some other organization simply in order to be allowed to submit patches adding new hardware support to the upstream Linux kernel.
A policy such as that would make a project like Linux much less likely to be used in general as that would discourage usage/contributions by hardware vendors and thus in turn would discourage usage of the kernel by software developers.

Thank you once again for bringing this matter to our attention. We appreciate your support in upholding the integrity of the PlatformIO community and ensuring fair and transparent practices within the open-source ecosystem 🙏

As a matter of transparency I think it would be a good idea to add some more detailed vendor hardware license cost information to the pricing page (https://registry.platformio.org/pricing) as it's not clear at all what it costs for a vendor to add support for a new hardware to PlatformIO.

I would imagine that the funding for a specific feature needs to come either from users who are willing to pay, or vendors who are willing to pay. There are enough users willing to pay for Atmel/STM32 support to justify supporting it, and that demand probably doesn't exist yet for RPi.
This request seems reasonable, but the response is also reasonable.

I would imagine that the funding for a specific feature needs to come either from users who are willing to pay, or vendors who are willing to pay.

From what it appears the specific feature in question is already written and the licensing fee is effectively just for merging support.
Since it was stated that "Our intention is to provide access to professional embedded software without charging developers directly." it doesn't seem PlatformIO even has an option for users/developers to pay for new hardware support licensing, it seems PlatformIO specifically wants hardware vendors to have licensing agreements for adding new hardware platforms, although this approach seems to directly contradict the no vendor lock-in statements made in numerous places so I'm not really sure.

There are enough users willing to pay for Atmel/STM32 support to justify supporting it, and that demand probably doesn't exist yet for RPi.

Did users or the hardware vendor pay for Atmel/STM32 support?

@ebenupton Sorry for the last post from me, I deleted it. I misunderstood your post. It is a no go that Raspberry Pi should pay for a users work which gains the business of PIO.
I'm using PIO for many years und I get more and more frustrated with every release.

We from OpenKNX decided to change over from Arduino VSC plugin to PIO because of the not yet offical support of the great arduino-pico core. While waiting some time was acceptable, we never thought that the great work from Earle and Max will be rejected. We are really disappointed atm.
If this really will be the case our answer will 100% sure to say "Goodbye PIO. We will never come back."

Adding to some of the previous comments, this is also bad news for my
project.
I've spent several months preparing various RP2040 configurations in PIO.
The plan was to offer a knowledge bridge for PIO Arduino developers to
develop with RP2040 boards easily and more importantly for RP2040
developers to have access to the Arduino libraries via PIO. Yes, all of the
code works in Arduino IDE but then why use PIO?
I'm now facing a rewrite of a lot of code and documentation to make it work
with Pico SDK. This is assuming that there are equivalent libraries that
I'll need for Pico SDK such as ArduinoJSON.
This doesn't feel very open sourcey.
On Sat, 27 May 2023, 08:24 Dom, @.***> wrote:

We from OpenKNX https://github.com/OpenKNX decided to change over from
Arduino VSC plugin to PIO because of the not yet offical support of the
great arduino-pico core. While waiting some time was acceptable, we never
thought that the great work from Earle and Max will be rejected. We are
really disappointed atm.
If this really will be the case our answer will 100% sure to say "Goodbye
PIO. We will never come back."
—
Reply to this email directly, view it on GitHub
https://github.com/platformio/platform-raspberrypi/pull/36#issuecomment-1565250119,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AFZGIO7MAQDTYG7XJ6GKWVDXIGT35ANCNFSM5YLJED5Q
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

@ebenupton Sorry for the last post from me, I deleted it. I misunderstood your post. It is a no go that Raspberry Pi should pay for a users work which gains the business of PIO. I'm using PIO for many years und I get more and more frustrated with every release.

Thanks Stefan. I have appreciated your contributions to this discussion, and was concerned that I'd offended you.

I think the most professional resolution would be to merge this PR and mark the platform support “experimental (not for production use)” if Platformio insists that official support requires a yearly payment from the chip vendor.
If a major rewrite of Platformio in the future (hypothetically) requires a significant effort to keep this platform working, I guess you could argue for its deprecation and removal unless the community steps up again.
Throwing away such a high-quality contribution seems to be very disrespectful to the open-source community, irrespective of the business drivers in play.

Me checking my E-Mails this morning

@ivankravets
so it's all about money isn't it?
While I clearly disrespect PlatformIO Labs behaviour on this matter, I see the need for substantial financing.
So, numbers, please. Then we can think about some fundraising, probably...

Does this policy of only allowing community-made updates to platforms if the vendor pays licensing apply to all platforms in the registry?
Why are there any platforms in the registry besides the 8 official and verified ones? If updates by the community are rejected for "community" platforms, then why have community platforms at all?
Also, please, at the very least warn potential users that the current raspberrypi platform in the registry is not supported, will not get updated and has a demonstrative character, and is not recommend using it for production use.
Just one line of text can save potential users days of pointless work.

Hello everyone,
I appreciate your comments and concerns regarding the recent discussions between PlatformIO and Raspberry Pi Trading. I would like to address some of the questions raised and provide further insights into the situation.

"Did users or the hardware vendor pay for Atmel/STM32 support?"

During the period of 2016-2019, PlatformIO was primarily funded by end developers (paid plans), and we did not charge silicon vendors for support. However, we realized that this business model hindered the widespread adoption of PlatformIO Labs technology in the embedded systems market. As a result, we made significant changes. Today, PlatformIO Project is free for anyone, including commercial use, and we have open-sourced the paid part of PlatformIO Labs technology under the permissive Apache 2.0 license.
In 2020, we expanded our technology to the silicon industry, offering next-gen solutions for embedded development while reducing development costs for software ecosystems. We welcome all silicon, hardware, and software providers without any limitations or privileges.

"This approach seems to directly contradict the no vendor lock-in statements made in numerous places."

PlatformIO is committed to being a silicon-agnostic ecosystem. The term "vendor lock-in" primarily pertains to silicon vendors, who often strive to tie developers to their specific software ecosystem, including IDEs, tools, and frameworks. Our goal is to alleviate this issue. With PlatformIO, switching between different MCUs or silicon vendors is as simple as changing one line in the "platformio.ini" file. You don't need to install new tools, re-invest in your CI/CD infrastructure, or learn a new IDE. We provide the flexibility and freedom to choose the best options for your projects.

"All of the code works in Arduino IDE, so why use PlatformIO?"

We never force Arduino developers to use PlatformIO. While we do support Arduino code, our mission goes beyond frameworks and tools. PlatformIO is the only neutral platform where developers and silicon vendors can truly benefit. It's important to note that Arm has a stake in Arduino and promotes its own interests through the platform. If you visit the Arduino store, you won't find alternative silicon to Arm in their official products. We've consciously chosen a different path. We have turned down lucrative proposals because our priority is not just monetary gain. We aim to reduce complexity in the silicon industry and serve the interests of the entire developer community.

"Raspberry Pi and new silicons in the PlatformIO ecosystem"

We receive numerous feature requests from the community to add support for new MCUs), and we invest our own resources to integrate non-commercial products for learning purposes. PlatformIO serves as the engine for critical projects like HomeAssistant, which uses ESPHome as a bridge for accessing hardware, and Marlin, the most popular alternative firmware for 3D printers. We have over 3,000,000 developers in our rapidly growing community. Adding new commercial silicons to our ecosystem involves significant costs, which we must carefully consider.
Regarding commercial silicons, including Raspberry Pi Trading, PlatformIO indirectly contributes to their revenue. It is perplexing why these companies would demand licensing and royalty fees from the open-source community while expecting us to provide a top-tier developer experience. We believe in fair collaboration, where all parties contribute to the growth and success of the ecosystem.

"We were unable to justify paying the very substantial recurring fees involved."

To clarify, the licensing fee has not been communicated as an exorbitant amount. If Raspberry Pi Trading truly values freedom for their customers, they should have engaged in a discussion about the licensing fee. We have expressed our willingness to find a fee that aligns with their budget, considering the importance of both communities and reputations. Regrettably, we have not received a response from them.
In summary, PlatformIO Labs is not a volunteer organization, and we don't have the means to cover the bills of Raspberry Pi Trading or any other company. We are a bootstrap company, working without investments, and rely on fair collaboration with partners. If these companies appreciate our work and value both communities, they should be able to afford the licensing fee. Alternatively, they can provide an equivalent developer experience at a lower cost.

Thank you for your understanding. Transparency and honesty have always been our guiding principles. We appreciate the support of other technology partners, even during challenging times when our R&D team is located in Ukraine.
Regards,
Your friends at PlatformIO

Sorry, I forgot about this important question:

"It's also unclear what would happen if a hardware vendor were to say stop paying recurring licensing fees/terminate a licensing agreement with PlatformIO or go out of business"

Under the PlatformIO Labs licensing model, the integration and support for a specific hardware platform remain perpetual. This means that even if a silicon vendor were to stop paying recurring licensing fees or terminate the agreement, the existing integration and functionality for that platform will continue to be available to the community. In such a situation, there are no risks or negative impacts on the projects and developers who rely on that platform within the PlatformIO ecosystem.
PlatformIO is committed to providing a stable and reliable development environment for the community. Our licensing agreements are designed to ensure the long-term sustainability of the platform, regardless of the individual decisions or circumstances of specific silicon vendors.
We value the trust and support of our community, and we strive to maintain a robust ecosystem that empowers developers to build and innovate without disruption.
If you have any further questions or concerns, please feel free to ask me here.

While I clearly disrespect PlatformIO Labs behaviour on this matter, I see the need for substantial financing.

@Ing-Dom I would like to urge everyone to remain respectful and constructive, if we don't want this thread to get locked. Though I am guilty as charged of HN-posting here myself (however, I am a Platformio user – not for the RP2040-based boards, though, and also have experience leading an OSS project).

So, numbers, please. Then we can think about some fundraising, probably...

I think https://platformio.org/donate already exists. Perhaps, @ivankravets could clarify what place donations have in their post-2020 business strategy when they shifted towards direct deals with vendors.
I think the funding model behind https://squidfunk.github.io/mkdocs-material/insiders/ could be a great inspiration. Maybe Platformio could be specific about their donation goals for particular platform support (especially, for platforms that are more popular among hobbyists than embedded professionals) like the Material for MkDocs does it:

The following section lists all funding goals. Each goal contains a list of features prefixed with a checkmark symbol, denoting whether a feature is already available or planned, but not yet implemented. When the funding goal is hit, the features are released for general availability.

This means that even if a silicon vendor were to stop paying recurring licensing fees or terminate the agreement, the existing integration and functionality for that platform will continue to be available to the community.

@ivankravets I think @ebenupton specifically mentioned that it was the "recurring fees" that were the biggest hurdle for them.
I like both Platformio platform and Raspberry Pi tools and I hope you will find a way to cooperate in a way that would help everyone innovate! 🤝

@Ing-Dom I would like to urge everyone to remain respectful and constructive
I don't think telling that I cannot respect some companies behaviour is disrespectfull. Nevertheless, I'm serious (and constructive)

If it's about money, let's do fundraising. Let's see if we can scrape it together.
If it's about principles and about winning, well, there is nothing one could do... but searching for alternatives.

@berezovskyi , @Ing-Dom

"What place do donations have in their post-2020 business strategy when they shifted towards direct deals with vendors?"

Donations have a place in our business strategy because they were requested by our users. Many businesses find it hard to believe that a professional platform like PlatformIO is offered for free. As a result, they express a desire to support our work through donations.

"If it's about money, let's do fundraising. Let's see if we can scrape it together."

PlatformIO Labs does not have financial problems. Our business model is well-supported by our technology partners, and both parties are satisfied. This allows our partners to focus on their own product development while relying on PlatformIO Labs for integration, maintenance, professional support, and ensuring the satisfaction of end developers.
We have explored various options to create a sustainable business over the past 8 years (one, two, three), including fundraising/foundation attempts. However, these approaches did not yield the desired results. In 2020, we made a strategic decision to invest significant resources in our technology and open it to silicon vendors. This involved developing a next-generation IDE framework, UI toolkit, and a Package Registry with our own CDN infrastructure that handles a substantial amount of global traffic. By leveraging our technology, silicon vendors can save both money and years of development time.
PlatformIO Labs has been the primary driving force behind the PlatformIO Core project, contributing to numerous community and commercial projects worldwide. Many companies utilize PlatformIO for commercial purposes since even Arduino charges for their CLI tool.
Therefore, our current business model is a win-win-win situation for all parties involved: developers/manufacturers, PlatformIO Labs, and silicon vendors.

@Ing-Dom I would like to urge everyone to remain respectful and constructive

I don't think telling that I cannot respect some companies behaviour is disrespectfull. Nevertheless, I'm serious (and constructive)

This is a niggling point, but to say one, "clearly disrespect[s] PlatformIO Labs behaviour," does directly state disrespect. I believe the intention is a statement to this effect though: "PlatformIO Labs behaviour on this matter is not deserving of respect." Or, perhaps, "their stance is disrespectful of the spirit of community involvement and open-source." (to paraphrase the read of the room) This is a relatively cool-headed assessment of your take on the situation, and seems reasonable to me.
For those who have not followed the whole thread, here's my take of the situation and timeline:

Jun, 2022: maxgerhardt submits the PR of this very nice integration of earlephilhower/arduino-pico into PIO. Both parties and projects notably are community members with no direct affiliation to either PIO or Raspberry Pi, afaik.
Aug, 2022: after much deliberation, review, and updates the PR looks to be in a mergeable state.
Oct, 2022: PR had gone ignored and gets a direct bump from an outside party asking why it hasn't been merged yet. Many thumbsups, no team response.
Jan, 2023: another interested community member bump asking to please review and merge this much-requested, much-awaited, large PR. Many thumbsups, no team response.
Mar, 2023: another bump, another many thumbs, another nothing. All along maxgerhardt is quietly maintaining and updating the PR, clearly in the hopes it will get merged.
Apr, 2023: ivankravets of PIO enters the thread. He makes it clear that this PR has been sitting unmerged because they have been in talks with Raspberry Pi team about an official integration with funding from RPI. It goes unaddressed that an official RPI integration would likely not be a direct replacement for this PR which provides Arduino Platform support (and presumably the official integration would be with the RPI SDK).
May, 2023: maxgerhardt makes it clear that an RPI exec has recently privately contacted them to try to urge this PR getting merged. ivankravets responds implicating RPI in using the community to surreptitiously avoid licensing fees. Eben Upton joins the thread stating that PIO had approached them with a proposal seeking licensing fees in Oct, 2022 and they walked away from it without negotiations. Notably, this is months after this PR was already in a mergeable state.
Last 24 hours: This PR thread makes the front page of Hacker News due to the drama

It appears that PIO ignored this much-wished-for large community-effort PR for support which largely and primarily effects the large hobbyist community which has rallied around the project, in the hopes that it would be a bargaining chip against a yet-to-be-proposed licensing fee from RPI for official support.
Now, more recently, RPI has made it clear that they are very much interested in getting this PR merged for their own benefit without being willing to proffer licensing fees to PIO.
I'd like to say with all due respect as someone who genuinely respects both the ethos and achievements of both the Raspberry Pi Foundation and PlatformIO that I'm ashamed of both parties, from my outside read of the situation. It seems they are both using the community as pawns in their intended-to-be-behind-the-scenes jockeying over licensing fees.
What I see as the right decision here, that should have happened before PIO approached RPI: Just merge the PR. Approach RPI over official SDK support, separately. That said, again, RPI is not faultless given the way this has played out. Either way: please disinvolve this community effort as a bargaining chip from your licensing negotiations and show some good faith to the community by merging this.
That said, I believe I'm not alone in feeling the situation has also severely tarnished the reputation of RPI, and it would be a reasonable good faith gesture to publicly enter into some sort of licensing negotiation with PIO, as they've made it clear they're willing to find a reasonable middle ground in fees negotiations and the value of support from them is obviously not-zero.

Now, more recently, RPI has made it clear that they are very much interested in getting this PR merged for their own benefit without being willing to proffer licensing fees to PIO.

Did they? My understanding of the conversation thus far was that RPi put their priorities elsewhere, but I may have missed something. Can you share the part of the thread where this happened? Was it outside of this thread?

Now, more recently, RPI has made it clear that they are very much interested in getting this PR merged for their own benefit without being willing to proffer licensing fees to PIO.

Did they? My understanding of the conversation thus far was that RPi put their priorities elsewhere, but I may have missed something. Can you share the part of the thread where this happened? Was it outside of this thread?

This is the one you missed: https://github.com/platformio/platform-raspberrypi/pull/36#issuecomment-1553603305

I want to clarify a few points regarding the dynamics at play. Raspberry Pi Trading is a separate company focused on generating profit, rather than being a foundation. They utilize closed ARM cores and ARM charges companies an "entrance fee" and "royalty fee" for each sold Raspberry Pi chip. Additionally, Raspberry Pi Trading has not open-sourced its MCU IP. This means that both ARM and Raspberry Pi Trading benefit financially from the PlatformIO community.
Now, my "conclusion" regarding PlatformIO Labs and comments above:

PlatformIO Labs made a wrong decision to open up a significant part of its technology to the community. In retrospect, keeping PlatformIO proprietary would have allowed them to approach Raspberry Pi Trading directly as an alternative with superior development tools for their products.
PlatformIO Labs is hesitant to pay for the integration of Raspberry Pi Trading products. This reluctance might stem from the fact that it would lead to additional costs for the ecosystem and infrastructure, such as maintenance and support expenses, as well as the need to invest in cloud infrastructure to serve their packages.

It's often puzzling how people tend to trust politics while harboring skepticism towards volunteers or those who voice criticism. This saga serves as an example of this phenomenon. While the actors involved are different, the underlying logic remains the same. PlatformIO Labs is portrayed in a negative light and is expected to pay "more taxes" to appease the "politics".
I appreciate your perspective on the matter and acknowledge that this situation has had a negative impact on the reputation of both Raspberry Pi Trading and PlatformIO Labs. It would indeed be a reasonable gesture for Raspberry Pi Trading to engage in licensing negotiations with PlatformIO Labs and find a mutually agreeable middle ground in terms of fees. This would demonstrate good faith towards the community and help repair some of the tarnished reputation.

@ivankravets If you are not interested in user contribution please close this PR instead of kidding the community. It is time to say good bye to PIO.

To be honest, I don't see how this is tarnishing the reputation of Raspberry Pi. I don't expect them to pay for every project involving their microcontroller. Sure, it would be nice. But I think it's fine if they want to only do their micropython and SDK thing.
Likewise, I understand that Platformio doesn't want to pay for hosting and support for every single microcontroller architecture out there. I appreciate that we can just use the arduino-pico core by putting a link to GitHub in the platformio.ini file.
Dear @ivankravets
I just still have a few unanswered questions:
Does this policy of only allowing community-made updates to community-platforms if the vendor pays licensing apply to all platforms in the registry?
Why are there any platforms in the registry besides the 8 official and verified ones? If updates by the community are rejected for "community" platforms, then why have community platforms at all? Why not have only official platforms (where a vendor pays for licensing) in the registry? And community-supported platforms just need to be hosted by the community and get no support from PlatformIO Labs.
I would totally understand something like "we keep supporting those platforms out of tradition, but only add new platforms when someone pays.
Also, please, at the very least warn potential users that the current raspberrypi platform in the registry is not supported, will not get updated and has a demonstrative character, and is not recommend using it for production use.
Just one line of text can save potential users days of pointless work.
Right now, having the raspberrypi platform in the registry seems dishonest to me. It looks like there is some support when there is actually none.
Many Greetings

Now, my "conclusion" regarding PlatformIO Labs and comments above:
1. PlatformIO Labs made a wrong decision to open up a significant part of its technology to the community. In retrospect, keeping PlatformIO proprietary would have allowed them to approach Raspberry Pi Trading directly as an alternative with superior development tools for their products.

I hope that this response is in frustration over the current situation and that your core belief is closer to the statement you made prior:
"At PlatformIO Labs, we firmly believe in upholding the principles of transparency and fairness within the open-source ecosystem. While many silicon vendors often consider open-source communities as entities they can freely benefit from, it is important to recognize that open source does not equate to "free."
The open-source hobbyist community has rallied around your project and acted as advocates and champions for it, given the commitment to the values you proclaim to firmly believe. What you've achieved is great. Please don't lose sight of that vision in frustration.
The community, too, is rightly frustrated to be held in the balance here. You claim a support burden is the key gating factor for merging this now, but it seems this has been maintained and used widely in the wild for nearly a year now without your team's involvement. The only ask now is a simple final merge so that people don't have to go to extra steps to use this. It is clearly better than the existing, admittedly flawed, support and would only bring more dedicated hobbyists to be advocates of PIO.
That's something that's important to not lose sight of. Hobbyists often have day jobs that are adjacent. A hobbyist using PIO for their home Pi Pico project might at work advocate for PIO, or take time out of their busy schedule to lobby on your behalf publicly towards RPI.
Please hold strong to your belief in the open-source community. PIO has been a breath of fresh air in the embedded world, and one that rightly deserves the unabashed public support of RPI. Just, everyone, let's play fair!

To be honest, I don't see how this is tarnishing the reputation of Raspberry Pi. I don't expect them to pay for every project involving their microcontroller. Sure, it would be nice. But I think it's fine if they want to only do their micropython and SDK thing and leave the rest to the community. Likewise, I understand that PlatformIO doesn't want to pay for hosting and support for every single microcontroller architecture out there. I appreciate that we can just use the arduino-pico core by putting a link to GitHub in the platformio.ini file.

This might be the case were it not for the fact that major players from RPI (representing whichever entity), have directly been attempting to privately influence the maintainer of this PR. I can certainly understand PIO's and invankravets' frustration over this. It is a surreptitious direct attempt to benefit from PIO's work without any payment.

I appreciate your perspective on the matter and acknowledge that this situation has had a negative impact on the reputation of both Raspberry Pi Trading and PlatformIO Labs. It would indeed be a reasonable gesture for Raspberry Pi Trading to engage in licensing negotiations with PlatformIO Labs and find a mutually agreeable middle ground in terms of fees. This would demonstrate good faith towards the community and help repair some of the tarnished reputation.

"This would demonstrate good faith towards the community...", dis-involving the community's efforts here from the licensing discussion by merging this PR would be the move we're looking for from you. The ball started rolling with the lack of transparency and using the community by ignoring this PR last year while you were preparing a fees proposal for RPI (and after that for months, while you were presumably still attempting to chase an agreement with them).

I appreciate your perspective on the matter and acknowledge that this situation has had a negative impact on the reputation of both Raspberry Pi Trading and PlatformIO Labs.

Sorry @ivankravets but I doubt the majority of the users see it this way. I don't see any obligation from RPiT to financially support PIO or any other project that supports their silicon. They have their own SDK.
The argument they should pay because they profit is nonesense. You would also profit from Earle's and Max' work, do you plan to pay royalties to them?
Do you pay royalties or support financially any of the open source tools you are utlizing in PIO? Do you pay Microsoft for utilizing VSC ? I doubt it...
You concept for PIO licensing is - in my opinion - a great misconception. I doubt this will work. But we will see.
But the biggest reason you are the bad guy here, is that there was no transparency at all.
You should have stated at the very beginning of this PR, that it will only be merged if RPi pays royalties. You didn't. You ghosted us. And then talk about being transparent ..
Personal optionon:
You did this on purpose, to let this not-yet-offical but great port from Earle and Max gain importance and spread out. To force RPi to pay the royalties by holding the gullible devs (in retrospective, I was to naive, too) as hostage.

PlatformIO is committed to being a silicon-agnostic ecosystem. The term "vendor lock-in" primarily pertains to silicon vendors, who often strive to tie developers to their specific software ecosystem, including IDEs, tools, and frameworks. Our goal is to alleviate this issue. With PlatformIO, switching between different MCUs or silicon vendors is as simple as changing one line in the "platformio.ini" file. You don't need to install new tools, re-invest in your CI/CD infrastructure, or learn a new IDE. We provide the flexibility and freedom to choose the best options for your projects.

If that's the case I think it would be a good idea to update the no vendor lock-in statement to be more accurate, the homepage statement is currently "A place where Developers and Teams have true Freedom(Use favorite OS, IDE, Hardware and Software tools)! No more vendor lock-in!" which implies that specifically "Developers" and "Teams" have this "Freedom" when in reality it would appear that this is just means PlatformIO does not make exclusive licensing deals with any hardware vendors.
If I'm understanding the situation correctly then contrary to the homepage statement "Developers" and "Teams" do not in fact actually have the freedom to "Use favorite OS, IDE, Hardware and Software tools" in cases where their "favorite" "Hardware" is manufactured by a vendor without a PlatformIO licensing agreement.

Regarding commercial silicons, including Raspberry Pi Trading, PlatformIO indirectly contributes to their revenue. It is perplexing why these companies would demand licensing and royalty fees from the open-source community while expecting us to provide a top-tier developer experience. We believe in fair collaboration, where all parties contribute to the growth and success of the ecosystem.

I want to clarify a few points regarding the dynamics at play. Raspberry Pi Trading is a separate company focused on generating profit, rather than being a foundation. They utilize closed ARM cores and ARM charges companies an "entrance fee" and "royalty fee" for each sold Raspberry Pi chip. Additionally, Raspberry Pi Trading has not open-sourced its MCU IP. This means that both ARM and Raspberry Pi Trading benefit financially from the PlatformIO community.

Is ARM also required to pay a license fee for PlatformIO support? Having PlatformIO support would indirectly contribute to the revenue of many organizations/individuals, it seems a bit arbitrary that Raspberry Pi Trading specifically is the entity being specifically asked to pay a licensing fee when there are other commercial entities(such as ARM) in the supply chain that indirectly benefit.
If Raspberry Pi Trading did not exist and the only entity were the foundation would a license fee still be required for PlatformIO support?

To clarify, the licensing fee has not been communicated as an exorbitant amount. If Raspberry Pi Trading truly values freedom for their customers, they should have engaged in a discussion about the licensing fee. We have expressed our willingness to find a fee that aligns with their budget, considering the importance of both communities and reputations. Regrettably, we have not received a response from them.

What qualifies as an "exorbitant amount" is rather subjective and subject to many factors. Are the fees directly or indirectly tied to manufacturing volume? For example per unit licensing fees may be negligible for a hardware component that has a high per unit profit margin and low volume while at the same time being uneconomical for high volume low margin hardware components.
Without having transparency in regards to what the hardware vendor PlatformIO license fees actually are specifically I don't think the community is going to be able to make a reasonable assessment in regards to the fees being "exorbitant" or not.

As an outside party just interested in what's best for the community, I'd like to offer this olive branch:
If PIO merges this PR, I will draft a petition directed at Raspberry Pi Trading to engage in earnest and fair negotiations over a paid agreement for official support with PlatformIO. RPI has made it clear that they value this support, and now the community needs to make it clear that they expect fair turnaround from both parties.

Here's a first draft of what I would offer as a petition for the community to sign. Comments welcome:

Subject: An Open Petition to Raspberry Pi Trading Regarding RP2040 Support in PlatformIO
Dear Raspberry Pi Trading,
We, the open-source community, write this petition in regard to the ongoing issue concerning official support for the RP2040 micro-controller on PlatformIO IDE. This is an issue that impacts all developers who, like us, have benefited greatly from your dedication to creating accessible and user-friendly hardware.
In June 2022, the open-source community, in a true spirit of collaboration and advancement, submitted a pull request aimed at greatly improving Arduino platform support for the RP2040 micro-controller in PlatformIO. However, to our collective disappointment, the progress of this integration was stalled without clear reason.
After nearly a year of silence, we discovered in April 2023 that PlatformIO was pursuing an official support agreement with your organization, including licensing fees, which seemed to be a barrier to the integration we were so eagerly waiting for. This development left us feeling disheartened, and our trust in PlatformIO was put to the test.
We also feel it necessary to express our disappointment at the surreptitious attempt by Raspberry Pi Trading to circumvent this licensing agreement by privately trying to influence the open-source community to merge the pull request. Such actions have strained the trust between Raspberry Pi Trading and the open-source community, which we hope can be mended.
Despite these setbacks, PlatformIO, a small yet dedicated team, has continued to carry the burden of operating a service that incurs hosting and technical support costs. They extend their service to hardware users regardless of whether the hardware vendor remunerates them. Raspberry Pi Trading represents the largest entity for which they incur these costs without compensation.
However, in recent times, PlatformIO has shown its commitment to the open-source community in concrete actions. They have proactively merged the community pull request for RP2040 support, demonstrating their commitment to serving the community. They have reaffirmed their commitments to fair, transparent, and timely addressing of community concerns and involvement. Furthermore, they have expressed their willingness to engage in fair and earnest negotiations over the said agreement with Raspberry Pi Trading. We respect and appreciate these steps, and we now beseech you, Raspberry Pi Trading, to do the same.
We believe in the spirit of open-source. We believe in the creativity, progress, and collaboration it fosters. We implore you to remember this spirit as you engage with PlatformIO and negotiate the terms of the official support agreement.
We understand that there has been a significant discrepancy over what constitutes "very substantial recurring fees." We, as the community that this decision impacts the most, feel it is important that we understand the specifics of these negotiations. Therefore, we request that if a licensing agreement cannot be reached, the last state of the terms as proposed by both parties should be fully disclosed to us, the community. Transparency in this matter will serve to build trust and create a common understanding.
We recognize the incredible value that Raspberry Pi Trading and PlatformIO have brought to the open-source community over the years. Your products and platforms have enabled us to create, learn, and innovate. As we look to the future, we urge you to continue to place the interests of the open-source community at the heart of your decision-making processes.
We, the open-source community, hope this petition is received in the spirit of collaboration, transparency, and mutual respect that defines us. We look forward to a resolution that benefits all parties involved.
Yours faithfully,
[[ The Open-Source Community ]]

We also feel it necessary to express our disappointment at the surreptitious attempt by Raspberry Pi Trading to circumvent this licensing agreement by privately trying to influence the open-source community to merge the pull request. Such actions have strained the trust between Raspberry Pi Trading and the open-source community, which we hope can be mended.

Requiring private licensing agreements with hardware manufacturers like this to merge community developed pull requests is so different from what is the norm for open source projects that I don't think one can really fault Raspberry Pi Trading here for not being interested in pursuing this sort of licensing agreement. Raspberry Pi is generally one of the better hardware vendors when it comes to open source community engagement, although there are certainly areas they can improve.

Despite these setbacks, PlatformIO, a small yet dedicated team, has continued to carry the burden of operating a service that incurs hosting and technical support costs. They extend their service to hardware users regardless of whether the hardware vendor remunerates them.

This doesn't appear to be accurate as the pull request has not been merged, I assume this is in anticipation of it being merged?

Raspberry Pi Trading represents the largest entity for which they incur these costs without compensation.

I think ARM is a larger entity than Raspberry Pi Trading so I don't think this is accurate either.

We believe in the spirit of open-source. We believe in the creativity, progress, and collaboration it fosters. We implore you to remember this spirit as you engage with PlatformIO and negotiate the terms of the official support agreement.

Requiring private licensing agreements with hardware manufacturers like this for merging community developed pull requests tends to be something that's contrary to the spirit of open source collaboration in general so I'm not sure this part makes sense.

Yes, in anticipation of a merge. I'm offering up a best-case path for both parties to follow to mend their reputations.
PlatformIO's costs are most related to specific micro-controllers, so ARM as a broader entity seems less relevant.
I think also a licensing agreement isn't exactly the right way to put it. I think what PlatformIO would be offering is a combination of their hosted registry, technical support to platform end users, and help with further integration of the RasPi SDK. They can correct me on any of these points if I'm mistaken.
Also, to be clear, all of this is predicated on PlatformIO no longer holding this PR hostage in their negotiations, and promising to never do anything like this again.

PlatformIO's costs are most related to specific micro-controllers, so ARM as a broader entity seems less relevant.

It's rather unclear what the cost structure is here. Adding another micro-controller that has a lot in common with other already supported micro-controllers is not really something one would expect to typically be a major cost center in terms of development work.

I think also a licensing agreement isn't exactly the right way to put it.

That was just the terminology PlatformIO is using.

I think what PlatformIO would be offering is a combination of their hosted registry, technical support to platform end users, and help with further integration of the RasPi SDK. As well as prominent advertising of Raspberry Pi as an officially supported partner. They can correct me on any of these points if I'm mistaken.

I think one would typically call this a support agreement with sponsorship typically.

Yes, I agree. I believe this PR also represents a significant alleviation of any potential development burden PlatformIO might have incurred to recognize this agreement, and should be reflected in the (hopefully) finalized terms.
As well, all due respect should be paid by PlatformIO to what looks like nearly 100 contributors to earlephilhower/arduino-pico and particularly maxgerhardt for his dedicated crafting and maintenance of the PR, as well as general patience and transparency in the matter.
Yes, a support/sponsorship agreement is I think a most appropriate descriptor of what is proposed, as I understand it.

Thank you for expressing your concerns and providing feedback. It's important to approach these discussions with respect and constructive solutions. In Ukraine, we call these people - "sofa experts". "Sofa experts" know everything and they have solutions to all problems in the world.

"Raspberry Pi Pico Arduino core and Maximilian's PR"

We appreciate the contributions made by both authors. However, it's important to clarify that PlatformIO does not depend on the "Raspberry Pi Pico Arduino core," and we may not be familiar with it. We have a rigorous review process for merging PRs, and many have been successfully merged, even for commercial development platforms. You can find examples of merged PRs for commercial development platforms in our repositories (see https://github.com/platformio/platform-espressif32/pulls).
Our policy is that if a PR provides commercial integration and the silicon vendor behind it is not our technology partner, the PR will not be merged. This rule applies to all silicon vendors, not just Raspberry Pi Trading. Our existing technology partners support us financially, and it wouldn't be fair to use their contributions to benefit other companies without their consent.
If this is not clear, I would suggest reaching out to IDE providers like IAR or Segger and asking them to provide their IDE for Raspberry Pi Trading products for free. You'll likely find that this is not a common practice. Raspberry Pi Trading, like other businesses, should acquire the appropriate licenses if they want to leverage existing technology rather than investing their own resources. Just as they obtained an ARM technology license and built their MCU on top of it, we expect them to respect the intellectual property of others.
Please remember that over 99% of the open-source code in PlatformIO is written by PlatformIO Labs employees who are paid by the company, not by ARM or Raspberry Pi Trading.

"Inform developers that this integration is not recommended for commercial use"

We appreciate your suggestion to inform developers that the integration may not be recommended for commercial use. We will discuss this internally and find a way to gracefully remove support for Raspberry Pi Trading products without disrupting existing users. In the meantime, we advise users to consider migrating their projects to the tools recommended by Raspberry Pi Trading themselves.

"IP and protecting own investments"

PlatformIO Labs is not a volunteer organization or foundation. We have our own vision for the PlatformIO, which spans decades, not just years. Negative reactions from the community are expected from time to time, and we are committed to being open and providing all the necessary details. If you're interested in our business model, it is based on the TaaS (Technology as a Service) model. You can find a comprehensive explanation of this model in this LinkedIn article.

"VSCode and do we pay to Microsoft"

Microsoft's approach with VSCode is similar to ours. VSCode is free for end developers, but other businesses are not allowed to leverage it without permission. Microsoft has invested significant resources into VSCode, and we respect their decisions regarding its usage. A similar example can be found in this GitHub issue: [link to the issue].

"Open source and 'you owe me'"

It's important to understand that open-source projects operate under different models and principles. While some authors may choose to provide ongoing maintenance and support, it is not an obligation for them to do so. Open-source contributors share their intellectual property with the community voluntarily, and their level of involvement may vary.
At PlatformIO, we value transparency and honesty. We are committed to providing a professional and reliable platform for our users. While we understand concerns about technology theft and competition, we believe in focusing on delivering the best possible solutions to our users and staying ahead in the market.
In the fast-paced business world, it's crucial to act swiftly and strive to be a leader in our field. We appreciate the support and trust of our community as we continue to innovate and improve the PlatformIO ecosystem.
Thank you for your understanding and for being part of our journey 🙏
P.S.: Have a great weekend! 🚀
Regards,
Your friends at PlatformIO.

Our existing technology partners support us financially, and it wouldn't be fair to use their contributions to benefit other companies without their consent.

Being able to use open source code without having to negotiate private licensing deals is kind of a big reason companies participate in open source ecosystems in general. Requiring this sort of consent(ie privately negotiated licensing deals) largely negates that benefit for everyone. I think part of the confusion here is due to PlatformIO's marketing as an open source friendly project while not following the typical open source ecosystem expectations here.

If this is not clear, I would suggest reaching out to IDE providers like IAR or Segger and asking them to provide their IDE for Raspberry Pi Trading products for free. You'll likely find that this is not a common practice.

I understand that you're positioning PlatformIO more in the market segment of closed source commercial IDE's rather than a typical open source development tooling project as many users are expecting, updating the marketing may help clarify this to users so that they will be better able to understand if PlatformIO is suitable for their requirements.

"Inform developers that this integration is not recommended for commercial use"

We appreciate your suggestion to inform developers that the integration may not be recommended for commercial use. We will discuss this internally and find a way to gracefully remove support for Raspberry Pi Trading products without disrupting existing users. In the meantime, we advise users to consider migrating their projects to the tools recommended by Raspberry Pi Trading themselves.

Okay this thread is very long and full of licensing guff so I may be misunderstanding, but I couldn't find any reference to the "not recommended for commercial use" quote in this thread and therefore I'm not sure about the context of this.
Is PlatformIO no-longer usable for commercial projects based on the RP2040?
The license section of the main platformio-core repository states the following, but I don't have very much confidence about using it for commercial projects right now - Quite the opposite in fact, as I'm now rather anxious about the ongoing projects that I'm currently using it for and how much I now need to change!

None of the discussion here has any effect on the LICENSE. This repository and all PlatformIO code is Apache v2 licensed, and this can be used and modified, largely without restriction, for commercial purposes. Most of the rights PlatformIO retains under the license pertain to their trademark/brand use.
The discussion regarding recommendations for what should be used in production are related more to PlatformIO seeming to have recently decided to take an anti-Raspberry Pi stance in their marketing and limit their advertising of support for related products.

Our policy is that if a PR provides commercial integration and the silicon vendor behind it is not our technology partner, the PR will not be merged. This rule applies to all silicon vendors, not just Raspberry Pi Trading. Our existing technology partners support us financially, and it wouldn't be fair to use their contributions to benefit other companies without their consent.

This statement appears in conflict with the months of earnest discussion that this PR began with. Further, in the case of this PR, it is an improvement to an existing vendor support which your team has crafted and openly, prominently, advertised. Today, your main page on PlatformIO.org lists Raspberry Pi as the very first supported vendor in its advertising copy.
It would seem that your team has made a conscious decision since years ago to advertise to and benefit from the viral grassroots marketing afforded by catering to the vast hobbyist community which has rallied around the Raspberry Pi platform.
It is only now where Raspberry Pi has publicly involved themselves in this PR that you seem to have taken this stance, and it appears to be a broader intention to deliberately avoid further advertising of support for Raspberry Pi.
While I understand the frustration that Raspberry Pi appears to have dodged support contract talks, this stance seems openly harmful to your brand and I would caution against further actions which would appear to be "sour grapes" hostility towards Raspberry Pi.
Further, if you are committed to re-branding as a more commercially focused entity I would recommend these immediate steps:

Relocate your domain away from a .ORG TLD, as it is misleading of your focus.
Remove the prominent heart-emoji "Donate" link from PlatformIO.org
Remove all advertising copy indicating that it is a, "project for the community."

This isn't what I want for the direction of the project, and I'm sure many others would agree and part ways, but it is important to keep your message and intentions consistent, honest, and clear.

If this is not clear, I would suggest reaching out to IDE providers like IAR or Segger and asking them to provide their IDE for Raspberry Pi Trading products for free. You'll likely find that this is not a common practice. Raspberry Pi Trading, like other businesses, should acquire the appropriate licenses if they want to leverage existing technology rather than investing their own resources. Just as they obtained an ARM technology license and built their MCU on top of it, we expect them to respect the intellectual property of others.

Let's all be clear here, as it seems your wording in this matter is causing worries over licensing: All of PlatformIO's IDE (or to be pedantic, their VSCode Extension, as they do not provide a full IDE) is permissively Apache v2 licensed, and prominently advertised as such, and as a, "project for the community."
All commercial use is generally permissible without any requirements of paid licensing. The primary rights PlatformIO Labs retain are with regards to their trademark and brand.
That's why this whole thing is so bizarre. Your whole brand lives and dies by your reputation with the open source community, and none of this behavior is in the spirit of the advertising of the project or your long-stated beliefs.
What PlatformIO has been hoping to sell to Rapberry Pi Trading would be better communicated as a support and sponsorship agreement, as I understand it. All this talk of licensing IP is just confusing things and is not appropriate to the discussion.

Okay this thread is very long and full of licensing guff so I may be misunderstanding, but I couldn't find any reference to the "not recommended for commercial use" quote in this thread and therefore I'm not sure about the context of this.
Is PlatformIO no-longer usable for commercial projects based on the RP2040?

@yngndrw
This comment:
https://github.com/platformio/platform-raspberrypi/pull/36#issuecomment-1501724359
It's not about licensing, it's about the features and support of the current raspberrypi platform in the registry.

"VSCode and do we pay to Microsoft"

Microsoft's approach with VSCode is similar to ours. VSCode is free for end developers, but other businesses are not allowed to leverage it without permission. Microsoft has invested significant resources into VSCode, and we respect their decisions regarding its usage. A similar example can be found in this GitHub issue https://github.com/platformio/platformio-vscode-ide/issues/1802

This is not an appropriate analogy. VSCode is free to end developers, and also free to other businesses to leverage! This is particularly egregious, as you are in fact operating a business which does exactly this.
What that issue addresses is that the hosted extension marketplace for VSCode is not included in their terms of use to be served from other software (which would include VSCode forks, but not exclusively apply to that).
The closest analogy for you would be if someone forked PlatformIO, you wouldn't allow your hosted Registry to be used by the fork. That's fair and reasonable. Let's not conflate that with any restrictions on broad use of the IDE software.

It would seem that your team has made a conscious decision since years ago to advertise to and benefit from the viral grassroots marketing afforded by catering to the vast hobbyist community which has rallied around the Raspberry Pi platform.

Further to this point, both Atmel and STMicroelectronics are among the most-used vendors on your platform. Both are prominently advertised and supported by the team. Both are very popular with hobbyists (e.g. Atmel for the original core of the Arduino product line and STMicro for the "blue-pill" and "black-pill" boards).
Should we now be worried that these platforms will be de-listed in a similar manner to what you seem to be attempting against Raspberry Pi if Atmel and STMicro do not enter into support contracts with PlatformIO?

"Being able to use open source code without having to negotiate private licensing deals is kind of a big reason companies participate in open source ecosystems in general."

We understand the value of open-source ecosystems and the benefits they bring to companies. PlatformIO is fully committed to providing a collaborative platform for embedded development that is both free and open source. Our advanced tools, such as the unified debugger, unit testing engine, static code analysis, and remote development, are all available at no cost. We operate under the permissive Apache 2.0 license, which means there is no need to negotiate private licensing deals with us if you are using PlatformIO Core and our IDEs for commercial projects. We continuously invest in these tools to ensure they meet the needs of our users.

"PlatformIO's marketing as an open source friendly project"

We take pride in being an open-source-friendly project and do not engage in word manipulation or misleading marketing. If you explore our website at PlatformIO Labs, you will find a dedicated link to the PlatformIO Open Source project under the "Technology" menu. Unlike proprietary IDEs such as IAR, Segger, ARM Keil, and Eclipse-based vendor IDE, we have chosen to embrace openness and provide developers and our technology partners with a collaborative environment. We welcome everyone to participate in the small revolution we initiated in the silicon industry eight years ago. Instead of charging developers and businesses for using our free tools, we charge silicon vendors who wish to leverage our modern and rapidly growing ecosystem for next-gen embedded development. It's important to note that commercial integration with the PlatformIO ecosystem may require a special license, as outlined in our public pricing page. We strive to strike a balance between supporting the open-source community and sustaining our operations.

"Is PlatformIO no-longer usable for commercial projects based on the RP2040?"

For questions regarding commercial projects based on the RP2040, it would be best to reach out directly to Raspberry Pi Trading. They have rejected our proposal and are working on their own tools, which are the only officially recommended options for commercial use (see https://github.com/platformio/platform-raspberrypi/pull/36#issuecomment-1560504425). As we don't have official support for RP2040, we cannot provide technical or maintenance assistance in this regard. If you encounter any questions or issues while using PlatformIO with RP2040 in its current state, I recommend contacting Raspberry Pi Trading, although they may redirect you elsewhere or encourage the use of their own tools and workflows. This situation exemplifies the "lock-in" approach where fewer choices are provided to customers.
Additionally, merging the PR for RP2040 integration would likely result in an ongoing cycle of new PRs to avoid licensing fees under the guise of "community contributions". We have numerous other ideas on how to invest our resources and energy to increase the adoption of our technology.

"catering to the vast hobbyist community which has rallied around the Raspberry Pi platform."

Is it a joke? If is not, it seems there may be some confusion here. The Raspberry Pi 2040 (RP2040) was announced in 2021, and by that time, over 2,000,000 developers were already using PlatformIO. Therefore, the share of RP2040 within the PlatformIO ecosystem is relatively small compared to other development platforms that drive our ecosystem forward.

Conclusion: We appreciate your feedback and encourage constructive discussions. If you have any concerns or disagreements with our business model, we encourage you to propose an alternative approach. Alternatively, if you believe there is a better organization or repository on GitHub that can provide a superior replacement for the existing Raspberry Pi Trading legacy workflow in embedded development, please create it. We will gladly include a link to your "better ORG" in this PR and repository.

@ivankravets

"Our advanced tools, such as the unified debugger, unit testing engine, static code analysis, and remote development, are all available at no cost."

Putting my two cents in this round. You address professionell users who are interested in using the tools for free. But this users should pay, not the silicon vendors.
I'm using PIO a very long time and I remember this was your first business model, simple things are for free, for advanced users you have to pay for better tools. This was ok for me, but I never understand why you changed it.
I think many users are people who don't earn money with their passion, so take the money from professionals.
I understand Raspberry Pi, why should they pay for something they haven't ordered, every serious company think so.
Your attitude is dismissive to Earl E. Philhower and Max Gerhardt who invest many time to make it possible to serve a working Arduino core to PIO, shame on you.
You should think about that your business model is a gate keeper for silicon vendors who want not share your business model.
I don't think this  is the spirit of Open Source. Your general mission failed. Bye...

Dear @sstaub,
Thank you for your long-standing support and for sharing your perspective. We appreciate your feedback and would like to provide further insight into our position 🙏
At PlatformIO Labs, we have always believed in creating an inclusive and accessible ecosystem for developers of all backgrounds. Our initial business model focused on offering enhanced tools and features for advanced users through paid options while keeping the core functionalities free for everyone. This approach allowed us to strike a balance between serving the needs of professionals and supporting those who may not earn money from their passion projects.
However, as we evaluated the direction of our platform, we made a conscious decision to maintain free access to the modern ecosystem we have built. By doing so, we aim to remove barriers and enable talented engineers to enter the silicon industry without the burden of expensive proprietary tools. We firmly believe that charging developers, hobbyists, and others for essential access to PlatformIO would align us with the proprietary tooling market, where costs per engineer can range from $1000 to $5000 per year. Such an approach would hinder progress and perpetuate outdated workflows that have existed for decades.
Our mission has always been to challenge vendor lock-in, break monopolies, and empower developers with a professional ecosystem for embedded development. We have consciously chosen to prioritize the accessibility and progress of technology over immediate financial gains. Regardless of the challenges we may face, we remain committed to ensuring that anyone, anywhere can have free access to a powerful embedded development ecosystem.
Once again, we appreciate your support and value your perspective. We continuously strive to improve and evolve, guided by our mission to foster an open and inclusive environment for the benefit of the entire embedded development community.

Instead of charging developers and businesses for using our free tools, we charge silicon vendors who wish to leverage our modern and rapidly growing ecosystem for next-gen embedded development. It's important to note that commercial integration with the PlatformIO ecosystem may require a special license, as outlined in our public pricing page. We strive to strike a balance between supporting the open-source community and sustaining our operations.

I can't find any information regarding "special license" pricing on the public pricing page for hardware vendors, was this accidentally removed or something?

Additionally, merging the PR for RP2040 integration would likely result in an ongoing cycle of new PRs to avoid licensing fees under the guise of "community contributions".

I can't find any indications in the marketing material that community supported vendor hardware is not supported. This is extremely unusual as I'm not aware of any other open source project rejecting contributions for similar reasons.

This situation exemplifies the "lock-in" approach where fewer choices are provided to customers.

Keep in mind the "special license" vendor "lock-in" strategy here is a strategic choice made by the PlatformIO project and not Raspberry Pi which is a big reason why everyone finds this community PR rejection so strange.

@ivankravets Thank you for re-asserting your commitment to open-source, as your recent comments had called this into question. Since I know this PR has recently pulled in a lot of outsiders who are only vaguely familiar with PlatformIO, I'd like to openly acknowledge and pay respect to what you've achieved here:
PlatformIO started as an MIT-licensed project by Ivan in 2014, and the core of it has been Apache 2.0 licensed since 2015. It has in large part been a two-man operation coming from Ivan and Valerii since that period. As Ivan mentioned above, some features of their IDE (e.g. the debugger and unit testing elements) had been locked behind a subscription for a time, but they managed to offload the costs of developing these to vendor partnerships and opted to make the whole environment open-source in 2019.
The top comment on the HN thread from a couple of days ago closed with this:

"The PlatformIO team’s responses all feel like they were written by a team of lawyers and PR people, or at least someone trying to pretend to be a team of lawyers and PR people. I don’t entirely understand what’s going on with this whole situation but from what I’ve seen I think I’ll steer clear of PlatformIO in the future."

I saw many similar sentiments in the comments there as well. So, I just want to acknowledge Ivan as a technical founder who has for nearly a decade focused on making PlatformIO an open-source developer-friendly ecosystem. If you "git blame" the most recent commit to platformio-core, the vast majority of the 40K+ lines in it were personally most recently touched by Ivan. This is a passion project by a developer who has long-held and prioritized open-source values.
Now more recently, with them operating out of and living in Kyiv, I can imagine that the stresses of daily life are more significant than that for most of us around the world the past couple of years. I also want to acknowledge that and respect that they've been continuing to make great progress in that time, and wish for the safety and well-being of them and their loved ones.
Again, thank you Ivan and Valerii for the great achievements here and your continued commitment to making the best embedded development environment fully free and open for developers!
With all that said, I do still feel that there are some unaddressed major outstanding issues in Ivan's current response to this PR, and some of them do come from what feels like "corporate split-tongue talk" (to paraphrase the quote above). I hope that Ivan can be earnest in addressing the community to resolve these, as the reputation of the project appears to have been hurt not just by the particulars of how this PR has been addressed but also by the impersonal approach to engaging with the community; often avoiding directly addressing important points:
Precedent of robust support without a vendor support contract
This is certainly first and foremost: You are now saying your primary worry about merging this PR is that it could set a precedent for merging other similar ones which would serve to bypass your value-add when approaching silicon vendors for support contracts. Again, I don't think licensing is really the term you want to be throwing around here, given what you're offering.