Arduino Pro IDE

Download

You can download the latest version of the Arduino Pro IDE application for the supported platforms from the GitHub release page or following the links in the following table.

Latest version

Platform	32 bit	64 bit
Linux		Linux 64 bit
Linux ARM	🚧 Work in progress...	🚧 Work in progress...
Windows		Windows 64 bit
macOS		macOS 64 bit

Previous versions

These are available from the GitHub releases page.

Nightly builds

These builds are generated every day at 03:00 GMT from the master branch and should be considered unstable. In order to get the latest nightly build available for the supported platform, use the following links:

Platform	32 bit	64 bit
Linux		Nightly Linux 64 bit
Linux ARM	🚧 Work in progress...	🚧 Work in progress...
Windows		Nightly Windows 64 bit
macOS		Nightly macOS 64 bit

These links return an HTTP 302: Found response, redirecting to latest generated builds by replacing latest with the latest available build date, using the format YYYYMMDD (i.e for 2019/Aug/06 latest is replaced with 20190806 )

Build from source

If you’re familiar with TypeScript, the Theia IDE, and if you want to contribute to the project, you should be able to build the Arduino Pro IDE locally. Please refer to the Theia IDE prerequisites documentation for the setup instructions.

Build

yarn

Rebuild the native dependencies

yarn rebuild:electron

Start

yarn start

CI

This project is built on GitHub Actions.

• Snapshot builds run when changes are pushed to the master branch, or when a PR is created against the master branch. For the sake of the review and verification process, the build artifacts can be downloaded from the GitHub Actions page. Note: due to a limitation with the GH Actions UI, you cannot download a particular build, but you have to get all together inside the build-artifacts.zip.
• Nightly builds run every day at 03:00 GMT from the master branch.
• Release builds run when a new tag is pushed to the remote. The tag must follow the semver. For instance, 1.2.3 is a correct tag, but v2.3.4 won't work. Steps to trigger a new release build:
  • Create a local tag:

  git tag -a 1.2.3 -m "Creating a new tag for the `1.2.3` release."

  • Push it to the remote:

   git push origin 1.2.3

FAQ

• Q: Can I manually change the version of the arduino-cli used by the IDE?

• A: Yes. It is possible but not recommended. The CLI exposes a set of functionality via gRPC and the IDE uses this API to communicate with the CLI. Before we build a new version of IDE, we pin a specific version of CLI and use the corresponding proto files to generate TypeScript modules for gRPC. This means, a particular version of IDE is compliant only with the pinned version of CLI. Mismatching IDE and CLI versions might not be able to communicate with each other. This could cause unpredictable IDE behavior.

• Q: I have understood that not all versions of the CLI is compatible with my version of IDE but how can I manually update the arduino-cli inside the IDE?

• A: Get the desired version of arduino-cli for your platform and manually replace the one inside the IDE. The CLI can be found inside the IDE at:

  • Windows: C:\path\to\Arduino Pro IDE\resources\app\node_modules\arduino-ide-extension\build\arduino-cli.exe,
  • macOS: /path/to/Arduino Pro IDE.app/Contents/Resources/app/node_modules/arduino-ide-extension/build/arduino-cli, and
  • Linux: /path/to/Arduino Pro IDE/resources/app/node_modules/arduino-ide-extension/build/arduino-cli.

Architecture overview

The Pro IDE consists of three major parts:

• the Electron main process,
• the backend, and
• the frontend.

The Electron main process is responsible for:

• creating the application,
• managing the application lifecycle via listeners, and
• creating and managing the web pages for the app.

In Electron, the process that runs the main entry JavaScript file is called the main process. The Electron main process can display a GUI by creating web pages. An Electron app always has exactly on main process.

By default, whenever the Electron main process creates a web page, it will instantiate a new BrowserWindow instance. Since Electron uses Chromium for displaying web pages, Chromium's multi-process architecture is also used. Each web page in Electron runs in its own process, which is called the renderer process. Each BrowserWindow instance runs the web page in its own renderer process. When a BrowserWindow instance is destroyed, the corresponding renderer process is also terminated. The main process manages all web pages and their corresponding renderer processes. Each renderer process is isolated and only cares about the web page running in it.^[1]

In normal browsers, web pages usually run in a sandboxed environment, and accessing native resources are disallowed. However, Electron has the power to use Node.js APIs in the web pages allowing lower-level OS interactions. Due to security reasons, accessing native resources is an undesired behavior in the Pro IDE. So by convention, we do not use Node.js APIs. (Note: the Node.js integration is not yet disabled although it is not used). In the Pro IDE, only the backend allows OS interaction.

The backend process is responsible for:

• providing access to the filesystem,
• communicating with the Arduino CLI via gRPC,
• running your terminal,
• exposing additional RESTful APIs,
• performing the Git commands in the local repositories,
• hosting and running any VS Code extensions, or
• executing VS Code tasks^[2].

The Electron main process spawns the backend process. There is always exactly one backend process. However, due to performance considerations, the backend spawns several sub-processes for the filesystem watching, Git repository discovery, etc. The communication between the backend process and its sub-processes is established via IPC. Besides spawning sub-processes, the backend will start an HTTP server on a random available port, and serves the web application as static content. When the sub-processes are up and running, and the HTTP server is also listening, the backend process sends the HTTP server port to the Electron main process via IPC. The Electron main process will load the backend's endpoint in the BrowserWindow.

The frontend is running as an Electron renderer process and can invoke services implemented on the backend. The communication between the backend and the frontend is done via JSON-RPC over a websocket connection. This means, the services running in the frontend are all proxies, and will ask the corresponding service implementation on the backend.