Skills

Embedded Systems Design

8 weeks · 0 milestones

Design an embedded system for a defined application, documenting the hardware-software interface at the level a firmware developer would need to implement it. The design must include: a hardware schematic showing the microcontroller, relevant peripherals (sensors, actuators, communication interfaces), and power supply with all connections labelled, a pin assignment table mapping hardware signals to microcontroller GPIO pins with electrical characteristics (voltage levels, current drive, pull-up/pull-down requirements), a peripheral interface specification for at least 2 hardware interfaces (I2C, SPI, UART, or ADC) with timing diagrams and documented protocol, a firmware architecture document describing the top-level software structure, interrupt strategy, and memory layout, and a test plan with at least 5 hardware verification tests. Preferred proof: a design for a real embedded hardware project with documented hardware bring-up evidence. Accessible alternative: a complete design in Wokwi (browser-based Arduino/ESP32 simulator, free) with simulation evidence that the hardware interface behaves as specified — Wokwi supports real sensor simulation for common I2C and SPI devices. Proof artifacts: the schematic and pin assignment (design artifact) and the interface timing analysis and test plan (analysis artifact). Verification: an embedded systems or electronics engineer reviews the interface specification — 'this I2C pull-up value seems wrong for this bus capacitance; what does that do to your rise time?' — requiring you to reason from your own interface specification.

Part of: Engineering · Proves for: Engineers, UG

Milestone map

3 milestones

Define the embedded system requirements and produce a hardware block diagram

2–3 weeks (system selection + requirements definition + block diagram + BOM)

Define a complete embedded system design brief. The system must be more complex than a single-peripheral HAL project — suitable examples include: a wireless sensor node (microcontroller + temperature/humidity sensor + LoRa or WiFi radio + battery management); a motor controller (microcontroller + H-bridge driver + encoder feedback + UART command interface); a data acquisition system (microcontroller + ADC + SD card storage + RTC); or a home automation controller (microcontroller + relay module + keypad input + LCD display). Define quantitative system requirements: power budget (supply voltage, maximum current draw), timing requirements (sampling rate, response latency), communication interface (protocol, data rate), and reliability requirement (what happens on power loss or sensor failure). Produce a hardware block diagram showing all physical components, their interconnections, and the communication protocols used at each interface.

Proof required

Submit: (1) the design brief with at least six numbered, quantitative system requirements; (2) the hardware block diagram showing all components and interface protocols/voltages (draw.io is free); (3) a bill of materials (BOM) table listing each component, its function, and whether physical hardware or a free simulator (Wokwi) will be used for the proof.

What gets checked

Requirements are quantitative and specific — 'power budget: 3.3 V supply, maximum 80 mA average current to achieve 24-hour battery life on a 2000 mAh cell' is a valid requirement; 'low power' is not
Hardware block diagram labels every interface with protocol and signal level — 'I2C / 3.3 V logic' on the connection between the MCU and the sensor; an unlabelled arrow is not an interface specification
BOM lists every physical component or simulated component — a BOM that omits passive components (resistors, capacitors, crystal) has not captured the full system cost and complexity

Common mistakes

Defining requirements that are not verifiable — a requirement that cannot be tested (e.g. 'reliable operation') cannot be used to evaluate whether the design meets it; all requirements must be testable against a measurable criterion
Producing a software architecture block diagram rather than a hardware block diagram — the M1 diagram shows physical components (ICs, sensors, connectors, power regulators) and their electrical interfaces; a software layer diagram belongs in M2

Resources

Foundationstart here

Depthgo deeper

Masteryfor the dedicated

What a verifier looks for

Engineering Design Triad: M1 produces a design artifact (hardware block diagram + BOM) — this is the first of three artifact types required across M1–M3.
Requirements must be quantitative and testable — check that each requirement has a number, a unit, and an implied test method.
Hardware block diagram must label all interfaces with protocol and signal level — check that no connections are unlabelled arrows.
BOM must list all components including passives — check for completeness against the block diagram.
Reviewer must be an electrical engineer or embedded systems engineer — hardware interface selection and power budget validity require domain expertise.

You'll sign in first, then come straight back here.

