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.
Milestone map
Milestone map
3 milestones
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