@@ -321,8 +321,8 @@ changes in the generated code.

### Additional settings

If you need to push a commit that's only shipping documentation changes or example files, thus a complete no-op for the

test suite, please start the commit message with the string **[skip ci]** to skip the build and give that slot to someone

else who does need it.

test suite, please start the commit message with the string **[skip ci]** to skip the build and give that slot to

someone else who does need it.

If your PR doesn't need to be included in the changelog, please start the commit message and PR title with the string

**[skip changelog]**

@@ -8,7 +8,8 @@

- `data` - directory used to store Boards/Library Manager index files and Boards Manager platform installations.

- `downloads` - directory used to stage downloaded archives during Boards/Library Manager installations.

- `user` - the equivalent of the Arduino IDE's ["sketchbook" directory][sketchbook directory]. Library Manager

installations are made to the `libraries` subdirectory of the user directory.

installations are made to the `libraries` subdirectory of the user directory. Users can manually install 3rd party

platforms in the `hardware` subdirectory of the user directory.

- `builtin.libraries` - the libraries in this directory will be available to all platforms without the need for the

user to install them, but with the lowest priority over other installed libraries with the same name, it's the

equivalent of the Arduino IDE's bundled libraries directory.

@@ -45,6 +46,25 @@

- `network` - configuration options related to the network connection.

- `proxy` - URL of the proxy server.

### Default directories

The following are the default directories selected by the Arduino CLI if alternatives are not specified in the

configuration file.

- The `directories.data` default is OS-dependent:

- on Linux (and other Unix-based OS) is: `{HOME}/.arduino15`

- on Windows is: `{HOME}/AppData/Local/Arduino15`

- on MacOS is: `{HOME}/Library/Arduino15`

- The `directories.download` default is `{directories.data}/staging`. If the value of `{directories.data}` is changed in

the configuration the user-specified value will be used.

- The `directories.user` default is OS-dependent:

- on Linux (and other Unix-based OS) is: `{HOME}/Arduino`

- on Windows is: `{DOCUMENTS}/Arduino`

- on MacOS is: `{HOME}/Documents/Arduino`

## Configuration methods

Arduino CLI may be configured in three ways:

@@ -4,8 +4,8 @@ The Arduino CLI is an open source Command Line Application written in [Golang] t

compile, verify and upload sketches to Arduino boards and that’s capable of managing all the software and tools needed

in the process. But don’t get fooled by its name: Arduino CLI can do much more than the average console application, as

shown by [Arduino IDE 2.x][arduino ide 2.x] and [Arduino Cloud], which rely on it for similar purposes but each one in a

completely different way from the other. In this article we introduce the three pillars of the Arduino CLI, explaining how

we designed the software so that it can be effectively leveraged under different scenarios.

completely different way from the other. In this article we introduce the three pillars of the Arduino CLI, explaining

how we designed the software so that it can be effectively leveraged under different scenarios.

## The first pillar: command line interface

@@ -132,17 +132,18 @@ $ arduino-cli lib search FlashStorage --format json | jq .libraries[0].latest

```

Even if not related to software design, one last feature that’s worth mentioning is the availability of a one-line

[installation script] that can be used to make the latest version of the Arduino CLI available on most systems with an HTTP

client like curl or wget and a shell like bash.

[installation script] that can be used to make the latest version of the Arduino CLI available on most systems with an

HTTP client like curl or wget and a shell like bash.

For more information on Arduino CLI's command line interface, see the [command reference].

## The second pillar: gRPC interface

[gRPC] is a high performance [RPC] framework that can efficiently connect client and server applications. The Arduino

CLI can act as a gRPC server (we call it [daemon mode]), exposing a set of procedures that implement the very same set of

features of the command line interface and waiting for clients to connect and use them. To give an idea, the following is

some [Golang] code capable of retrieving the version number of a remote running Arduino CLI server instance:

CLI can act as a gRPC server (we call it [daemon mode]), exposing a set of procedures that implement the very same set

of features of the command line interface and waiting for clients to connect and use them. To give an idea, the

following is some [Golang] code capable of retrieving the version number of a remote running Arduino CLI server

instance:

```go

// This file is part of arduino-cli.

@@ -210,8 +211,8 @@ a common Golang API, based on the gRPC protobuf definitions: a set of functions

offered by the Arduino CLI, so that when we provide a fix or a new feature, they are automatically available to both the

command line and gRPC interfaces. The source modules implementing this API are implemented through the `commands`

package, and it can be imported in other Golang programs to embed a full-fledged Arduino CLI. For example, this is how

some backend services powering [Arduino Cloud] can compile sketches and manage libraries. Just to give you a taste of what

it means to embed the Arduino CLI, here is how to search for a core using the API:

some backend services powering [Arduino Cloud] can compile sketches and manage libraries. Just to give you a taste of

what it means to embed the Arduino CLI, here is how to search for a core using the API:

