feat: initial zephyr support

[HipsterBrown]

Fixes #222

With this PR, Zephyr support has been added to the following commands:

• setup
• teardown
• build
• run
• doctor / info

It's not a quick process at the moment. The slowest part is the west packages pip --install and west sdk install. I'll explore ways to speed it up as folks use it. It may also be worth exploring using uv for the python virtual environment creation rather than the system or brew/apt installed python. It would be neat to try out zerobrew for faster Homebrew package management as well.

There's also opportunity for other DX features like a convenience command for creating a new board target, managing overlays, and scanning for available devices. At the moment, new board targets will be blown away by Moddable SDK updates unless a specific branch is provided to the xs-dev update command. Maybe it could be possible to store board / device targets in a project directory instead of the SDK repo.

[HipsterBrown]

🚀 PR was released in v1.1.0 🚀

[phoddie]

Woohoo!!

[phoddie]

There's also opportunity for other DX features like a convenience command for creating a new board target, managing overlays, and scanning for available devices. At the moment, new board targets will be blown away by Moddable SDK updates unless a specific branch is provided to the xs-dev update command.

Great observation. Because each of the hundreds of boards supported by Zephyr can be a Moddable SDK target, it is a little overwhelming. The good news is that mcdevicetree does nearly all the work of creating a functional port. That's very different from other platforms we support. I was thinking we could simply provide a default port when there is a Zephyr target requested that isn't in the Moddable SDK's Zephyr platform support, for example mcconfig -d -m -p zephyr/foo, we would map that to Zephyr's foo board to provide the default behavior for that. If you want more than the default provides, you can still do that.

As an example, the nucleo_f413zh board support is just two files. The first defines ZEPHYR_BOARD to nucleo_f413zh and the other is a two line provider.js that maps in the host provider instance:

import device from "mc/devicetree"
export default device;

Maybe it could be possible to store board / device targets in a project directory instead of the SDK repo.

This is something we'd like to do, so that a port could live outside the SDK, but it has eluded us to date. But, for this particular Zephyr need, having no directory at all seems even simpler.