A few months ago, this installed version 1.0.8 of framework-wizio-pico. A new installation today installed version 1.0.9. Is there a way to specify an exact version for better stability/reproducibility of the dev environment.
Ideally this would be in a checked in file such as platformio.ini such that it stays with the project, as libdep does.
Thanks Wizio. Yes, there we some reports on the Pico SDK forums about issues with SDK 1.2.0 so I wanted to control which one I use. (I also noticed slightly better memory and cpu optimization with 1.2.0).
Is there a way to specify that the project uses 1.0.8?
I believe that being able to check out a project and automatically reproducing the development environment, including versions of the various components, is an important aspect of platformio. Otherwise results are non predictable.
All PlatformIO core platforms can do this. WizIO’s platform is slightly different due to it still being in development and not having Github releases or being integrated / recongized as a builtin PlatformIO platform yet.
The way things usually work is that you have a “platform”, e.g. https://github.com/platformio/platform-ststm32/. This platform is specific to one microcontroller platform, say STM32 chips or the Raspberry Pi RP2040 series. It contains:
Board definitions
Platform code (platform.py, connects the platform code to the PlatformIO core, sets up various things such as uploader methods)
Builder code (builder/main.py, builder/frameworks/arduino.py, …, this tells SCons how to build the firmware for a specific framework, say Arduino)
Declaration of packages used by the platform (platform.json)
Miscellenous stuff (SVD files, …)
A platform of one particular version in term makes use of packages. These packages are declared in the platform.json manifest file, see e.g. here.
A package can contain anything. Typical packages are the compiler (toolchain-gccarmnoneeabi), upload tools (tool-openocd) and framework code (framework-arduinoststm32). The packages reside in the PlatformIO trusted package repository (accessed by pio package publish .. etc on the CLI).
The platform.json specifies the default version of a used package. See e.g.
this is from the STSTM32 14.0.0 version of the file, stating that the package framework-arduinoststm32 shall be used in the version ~4.20000.0, which is a SemVer encoded version string for Arduino Core 2.0.0 (~ meaning ‘circa’, aka minor version updates are allowed).
In the platformio.ini you can control what version of the platform you are using. This is true for all platforms as this is a PlatformIO core feature. See e.g. here.
By doing
platform = ststm32
you instruct PlatformIO to use whatever the latest ST STM32 platform is that you have installed in PlatformIO. By doing e.g.
platform = ststm32@7.0.0
you will get the 7.0.0 release of the platform which first introduced Arduino core 1.9.0, which you also see in the platform.json
So by stating which release version of a platform you want, you can thus also control what e.g. Arduino core version you want, which is controlled by the package version the platform specifies.
However, you can also control it independently by using the platform_packages directive in the platformio.ini. With this you are able to set an explicit (semantic) version for a package that PlatformIO shall use. So you can say, use the latest platform code but with an older package (e.g. an older Arduino core), say with
you are able to specify that you want the fixed platform version 14.0.0, which would give you Arduino core 2.0.0, but then we also override the to-be-used version of the framework-arduinoststm32 package to the 1.9.0 version.
However, you can still refer to a specific git commit hash or branch, as shown e.g. here and here. This works universally. You can also inspect all branches here and all commits here.
the platform does not a fixed version string to refer to the package where the SDK code is stored but uses a git reference. This has a nasty side effect that even if you specify older platform versions the platform.json of these will still point to the framework via git and will thus pull the latest version on the default branch of that repo. This is not the way it’s usually done in PlatformIO-controlled platforms, as I’ve shown above with STSTM32 and version strings refering to the PlatformIO package repository. Again, framework-wizio-pico is not registered with the PlatformIO registry, as opposed to e.g. framework-arduinoststm32.
But, as I’ve already shown above we can still manually control the version of the used package with platform_packages, and inside those expressions we can refer to a git repo’s commit hash and branch.
So, once you’ve e.g. tested your firmware to be compilable and working on one particular platform and package version, you can extract those commit hashes (execute git log -n1 in the platform and framework folder, e.g. C:\Users\<user>\.platformio\platforms\wizio-pico and C:\Users\<user>\.platformio\packages\framework-wizio-pico) and hardcode them into the platformio.ini.
For example with taking the most recent commits of both, one can do
and that will freeze the platform and framework package code version, giving you reproducable results.
As explained above, to make this easier, the developer of the platform should register the platform and the packages it uses with the PlatformIO registry, so that a versioning exists for these things that can be refered to with the usual @<version> syntax. The platform.json should then also be changed to not refer to a git link, but to a particular publish version in the registry.
Thanks @maxgerhardt!. Very useful and informative and answered my question and beyond.
I will ready it carefully and will see how I can apply it to my projects.
@wizio, this is very interesting material. How about registering ‘baremetal’ as a out of the box platform? (‘sdk’ may be a more descriptive name than ‘baremetal’ ?).
Hi, @maxgerhardt, I determined the two commit hashes I want to use (an older version) and set them up in my platformio.ini. When I build, they seems to be fetched correctly but I am getting a warning about an ambiguous source for the compiler (with your name in it ;-))
Any suggestion?
Warning
=======
Tool Manager: Installing toolchain-gccarmnoneeabi @ =1.70201.0
Tool Manager: Warning! More than one package has been found by toolchain-gccarmnoneeabi @ =1.70201.0 requirements:
- platformio/toolchain-gccarmnoneeabi @ 1.50401.210106
- maxgerhardt/toolchain-gccarmnoneeabi @ 1.40903.0
Funny. The version requement is @ =1.70201.0 yet it lists a 1.50401.210106 and a 1.40903.0 version which are clearly completely out of range. But I think I observed that behavior too.
Later in the build / after unpacking and installing everything, it should print PACKAGES: with the used packages and their version. What is the compiler version there?
Okay so it indeed found the package of the correct version, which is nice. Maybe the package warning is just a general warning, even though it is not related to the actual packages used. I will open an issue in the core for that.
Thanks @wizio. I tried these two platformio.ini but it doesn’t work. The serial port is established, the uploaded uses it successfully to enter boot mode, and the program runs but I don’t see any output. Do you happen to have a hello world with the latest version that printf to USB/CDC?
[env:raspberry-pi-pico]
; Fixing to Wizio 1.08 which is known to be good.
platform = https://github.com/Wiz-IO/wizio-pico.git
platform_packages =
framework-wizio-pico@https://github.com/Wiz-IO/framework-wizio-pico.git
board = raspberry-pi-pico
framework = baremetal
upload_protocol = picoprobe
debug_tool = picoprobe
; Adjust it to the COM port used by the analyzer on your system.
monitor_port = COM4
; This enables Pico's int64 printf.
board_build.nano = disable
board_build.pio = src/display/tft_driver.pio
build_flags =
-O3
-Wno-missing-field-initializers
-I src
-I "$PROJECT_CORE_DIR/packages/framework-wizio-pico/SDK111/hardware"
-I "$PROJECT_CORE_DIR/packages/framework-wizio-pico/SDK/pico"
-D LIB_PICO_STDIO_USB
lib_ignore = freertos, wiring
[env:raspberry-pi-pico]
; Fixing to Wizio 1.08 which is known to be good.
platform = https://github.com/Wiz-IO/wizio-pico.git
platform_packages =
framework-wizio-pico@https://github.com/Wiz-IO/framework-wizio-pico.git
board = raspberry-pi-pico
framework = baremetal
upload_protocol = picoprobe
debug_tool = picoprobe
; Adjust it to the COM port used by the analyzer on your system.
monitor_port = COM4
; This enables Pico's int64 printf.
board_build.nano = disable
board_build.pio = src/display/tft_driver.pio
build_flags =
-O3
-Wno-missing-field-initializers
-I src
-I "$PROJECT_CORE_DIR/packages/framework-wizio-pico/SDK111/hardware"
-I "$PROJECT_CORE_DIR/packages/framework-wizio-pico/SDK/pico"
-D LIB_PICO_STDIO_UART
-D LIB_PICO_STDIO_USB
lib_ignore = freertos, wiring