```go

// This file is part of arduino-cli.

@@ -296,8 +297,7 @@ use and provide support for.

You can start playing with the Arduino CLI right away. The code is open source and [the repo][arduino cli repository]

contains [example code showing how to implement a gRPC client][grpc client example]. If you’re curious about how we

designed the low level API, have a look at the [commands package] and don’t hesitate to leave feedback on the [issue

tracker]

if you’ve got a use case that doesn’t fit one of the three pillars.

tracker] if you’ve got a use case that doesn’t fit one of the three pillars.

[golang]: https://go.dev/

[arduino ide 2.x]: https://github.com/arduino/arduino-ide

@@ -5,31 +5,65 @@ Platforms add support for new boards to the Arduino development software. They a

[Boards Manager](package_index_json-specification.md) or manual installation to the _hardware_ folder of Arduino's

sketchbook folder (AKA "user directory").<br> A platform may consist of as little as a single configuration file.

## Hardware Folders structure

## Platform installation directories

The new hardware folders have a hierarchical structure organized in two levels:

If the platforms are installed using the Board Manager the installation directory location will be as follow:

- the first level is the vendor/maintainer

- the second level is the supported architecture

`{directories.data}/packages/{VENDOR_NAME}/hardware/{ARCHITECTURE}/{VERSION}/...`

A vendor/maintainer can have multiple supported architectures. For example, below we have three hardware vendors called

"arduino", "yyyyy" and "xxxxx":

- `{directories.data}` is the data directory as specified in the

[configuration file](configuration.md#default-directories).

- `{VENDOR_NAME}` is the identifier of the vendor/maintainer of the platform.

- `{ARCHITECTURE}` is the architecture of the CPU used in the platform.

- `{VERSION}` is the platform version.

Alternatively, a platform may be manually installed by the user inside the Sketchbook/user directory as follows:

`{directories.user}/hardware/{VENDOR_NAME}/{ARCHITECTURE}/...`

- `{directories.user}` is the user directory as specified in the

[configuration file](configuration.md#default-directories).

- `{VENDOR_NAME}` is the identifier of the vendor/maintainer of the platform.

- `{ARCHITECTURE}` is the architecture of the CPU used in the platform.

A vendor/maintainer may have multiple supported architectures.

Let's see an example, below we have a bunch of platforms downloaded from three hardware vendors `arduino`, `adafruit`

and `esp32`, and installed using the Board Manager:

```

{directories.data}/packages/arduino/hardware/avr/1.8.6/...

{directories.data}/packages/arduino/hardware/esp32/2.0.18-arduino.5/...

{directories.data}/packages/arduino/hardware/nrf52/1.4.5/...

{directories.data}/packages/adafruit/hardware/nrf52/1.6.1/...

{directories.data}/packages/esp32/hardware/esp32/3.0.7/...

```

hardware/arduino/avr/... - Arduino - AVR Boards

hardware/arduino/sam/... - Arduino - SAM (32bit ARM) Boards

hardware/yyyyy/avr/... - Yyy - AVR

hardware/xxxxx/avr/... - Xxx - AVR

In this example three architectures have been installed from the vendor `arduino` (`avr`, `esp32` and `nrf52`), and one

from `adafruit` and `esp32` (`nrf52` and `esp32` respectively). Note that the vendor `esp32` has the same name as the

architecture `esp32`.

If the user manually installed the same platforms, they should have unpacked them in the following directories:

```

{directories.user}/hardware/arduino/avr/...

{directories.user}/hardware/arduino/esp32/...

{directories.user}/hardware/arduino/nrf52/...

{directories.user}/hardware/adafruit/nrf52/...

{directories.user}/hardware/esp32/esp32/...

```

In this latter case the version must be omitted.

The vendor "arduino" has two supported architectures (AVR and SAM), while "xxxxx" and "yyyyy" have only AVR.

### Notes about choosing the architecture name

Architecture values are case sensitive (e.g. `AVR` != `avr`).

If possible, follow existing architecture name conventions when creating hardware packages. Use the vendor folder name

to differentiate your package. The architecture folder name is used to determine library compatibility and to permit

referencing resources from another core of the same architecture, so use of a non-standard architecture name can have a

harmful effect.

Platform developers should follow the existing architecture name conventions when creating hardware packages, if you

need to differentiate your package use the vendor/maintainer folder name to do so.

The architecture name is used to determine the libraries compatibility and to permit referencing resources from another

platform of the same architecture. Use of a non-standard architecture name can have a harmful effect.

## Architecture configurations

@@ -312,7 +312,8 @@ The `properties` associated to a port can be used to identify the board attached

"candidate" board attached to that port.

Some port `properties` may not be precise enough to uniquely identify a board, in that case more boards may match the

same set of `properties`, that's why we called it "candidate".

same set of `properties`, that's why we called it "candidate". The board identification properties should be used only

if they allows to match the board model beyond any doubt.

Let's see an example to clarify things a bit, let's suppose that we have the following `properties` coming from the

serial discovery:

@@ -392,6 +393,13 @@ myboard.upload_port.1.apples=40

will match on both `pears=20, apples=30` and `pears=30, apples=40` but not `pears=20, apples=40`, in that sense each

"set" of identification properties is independent from each other and cannot be mixed for port matching.

#### An important note about `vid` and `pid`

The board identification properties should be used only if they allows to match the board model beyond any doubt.

Sometimes a board do not expose a unique vid/pid combination, this is the case for example if a USB-2-serial converter

chip is used (like the omnipresent FT232 or CH340): those chips exposes their specific vid/pid that will be the same for

all the other boards using the same chip. In such cases the board identification properties should NOT be used.

#### Identification of board options

[Custom board options](platform-specification.md#custom-board-options) can also be identified.