Design Methodology · Study deck
Virtual Hardware: Test Harnesses
A virtual board can prove state order before real parts arrive.
Blueprint Bina is your guide for this deck.
After studying this chapter
Learning objectives
You will be able to:
- Define which hardware-programming claims a simulator can support and which claims require physical hardware.
- Build a repeatable virtual circuit that links firmware, pin maps, virtual peripherals, test inputs, and expected observations.
- Use simulated boards and peripherals to exercise firmware logic, state transitions, error handling, and interface assumptions.
- Capture simulation evidence without overclaiming timing, analog, radio, power, or environmental behavior.
Major section
Begin With One Risky Line of Code
Firmware is the code that runs on a device.
- A virtual board can run the code before the real parts arrive.
- Fast virtual tests can cover many code paths, but ideal parts may hide rise time, noise, pull-up, and current faults.
- A detailed model can help, but it is still a model.
Major section
Begin With One Risky Line of Code (continued)
A short honest result is more useful than a long demo with no claim.
- This first pass does not release the product.
- The deeper route tells you which claims must wait for real hardware.
- Some claims need both.
- This stops a fast test from being read as full proof.
Major section
Simulate, Then Prove Firmware
Virtual hardware is useful when the team is clear about the claim.
- A strong simulation pass names three things before anyone celebrates a green run: the firmware behavior being exercised, the model boundary, and the bench check that will replace the virtual assumption.
- That keeps a simulator from becoming a shortcut around hardware truth.
Major section
Simulate, Then Prove Firmware (continued)
For an ESP32 or Arduino-style node, the model may cover GPIO, serial logs, button state, virtual DHT22/BME280 values, and an MQTT mock, while omitting Wi-Fi coexistence, regulator behavior, antenna placement, and sleep current.
- For an RP2040 or Zephyr target, it may cover I2C/SPI/UART sequencing and reset logic while omitting actual pullups, timing margin, and board variant constraints.
- Those hand-offs make Hardware simulation is useful when every run starts with a claim and ends with evidence plus a hardware-transfer action actionable within: Simulate, Then Prove Firmware.
- The loop is deliberately conservative.
Major section
Build Virtual Circuit Test Harness
For a Wokwi project, keep diagram.json, firmware source, board target, library versions, serial output, and scenario instructions together.
- For Renode or QEMU, keep the platform description, machine configuration, firmware image, startup script, UART log, and CI command.
- For Arduino CLI, PlatformIO, or Zephyr builds, keep the board identifier, compile flags, dependency lock state, and simulator-specific setup.
- The review artifact should be runnable by someone who did not build the demo.
Major section
Build Virtual Circuit Test Harness (continued)
A Raspberry Pi Pico or RP2040 simulation may exercise GPIO, PWM, I2C, SPI, UART, timers, and interrupt handling.
- An ESP32 or Arduino-style node may exercise Wi-Fi/MQTT mock paths, OLED updates, button state, LED state, DHT22/BME280/DS18B20-style sensor values, and serial diagnostics.
- A useful run includes normal, boundary, missing-device, invalid-value, reset, and rapid-input cases.
- This keeps the virtual circuit from becoming a separate truth source.
Major section
Build Virtual Circuit Test Harness (continued)
Each case should state the expected serial line, display state, LED state, message count, timeout branch, or assertion result.
- If the simulation checks an I2C sensor branch, the handoff should name the bench counterpart: pullup values, bus speed, address scan, logic-analyzer capture, and sensor-read timing.
- If it checks a sleep or watchdog path, the handoff should name current measurement, wake source, reset reason, brownout threshold, and battery-load test.
- If it checks a gateway service image in QEMU or Renode, the handoff should name boot timing, peripheral availability, network path, log correlation, and target-board rerun.
Major section
Ideal Models Hide Gaps
A clean simulated I2C transaction does not prove a real cable, board layout, or pullup value will survive the bench.
- Most virtual hardware models are intentionally simplified.
- A clean UART parser run does not prove level shifting, framing under noise, or connector strain.
- Transfer gap:: The exact physical measurement or bench scenario that must follow the simulator run.
Major section
Ideal Models Hide Gaps (continued)
They may not model pullup resistance, bus capacitance, rise/fall time, ADC noise, oscillator drift, brownout, regulator dropout, interrupt jitter, DMA timing, flash wear, boot strap pins, ESD damage, connector tolerance, or sensor calibration.
- A successful simulated Wi-Fi publish does not prove antenna placement, roaming, coexistence, or access-point recovery.
- If a simulated SPI waveform has the right command order, the bench still needs chip-select timing, voltage level, setup/hold margin, real peripheral response, and noise check.
- If a simulated sleep path reaches low-power mode, the bench still needs current draw, wake latency, watchdog behavior, and battery-load measurement.
Major section
Ideal Models Hide Gaps (continued)
If a simulator runs a Zephyr or embedded-Linux image, the target board still needs driver availability, device-tree accuracy, bootloader behavior, peripheral timing, flash partition, and recovery-path checks.
- The practical reason to write these limits down is that simulator failures and bench failures have different root-cause classes.
- A simulator mismatch may be firmware logic, fixture data, library version, build target, or model coverage.
- A bench mismatch may be schematic, assembly, power integrity, tolerance, environmental condition, instrument setup, or firmware timing.
Major section
Choose the Simulator Role
Models may be idealized and may not represent exact board variants, analog behavior, power, or RF conditions.
- Project link, exported project files, firmware commit, and run log.
- Embedded Linux boot, firmware services, board-level software behavior, repeatable CI tests, and multi-node setups.
- Peripheral coverage and timing fidelity depend on the model and configuration.
Deck summary
Key takeaways
Firmware is the code that runs on a device.
- A short honest result is more useful than a long demo with no claim.
- Virtual hardware is useful when the team is clear about the claim.
- For an ESP32 or Arduino-style node, the model may cover GPIO, serial logs, button state, virtual DHT22/BME280 values, and an MQTT mock, while omitting Wi-Fi coexistence, regulator behavior, antenna placement, and sleep current.
- For a Wokwi project, keep diagram.json, firmware source, board target, library versions, serial output, and scenario instructions together.
Retrieval practice
Recall check
Blueprint Bina says: answer from memory, then check your reasoning.
Q1A virtual alarm board responds correctly to a stuck input. What can that run support?
Show answer
Answer: A The virtual side covers code order, state changes, and error paths.
Q2An ESP32 simulation passes with an MQTT mock. What should its handoff name?
Show answer
Answer: D A useful pass records the exercised behavior, model boundary, and physical follow-up.
Print reference
Answers
Answer key.
- A · The virtual side covers code order, state changes, and error paths.
- D · A useful pass records the exercised behavior, model boundary, and physical follow-up.