Name already in use

Corrected Comment in AnalogInput.ino

…erate/download-file-action-2

Bump carlosperate/download-file-action from 1 to 2

Bumps [carlosperate/download-file-action](https://github.com/carlosperate/download-file-action) from 1 to 2.
- [Release notes](https://github.com/carlosperate/download-file-action/releases)
- [Commits](carlosperate/download-file-action@v1...v2)

---
updated-dependencies:
- dependency-name: carlosperate/download-file-action
  dependency-type: direct:production
  update-type: version-update:semver-major
...

Signed-off-by: dependabot[bot] <support@github.com>

…go/delete-artifact-2

Bump geekyeggo/delete-artifact from 1 to 2

Bumps [geekyeggo/delete-artifact](https://github.com/geekyeggo/delete-artifact) from 1 to 2.
- [Release notes](https://github.com/geekyeggo/delete-artifact/releases)
- [Commits](GeekyEggo/delete-artifact@v1...v2)

---
updated-dependencies:
- dependency-name: geekyeggo/delete-artifact
  dependency-type: direct:production
  update-type: version-update:semver-major
...

Signed-off-by: dependabot[bot] <support@github.com>

Use ClangFormat as code formatter for examples

The code formatting tool used by the Arduino IDE 1.x "Auto Format" feature is "Artistic Style". This was changed to
ClangFormat in Arduino IDE 2.x. Now that the stable Arduino IDE 2.0.0 release has been made, this is now the official
code formatting tool for use with Arduino sketches.

Due to differences in the two tools, some unavoidable minor changes occurred in the formatting style. This meant that
the Arduino IDE 2.x user may experience some unexpected changes to the unmodified official example sketches when running
an "Auto Format". So the examples in this repository must be formatted to comply with the updated Arduino code style.

The changes are mostly the result of ClangFormat being more "opinionated" than "Artistic Style" was under the fairly
light-handed formatter configuration used by Arduino IDE 1.x Auto Format. Due to this factor, formatting changes
required to bring the examples into compliance with the new style mostly do not conflict with the Arduino IDE 1.x style.
The only exception is the more complex code of the ArduinoISP sketch. In this case, the sketch is more of a utility
program than an example, so the formatting changes will not be impactful for users who continue to use the outdated
Arduino IDE version.

For the sake of efficiency, the repository's GitHub Actions workflows are configured to only run when relevant files are
modified.

The formatter configuration file is one such file, yet was previously omitted from the paths filter.

The repository includes a script that formats the code in the example sketches.

Previously, this script was only provided to make it easy for contributors to achieve compliant code formatting while
preparing a pull request.

In addition to this effort to facilitate compliance, enforcement is implemented by a GitHub Actions workflow.

Since the formatter tool does not have the directory tree recursion capability needed to process all the files in the
repository, it is necessary to implement such capability using a `find` command. Previously this was done both in the
script and the workflow.

`find` is ridiculously complex and unintuitive, prone to confusing bugs. For this reason, it will be best to avoid
maintaining redundant code for recursing through the example code files. This is accomplished by simply running the
script from the workflow. Even though the two have different goals (making formatting compliant vs checking whether
formatting is compliant), the two are easily aligned by formatting the files in the workflow, then checking for a diff.
This approach has been widely used in other Arduino Tooling Team formatting check workflows and I find the diff is very
effective at communicating which changes are required, likely more so than the approach previously used in the workflow.

The repository includes a script that formats the code in the examples.

When running this script locally, the contributor must have the formatter tool installed and in the system PATH.
Previously this dependency was only explained by a comment in the script, which is not likely to be seen by the
contributor in advance of running it. This means they would encounter a somewhat cryptic error message.

A more contributor friendly approach is for the script to check for the availability of the tool, then exit with a
friendly error message if it is not found.

The `.ipp` and `.tpp` file extensions, commonly used for inline or template function definitions included in C++ header
files, have now been added to the Arduino sketch specification as supported extensions. Even though it is unlikely such
extensions will ever be used in the example sketches of this repository, it is best to be comprehensive in the
extensions covered by the formatter script

The repository includes a script that formats the example sketch code. This uses a `find` command to recurse through the
example folders and run the formatter on each file with a relevant extension.

Previously a regular expression was used for that matching. Although perfectly functional, the same can be achieved in
an easier to understand and maintain manner using globs.

A script included in the repository formats the code in the examples according to Arduino's standard style.

Since the formatter tool does not have a recursive capability, `find` must be used. This results in a fairly long and
complex command.

Adding line breaks to split the command into its individual arguments, with indentation to indicate the structure of
these arguments makes the command easier to understand.

Use form-based issue templates

High quality feedback via GitHub issues is a very valuable contribution to the project. It is important to make the
issue creation and management process as efficient as possible for the contributors, maintainers, and developers.

Issue templates are helpful to the maintainers and developers because it establishes a standardized framework for the
issues and encourages the contributors to provide the essential information.

The contributor is now presented with a web form when creating an issue. This consists of multi-line input fields that
have the same formatting, preview, and attachment capabilities as the standard GitHub Issue composer, in addition to
menus and checkboxes where appropriate.

The use of this form-based system should provide a much better experience for the contributors and also result in higher
quality issues by establishing a standardized framework for the issues and encouraging contributors to provide the
essential information.

A template chooser allows the contributor to select the appropriate template type, redirects support requests to the
appropriate communication channels via "Contact Links", and provides a prominent link to security policy to guide any
vulnerability disclosures.

The clear separation of the types of issues encourages the reporter to fit their report into a specific issue category,
resulting in more clarity. Automatic labeling according to template choice allows the reporter to do the initial
classification.

…erate/download-file-action-1.1.1

Bump carlosperate/download-file-action from 1.0.3 to 1.1.1

The `carlosperate/download-file-action` action is used in the GitHub Actions workflows as a convenient way to download
external resources.

A major version ref has been added to that repository. It will always point to the latest release of the "1" major
version series. This means it is no longer necessary to do a full pin of the action version in use as before.

Use of the major version ref will cause the workflow to use a stable version of the action, while also benefiting from
ongoing development to the action up until such time as a new major release of an action is made. At that time we would
need to evaluate whether any changes to the workflow are required by the breaking change that triggered the major
release before manually updating the major ref (e.g., uses: `carlosperate/download-file-action@v2`). I think this
approach strikes the right balance between stability and maintainability for these workflows.

…/upload-artifact-3

Bump actions/upload-artifact from 2 to 3

…/download-artifact-3

Bump actions/download-artifact from 2 to 3

…/checkout-3

Bump actions/checkout from 2 to 3

Bumps [carlosperate/download-file-action](https://github.com/carlosperate/download-file-action) from 1.0.3 to 1.1.1.
- [Release notes](https://github.com/carlosperate/download-file-action/releases)
- [Commits](carlosperate/download-file-action@v1.0.3...v1.1.1)

---
updated-dependencies:
- dependency-name: carlosperate/download-file-action
  dependency-type: direct:production
  update-type: version-update:semver-minor
...

Signed-off-by: dependabot[bot] <support@github.com>

Bumps [actions/upload-artifact](https://github.com/actions/upload-artifact) from 2 to 3.
- [Release notes](https://github.com/actions/upload-artifact/releases)
- [Commits](actions/upload-artifact@v2...v3)

---
updated-dependencies:
- dependency-name: actions/upload-artifact
  dependency-type: direct:production
  update-type: version-update:semver-major
...

Signed-off-by: dependabot[bot] <support@github.com>

Bumps [actions/download-artifact](https://github.com/actions/download-artifact) from 2 to 3.
- [Release notes](https://github.com/actions/download-artifact/releases)
- [Commits](actions/download-artifact@v2...v3)

---
updated-dependencies:
- dependency-name: actions/download-artifact
  dependency-type: direct:production
  update-type: version-update:semver-major
...

Signed-off-by: dependabot[bot] <support@github.com>

Bumps [actions/checkout](https://github.com/actions/checkout) from 2 to 3.
- [Release notes](https://github.com/actions/checkout/releases)
- [Changelog](https://github.com/actions/checkout/blob/main/CHANGELOG.md)
- [Commits](actions/checkout@v2...v3)

---
updated-dependencies:
- dependency-name: actions/checkout
  dependency-type: direct:production
  update-type: version-update:semver-major
...

Signed-off-by: dependabot[bot] <support@github.com>

Configure Dependabot to check for outdated actions used in workflows

Dependabot will periodically check the versions of all actions used in the repository's workflows. If any are found to
be outdated, it will submit a pull request to update them.

NOTE: Dependabot's PRs will occasionally propose to pin to the patch version of the action (e.g., updating
`uses: foo/bar@v1` to `uses: foo/bar@v2.3.4`). When the action author has provided a major version ref, use that instead
(e.g., `uses: foo/bar@v2`). Dependabot will automatically close its PR once the workflow has been updated.

More information:
https://docs.github.com/code-security/dependabot/working-with-dependabot/keeping-your-actions-up-to-date-with-dependabot

On every push that changes relevant files, and periodically, configure the repository's issue and pull request labels
according to the universal, shared, and local label configuration files.

…rd combo

Pin A5 is used by the "StringComparisonOperators" example. The Nano RP2040 Connect uses the u-blox NINA-W102's ADC for
pins A4-A7. This means those pins are only usable in a sketch when it contains an `#include` directive for the WiFiNINA
library. This results in compilation of that example failing for the Nano RP 2040 Connect. The need for this `#include`
directive is surely an intentional design decision, and thus not likely to change.

Although it is possible to add compatibility to the sketch with a preprocessor conditional, the added complexity in what
is intended to be a very beginner friendly example is likely not worth it. Another option would be to change the sketch
to use a different pin, but that sort of change does not fall within my remit.

The error message the user will experience if they attempt to compile this sketch for their board is reasonably good so I
suppose the realistic best way forward is to consider this not a bug and just skip the sketch.

This attribute was used to configure the workflow to skip compilation of examples that used `pulseIn()` for boards that
were already known to not provide this functionality.

The only such board was the Portenta H7 and that has since gained a `pulseIn()`. Since all boards now have `pulseIn()`,
the attribute no longer serves a purpose and can be removed from the workflow.

At the time the "Compile Examples" CI workflow was written, the Portenta H7 board did not have a `pulseIn()` function.
Although this was a legitimate bug, since this was an issue with the `arduino/ArduinoCore-mbed` code base, already
tracked there, and unrelated to the code hosted in this repository, it was determined that the best approach would be to
configure the workflow to not compile the examples that used `pulseIn()` for the Portenta H7.

Since that time, `pulseIn()` has been implemented for Portenta H7 and so we can now compile these sketches for that board.

The "Compile Examples" workflow used to do a "smoke test" sketch compilation CI check uses a job matrix to compile the
sketches for all boards of interest.

By default, the matrix job is named by the matrix element for that job. This element includes board data used to make
board-specific job customizations. That attribute data makes the job name, which is used to identify it in the checks
status UI and workflow logs, fairly cryptic. The only information of interest to a human identifying the job is the FQBN.
Defining a custom job name overrides the default job naming behavior.

Since the time the workflow was written, the "Arduino Mbed OS Boards" platform was split into a variant for each of the
boards "families" supported by that platform. The benefit of this split is a reduction of installation and compilation
times. The previous `arduino:mbed` platform is still available to ease the transition to the new platforms, but it is
deprecated.