Implement and verify the embedded system on hardware or simulator

3–4 weeks (implementation + test plan execution + verification)

Implement the complete embedded system defined in Milestone 1. The implementation must include: a hardware abstraction layer (HAL) for all peripherals listed in the BOM; a main application with a state machine or task scheduler that meets the timing requirements; and communication functionality (send or receive data over the specified protocol). Use a real hardware platform or Wokwi for the implementation. Write and execute a verification test plan covering each system requirement from M1 — for each requirement, state the test method, the test input or condition, and the measured result. At least four of the six requirements must pass their verification tests.

Proof required

Submit: (1) the complete source code in a public GitHub repository or Wokwi project link; (2) the verification test plan table (requirement number, test method, test condition, expected result, measured result, pass/fail) covering all six requirements; (3) a video or Wokwi simulation link showing the system operating through a complete operational cycle (all states visited, communication output visible); (4) a serial monitor or logic analyser screenshot confirming the communication protocol output for at least one interface.

What gets checked

Verification test plan maps one-to-one with the M1 requirements — every requirement from M1 has a corresponding test row; a test plan that covers only some requirements has not verified the design
Measured results are actual measurements, not claimed values — 'measured average current: 73 mA (multimeter reading, full operation)' is a valid measured result; 'should be within spec' is not
At least four of six requirements pass — a system where fewer than four requirements are verified as passing has not demonstrated a functioning design; requirements that fail must be listed with the measured deviation

Common mistakes

Writing the verification test plan after implementation to match what was built rather than testing against the original requirements — the test plan must test each numbered M1 requirement; tests that were written to describe what the system does (not what it was required to do) cannot verify requirements
Skipping the communication interface verification — the serial monitor or logic analyser screenshot is mandatory; a claim that the communication interface works without evidence cannot be accepted

Resources

Foundationstart here

Depthgo deeper

Masteryfor the dedicated

What a verifier looks for

Engineering Design Triad: M2 produces an analysis artifact (verification test plan with measured results) and contributes to the design artifact (implemented firmware + hardware setup) — both must be present.
Verification test plan must cover all six M1 requirements — check each row maps to a numbered requirement.
Measured results must be actual values — 'should be within spec' fails; 'measured 73 mA, within 80 mA requirement ✓' passes.
Communication interface verification must be a screenshot — not a verbal claim.
At least four of six requirements must pass — check the pass/fail column; fewer than four passes means the design has not met its requirements.
Reviewer must have embedded systems development experience — test plan quality and measurement validity require domain expertise.

You'll sign in first, then come straight back here.

Produce an embedded systems design report and present for technical review

2–3 weeks (report compilation + reviewer meeting)

Compile the design brief, hardware block diagram, BOM, firmware implementation, and verification test plan results into a structured embedded systems design report. The report must include: an executive summary (1 paragraph); system requirements (from M1); hardware design (block diagram + BOM + component selection rationale for the two most critical components); firmware architecture (FSM/task diagram + HAL structure); verification results (test plan table from M2 with pass/fail); discussion (two design tradeoffs made, one known limitation, and one future improvement); and conclusions. Present the report to a qualified reviewer (electrical engineer or software engineer with embedded systems experience) in a 25–40 minute technical session where they challenge at least two design decisions (one hardware, one firmware).

Proof required

Submit: (1) the complete embedded systems design report (all sections above, 900–1300 words); (2) the verification results summary table (all six requirements with pass/fail and measured values); (3) a code review record covering the reviewer's two technical challenges and your responses (250 words minimum, attributing the reviewer by professional role and relevant background).

What gets checked

Component selection rationale for the two critical components cites a specific datasheet specification — 'selected the DHT22 over the DHT11 because the DHT22 has ±0.5°C accuracy (datasheet Table 1) vs. ±2°C for the DHT11; the system requirement is ±1°C' is a valid rationale
Design tradeoffs section names a specific choice and the alternative rejected — 'chose polling over interrupt-driven sensor sampling because the 100 ms sampling rate allows polling without missing samples; interrupt-driven would add complexity without benefit at this rate' is a valid tradeoff
Reviewer challenges cover both hardware and firmware — a review that only challenges firmware (no hardware questions) or only hardware (no firmware questions) has not covered the full system

