Engineering Expertise

Firmware is where a hardware product’s behavior lives. Here is what drives embedded scope, what you should receive at the end, and how to evaluate a partner.

Embedded systems engineering is the design of the software that runs directly on a product’s hardware, usually on a microcontroller. There is no operating system built in like that of a desktop. It is what determines how the product behaves once it is switched on.

The mechanical design determines what a product can physically do. The electronics determine what it can sense and drive. The firmware determines what it does, under what conditions, and how it responds when something is wrong. It is also the discipline most often underestimated at scoping, because it is the least visible one at the start of a program.

This guide covers the firmware side of an integrated design. For how it sits alongside the mechanical and electrical work, see the complete guide to mechatronics engineering.

What Does Embedded Systems Engineering Cover?

The work spans more than writing code that runs on a chip, and the scope tends to surprise teams who have priced it as a single line item.

• Hardware bring-up. Proving each subsystem on a new board works, one at a time, before anything integrates.
• Driver and peripheral work. Making sensors, motor drivers, displays, and storage function reliably across their operating range.
• Control logic. The loops and state machines that decide what the product does with what it senses.
• Communications. Wired protocols such as SPI, I2C, CAN, UART, and RS-485, and wireless including Wi-Fi, Bluetooth, LoRa, and cellular.
• Update and recovery. How firmware gets onto the product in production and how it gets updated in the field without creating a device that cannot recover.
• Diagnostics. What the product reports when something goes wrong, which determines whether a field failure can be diagnosed remotely or requires a return.

The last two are the ones most often omitted from an early scope and most often needed later. A product with no update path and no diagnostics is inexpensive to develop and expensive to support.

What Drives Firmware Scope Up or Down?

Five factors drive embedded effort more than lines of code or feature count.

1. Control complexity. Reading a sensor and displaying a value is a different class of work from closed-loop control. Control loops carry tuning, stability, and safety obligations that scale with the consequence of the machine behaving incorrectly.
2. Real-time constraints. If something must happen within a guaranteed time window, the architecture, the scheduling approach, and the testing all change.
3. Communications surface. Every protocol the device speaks is a specification to implement, a set of failure modes to handle and a body of testing to perform.
4. Update strategy. Field-updatable firmware requires a bootloader, a delivery mechanism, version management, and a recovery path for interrupted updates. It is worth doing on most connected products and it is not free.
5. Safety and regulatory context. Products where failure carries physical consequence need failure mode analysis, defined safe states, and evidence that both were considered. Anything that transmits also needs FCC equipment authorization before it can be marketed in the United States, and that approval path is a schedule input rather than a schedule variable.

The update decision in particular deserves attention early, because retrofitting an update mechanism into a shipped product is substantially harder than designing it in. We have written separately about when to add firmware over-the-air updates to your project.

What Should You Receive at the End?

Embedded deliverables are easier to under-specify than mechanical ones, because firmware has no physical presence to inspect. Name each item explicitly in the statement of work.

Deliverable	Why it matters
Firmware source code	Without source you cannot maintain, extend or port the product. This should be named explicitly rather than covered by a general reference to design ownership.
Build environment and configuration	Source you cannot compile is not usable. Toolchain versions and build settings belong in the handover.
Programming and production procedure	How firmware gets onto units during manufacturing, including any required fixtures or test steps.
Protocol and interface documentation	What the device says, to what, and in what format. Needed by anyone integrating with it later.
Test evidence	What was verified and under what conditions, including edge cases and failure behavior.
Bootloader and update mechanism	If the product is field-updatable, the update path and its recovery behavior are part of the product.

Architecture Decisions That Are Hard to Reverse

A handful of early embedded decisions are inexpensive at the start and costly to revisit once the product is built around them.

1. Microcontroller selection. Memory, peripheral count, and processing headroom constrain everything downstream. Selecting a part with no margin means a later feature request forces a hardware change rather than a software one.
2. Bare-metal against a real-time operating system. Bare-metal firmware is simpler and more predictable at small scale. An RTOS handles concurrency more cleanly as the product grows. Switching between them mid-program is close to a rewrite.
3. Whether the product can be updated. Retrofitting an update mechanism into shipped hardware is substantially harder than designing it in, and the decision needs to be made before the bootloader and memory map are set.
4. Communication architecture. What talks to what, in which direction, and what happens when a link drops. Adding a protocol later is straightforward. Changing the model the whole system is built on is not.
5. Where state lives. Whether the device holds its own configuration, receives it from elsewhere, or both, determines behavior after a power cycle and after a failed update.

A partner who raises these during scoping is treating firmware as architecture rather than as a task list, which is the useful signal to look for in an early conversation.

How Embedded Work Interacts With the Board

Firmware and hardware constrain each other continuously, and the coupling is tighter than most program plans assume.

Pin assignment is a board decision with firmware consequences: peripherals are not interchangeable across pins, and a routing-driven pin choice can push a function onto a peripheral that cannot support it. Test points are a board decision that determines whether firmware can be debugged at all. Power architecture determines what low-power modes are achievable. Component selection determines which drivers exist and which have to be written from scratch.

This is why board and firmware work well as one workstream rather than two coordinated ones. Where they are split across organizations, the coordination cost lands during bring-up, which is already the least predictable phase of the program. The board side of this is covered in PCB design for custom products.

Security on Connected Products

Any product that connects to a network can be reached by someone you did not intend, and embedded devices have fewer defenses available than general-purpose computers do.

Four considerations cover most of it for a typical connected product. Firmware updates need to be authenticated, because an update path that will accept unsigned firmware is a way to replace the product’s behavior entirely. Credentials and keys need somewhere to live that is not plain flash memory readable over a debug port. Debug interfaces left enabled in production are a common and entirely avoidable exposure. And the communication itself needs transport security appropriate to what it carries.

