ZAP integration with PlatformIO

1

Hello!

I’m a lead developer and maintainer of the ZAP open-source project (GitHub - project-chip/zap: ZAP is Zigbee Cluster Library configuration tool and generator. It allows users to configure their ZCL application using web-like interface and then generate the required artifacts for this application, based upon the templates inside a given ZCL SDK.). Its a visual tool for embedded developers to configure Zigbee ZCL applications, written in node.js/electron.

We have a plan to integrate it with VSCode and platformIO came to mind.

I don’t know much about platformIO at this point, but my question around this are:

  • is platformIO architecture such, that making this new visual editor inside VSCode as part of platformIO ecosystem would allow to use some extra services and features of the platformIO itself, which could make overall effort easier?

  • or are cases like this (a separate visual tool for embedded developers) something that should be developed as a completely separate VSCode extension, unrelated to platformIO?

  • if it’s developed as a separate tool, are there some APIs or integration points I should consider between platformIO and these additional VSCode extensions that are also targeted at embedded developers? If there are some extra features that could be enabled if platformIO is also present in the VSCode installation, that would be a good way to add end-user value.

Thanks for the time. I’m just attempting to scope out this effort, and I don’t have enough knowledge about platformIO yet to understand what makes sense and what not. Any answer will be appreciated.

Cheers,
T

2

But the code that comes out at the other end of it is C/C++, and compiled down to a firmware binary for some microcontroller? Is that microcontroller already supported maybe?

PlatformIO is mainly the PlatformIO VSCode extension (https://github.com/platformio/platformio-vscode-ide/) that is the front-end to the underlying PlatformIO core (https://github.com/platformio/platformio-core/) which is extended by specific PlatformIO platforms, which define the microcontroller boards and frameworks (e.g. an Arduino core) and the build, upload and debug logic behind it (e.g. https://github.com/platformio/platform-espressif32/ or https://github.com/platformio/platform-atmelavr/).

Usually integrating something with PlatformIO means that someone has a new embedded framework (aka a bunch C/C++ files) for some microcontroller board (that may or may not be known to PlatformIO yet), so the process of integration is writing board definitions, creating packages where the source code is contained and build logic (in Python) that instructs the underlying build system (SCons) on how to build the firmware correctly, along with the instructions on which tools to use to upload the firmware. That is basically the gist of the “Custom Platform & Board” documentation.

The PlatformIO VSCode extension isn’t supposed to be extendable a lot by an integrator, as in, one can’t write a custom platform extension in such a way that it adds a new window to the GUI in which one can do arbitrary stuff. For that the extension code itself must be altered and it would be a whole different beast. A platform extension extends the core’s ability to build for a new framework or microcontroller board, which is then automatically exposed to the frontend.

So what you can do is write a VSCode extension that by itself is that visual editor, that is then able to auto-generate the source code and pack it as a PlatformIO project, which can tie in with a custom PlatformIO platform extension so that PlatformIO can build the firmware normally. Those are my views on it as someone who doesn’t know a lot about your project though, but a bit about PlatformIO :smiley: .

Maybe @ivankravets has additional thoughts to share.

3

Thank you @maxgerhardt , this makes a lot of sense and was very helpful for my understanding.

Indeed, there are multiple different SDKs (C or C++) that sit underneath the visual tool, and they support their own set of compilers and chips and boards and what not. So those things would be natural candidates for becoming part of platform IO, not the actual high-level visual tool.

Like you said: yes, in this case, this would be a completely different beast if you start upward integration with some specific visual editors and such, so I wondered what the nature of the beast actually is. :slight_smile:

I’ll proceed with a current assumption then, that we do our own VSCode extension to integrate the UI and the generation capabilities to generate C/C++ code, but platform IO integration starts happening only at the intersection of these generated code artifacts, the SDK code itself that consumes them, and the toolchains that assemble the whole thing into the firmware in the end.

Thanks again! Appreciate the time…

4

Hi Timotej,

There is no API for the case which you described. Node.JS does not fit well with embedded technology and we don’t provide any packages for it. Yes, there is hype with “electron-based” applications but it seems that only developers who write these apps are in love with what they do.
We had a very bad experience with Node.JS and are happy that moved away from it. See what we did Sunsetting Atom | The GitHub Blog. The hell with modules and native access to embedded devices could not be explained in polite form.

We developed our own Modern UI toolkit which is fully independent of the operating systems, IDEs, code editors, and even Node.JS, etc. It can be integrated into any IDE (VSCode, Eclipse, etc). It fits well with your use case, can save a lot of resources, and reduce time to market cost.

Please contact us at About Us | PlatformIO Labs.