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
platform = ststm32@14.0.0
platform_packages =
framework-arduinoststm32@~4.10900.0
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.
You will see however that the platform = wizio-pico@<version> syntax will not work because they are not released in the PlatformIO package system. A request for https://api.registry.platformio.org/v3/packages/platformio/platform/wizio-pico will give 404 whereas e.g. https://api.registry.platformio.org/v3/packages/platformio/platform/ststm32 will show you all the available versions. Also there are no releases here which the platforms usually have.
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.
So a perfectly valid thing to do is saying
platform = https://github.com/Wiz-IO/wizio-pico.git#ad2d813e2deee73ef4e162ce07f5560236cd7ed5
(current master commit) and that will freeze the entire platform. Not the packages because there’s another caveat, below.
One can also e.g. do
platform = https://github.com/Wiz-IO/wizio-pico.git#v106
to refer to a brach (this branch is 2 months old so you shouldn’t use it, just an example).
And finally you can also independently change the package version. As you can see in here and
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
platform = https://github.com/Wiz-IO/wizio-pico.git#ad2d813e2deee73ef4e162ce07f5560236cd7ed5
platform_packages =
framework-wizio-pico@https://github.com/Wiz-IO/framework-wizio-pico.git#62054597f18cec5c7e312c1286289e24de1d756b
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.