Library Selection
Treat a library as part of the firmware and hardware contract. A popular
package that compiles for one architecture may still use incompatible pins,
timers, memory, bus assumptions, or APIs on another.
Intake
Record exact board/module, architecture, Arduino core or vendor SDK, compiler,
toolchain, required API, bus/pin constraints, memory budget, license boundary,
update policy, and whether the device is connected or field-updatable.
Process
- Find the upstream source, release/tag, license, supported architectures, and
framework instructions. Prefer primary repositories and current release notes.
- Compare candidate API fit, board variants, transitive dependencies, flash/
SRAM/heap impact, blocking behavior, concurrency, bus/pull-up assumptions,
and error/recovery behavior.
- Check open issues and maintenance signals without treating stars or install
count as compatibility proof.
- Select a pinned version, record provenance and rationale, and document
unsupported board/framework branches.
- Run a minimal compile fixture, then a simulated or target behavior check.
Anti-rationalization
| Shortcut |
Response |
| "It has many installs." |
Verify architecture, core version, API, and hardware contract. |
| "The newest version is best." |
Read release notes, compatibility, footprint, and regression history. |
| "The I2C scanner found it." |
Test library initialization, register reads, timing, and error paths. |
| "It worked on AVR." |
Recheck ESP32/S3/Pico architecture, pins, timers, and memory. |
| "The dependency is only a helper." |
Include transitive code and license/security review. |
Verification
- Candidate comparison contains source, version, architecture, and license.
- Minimal compile output names the exact FQBN/environment and dependency
resolution.
- Memory delta and one runtime/simulation behavior result are recorded.
- Connected devices have a dependency update and secret-handling plan.
Shared output contract
Use the shared Arduino skill contract:
state assumptions, required tools and versions, implementation steps,
tests/evidence by proof stage, known limitations, and recovery/security notes.
1---2name: library-selection3description: Use when selecting, replacing, pinning, or auditing an Arduino, ESP32, RP2040, C++, or vendor-framework library. Compare architecture support, framework and version compatibility, API behavior, footprint, maintenance, provenance, security, and hardware assumptions before installation.4---5
6# Library Selection
7
8Treat a library as part of the firmware and hardware contract. A popular
9package that compiles for one architecture may still use incompatible pins,
10timers, memory, bus assumptions, or APIs on another.
11
12## Intake
13
14Record exact board/module, architecture, Arduino core or vendor SDK, compiler,
15toolchain, required API, bus/pin constraints, memory budget, license boundary,
16update policy, and whether the device is connected or field-updatable.
17
18## Process
19
201. Find the upstream source, release/tag, license, supported architectures, and
21 framework instructions. Prefer primary repositories and current release notes.
222. Compare candidate API fit, board variants, transitive dependencies, flash/
23 SRAM/heap impact, blocking behavior, concurrency, bus/pull-up assumptions,
24 and error/recovery behavior.
253. Check open issues and maintenance signals without treating stars or install
26 count as compatibility proof.
274. Select a pinned version, record provenance and rationale, and document
28 unsupported board/framework branches.
295. Run a minimal compile fixture, then a simulated or target behavior check.
30
31## Anti-rationalization
32
33| Shortcut | Response |
34|---|---|
35| "It has many installs." | Verify architecture, core version, API, and hardware contract. |
36| "The newest version is best." | Read release notes, compatibility, footprint, and regression history. |
37| "The I2C scanner found it." | Test library initialization, register reads, timing, and error paths. |
38| "It worked on AVR." | Recheck ESP32/S3/Pico architecture, pins, timers, and memory. |
39| "The dependency is only a helper." | Include transitive code and license/security review. |
40
41## Verification
42
43- Candidate comparison contains source, version, architecture, and license.
44- Minimal compile output names the exact FQBN/environment and dependency
45 resolution.
46- Memory delta and one runtime/simulation behavior result are recorded.
47- Connected devices have a dependency update and secret-handling plan.
48
49## Shared output contract
50
51Use [the shared Arduino skill contract](../../docs/arduino-skill-contract.md):
52state assumptions, required tools and versions, implementation steps,
53tests/evidence by proof stage, known limitations, and recovery/security notes.
wedsamuel1230