There are currently 3 platforms available for targeting the Pico/RP2040 in PlatformIO, only Max’s extension of the earlephilhower core and the wizio-pico support the official RPi SDK.
To the best of my understanding, Max’s extension offers partial support for the official SDK whilst Wizio’s offers the full SDK.
It appears the wizio-pico repo was sadly discontinued by the original author @wizio , and as a result there appear to be at least 3 dozen forks of the last PR from a fork of the original repo: https://github.com/blackketter/wizio-pico.
None of these forks appear to be actively maintained, some last updated in 2022 some in early 2023. This currently appears to be the most recent: https://github.com/ec-solutions/ez-pico
The original author has also updated 2 new repos relatively recently seemingly related to the original repo: https://github.com/Wiz-IO/framework-wizio-pico https://github.com/Wiz-IO/wizio-pico-examples
So my question really boils down to where I place my bet…
I could follow the other 36+ forks and try and maintain my own standalone fork, which seems like a broken approach long-term. I’m fairly certain I can’t be the only one reluctant to base their project off an unmaintained build environment.
@maxgerhardt your extension contains the full SDK is it possible to target the full SDK without including the (any) Arduino core?
Could you clarify why I can’t pull in headers in rp2_common but I can include from common and rp2040? Eg. I can’t #include "pico/malloc.h" but I can #include "pico/multicore.h" and #include "hardware/structs/systick.h" I don’t really understand the PIO setup here.
Is there an approach where we can integrate some of wizio-pico into your work so at least we can have a common codebase and take advantage of all the board defs in the Earle Philhower core?
Lastly, if not, would you have any suggestions on building a baremetal-pico platform that might get community support to remain actively maintained?
Thoughts much appreciated, especially those that might avoid any foot-shooting and yak shaving…
The Arduino-Pico core allows programming against the SDK (currently 1.5.1, latest one) like the docs say. There is however no way to disable the compilation of the Arduino core files – alas, if you don’t use any of the Arduino functions, most should be thrown out by the linker though. For some things though, you have to go through the Arduino functions. And whether that programming is done in the Arduino IDE or in PlatformIO doesn’t matter.
Currently I don’t know of a PlatformIO platform like WizIO’s that has gives pure access to latest Pico-SDK and I’m not working on one.
This pulls in the framework-wizio-pico framework and 2 other packages from the original author.
I’ve now forked the platform and those 3 original repos and updated the platform.json in wizio-pico to those forks just to avoid any more repos being randomly deleted that I might depend on.
I have to say the build and upload is rapid, and noticeably faster than with the Arduino core. repack-sdk.py in tool-wizio-pico appears to re-package the original SDK and flatten the file structure, which might be the reason… which is also going to make it harder to reason about.
I am relatively very new at this and specially at Raspberry Pi Pico, I tried using normal Pico SDK and it was working and then suddenly cmake stopped and I could not figure out anything so I switched to platformIO which is working fairly but I want to access Pico specific functions and I am trying for hours now, I am trying different platforms but they always end up with weird errors, I tried Arduino Pico, it doesn´t work and gives me this error about missing commands from git. And someone on git told me that Arduino Pico is for some other arduino core (Whatever that means). And now I am trying this what you mentioned (I have attached contents of the file below), as you mentioned and it gives me this error
Verbose mode can be enabled via -v, --verbose option
Error: Unknown board ID ‘pico’
It refers to this file platform.ini
; Build options: build flags, source filter
; Upload options: custom upload port, speed and extra flags
; Library options: dependencies, extra library storages
; Advanced options: extra scripting
; Please visit documentation for the other options and examples
The issue is in the error you have posted: Error: Unknown board ID ‘pico’ You have specified an invalid board name in your platform.ini. The board name is very specific and map a boards unique configuration back to a standard one.
If you want to use Platform.IO with the Pico SDK below is a minimal generic platform.ini file that I currently use, with the forks I made of the original wizio-pico platform & frameworks against SDK v1.4.
I get this when I include this
src\main.cpp:10:17: error: expected constructor, destructor, or type conversion before ‘;’ token
compilation terminated due to -Wfatal-errors.
*** [.pio\build\pico-dap\src\main.cpp.o] Error 1
Firstly, the code you have posted is either incomplete, badly formatted, or won’t compile. You need to post what you are working with - and format it so people can read it.
Secondly, none of the code I can read is sending anything to the serial ports. What is it you expect to monitor?
Thirdly, you need to get a minimal working example to solve your problem. You have a load of code in there that may - or may not affect affect what is happening, but 99% of it is unrelated to solving your serial port issue. All your man.cpp should contain is this:
Fourth, you changed the platformio.ini I originally posted without the basics working and removed the USB build flags, which is what I assume you want.
Lastly, friendly advice. Don’t even think of touching the Pico’s PIO interfaces until you have an understanding of how this all works. Get your basics working properly and then build on that. I would suggest you start a new thread on the community for future help.
I have to work with PIO, that is the main point and I am struggling. Mainly because of switching between softwares. I started with standard PICO SDK, everything was fine and then cmake stopped working saying some configuration setting is bad and I had not changed anything.
I switched to platformIO and I could work basically and my functionality was working with some irregularities and to solve that I had to include PICO SDK functions so I found your post, tried that and now sort of again starting from the bottom, for the third time.
Great to hear from you!
I appreciate you felt let down after all the work you put in to the framework, but if you’d like to reconsider, I’d be glad to be a part and be an active contributor, and have been merging in bug fixes to my fork as I find them.
One area I have been looking at is pulling in the libraries and ArduinoCore-API from the earlephilhower core into a standalone lib as part of the framework. This core seems to have a great many libraries implemented with a lot of eye balls on it and means we could share the Arduino library maintenance and focus of Arduino API compatibility with the SDK, as well as update it to 1.5
For example, for some reason I couldn’t get UART to play nicely across multiple cores so had to re-implement that from scratch.
My goal currently is to get the framework up to SDK1.5 with normal Pico conventions, compile out any basic Arduino calls like Serial.print/ln, byte, millis etc which seems to cover 75% of libraries I’ve looked at, and then just include an Arduino.h as an API compatibility layer.
I also need to find a way to auto generate a library.json for any included library to avoid PIO needing lib_compat_mode = off
I would also be awesome if you could explain how you re-package the Pico SDK. Compile times are super fast, but I’ve still not understood how it all comes together.