Prototyping · Study deck
What Software Prototypes Prove
Picture a greenhouse demo that reads a sensor, sends a value, and starts a fan.
Voltage Vera is your guide for this deck.
After studying this chapter
Learning objectives
You will be able to:
- Explain: It may prove that an I2C sensor can be read without blocking the loop, that an MQTT publish path keeps enough status for recovery, or that a gateway contract survives a network outage.
- Explain: If the question is the cloud contract, a Python simulator can publish representative JSON to Mosquitto, EMQX, AWS IoT Core, or Azure IoT Hub before the real device firmware is complete.
- Explain: In FreeRTOS or Zephyr, it may be task priority, queue depth, stack high-water mark, timer jitter, and whether a work queue can starve a lower-priority sampling task.
Major section
In 60 Seconds · Start With the Story
A polished screen proves little if the software loses the reading during a restart or depends on a link that the real site cannot keep.
- Firmware means software stored on a device.
- Inter-integrated circuit (I2C) means a short shared wired link between chips.
- A payload means the useful data inside one message.
Major section
Prototype the Software Risk
A software prototype is useful when it isolates the behavior that could invalidate the design.
- It may prove that an I2C sensor can be read without blocking the loop, that an MQTT publish path keeps enough status for recovery, or that a gateway contract survives a network outage.
- It should not try to become the production firmware on day one.
- A driver plus one state transition may be enough to expose stale data or a timeout; a polished application screen is not required.
- Instrument the slice with logs or status traces and run both the normal case and a fault case.
Major section
Prototype the Software Risk (continued)
The decision records what can be reused, what needs retest on integrated hardware, and what should be discarded.
- The route makes a software prototype valuable when its evidence explains success and failure, not merely when the code runs once.
- The smallest useful slice includes the real boundary that creates the risk.
- For firmware, that might be a driver plus a state machine.
- For integration, it might be a device simulator plus broker payloads.
Major section
Prototype the Software Risk (continued)
For operations, it might be a firmware version, log format, and fault state that support can interpret.
- The front end is the client-facing part: screens, controls, workflow, and the user experience that lets a person interact with the system.
- The back end is the server-side part: data storage, APIs, authentication, algorithms, and services the user normally does not see directly.
- Full-stack work connects those two sides and proves the contract between them.
Major section
Pick Runtime Deliberately
An Arduino sketch can answer a quick sensor-read question, but it may hide memory, interrupt, and scheduling behavior.
- ESP-IDF, Zephyr, or FreeRTOS can expose task timing, watchdog behavior, queues, and driver boundaries.
- A Python or Node.js harness can test a cloud contract, but it does not prove the microcontroller timing path.
- For a hardware-in-loop run, include the fixture, power supply, serial log, and fault injected.
Major section
Pick Runtime Deliberately (continued)
If the team only needs to compare SHT31 and BME280 library behavior, an Arduino or PlatformIO sketch with Serial Monitor output may be enough.
- If the question is whether a valve controller can keep sampling while MQTT reconnects, use ESP-IDF, Zephyr, or FreeRTOS so tasks, queues, watchdogs, and timer callbacks are visible.
- If the question is the cloud contract, a Python simulator can publish representative JSON to Mosquitto, EMQX, AWS IoT Core, or Azure IoT Hub before the real device firmware is complete.
- That evidence lets another engineer repeat the same risk test without guessing which laptop, board variant, or temporary script produced the result.
Major section
Firmware Timing Shapes Results
Two prototypes can show the same dashboard value while proving different things.
- These details decide whether the prototype is a throwaway sketch, a reusable driver experiment, or a candidate production slice.
- Timing evidence should name the owner of each wait.
- In a bare superloop, the evidence may be maximum loop time, retry counters, and watchdog reset reason.
Major section
Firmware Timing Shapes Results (continued)
In FreeRTOS or Zephyr, it may be task priority, queue depth, stack high-water mark, timer jitter, and whether a work queue can starve a lower-priority sampling task.
- A battery prototype that sleeps between samples should record wake reason, radio association time, publish duration, and current spikes measured with a power profiler or shunt fixture.
- An OTA prototype should record image slot, bootloader result, rollback condition, and what local state survives a failed update.
- These details are not paperwork; they decide whether later software architecture can trust the prototype or must repeat the experiment with the final runtime model.
Major section
Evidence Layers · Prototype Forms
The chapter should identify which layer is being tested so later work does not confuse a working sketch with a production-ready subsystem.
- Application state names transitions, stale readings, and recovery, while the communication contract records payload shape, retries, and offline queue behavior.
- A working publish message therefore cannot prove reset behavior or an interrupted update.
- the Software prototype forms and evidence strength diagram orders software forms by the uncertainty they can expose.
- A throwaway sketch can check one library or pin behavior, while a firmware slice can exercise boot, watchdog, or driver risk.
Major section
Risk Review
Timeout logs and retry counts support the blocking check; state logs show named transitions and a fault state.
- Versioned configuration records calibration and switches without exposing secrets.
- Normal and fault artifacts make the run observable.
- The handoff row separates reusable code from throwaway demo work, and the update row asks for an interrupted-update test or a clear deferral.
Major section
Risk Review (continued)
These rows matter together: a normal run may look sound while an unbounded network call or stale status still breaks the prototype.
- Blocking risk: Every network, storage, sensor, update, and bus operation has a timeout or bounded retry path.
- Observability risk: Logs, counters, status LEDs, debug pins, serial output, or trace files explain what happened during the run.
- Handoff risk: The team can say which code is throwaway, which parts may be reused, and which assumptions define the next rerun condition.
Major section
Keep the Prototype Small · Worked Scenario: Pump Room Leak Monitor
The alarm timing, enclosure assumptions, configuration storage, and OTA path remain prototype-only until later software chapters test them directly.
- Small prototypes are easier to challenge.
- A team is prototyping firmware for a pump room leak monitor.
- The review record includes build command, board revision, firmware version, and one clean log.
Major section
Integration Boundary · Software Prototype Review Record
Leave a record that another engineer can replay or challenge.
- A normal run records boot, sensor read, alarm clear, status publish, and the idle path with its build version.
- Fault runs add missing or stuck input, gateway loss, and restart during alarm; the status fields show stale data and the last fault.
- the Software prototype review record diagram keeps the pump-room firmware claim narrow enough to replay.
- The record marks a sensor driver and payload schema as candidates for reuse, while alarm timing and debug output remain temporary.
Major section
Common Failure Patterns
Happy-path-only evidence: The demo works only when every dependency is available.
- Unbounded communication: Connection loops, bus reads, or update checks can block forever.
- Every external dependency needs a timeout or bounded retry.
- Unrepeatable build: The prototype cannot be rebuilt because the tool version, board profile, or configuration was not recorded.
Deck summary
Key takeaways
A polished screen proves little if the software loses the reading during a restart or depends on a link that the real site cannot keep.
- A software prototype is useful when it isolates the behavior that could invalidate the design.
- The decision records what can be reused, what needs retest on integrated hardware, and what should be discarded.
- For operations, it might be a firmware version, log format, and fault state that support can interpret.
- An Arduino sketch can answer a quick sensor-read question, but it may hide memory, interrupt, and scheduling behavior.
Retrieval practice
Recall check 1 of 4
Voltage Vera says: answer from memory, then check your reasoning.
Q1The next prototype decision depends on recovery after Wi-Fi loss. What firmware slice should the team build first?
Show answer
Answer: D The slice exposes the decision risk and its fault path.
Retrieval practice
Recall check 2 of 4
Voltage Vera says: answer from memory, then check your reasoning.
Q2Per this chapter, how does it define 'full-stack' work in an IoT prototype?
Show answer
Answer: D see answers page
Retrieval practice
Recall check 3 of 4
Voltage Vera says: answer from memory, then check your reasoning.
Q3Per this chapter's 'Firmware Timing Shapes Results' section, what does it mean for timing evidence to 'name the owner of each wait'?
Show answer
Answer: B see answers page
Retrieval practice
Recall check 4 of 4
Voltage Vera says: answer from memory, then check your reasoning.
Q4A prototype reads a sensor and updates a dashboard once, but it has no timeout, no stale-data flag, and no record of the payload fields. What should the team do before treating it as evidence?
Show answer
Answer: A A useful software prototype proves a bounded behavior and leaves a reviewable record.
Print reference
Answers 1 of 2
Answer key.
- D · The slice exposes the decision risk and its fault path.
- D · The chapter names the software stack by responsibility, not job title: the front end is the client-facing part (screens, controls, workflow), the back end is the server-side part (storage, APIs, authentication, algorithms), and full-stack work connects those two sides and proves the contract between them -- for example a web button sending a command, a gateway API validating it, a device state machine applying it, and a sensor reading confirming the outcome.
Print reference
Answers 2 of 2
Answer key.
- B · The chapter says timing evidence should name the owner of each wait, then gives four concrete examples of what that means in practice: an I2C read blocking behind clock stretching, a TLS handshake holding a network task, a filesystem write stalling during a flash erase, and a sensor interrupt arriving while the application is already processing an alarm -- each a distinct, identifiable cause rather than an undifferentiated total delay.
- A · A useful software prototype proves a bounded behavior and leaves a reviewable record.