Generate Platform.IO board definitions

[earlephilhower]

As part of the boards.txt generation, also make necessary files for
Platform.IO.

Fixes #399

[maxgerhardt]

This looks like a very good start, but there are some things to iron out:

• the JSON files double-define build.variant and build.arduino.earlephilhower.variant (the latter which is always a constant rpipico), but for boards only supporting one core, there should also only be one variant definition as to not make it confusing.
• since the builder script prefers the value in build.arduino.earlephilhower.variant first and if that does not exist goes to build.variants, all the generated board JSON files are using the constant rpipico variant folder and not the actually wanted folder
• the value of the variant should be the folder name, verbatim. looking at e.g. adafruit_feather.json, it has "variant": "ADAFRUIT_FEATHER_RP2040", but the folder name in the Arduino core is adafruit_feather, and hence wrong in both the upper-casing of the name and the actually wrong folder name. Other boards like adafruit_itsybitsy.json reference ADAFRUIT_ITSYBITSY_RP2040 although it should be adafruit_itsybitsy, etc.
• The values for boot2_source are missing the .S file extension at the end
• We might additionall want to use this opportunity to get rid of the constant 500mA USB load current define introduced in Fix PlatformIO build #395 since we get the real source data here, and some boards do have a differing 250mA, by writing it into the extra_flags or a new field in the earlephilhower object that is then processed by an adapted builder script.

The rest looks good. I can complete the fixup and testing of it by next week for sure.

[earlephilhower]

The JSON files double-define build.variant and build.arduino.earlephilhower.variant (the latter which is always a constant rpipico), but for boards only supporting one core, there should also only be one variant definition as to not make it confusing.

Since the builder script prefers the value in build.arduino.earlephilhower.variant first and if that does not exist goes to build.variants, all the generated board JSON files are using the constant rpipico variant folder and not the actually wanted folder

The value of the variant should be the folder name, verbatim. looking at e.g. adafruit_feather.json, it has "variant": "ADAFRUIT_FEATHER_RP2040", but the folder name in the Arduino core is adafruit_feather, and hence wrong in both the upper-casing of the name and the actually wrong folder name. Other boards like adafruit_itsybitsy.json reference ADAFRUIT_ITSYBITSY_RP2040 although it should be adafruit_itsybitsy, etc.

The values for boot2_source are missing the .S file extension at the end

We might additionall want to use this opportunity to get rid of the constant 500mA USB load current define introduced in Fix PlatformIO build #395 since we get the real source data here, and some boards do have a differing 250mA, by writing it into the extra_flags or a new field in the earlephilhower object that is then processed by an adapted builder script.

I also found a missing comma in the generated JSONs, fixed.

Can you please eyeball things again, @maxgerhardt ?

[earlephilhower]

Also, I'm not sure about the PIO packaging process, but if you think we should combine it with the release process here, let me know. I push out bugfixes every 2-3 weeks, so I know it can be a pain keeping up if you manually have to generate a new PI O package.

[maxgerhardt]

This looks very good now, I'll verify compilation in a project and report back.

I push out bugfixes every 2-3 weeks, so I know it can be a pain keeping up if you manually have to generate a new PI O package.

This is not a problem yet since there is not yet a PlatformIO package of this core in the PlatformIO registry. The PlatformIO projects in the documentation reference the git link to this repo, and in my test projects they link to my fork https://github.com/maxgerhardt/arduino-pico, for which I can easily fetch upstream changes with just one button.

After I get debugging finally working (with the help of hopefully raspberrypi people) and the toolchain package is published (earlephilhower/pico-quick-toolchain#4 and earlephilhower/pico-quick-toolchain#5 are still open), then I, or you, can publish the package in the PIO repository.

From other repositories I have seen Github Action files which actually automate this -- I don't remember which one exactly, but I can have another look. After all though, all the github action must do is call pio login with some secret provided in the repo and then pio package publish, so it's definitely possible.

[zjwhitehead]

Thanks for all your work on this guys. I'm really looking forward to building for (adafruit) RP2040 with PlatformIO

[maxgerhardt]

Sooo I finally got around for a quick test and this is working properly now. The JSON files can be used as-is and I've already added them in my platform's board/ folder where they belong (https://github.com/maxgerhardt/platform-raspberrypi/tree/develop/boards). I've created the project https://github.com/maxgerhardt/pio-pico-earlephilhower-test-all-variants/ to ensure a sketch compiled successfully for all now 23 boards.

3 things:

• This needs a minor fixup of the builder script ( Correctly use earlephilhower.varant if variant not given, ensure USB… #444)
• Do we want to keep the generated JSON files here for reference? They're only needed in platform-raspberrypi to be made available to the users. (That also means, if there's an update to the board JSON files, they would need to be merged back into platform-raspberrypi to become effective). I would say keep them here from for reference and to not complicate things.
• The Pico board is now double, platform-raspberrypi already had a pico.json which I've extended to be core-switchable (by default mbed-os, with board_build.core = earlephilhower it switches to this core), and now we have rpipico.json which is the earlephilhower-only version of the board, which technically already covered by pico.json. However, I also see rpipicp.json being useful as no core-switching directive is needed then in the platformio.ini. The same with arduino_nano_connect.json (this core) and nanorp2040connect (mbed-os core) being for the same physical board. I would say however to keep both board definitions for simplicity of generating them.

[earlephilhower]

* This needs a minor fixup of the builder script ([ Correctly use earlephilhower.varant if variant not given, ensure USB… #444](https://github.com/earlephilhower/arduino-pico/pull/444))

Will merge after this one...

* Do we want to keep the generated JSON files here for reference? They're only needed in platform-raspberrypi to be made available to the users. (That also means, if there's an update to the board JSON files, they would need to be merged back into platform-raspberrypi to become effective). I would say keep them here from for reference and to not complicate things.

Sure, let's keep them here.

* The Pico board is now double, platform-raspberrypi already had a `pico.json` which I've extended to be core-switchable (by default mbed-os, with `board_build.core = earlephilhower` it switches to this core), and now we have `rpipico.json` which is the earlephilhower-only version of the board, which technically already covered by `pico.json`. However, I also see `rpipicp.json` being useful as no core-switching directive is needed then in the `platformio.ini`. The same with `arduino_nano_connect.json` (this core) and `nanorp2040connect` (mbed-os core) being for the same physical board. I would say however to keep both board definitions for simplicity of generating them.

Also agreed, makes it easier for the end user I think.