Skip to content

Some documentation improvement for pluggable discovery/montior #1636

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Jan 24, 2022
Merged

Some documentation improvement for pluggable discovery/montior #1636

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
e774783
Fixed wrong "event" fields in pluggable monitor specs
cmaglie Jan 24, 2022
c886915
Better specify discoveryDependencies and monitorDependencies fields i…
cmaglie Jan 24, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
18 changes: 10 additions & 8 deletions docs/package_index_json-specification.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -246,14 +246,16 @@ Each PLATFORM describes a core for a specific architecture. The fields needed ar
- `toolsDependencies`: the tools needed by this platform. They will be installed by Boards Manager along with the
platform. Each tool is referenced by the triple (`packager`, `name`, `version`) as previously said. Note that you can
reference tools available in other packages as well, even if no platform of that package is installed.
- `discoveryDependencies`: the Pluggable Discoveries needed by this platform. Each discovery is referenced by the pair
(`packager`, `name`), the `version` is not specified because the latest installed discovery tool will always be used.
Like `toolsDependencies` they will be installed by Boards Manager along with the platform and can reference tools
available in other packages as well, even if no platform of that package is installed.
- `monitorDependencies`: the Pluggable Monitors needed by this platform. Each monitor is referenced by the pair
(`packager`, `name`), the `version` is not specified because the latest installed monitor tool will always be used.
Like `toolsDependencies` they will be installed by Boards Manager along with the platform and can reference tools
available in other packages as well, even if no platform of that package is installed.
- `discoveryDependencies`: the Pluggable Discoveries needed by this platform. These are [tools](#tools-definitions),
defined exactly like the ones referenced in `toolsDependencies`. Unlike `toolsDependencies`, discoveries are
referenced by the pair (`packager`, `name`). The `version` is not specified because the latest installed discovery
tool will always be used. Like `toolsDependencies` they will be installed by Boards Manager along with the platform
and can reference tools available in other packages as well, even if no platform of that package is installed.
- `monitorDependencies`: the Pluggable Monitors needed by this platform. These are [tools](#tools-definitions), defined
exactly like the ones referenced in `toolsDependencies`. Unlike `toolsDependencies`, monitors are referenced by the
pair (`packager`, `name`). The `version` is not specified because the latest installed monitor tool will always be
used. Like `toolsDependencies` they will be installed by Boards Manager along with the platform and can reference
tools available in other packages as well, even if no platform of that package is installed.

The `version` field is validated by both Arduino IDE and [JSemVer](https://github.com/zafarkhaja/jsemver). Here are the
rules Arduino IDE follows for parsing versions
Expand Down
18 changes: 9 additions & 9 deletions docs/pluggable-monitor-specification.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -62,7 +62,7 @@ port configuration, and which parameters are available to the user.

```JSON
{
"event": "describe",
"eventType": "describe",
"message": "ok",
"port_description": {
"protocol": "serial",
Expand Down Expand Up @@ -127,7 +127,7 @@ The response to the command is:

```JSON
{
"event": "configure",
"eventType": "configure",
"message": "ok"
}
```
Expand All @@ -136,7 +136,7 @@ or if there is an error:

```JSON
{
"event": "configure",
"eventType": "configure",
"error": true,
"message": "invalid value for parameter baudrate: 123456"
}
Expand Down Expand Up @@ -167,7 +167,7 @@ The answer to the `OPEN` command is:

```JSON
{
"event": "open",
"eventType": "open",
"message": "ok"
}
```
Expand All @@ -177,7 +177,7 @@ other error condition happens:

```JSON
{
"event": "open",
"eventType": "open",
"error": true,
"message": "unknown port /dev/ttyACM23"
}
Expand All @@ -191,7 +191,7 @@ tool:

```JSON
{
"event": "port_closed",
"eventType": "port_closed",
"message": "serial port disappeared!"
}
```
Expand All @@ -200,7 +200,7 @@ or

```JSON
{
"event": "port_closed",
"eventType": "port_closed",
"message": "lost TCP/IP connection with the client!"
}
```
Expand All @@ -212,7 +212,7 @@ Client/IDE. The answer to the command is:

```JSON
{
"event": "close",
"eventType": "close",
"message": "ok"
}
```
Expand All @@ -221,7 +221,7 @@ or in case of error

```JSON
{
"event": "close",
"eventType": "close",
"error": true,
"message": "port already closed"
}
Expand Down