Common mistakes

Omitting the verification results table — this is the evidence that the system meets its requirements; a report without it is an incomplete engineering document
Presenting to a reviewer with only software experience and no embedded or hardware knowledge — the hardware design tradeoffs (power, communication protocols, component selection) require hardware domain knowledge to evaluate; a pure software reviewer cannot challenge the hardware design decisions

Powstik Guide

An embedded systems design report, technically reviewed.

Steps

Assemble brief, block diagram, BOM, firmware and test results into one report.
Check every number traces to a calculation.
Book a qualified reviewer.
Log at least three challenges and your answers.

Template

Review session log
Date:            Duration:
Reviewer name:
Reviewer role and credentials:

Challenge 1 (firmware or verification results):
  What they asked:
  My answer:
  Did it hold?
Challenge 2:
  What they asked:
  My answer:
  Did it hold?
Challenge 3:
  What they asked:
  My answer:
  Did it hold?

What I will change because of this session:

What gets sent back

A reviewer who doesn't meet the stated bar.
Notes without the reviewer's name and role.
No verification results.

Resources

Foundationstart here

Depthgo deeper

What a verifier looks for

Engineering Design Triad check: M1–M3 together produce a design artifact (hardware block diagram + BOM + firmware architecture diagram), an analysis artifact (verification test plan with measured results), and a documentation artifact (embedded systems design report with tradeoffs and component selection rationale) — confirm all three types are present.
Verification table must include all six requirements with measured values — check that the table is not a subset of requirements.
Reviewer must have challenged both a hardware and a firmware decision — check the code review record for both types.
Component selection rationale must cite datasheet specifications — check that the rationale references a named table, figure, or parameter from the datasheet.
Reviewer must have embedded systems experience covering both hardware and firmware — a single-discipline reviewer cannot evaluate the full design.
The Proof Accessibility Rule applies — Wokwi, Arduino IDE, PlatformIO, and draw.io are all free.

You'll sign in first, then come straight back here.

Part of

Electrical & Electronics Engineering →Robotics & Embedded AI →Robotics 2: Build →

Related outcomes

Milestone map

3 milestones

Define the embedded system requirements and produce a hardware block diagram

2–3 weeks (system selection + requirements definition + block diagram + BOM)

Proof required

What gets checked

Requirements are quantitative and specific — 'power budget: 3.3 V supply, maximum 80 mA average current to achieve 24-hour battery life on a 2000 mAh cell' is a valid requirement; 'low power' is not
Hardware block diagram labels every interface with protocol and signal level — 'I2C / 3.3 V logic' on the connection between the MCU and the sensor; an unlabelled arrow is not an interface specification
BOM lists every physical component or simulated component — a BOM that omits passive components (resistors, capacitors, crystal) has not captured the full system cost and complexity

Common mistakes

Defining requirements that are not verifiable — a requirement that cannot be tested (e.g. 'reliable operation') cannot be used to evaluate whether the design meets it; all requirements must be testable against a measurable criterion
Producing a software architecture block diagram rather than a hardware block diagram — the M1 diagram shows physical components (ICs, sensors, connectors, power regulators) and their electrical interfaces; a software layer diagram belongs in M2

Resources

Foundationstart here

Depthgo deeper

Masteryfor the dedicated

What a verifier looks for

Engineering Design Triad: M1 produces a design artifact (hardware block diagram + BOM) — this is the first of three artifact types required across M1–M3.
Requirements must be quantitative and testable — check that each requirement has a number, a unit, and an implied test method.
Hardware block diagram must label all interfaces with protocol and signal level — check that no connections are unlabelled arrows.
BOM must list all components including passives — check for completeness against the block diagram.
Reviewer must be an electrical engineer or embedded systems engineer — hardware interface selection and power budget validity require domain expertise.

You'll sign in first, then come straight back here.

Implement and verify the embedded system on hardware or simulator

3–4 weeks (implementation + test plan execution + verification)

Proof required

What gets checked

