6. Electronics Design¶
Global Class¶
A large portion of the lecture reviewed core components: resistors (Ohm’s law, power dissipation), capacitors (charge storage, bypassing, filtering), inductors, diodes (including Zener and LEDs), MOSFETs (as voltage-controlled resistors for switching and power control), and voltage regulators for stable supply rails.

The global session introduced the electronics design assignment: design and simulate a circuit this week, fabricate it later. The focus was on understanding components (passive and active), reading datasheets, and thinking about current, voltage, power, and grounding before touching layout tools.

The workflow for PCB design was outlined: sketch → schematic capture → assign footprints → layout and routing → DRC/ERC checks → export (Gerber/SVG) → fabrication.
KiCad was recommended as the primary open-source EDA tool, with attention to libraries, design rules, layers, and fabrication constraints.
Local Class¶
Guillem Lecture¶
A lecture by Guillem explored the essence of computation as rule-following: computers do not think; they apply clear instructions step by step to transform information. From Boolean logic, Turing’s abstract machines, Shannon’s electrical switches, von Neumann’s architecture, the Apollo program’s integrated circuits, and Linux as a unifying software layer, we got an birds-eye overview of the history of computing.
We started by physically opening devices—computers, routers, and other electronics—to examine CPUs, memory chips, voltage regulators, crystals, and capacitors. Handling these components made the physical constraints of computation tangible: energy consumption, heat dissipation, spatial density. This hands-on exploration built familiarity and confidence, grounding abstract concepts in real hardware.
Every digital operation is ultimately reduced to yes/no transitions. There is no magic— only structured layers of rules executed reliably and at massive scale. Hardware executes decisions; software describes them; abstraction layers coordinate them. Computation is an organized physical decision-making system that implements our design choices. We are not building “intelligence” in the abstract, but structured, energy-aware rule systems embedded in material devices. Ultimately, humans remain the thinkers and designers behind the computing power, however powerful and well-structured it becomes.
Hands-on¶
After getting acquainted with circuit boards and such, we did some with group exercises and assignments
Breadboard LED Test¶
Basic LED circuit assembled on a breadboard to verify polarity, resistor placement, and switching behavior. This hands-on test reinforced how a simple rule-based decision (switch on/off) becomes a visible electrical outcome through current flow and voltage drop.

Measuring Current with Multimeter¶
Using a multimeter to measure current in the LED circuit. This exercise connected theory to practice: verifying voltage levels, understanding resistance limits, and confirming how energy flows through the circuit. It emphasized that electronics is not abstract logic alone, but measurable physical behavior governed by electrical constraints.

Final product¶
Milled and soldered ATtiny-based development board. This board integrates the microcontroller, headers, decoupling components, button, and support circuitry. Observing the routed traces and component placement helped us understand how schematic decisions translate into physical copper geometry and signal paths.

Kicad¶
Schematics¶
We began by reviewing previous Fab Academy documentation and example boards (FabTinyISP, ATtiny-based dev boards, UPDI programmers) to understand common layouts, design rules, and typical mistakes.
We built the circuit in KiCad from scratch: ATtiny402, power header, UPDI interface, LED with current-limiting resistor, and button with pull-down resistor. The focus was clarity in net naming (UPDI, BUTTON_PIN, LED_PIN, 5V, GND) and organizing the schematic into functional blocks (Power, Programming, I/O, Expansion).

Electrical reasoning before layout¶
Before routing, we reviewed Ohm’s law and verified LED resistor values using measured voltage drops. We mapped voltage points (A–B–C–D) to understand real behavior versus ideal schematics. This grounded the design in physical constraints—current, resistance, and voltage drop—rather than symbolic connections.
The schematic was refined to ensure:
• Proper current limiting for the LED
• Defined button logic state
• Clean UPDI programming path


