feat: expose the Arduino state to VS Code extensions

[dankeboy36]

Motivation

To provide a way to implement external tools for the Arduino IDE without modifying the IDE codebase. See #58.

This PR introduces a tiny layer of code to listen to Arduino context-related changes and set it on the VS Code workspaceState. Other VS Code extensions can import this new VSIX API and retrieve context information from the Arduino IDE—information such as the sketch path, FQBN of the currently selected board, etc. See https://github.com/dankeboy36/vscode-arduino-api for more details.

I have an ongoing reference re-implementation of the ESP exception decoder. It works in the Arduino IDE. I did the reference implementation in Code and noticed that Theia has a few bugs, so the final implementation comes a bit later:

espDecoder.mp4

Change description

Other information

Reviewer checklist

• PR addresses a single concern.
• The PR has no duplicates (please search among the Pull Requests before creating one)
• PR title and description are properly filled.
• Docs have been added / updated (for bug fixes / features)

[me-no-dev]

Hi @dankeboy36 ! This looks like a great idea! My question is wether the extensions can have access to all board properties defined in boards.txt and possibly the ones in platform.txt.?

I checked your code for the Exception Decoder and it seems that it's going through the installed tools and is searching for executable ending on gdb. While such thing would work for ESP8266 installed through the board manager, it would need modification to work when platform is installed from git and would not at all work correctly on ESP32 platform, which needs to know what chip is being used, in order to pick up the correct GDB package and path.

An amazing thing would be to be able to listen on the Serial Monitor and print exceptions directly inline, much like idf.py monitor, or create custom Plotter, etc.

[dankeboy36]

I checked your code for the Exception Decoder, and it seems that it's going through the installed tools and is searching for executable ending on gdb.

Thanks for taking the time and looking into the PR. I also checked your original Java implementation quite a lot recently 😄 The current GDB lookup is a hack. It will be resolved soon using only the boardDetails from the CLI.

My question is wether the extensions can have access to all board properties defined in boards.txt and possibly the ones in platform.txt.?

On the spot. This is precisely the idea. It's not yet available from the IDE, but the CLI can print the build_properties for a board, so it will be possible to get build.tarch=xtensa or different with arduino/arduino-cli#2151.

I do not know much about the platform.txt, but if required, I hope the CLI maintainers can help us.

[me-no-dev]

I do not know much about the platform.txt, but if required, I hope the CLI maintainers can help us.

with access to all build variables in platform.txt, you could get the location of GDB by just getting the value of debug.toolchain.path or compiler.path (depending on the chip). Same goes for esptool and other necessary things to get file system uploads working, etc.

[dankeboy36]

with access to all build variables in platform.txt, you could get the location of GDB by just getting the value of debug.toolchain.path or compiler.path (depending on the chip). Same goes for esptool and other necessary things to get file system uploads working, etc.

I appreciate your input! The tool paths can be inferred from the combination of the boardDetails#requiredTools and the dataDirPath using the currently proposed API. At this point, I do not see the necessity to expose the platform.txt content. It might change in the future. For now, I want to focus on enabling the API for tool developers and reimplementing one or two existing tools as VS Code extensions so that others can understand how to do it. If there is a need for it from the community, I am sure the CLI team can help us.

[me-no-dev]

At this point, I do not see the necessity to expose the platform.txt content.

required tools will show only for installation from Board Manager and not when installed from git. For ESP32 platform all tools for all chips will be there (when installed from board manager), so you can not really figure out what is needed and what is where without having all build variables available. For single chip/architecture platform this might work fine, but not for ESP32 for sure.

[dankeboy36]

when installed from git.

Could you share the procedure for how to do such an installation?

[per1234]

with access to all build variables in platform.txt, you could get the location of GDB by just getting the value of debug.toolchain.path or compiler.path

The build properties mentioned by @dankeboy36 include those set in platform.txt. This includes the debug.toolchain.path and compiler.path properties.

[per1234]

Could you share the procedure for how to do such an installation?

Here it is @dankeboy36:

https://docs.espressif.com/projects/arduino-esp32/en/latest/installing.html#windows-manual-installation

There are sets of manual installation instructions for Windows, Linux, and macOS, I linked to the Windows section simply because that is the first set of instructions. Scroll down on the page for the others.

[dankeboy36]

Depends on arduino/arduino-cli#2184. I have pinned the CLI version for the time being.

[kittaakos]

Depends on arduino/arduino-cli#2184. I have pinned the CLI version for the time being.

There is a separate PR with the CLI version update. Rebasing from it should reduce the outgoing changes of this PR: #2083.

[kittaakos]

set it on the VS Code workspaceState.

• Do not write the state into the workspace. There are known Theia bugs. See upstream: plugin-ext: Change PluginsKeyValueStorage to not continuously access the disk eclipse-theia/theia#12236. Keep the state in the memory for the reference implementation.
• There should be a mechanism in the future to collect all Arduino tool VSIX available in IDE2 and populate the Tools menu. Find a way how to identify an IDE2 tool VSIX among other VSIXs. The keywords field of the extension manifest looks natural.

[dankeboy36]

Bocked by arduino/arduino-cli#2197.

[kittaakos]

Duplicate of #2110