Embedded System Design: A Practical Guide for Product Teams

Embedded system design is the process of defining how a product’s electronics and firmware work together as one purpose-built computer: selecting a microcontroller (MCU) or system-on-chip (SoC), the peripherals and interfaces the product needs, how it manages power, and whether its firmware runs on a real-time operating system (RTOS) or directly on the hardware. It is an architecture discipline, settled before the schematic is final rather than discovered afterward.

These decisions depend on each other. An MCU’s pin count, peripheral set, and power modes limit what the firmware can do, and the firmware’s timing and memory needs limit which hardware configuration will actually work. A chip family, a bus assignment, or a decision to run a scheduler is cheap to change on a whiteboard and expensive to change once the PCB is routed and firmware has been written against a specific pin map. That contrast, early flexibility against post-layout cost, runs through every section below.

This guide stays at the architecture level, not firmware coding or physical board fabrication, which are separate disciplines; for the full stage-by-stage sequence from feasibility through production, see our hardware development process guide.

What Counts as the Core of an Embedded System

An MCU packages a processor core, a small amount of RAM, program memory (usually flash), and a set of peripherals onto a single chip, built to run one program and respond to physical events within predictable timing. Peripherals attached to that core do the physical work: reading a sensor, driving a motor, or talking to another chip. A SoC extends the same idea with more processing capacity, often multiple cores and larger memory, plus blocks for graphics or high-speed networking, usually paired with a full operating system such as Linux rather than a single firmware image.

• ADCs turn a sensor’s voltage into a number the firmware can use.
• Timers and PWM blocks generate precise pulses for motors or LEDs without tying up the core.
• Communication peripherals such as I2C, SPI, and UART controllers move data to other chips on the board.
• DMA controllers move data between memory and peripherals without the processor’s involvement.

Module, Custom PCB, or SoC: Choosing the Platform

Most teams are not choosing between a bare MCU and a bare SoC. The real decision is usually among three paths: a pre-certified module already containing an MCU or SoC plus RF circuitry, a custom PCB built around a chosen chip, or a mix of both across different boards in one product.

In our experience at Inventornest, we use an off-the-shelf module when it can meet the requirements and reduce development time, initial cost, and technical risk, particularly useful when validating a product before committing to production engineering. We consider a custom PCB when modules cannot meet the required dimensions, power consumption, interfaces, performance, or production cost. Volume alone does not determine the choice: a low-volume wearable may need a custom PCB because space is limited, while a higher-volume product may still benefit from an established module. We compare the additional development and validation cost of a custom PCB against the expected unit-cost savings over the planned quantity.

RTOS or Bare-Metal: Setting the Firmware Model

Bare-metal firmware runs a single loop, or a small set of interrupt handlers, directly on the hardware with no scheduler between code and processor. A real-time operating system such as FreeRTOS or Zephyr adds a scheduler that runs multiple prioritized tasks and lets firmware block on a timer or queue instead of polling it. Both are legitimate; the right one depends on what the product must do at once.

Whether a product runs a scheduler is a structural choice the hardware has to be built to support, not a detail to settle after the schematic is finished.

• Bare-metal tends to fit a single well-defined task loop, a tight RAM or flash budget, and no need for a standard network or security stack.
• An RTOS tends to fit several independent timing-sensitive activities, a need for connectivity or security libraries, or a team adding features without restructuring one main loop each time.

Memory capacity rules out options early: an MCU with too little RAM or flash can make an RTOS impractical, so the firmware model belongs in the same conversation as MCU selection, not after it.

Power Design Decisions That Shape the Board

Power design starts with a power budget: the current each mode draws and how long the product spends there. A device that sleeps most of its life and wakes briefly to transmit needs a different regulator and sleep strategy than one that runs continuously.

• Sleep and deep-sleep modes shut down unused clocks and peripherals, cutting draw to a fraction of active current.
• Peripheral power gating switches off an ADC or interface not in use rather than leaving it drawing current idle.
• Regulator choice trades simplicity for efficiency: linear is simple and quiet but wastes voltage as heat; switching is efficient but adds noise.
• Battery capacity should match the real duty cycle, not just the peak draw of the busiest mode.

In our experience at Inventornest, battery optimization can still create integration issues after the electrical side looks settled: increasing battery size requires additional internal space, and prototype sourcing can force its own compromises. Microchip’s low-power design patterns cover sleep-mode and peripheral-disable techniques in more depth.

I2C, SPI, and UART: Picking the Right Interface

Three serial interfaces appear on almost every board, trading wire count for speed.