None of this is exotic, and all of it is substantially harder to add after the architecture is set, particularly signed updates, which depend on decisions made in the bootloader. For products in regulated categories or deployed on client-partner networks, expect security questions during procurement rather than after, and expect to need documented answers.

The proportionate approach is to match the effort to the exposure. A sealed device with no network connection and no update path needs very little. A device that joins a corporate network and accepts remote updates needs all four addressed deliberately.

How to Evaluate an Embedded Partner

Six questions separate genuine embedded capability from board-level design with some code attached.

1. What have you shipped, and on what silicon? Specific platforms are more informative than a general claim of microcontroller experience.
2. How do you handle bring-up on a new board? A clear method here signals experience with the messiest phase of the work.
3. What is your approach to field updates and recovery? The answer reveals whether they have supported products after launch or only delivered them.
4. How do you test firmware? Look for something beyond manual bench checks, particularly for anything safety relevant.
5. Who owns the source, and when do we receive it? Ideally during the project rather than at the end.
6. Do your firmware and hardware engineers work on the same programs? Splitting them across organizations adds coordination cost precisely where iteration is most frequent.

Bravo Team develops firmware in C and C++ across platforms including STM32, PIC, and RP2040, with custom bootloaders, in-house board design, and on-site assembly. Board and firmware decisions constrain each other continuously, which is why both sit with the same team. The board side is covered in PCB design for custom products.

Production and Field Support

Embedded work does not end at a functioning prototype, and two downstream phases are worth scoping at the start rather than discovering later.

Production programming is the first. Firmware has to get onto units during manufacturing in a repeatable way, which usually means a programming fixture, a defined procedure, and some form of verification that the correct version was loaded. On a small run this can be manual. At volume it needs to be designed.

Field support is the second. When a unit misbehaves in service, what can you learn about it remotely? A product that logs its state and can report a fault code is diagnosable. A product that simply stops requires a return, an engineer, and a reproduction attempt. The difference is a design decision made early, and it has a direct cost consequence across the life of the product.

Neither of these appears in a feature list, and both appear in the total cost of owning the product.

The Underestimation Problem

Embedded work is consistently underestimated, and the reason is structural rather than careless.

Mechanical progress is visible. A model exists or it does not, a part is machined or it is not. Firmware progress is not visible in the same way, and the majority of the effort typically goes into the conditions that occur rarely: what happens when a sensor returns an implausible value, when a communication link drops mid-message, when power is removed during a write, when two events arrive in an order nobody anticipated.

That work rarely appears in an early estimate because it does not appear in the feature list. It appears in the schedule regardless. A partner who raises these cases during scoping rather than during integration is telling you something useful about how the program will run.

The same reasoning applies to operator-facing behavior, where a product that works correctly can still be difficult to use. We covered that in the hidden cost of bad HMI design.

How Bravo Team Approaches Embedded Development

Bravo Team develops firmware in C and C++ across microcontroller platforms including STM32, PIC, RP2040, and Teensy, with custom bootloaders and field-deployable remote firmware updates. Communication work spans wired protocols such as SPI, I2C, CAN, UART, and RS-485, and wireless including Wi-Fi, Bluetooth, LoRa, and cellular.

What matters more than the platforms and protocols is who sits next to whom. The engineers writing firmware work alongside the engineers laying out the board and the engineers designing the enclosure, in the same building, on the same program. Pin assignment, test point placement, power architecture, and component selection all get decided with the firmware consequences visible, rather than inherited after the fact.

“Bravo Team is able to rapidly develop products with our interdisciplinary approach. We have typically mechanical, electrical, software all under one team that is tasked with working on a project.”

Cody Orlovsky, PE, Co-Founder and Computer Engineer

That is why the bring-up phase, which is the least predictable part of an embedded program, tends to move differently when the board and the firmware came from one team.

Frequently Asked Questions

What is embedded systems development?

It is the design of software that runs directly on a product’s hardware, typically on a microcontroller. In a hardware product it determines what the device does, how it responds to sensor input and how it behaves when something goes wrong.

What is the difference between firmware and embedded software?

The terms are used almost interchangeably. Firmware usually implies software running close to the hardware with no full operating system beneath it. Embedded software is a slightly broader term that can include applications running on an embedded operating system.

Do I own the firmware source code?

You should, and it should be named as a distinct deliverable alongside mechanical CAD and board files rather than covered by a general reference to design ownership. Without source you cannot maintain or extend the product independently.

What drives the cost of embedded development?

Control complexity, real-time constraints, the number of communication protocols, whether the product needs field updates, and the safety or regulatory context. Feature count is a weaker predictor than any of these.

Do I need over-the-air updates?

For most connected products it is worth designing in, because retrofitting an update path into shipped hardware is substantially harder than including it from the start. For a sealed product with no connectivity and a stable feature set, it may not be justified.

Should the same firm do the board and the firmware?

It removes a coordination burden at the point where iteration is heaviest. Board and firmware decisions constrain each other continuously, from pin assignment through debugging, so splitting them across organizations tends to slow the loop.

How is embedded firmware tested?

Through a combination of bench testing on real hardware, automated testing where the architecture supports it, and deliberate fault injection to confirm behavior under sensor failure, communication loss, and power interruption. Ask any partner what their approach covers beyond manual checks.

Start the Conversation

If you are scoping a product where the behavior lives in firmware and want a realistic read on the effort involved, that conversation is worth having before the estimate is fixed. Bravo Team raises the update path, the diagnostics, and the failure cases during design rather than during integration, so a client-partner sees the real shape of the work before committing to a date. Schedule a discovery conversation.