Verification test plan maps one-to-one with the M1 requirements — every requirement from M1 has a corresponding test row; a test plan that covers only some requirements has not verified the design
Measured results are actual measurements, not claimed values — 'measured average current: 73 mA (multimeter reading, full operation)' is a valid measured result; 'should be within spec' is not
At least four of six requirements pass — a system where fewer than four requirements are verified as passing has not demonstrated a functioning design; requirements that fail must be listed with the measured deviation

Common mistakes

Writing the verification test plan after implementation to match what was built rather than testing against the original requirements — the test plan must test each numbered M1 requirement; tests that were written to describe what the system does (not what it was required to do) cannot verify requirements
Skipping the communication interface verification — the serial monitor or logic analyser screenshot is mandatory; a claim that the communication interface works without evidence cannot be accepted

Resources

Foundationstart here

Depthgo deeper

Masteryfor the dedicated

What a verifier looks for

Engineering Design Triad: M2 produces an analysis artifact (verification test plan with measured results) and contributes to the design artifact (implemented firmware + hardware setup) — both must be present.
Verification test plan must cover all six M1 requirements — check each row maps to a numbered requirement.
Measured results must be actual values — 'should be within spec' fails; 'measured 73 mA, within 80 mA requirement ✓' passes.
Communication interface verification must be a screenshot — not a verbal claim.
At least four of six requirements must pass — check the pass/fail column; fewer than four passes means the design has not met its requirements.
Reviewer must have embedded systems development experience — test plan quality and measurement validity require domain expertise.

You'll sign in first, then come straight back here.

Produce an embedded systems design report and present for technical review

2–3 weeks (report compilation + reviewer meeting)

Proof required

What gets checked

Component selection rationale for the two critical components cites a specific datasheet specification — 'selected the DHT22 over the DHT11 because the DHT22 has ±0.5°C accuracy (datasheet Table 1) vs. ±2°C for the DHT11; the system requirement is ±1°C' is a valid rationale
Design tradeoffs section names a specific choice and the alternative rejected — 'chose polling over interrupt-driven sensor sampling because the 100 ms sampling rate allows polling without missing samples; interrupt-driven would add complexity without benefit at this rate' is a valid tradeoff
Reviewer challenges cover both hardware and firmware — a review that only challenges firmware (no hardware questions) or only hardware (no firmware questions) has not covered the full system

Common mistakes

Omitting the verification results table — this is the evidence that the system meets its requirements; a report without it is an incomplete engineering document
Presenting to a reviewer with only software experience and no embedded or hardware knowledge — the hardware design tradeoffs (power, communication protocols, component selection) require hardware domain knowledge to evaluate; a pure software reviewer cannot challenge the hardware design decisions

Powstik Guide

An embedded systems design report, technically reviewed.

Steps

Assemble brief, block diagram, BOM, firmware and test results into one report.
Check every number traces to a calculation.
Book a qualified reviewer.
Log at least three challenges and your answers.

Template

Review session log
Date:            Duration:
Reviewer name:
Reviewer role and credentials:

Challenge 1 (firmware or verification results):
  What they asked:
  My answer:
  Did it hold?
Challenge 2:
  What they asked:
  My answer:
  Did it hold?
Challenge 3:
  What they asked:
  My answer:
  Did it hold?

What I will change because of this session:

What gets sent back

A reviewer who doesn't meet the stated bar.
Notes without the reviewer's name and role.
No verification results.

Resources

Foundationstart here

Depthgo deeper

What a verifier looks for

Engineering Design Triad check: M1–M3 together produce a design artifact (hardware block diagram + BOM + firmware architecture diagram), an analysis artifact (verification test plan with measured results), and a documentation artifact (embedded systems design report with tradeoffs and component selection rationale) — confirm all three types are present.
Verification table must include all six requirements with measured values — check that the table is not a subset of requirements.
Reviewer must have challenged both a hardware and a firmware decision — check the code review record for both types.
Component selection rationale must cite datasheet specifications — check that the rationale references a named table, figure, or parameter from the datasheet.
Reviewer must have embedded systems experience covering both hardware and firmware — a single-discipline reviewer cannot evaluate the full design.
The Proof Accessibility Rule applies — Wokwi, Arduino IDE, PlatformIO, and draw.io are all free.

You'll sign in first, then come straight back here.