PCB¶
The board layout followed single-layer milling constraints learned from earlier Fab Lab work: wide enough traces, minimal crossings, internal routing before outline. Components were compactly arranged around the ATtiny402 to reduce trace length. The octagonal board outline reflects intentional design rather than a default rectangle. Traces were routed to avoid unnecessary vias and respect milling limits (1/64” for traces, 1/32” for outline, as practiced in earlier cohorts.

Outcome¶
The progression moved into a clean, visually lean design polished by Dani.
With the end result at hand, it was obvious that electronics production is the organization of physical decisions: voltage, current, geometry, and material limits structured into a system.


Individual Assignment¶
Embodied Edge Architecture¶
Taking Eric Pan’s from Seeed Studio AI lecture as foundation, AI systems are structured in layers:
Hardware layer:
Input → Processing → Output → Communication
Software layer:
Dataset + Algorithm = Model (deployable as a library)
Edge computing prioritizes:
- Collect data
- Process data locally
- Move only what is necessary
Embodied AI refers to locally deployed, physically grounded, energy-aware systems embedded in machines.
Asfalt Architecture (v0)¶
Inputs - temperature sensors - user button
Processing - ATSAMD21E18A running closed-loop thermal control
Outputs - SSR controlling AC heater - status LED
Optional - UART / I²C expansion - future wireless
Edge Computing¶
All control runs locally.
sensor → evaluation → control → SSR switching
No cloud dependency.
Embodied Intelligence¶
Energy → heat response → sensor feedback → control adjustment
Constraints - thermal inertia - heat flow - safety limits
Evolution¶
v0 deterministic thermal control
v1 adaptive heating behavior
v2 edge model assistance
Position¶
Asfalt is - embodied - edge-native - expandable
SVG-PCB (Leo McElroy) – Rapid Controller Exploration¶
To explore the controller concept quickly and concretely, we used Leo McElroy’s SVG-PCB in-browser editor as a “sketchpad” for electronics. Instead of starting in a full EDA workflow, we described the board in code and generated an SVG PCB layout directly.
What we built in SVG-PCB¶
We used an ATtiny412 footprint from the Fab inventory library and routed a minimal breakout layout:
- Power pads: VCC, GND
- Programming pad: UPDI
-
Signal pads reserved for control + sensing:
-
PA3 (intended as output to drive heater control stage later)
- PA1 (intended as input for a button or sensor threshold)
- PA6 / PA7 (reserved as expansion pins for sensor communication)
What we learned from the SVG-PCB approach¶
- Pad naming matters: wiring in SVG-PCB fails if pad labels don’t match footprint keys (we fixed this by reading the ATtiny412 footprint definition and only using real pad names).
- Manufacturability is geometry: we moved from diagonal routes to traight breakout traces, which immediately made the layout more mill-friendly (no crossings, no acute angles, single-layer logic).

Why this matters for ASfalt¶
SVG-PCB let us “tinker” at the level that matters early on:
- Identify which pins are needed for sensing + actuation
- See how routing decisions constrain what is realistically buildable
- Treat the controller as part of an embodied physical loop (signals in, decisions, signals out)
This rapid prototyping step supported the transition from abstract ideas (edge + embodied AI) into real, routable electronics, before committing to the full schematic/PCB workflow in KiCad for the ASfalt controller board.

SVG-PCB Workflow¶
When attempting to move the SVG-PCB design into KiCad for refinement, the exported .kicad_pcb file was not fully compatible with the KiCad version being used. Importing the SVG directly resulted in filled copper graphics rather than editable tracks, making it impractical to polish and continue development inside KiCad from that file.
Although this limited its use as a production-ready workflow, SVG-PCB was still a valuable exploration tool. It clearly demonstrated how code-based descriptions directly generate physical electronics geometry. Defining pads, traces, and routing paths in JavaScript made the structural logic of the board explicit.

Even if the SVG-PCB board was not carried forward into KiCad, it was a great tool to play around with as it was developed by fellow Fablab collaborators.
Asfalt Controller — Schematic Development¶
The Asfalt system is conceived as a smart radiant top-heat cooking tool designed to upgrade existing street-food setups. The electronics architecture is intentionally designed to evolve progressively, starting with a simple and reliable embedded controller capable of managing heat while leaving room for sensing, interaction, and future edge intelligence.
- heater control
- temperature sensing
- user interface
- system power regulation
Development began using KiCad following the typical Fab Academy workflow for microcontroller-based boards, based on Fab Lab Leuven student Quentin Bolsee, built around the ATSAMD21E17A which provides a clear reference for the minimal circuit required to run an ATSAMD21 microcontroller.
Schematic Structure¶
To keep the design organized and scalable, the schematic was divided into four logical subsystems:
- Power
- MCU Core
- Heater Control
- Sensor + UI
This modular layout makes the schematic easier to read and allows each subsystem to evolve independently as the project develops.
Power Section¶
The Power block defines the supply architecture of the board.
An external 5V input connector was added to provide the primary supply voltage for the system. This input feeds a 3.3V voltage regulator which converts the incoming voltage into the level required by the microcontroller and other low-voltage components.
The output of the regulator defines the system power rail labeled:
PWR_3V3
This rail powers the microcontroller and all future peripheral components. Establishing this rail early ensures that the rest of the system references a consistent and stable power architecture.
MCU Core¶
At the center of the design is the ATSAMD21E17A microcontroller.
The microcontroller is powered through the 3.3V rail:
PWR_3V3 → VDDIN
PWR_3V3 → VDDANA
Ground pins are connected to the system ground reference:
GND → MCU ground pins
A decoupling capacitor was placed close to the microcontroller between the power rail and ground. This capacitor stabilizes the voltage supply and reduces noise generated by switching activity inside the device.
The VDDCORE pin is connected to a dedicated capacitor to ground. This capacitor supports the internal voltage regulator of the SAMD21 and is required for stable operation of the chip.
To enable programming and debugging of the board, a Serial Wire Debug header was added. This SWD interface exposes the programming pins of the microcontroller and allows firmware to be uploaded using standard ARM debugging tools.
This configuration establishes the minimal circuit required to power and program the microcontroller.

Heater Control¶
The Heater Control block defines the interface between the microcontroller and the heating system that will drive the Asfalt radiant hood.
A microcontroller output pin is routed through a series resistor to an external connector. This connector will later interface with a power switching stage such as a MOSFET driver or a solid-state relay controlling the heating element.
This configuration allows the microcontroller to send a control signal to the external power stage while protecting the MCU output pin.
A thermistor was also added in this section to allow temperature measurement. The thermistor forms a voltage divider with a resistor, producing an analog voltage that can be read by the microcontroller’s analog-to-digital converter.
This temperature measurement will later enable the system to regulate heating output and maintain safe operating conditions.
Sensor and User Interface¶
The Sensor + UI block introduces the first elements of system feedback.
A simple LED indicator and current-limiting resistor were added to provide a basic status output controlled by the microcontroller. This LED can be used during development to indicate system states such as power, heating activity, or debugging signals.
Additional user interface components such as buttons, displays, or communication modules may later be integrated in this section.
Current System Architecture¶
At this stage the schematic defines a minimal embedded controller architecture capable of supporting the Asfalt heating system.
The design currently includes:
- external 5V power input
- 3.3V voltage regulation
- ATSAMD21 microcontroller
- SWD programming interface
- heater control output
- temperature sensing input
- basic status LED
This is the basic structure of the Asfalt controller board and prepares the design for the pcb laoyour stage of development.

Asfalt Controller — PCB Layout Progress¶
The goal of this stage was to translate the logical schematic into a physical board layout that can eventually be fabricated in the Fab Lab milling workflow.
The PCB editor imports all components defined in the schematic and allows them to be arranged inside the physical board outline. At this stage the board outline was created as a simple polygon shape, reflecting the compact controller board that will eventually integrate into the ASFALT radiant hood system.

Initial Component Placement¶
Once the board outline was defined, the components from the schematic were imported into the PCB editor. KiCad automatically groups them outside the board area, where they can then be manually placed.
The initial layout strategy followed a simple architectural logic:
Center
The ATSAMD21E17A microcontroller (U1) was placed at the center of the board. This is the main processing unit and the node through which most signals will route.
Power section
The power input connector (J2) and the 3.3V regulator (U2) were positioned toward one side of the board to keep the power distribution path short and clear.
Programming interface
The SWD programming header was placed near the bottom of the board so that the debugger can be easily connected during development.
Heater control interface
The heater control connector and its associated components were grouped together to keep the high-power control circuitry isolated from the MCU core.
Sensor + UI components
The thermistor and LED components were positioned near the edge of the board so that they can later connect to sensors and indicators outside the controller.
At this stage the components remain loosely placed while the routing relationships between them become visible through the connection guide lines (ratsnest).

Routing Preparation¶
The blue guide lines shown between components represent the logical electrical connections defined in the schematic. These lines help guide the physical routing of copper traces on the board.
Before routing traces, components must be positioned in a way that minimizes crossing connections and keeps signal paths short. The placement process is therefore an iterative step where components are moved until the signal paths become simpler and more organized.
For this first pass, the layout focuses on keeping the following principles:
• microcontroller at the center
• power components close to the input connector
• decoupling capacitors placed close to the MCU power pins
• programming header accessible from the edge of the board
• sensor and heater interfaces grouped in separate zones
This structure reflects the same modular logic used earlier in the schematic.
Reference Layout¶
To guide the expected final structure of the board, an example PCB layout from a previous SAMD-based development board was studied. This reference layout illustrates several important design practices:
• central placement of the microcontroller
• symmetrical routing around the MCU pins
• short connections between power pins and decoupling capacitors
• clear separation between power, control, and I/O sections
• ground plane filling most of the board for signal stability
The reference layout provides a target structure for the ASFALT controller board as routing progresses.

Current Status¶
At this stage the PCB layout process has reached the following milestones:
• board outline created
• components imported from schematic
• first placement of MCU, power section, programming header, and peripheral connectors
• preliminary inspection of routing paths through the ratsnest connections
The board is now ready for the next steps of the layout workflow:
• precise component placement
• copper trace routing
• ground plane creation
• design rule checks
• export for fabrication
These steps will transform the logical controller architecture into a manufacturable board for the ASFALT system.
References¶
The development of the ASFALT controller electronics builds on a combination of Fab Academy knowledge, research on edge intelligence, and open tools developed within the Fab Lab network.
Key references include:
- Eric Pan – Fab Academy lecture on embodied AI and edge computing, which introduced the concept of computation as a physically embedded system operating close to sensors and actuators.
- Edge Impulse documentation and research papers on Edge AI, describing how machine learning models can run directly on microcontrollers and other constrained devices.
- Quentin Bolsee – SAMD development board documentation used as a reference for structuring the minimal circuit required to run an ATSAMD21 microcontroller and establish SWD programming.
- SVG-PCB design environment developed by Leo McElroy and Quentin Bolsee, explored as a workflow that links code and PCB design.
https://pcb.fabcloud.io/#/home - Fab Lab inventory (FabCloud) used for selecting components compatible with Fab Lab PCB milling workflows.
- RAGLAB repository used as a searchable internal knowledge base for Fab Academy electronics examples and design patterns.
Use of AI¶
Artificial intelligence tools were used during this week primarily as learning assistants, research aids, and documentation helpers.
An attempt was made to run the Mistral model locally within the RAGLAB environment in order to build a retrieval-augmented knowledge base using Fab Academy documentation and project material. This setup was not completed successfully because the computer crashed during model loading and indexing.
As a result, ChatGPT was used to assist with:
- interpreting Fab Academy electronics references
- exploring PCB design workflows
- structuring weekly documentation
- generating example prompts for experimentation with design tools
- discussing architectural approaches for the ASFALT controller electronics
Examples of prompts used during the week include:
Explain how to design a simple microcontroller board using SVG-PCB and how the generated design could later be recreated in KiCad.
Review Fab Lab inventory and recommend microcontroller options suitable for a smart heating controller with future expansion.
Explain how embodied AI and edge computing concepts apply to a microcontroller-based cooking tool such as ASFALT.
Guide the process of creating a minimal SAMD21 microcontroller board in KiCad including power regulation, decoupling capacitors, and SWD programming connections.
AI was used as a supporting tool for exploration and documentation, while the actual circuit design decisions and schematic development were carried out manually in KiCad.