Prototyping · Study deck

Managing Libraries and Version Control

Libraries save time only when they make a prototype easier to review.

Voltage Vera is your guide for this deck.

libraries

After studying this chapter

Learning objectives

You will be able to:

Choose libraries from evidence needs rather than popularity or habit.
Review target support, resource cost, API fit, update risk, and testability before adding a dependency.
Record exact library versions, sources, configuration, build commands, and evidence runs.
Structure a firmware repository so source, tests, hardware notes, configuration examples, and generated artifacts are easy to separate.

Major section

In 60 Seconds · Start With the Story

Version control records change; it does not make a change correct.

Libraries save time only when they make a prototype easier to review.
Months later, a new version changes its default time limit and the device repeats commands after a weak link.
A library can make a prototype look finished in an afternoon.

Major section

Dependencies Shift Responsibility

Adding a library is an architecture decision.

The prototype gains speed, but some behavior moves from code the team owns into code the team must understand, configure, test, and update.
A normal run checks the intended API path; a fault run checks the behavior that matters when an input, link, or resource fails.
The decision records why the version is kept and what change would require a new test.

A dependency choice should move from the prototype question through candidate review, version record, evidence runs, handoff decision, and update plan.

Major section

Dependencies Shift Responsibility (continued)

The review question is not whether a dependency is popular.

The dependency record should therefore say what the library proves and what it does not prove.
A driver that returns clean readings on one bench board does not prove bus timeout behavior.
Good dependency practice is not hostility to libraries.

Major section

Dependencies Shift Responsibility (continued)

A gateway client that publishes once does not prove reconnect backoff, queue pressure, TLS configuration, or broker permission failure.

A storage helper that writes a file does not prove full-storage, corrupt-record, migration, or power-loss behavior.
If the MQTT client owns reconnect timing, the application should still own stale-state policy and local alarm behavior.
If ArduinoJson owns parsing, the application should still own required fields, units, schema version, and rejected payload states.

Major section

Record Contract Before Import · Version Control as Evidence

Small commits make dependency behavior visible.

A sensor library might be acceptable if it exposes status codes, lets the application set timeouts, and does not hide stale readings.
A messaging library needs a visible connection state, bounded publish call, retry policy, queue limit, and TLS or credential configuration.
Generated files need an explicit policy.

Major section

Dependency Choice Is Evidence Choice · Avoid Invisible Complexity · Library Selection Gates

A software prototype often starts by adding a sensor driver, communication client, display library, storage helper, or cloud connector.

That shortcut is useful only if the team can still explain what the dependency owns and what evidence proves it behaves well enough for the prototype.
A library can hide bus timing, memory allocation, retry loops, blocking calls, and default configuration.
A small helper can pass quickly; a networking, storage, update, or security-sensitive dependency needs a stronger record.
the Software library selection gates diagram tests a cold-room messaging client before pilot adoption.

Major section

Make the Rejection Useful · Define the Reuse Boundary

If a library is rejected, record why.

A rejected option can still be useful evidence when a later reviewer asks why the prototype chose a smaller, slower, simpler, or less familiar dependency.
The safest dependency is not always the smallest one.
The safer choice is the dependency whose boundary is understandable.

Major section

Version and Build Records · What to Lock

Version control does not make a build reproducible by itself.

A reproducible prototype also needs dependency versions, source locations, lock files or equivalent records, configuration, and the command used to build or test the result.
The device run then keeps both normal publish output and a blocked-gateway timeout and retry trace.
the Modern IoT Development Stack diagram connects a dependency change to a rebuildable firmware artifact.
The dependency change in the Modern IoT Development Stack diagram connects three kinds of proof.

Major section

Firmware Evidence Repository

A repository should help reviewers separate source code, dependency configuration, tests, hardware notes, generated output, and secrets.

The exact folders vary by project, but the purpose should be clear.
Source, tests, hardware notes, a dependency manifest, and lock data should describe the build another reviewer needs to repeat.
the Firmware repository structure diagram shows which firmware evidence belongs in version control.
Commit examples and instructions instead, so a reviewer knows what is required without receiving a secret.

Major section

Source-Control Workflow · Cold-Room Dependency Review

A focused change names the library or version being updated and leaves unrelated feature edits out of the comparison.

The decision states whether to keep the change and which trigger would require another run.
For risky dependencies, run a relevant fault path too.
A team is prototyping a cold-room monitor.

Deck summary

Key takeaways

Version control records change; it does not make a change correct.

Adding a library is an architecture decision.
The review question is not whether a dependency is popular.
A gateway client that publishes once does not prove reconnect backoff, queue pressure, TLS configuration, or broker permission failure.
Small commits make dependency behavior visible.

Retrieval practice

Recall check 1 of 6

Voltage Vera says: answer from memory, then check your reasoning.

