Hardware Architecture

Introduction

Hardware architecture describes how the physical parts of your embedded system connect: the microcontroller, sensors, actuators, power supply, and the wires or buses between them. Before you write firmware or connect to a network, you need a plan for what sits on the breadboard and which pin each component uses.

Good hardware architecture prevents common student project failures: GPIO conflicts (two devices on the same pin), brownouts (motors starving the MCU), and logic-level mismatches (e.g. 5 V signals into a 3.3 V I/O pin). It also produces artifacts — a pin map and wiring diagram — that teammates and future you can follow.

This article covers the MCU as the central hub, planning inputs and outputs, serial buses, and power distribution. Pair it with Basics of electronics for component theory, Microcontrollers overview for MCU families, Voltage level shifting when mixing 3.3 V and 5 V parts, Motors and actuators and Distance sensors for robotics I/O, and Lab tools for prototyping for bring-up debugging.

The microcontroller as hub

The microcontroller (MCU) is the brain of the system. Whether you use an Arduino Uno, an ESP32 DevKit, an STM32 Nucleo, or another board, every sensor and actuator connects through the MCU's peripherals:

• GPIO pins — digital input/output, often PWM or touch — see Pulse width modulation
• Analog inputs (ADC) — variable voltages from potentiometers or analog sensors
• Serial buses — I²C, SPI, UART for modules that need more than one wire

Before wiring, draft a pin map: a table listing each component, which pin or bus it uses, and whether the connection is input, output, or bidirectional.

Example pin map (fragment):

Cross-check every pin against your board's pinout diagram and datasheet. Some pins are reserved for programming, crystals, or boot configuration — avoid them unless the documentation says they are safe for general I/O.

Keep heavy loads off the MCU's onboard regulator. Motors, servos, and large LED arrays need a separate supply with a common ground tied to the MCU.

Inputs and outputs

List every input and output your application needs before shopping or soldering. Group them by role:

• Sensing — temperature, light, distance (Distance sensors), presence, acceleration
• Human interface — buttons (Debouncing inputs), potentiometers, encoders, touch
• Indication — LEDs, OLED/LCD screens, buzzers
• Actuation — motors, servos, relays (Motors and actuators)

Prototype before integrating

Test each component on a breadboard with a small bring-up program before merging everything into the full firmware. Cheap module boards (e.g. KY-series) are fine for learning, but:

• Pin labels on the PCB may not match online tutorials
• Example code written for one board must be adapted to your pinout and logic voltage
• Multi-function modules (e.g. DHT11 for temp + humidity) still count as one physical device on the bus

Buses and peripherals

When several devices share a bus, plan addresses and chip-select lines up front.

I²C tip: Two devices with the same address cannot share the bus without a multiplexer. Check addresses in datasheets before wiring.

SPI tip: Only one slave's CS line should be LOW at a time during a transaction.

Add bus assignments to your pin map alongside direct GPIO connections.

Power architecture

Power distribution is part of hardware architecture, not an afterthought.

Supply and rails

• Identify the power source: USB, wall adapter, battery pack, or bench supply.
• Route Vcc and GND through breadboard power rails — do not feed every component from MCU pins.
• Use red wire for positive and black for ground. If you run both 5 V and 3.3 V, use a third color for one rail.

Decoupling and noise

• Place a 100 nF ceramic capacitor close to the MCU power pins.
• Add a larger electrolytic (10–100 µF) on the board's main power input when motors or radios are present.
• Separate noisy loads (motors, relays) with their own supply; tie grounds together at one point.

Current budget

Estimate total current draw. The onboard regulator on a DevKit can supply only a limited amount of current to peripherals. Sum LED, sensor, and module consumption; use an external regulator or supply when in doubt.

Block diagram vs pin map

A block diagram shows subsystems at a glance (MCU, sensor block, display, power). A pin map lists every connection in detail. You need both:

The block diagram answers "what major pieces exist?"; the pin map answers "which wire goes where?". See Documenting your design for how to include these in your project docs.

Relevant topics

• Embedded system architecture
• Basics of electronics
• Voltage level shifting
• Motors and actuators
• Distance sensors
• Lab tools for prototyping
• Microcontrollers overview
• Reading datasheets

Starting points

1. List every sensor and actuator your application needs; mark each as GPIO, I²C, SPI, or UART.
2. Draw a draft pin map before touching wires; resolve conflicts on paper first.
3. Wire and test one input (e.g. button or LDR) and one output (e.g. LED) — confirm levels and pull resistors.
4. Add power rails to the breadboard; connect the MCU's Vcc and GND to the rails before adding components.
5. Expand one bus device at a time — e.g. get I²C OLED working alone, then add a second I²C sensor.

Focus points

• Pin map before wiring — changing pins in software after the breadboard is full costs time.
• Common ground — all supplies and modules must share the same ground reference.
• Power from rails — components draw from Vcc/GND rails, not star-wired from GPIO pins.
• Verify logic levels — match sensor output voltage to what your MCU inputs tolerate.
• Label wires in your diagram — red/black discipline saves debug sessions.
• Heavy loads off the MCU regulator — motors and many LEDs need their own supply.
• Reserved pins — check your board's pinout for programming, power, and special-function pins before assigning GPIO.

Key points

• The MCU is the hub; every peripheral connects via GPIO or a serial bus.
• A pin map prevents conflicts and documents your design for firmware authors (including future you).
• I²C, SPI, and UART each have wiring rules — plan addresses and CS lines early.
• Power architecture — rails, wire colors, decoupling, and current budget — belongs in hardware design from day one.
• Prototype components individually before integrating the full system.