add(board): add Pimoroni Explorer RP2350 (PIM720)

[tyeth]

Tested buttons, i2c, gpio0-5, display and speaker.
I'll stick up a board page on circuitpython-org at some point soon.
Otherwise it's https://shop.pimoroni.com/products/explorer?variant=42092697845843

[bablokb]

I object to the changes in .devcontainer/. They are unrelated to this PR. They put temporary/build-environment files below the circuitpython/ directory, so running git status will detect new and non-commited files. Also, these changes do not improve anything.

Please revert these changes.

[tyeth]

I object to the changes in .devcontainer/. They are unrelated to this PR. They put temporary/build-environment files below the circuitpython/ directory, so running git status will detect new and non-commited files. Also, these changes do not improve anything.

Please revert these changes.

Thanks for spotting those!
I found the dev container doesn't have write access to /workspaces/ so the current scripts do not work for raspberry pi (+cortex-m). I'll drop from this PR and fixup to use /tmp/ or something.

[bablokb]

I found the dev container doesn't have write access to /workspaces/ so the current scripts do not work for raspberry pi (+cortex-m).

This is strange because it worked in the past, but maybe Github has changed something. I haven't used this recently. I will check tomorrow and see how this can be fixed. Anyhow, this should be handled in a separate issue/PR.

[tyeth]

I found the dev container doesn't have write access to /workspaces/ so the current scripts do not work for raspberry pi (+cortex-m).

This is strange because it worked in the past, but maybe Github has changed something. I haven't used this recently. I will check tomorrow and see how this can be fixed. Anyhow, this should be handled in a separate issue/PR.

Before you go wasting too much time testing, I might have messed up the first run of the dev container, due to impatience/ misreading the messaging (running multiple instances of postCreate).
Subsequent things might have been jeapodised by that, although I did destroy the container before recreating in later tests [way before editing the scripts].
The codespace user doesn't have write access to /workspaces/, only /workspaces/circuitpython, but if the postCreate script user is root then maybe it does work.
I always saw a couple of permission denied errors peppered in the script and a lack of arm-gcc created in workspaces / on $PATH, and possibly cloned submodules although maybe my impatience on the first go as I remember manually running make fetch-port-submodules. Later after path changes I verified the postCreate submodule fetch script worked.

[bablokb]

@tyeth I just tested it: /workspaces is writable and the exiting scripts just work. /workspaces is owned by user 'codespace' and that is the user that I am automatically login with.

So this might really be a problem caused by what you did. Or by something going on in the backgroud, it is a cloud platform after all and things are updated once in a while and if you use it at the wrong moment things might break.

[tyeth]

You mention the cloud. Is this testing locally in vscode or online in GitHub codespaces?

[bablokb]

All the scripts in .devcontainer are targeted at (online) Github codespaces. At the time of writing them, dev containers weren't available locally. Even now, local devcontainers don't provide the full functionality. VSC expects a .devcontainer/devcontainer.json, but this does not exist for CircuitPython, since there are port-specific .devcontainer/<port>/devcontainer.json files which you can select at container creation from Github, but not locally from VSC.

Nevertheless, it might be the time to evaluate local devcontainers again. Maybe the scripts have to be generalized, or maybe it just needs a HOWTO on how to use them properly for local devcontainers.