Q1Per this chapter, a gateway client library that has successfully published a message once during a demo has NOT yet proven which behavior of its own messaging contract?

AOne successful publish proves reconnect backoff, queue-pressure and broker-permission failure behavior.

BThe board I2C timeout proves the messaging library handles TLS and reconnect failure.

CReconnect backoff, queue pressure, TLS settings or broker permission failure.

DA storage-helper file write proves the gateway client can recover after broker rejection.

Show answer

Answer: C see answers page

Retrieval practice

Recall check 2 of 6

Voltage Vera says: answer from memory, then check your reasoning.

Q2Per this chapter's library-contract guidance, what must an OTA update library's contract include, distinct from a sensor or messaging library's contract?

ASensor status codes, application-set timeouts and stale-reading visibility for each sensor call

BMessaging connection state, bounded publish, retries, queue limit and TLS or credentials

CPackage verification, compatibility, health confirmation, rollback and active image-slot record after install

DStorage rules for full flash, corrupt records, interrupted writes and schema changes

Show answer

Answer: C see answers page

Retrieval practice

Recall check 3 of 6

Voltage Vera says: answer from memory, then check your reasoning.

Q3Per this chapter's 'Version Control as Evidence' section, what is the 'under-the-hood risk' it calls drift?

ADrift means mixed commits make it hard to assign behavior changes, even when all dependency versions are fixed.

BDrift means generated output lacks a generator version because that identifier captures every dependency affecting output.

CTransitive updates can change TLS, MQTT, parsing, flash timing, memory or exceptions without app code edits.

DDrift means an explicit source edit to TLS configuration, rather than an unseen dependency update.

Show answer

Answer: C see answers page

Retrieval practice

Recall check 4 of 6

Voltage Vera says: answer from memory, then check your reasoning.

Q4A firmware repo mixes generated binaries, source, and site keys in one folder. Which change helps review?

ACommit site keys with binaries so credentials travel beside generated output.

BSeparate source, tests, hardware notes, versions, generated output and secret handling.

CDelete tests to shrink the folder, hiding dependency and build provenance.

DKeep generated output mixed with source and treat the latest binary as provenance.

Show answer

Answer: B Clear boundaries make the build and dependency state reviewable.

Retrieval practice

Recall check 5 of 6

Voltage Vera says: answer from memory, then check your reasoning.

Q5A firmware repository contains source, generated files, board notes, tests, and credentials. Which structure supports review?

AMix generated output with source and infer build provenance from filenames alone during final review.

BStore live tokens beside source so board notes and code can share one review folder.

COmit board notes because compilation proves pin choices and hardware behavior.

DSeparate source, tests, board notes, config examples and generated output; keep real secrets out.

Show answer

Answer: D Clear boundaries make builds and evidence reviewable without exposing secrets.

Retrieval practice

Recall check 6 of 6

Voltage Vera says: answer from memory, then check your reasoning.

Q6A prototype adds a networking library. The demo publishes data, but no one recorded the version, timeout behavior, or what happens when the gateway is unavailable. What is the best next review action?

ARecord source, version, lock input, timeout and gateway-loss fault run before prototype handoff.

BAccept the library from a successful demo without version or timeout records.

CRemove the libraries first because dependency count is the root cause of this integration problem.

DDefer the current dependency record until later OTA work rather than reviewing it now.

Show answer

Answer: A A dependency should be reviewed through source, version, configuration, normal-run evidence, fault-run evidence, and update policy.

Print reference

Answers 1 of 4

Answer key.

C · The chapter lists three separate examples of what a single successful run does not prove for three different dependency types: a sensor driver reading cleanly once doesn't prove bus timeout behavior, a gateway client publishing once doesn't prove reconnect backoff or TLS/permission failure handling, and a storage helper writing a file once doesn't prove full-storage or corruption behavior.

Print reference

Answers 2 of 4

Answer key.

C · The chapter defines a different contract for each dependency role: sensor libraries need status codes and stale-reading visibility, messaging libraries need connection state and retry policy, storage libraries need full-storage and corruption policy, and OTA libraries specifically need package verification, compatibility checks, health confirmation, rollback behavior, and active image-slot tracking.

Print reference

Answers 3 of 4

Answer key.

C · The chapter distinguishes 'drift' from other version-control risks: it is specifically a transitive dependency update silently changing behavior (TLS defaults, keepalive, parsing, flash timing, memory footprint, exception handling) with no corresponding change to application source, which is why the chapter says a reviewer must compare the lockfile, manifest, and board package against the evidence record to catch it.
B · Clear boundaries make the build and dependency state reviewable.
D · Clear boundaries make builds and evidence reviewable without exposing secrets.

Print reference

Answers 4 of 4

Answer key.

A · A dependency should be reviewed through source, version, configuration, normal-run evidence, fault-run evidence, and update policy.