UART is the simplest option for a direct link to a single device but does not scale to many devices on one bus. SPI gives up pin count for throughput, since each extra device typically needs its own chip-select line. I2C trades speed for pin economy, sharing two wires across many devices through the addressing scheme defined in the I2C-bus specification. A board with one high-speed display and six environmental sensors often uses both: SPI for the display, I2C for the sensor cluster.

Hardware-Software Co-Design, in Practice

Hardware-software co-design treats the circuit and the firmware as one connected decision instead of a relay race where the hardware finishes first and the firmware adapts to whatever it receives, an approach with a long history in the technical literature on hardware-software co-design, since a late-discovered mismatch is expensive to fix.

• An MCU without a hardware I2C peripheral forces firmware to emulate it in software, costing CPU time and power.
• A sensor wired to the wrong bus or missing an interrupt pin can force firmware to poll continuously instead of sleeping between readings.
• A missing pull-up resistor or a mis-assigned pin can turn a five-minute schematic fix into a firmware workaround that takes days.

Each becomes visible only when electronics and firmware are reviewed together, which is why this guide treats them as joint calls, not separate checklists.

A Practical Architecture Checklist for Product Teams

A workable embedded architecture usually clears these checks before a single PCB is routed:

1. Confirm the MCU or SoC has enough timers, communication peripherals, and GPIO for every planned sensor, with headroom for at least one addition.
2. Decide module versus custom PCB using the trade-offs above, rather than defaulting to whatever the last product used.
3. Settle RTOS versus bare-metal before production firmware is written; retrofitting a scheduler onto bare-metal code usually means a rewrite.
4. Draft a power budget by mode (active, idle, sleep) and size the battery against the real duty cycle.
5. Map every sensor to a specific bus, with its clock speed and pin count, before layout starts.
6. Build and test the riskiest assumption first, not the easiest one.

A short technical feasibility check before the architecture is locked catches most blocking constraints, such as an MCU that cannot meet a power budget, while they are still cheap to fix. Once the layout is settled, boards go through fabrication and assembly: etching and plating copper, then placing and soldering parts, a physical process covered in our guide to pcb fabrication and assembly, not here.

In our experience at Inventornest, we usually need two PCB development iterations, though depending on complexity and the issues found a project may require four or five, and revisions can involve both PCB changes and firmware updates when that falls under the project scope. Common products with established functions and few unique features can pass the first build without changes; issues that do appear often trace back to a component performing differently in the actual application than what its supplier claims. We also develop the PCB before finalizing the enclosure, so its dimensions and layout inform the enclosure design. A build that passes its first functional test has not yet established full production validation, and a prototype validation checklist that goes beyond confirming the main function once is what surfaces integration issues while they are still cheap to fix.

Frequently asked questions

What is embedded system design?

Embedded system design is choosing an MCU or SoC, its peripherals and interfaces, its power strategy, and its firmware model so electronics and firmware work together as one purpose-built computer, decided before the PCB and firmware are finalized.

What is the practical difference between an MCU and a SoC?

An MCU packages one processor core, a small amount of memory, and a set of peripherals for running a single firmware program with predictable timing. A SoC adds more processing capacity, often multiple cores and larger memory, and typically runs a full operating system for workloads like image processing or complex user interfaces.

Do I need an RTOS, or is bare-metal firmware enough?

Bare-metal firmware is usually enough for a single well-defined task loop with a tight memory budget. An RTOS such as FreeRTOS or Zephyr earns its overhead once a product has several independent timing-sensitive activities or needs standard connectivity and security libraries.

When should a product use a module instead of a custom PCB?

A module makes sense when it can meet the product’s size, power, interface, and cost requirements, especially for validating a product before committing to production engineering. A custom PCB becomes the better choice once a module cannot meet those requirements, regardless of planned volume.

How do I choose between I2C, SPI, and UART for a given sensor?

UART suits a simple point-to-point link to one device. SPI suits devices needing higher throughput with a dedicated chip-select pin to spare. I2C suits several lower-rate devices sharing limited pins through addressing. Many boards use more than one interface across the same design.

What does hardware-software co-design mean for a product team?

It means reviewing electronics and firmware together as one decision, instead of finishing the circuit first and asking firmware to adapt afterward. A pin assigned to the wrong peripheral or a missing interrupt line can force a workaround that costs far more than fixing the schematic would have.

Where Inventornest fits

The decisions covered here, MCU or SoC selection, module versus custom PCB, RTOS versus bare-metal, power budgeting, and interface choice, are what an embedded design engagement works through before a schematic is final. Inventornest’s PCB and embedded system design work starts from these same questions rather than treating electronics and firmware as separate hand-offs.

Teams weighing these trade-offs can look through Inventornest’s portfolio for examples of how MCU, SoC, and interface choices played out across different products, or book a consultation to work through a specific product’s architecture first.