Embedded Firmware in Rust

Firmware that works, and stays maintainable

Firmware is the invisible foundation of your smart product. It's essential that you can trust your firmware. This starts with a solid architecture, strong tooling, and deliberate technology choices.

PCB with JLink debugger connected

The challenge

With existing firmware

  • Your firmware works, but making changes feels risky
  • Bugs and crashes that are hard to reproduce
  • Knowledge sits with one person (or has disappeared)
  • Further development takes more and more time

For new projects

  • You want to lay a solid foundation from the start
  • You want an architecture that can grow with you
  • You want to iterate quickly without instability
  • You want firmware that is transferable

We build firmware you can build on. Literally.

What we do

New firmware

From scratch, on your hardware or on a platform we choose together. Clean architecture, built to grow with you.

Firmware with PCB design

We also design hardware. When we do both, they're aligned from the start.

Firmware on existing hardware

You already have a PCB, your own or from a third party. We write the firmware that runs on it.

How we work

Requirements specification

Together we define the requirements: what should the system do, under what conditions, and what are the boundaries? This guides all decisions that follow.

Architecture

We start with a clear software architecture: which tasks does the system run, how do they communicate, and where are the boundaries? This prevents spaghetti code and makes your firmware extensible. For more complex projects, we use async Rust and the actor model to cleanly delineate functionality and responsibilities.

Example of a firmware task architecture
Click to enlarge

Setting up the development environment

We set up a complete development environment: a working Blinky or Hello World! as a starting point, flashing tools, CI workflows with automated tests, and a clear project structure. So your team can be productive from day one.

JLink debugger connected to a PCB Rust firmware in VS Code

Tests and code reviews

Every change is tested and reviewed. This catches issues early and keeps quality high, even as the project grows.

Automated tests in GitHub workflows

Knowledge transfer

Documentation makes or breaks the future of the project. We document the things that matter: how to build the firmware, which configuration is important, how to connect the debugger for flashing, how the architecture is structured, and how firmware updates work in the field.

Example of documentation
Click to enlarge

What you get

  • Firmware that does what it should, reliably
  • Code that is readable and maintainable
  • Documentation that helps your team move forward
  • Optional: guidance for further development yourself

Prefer firmware in C?

That's possible too. We have extensive experience with C on embedded.

To be honest: a C project typically takes more time than the same project in Rust. Not because we know C less well, but because it requires more discipline and testing to achieve the same quality. That's reflected in the price.

Do you have an existing C codebase you want to extend or maintain? Then C is often the logical choice. For new projects we recommend Rust, but the choice is yours.

About us

Jitter B.V. has been developing firmware for embedded systems for over ten years, five of those in Rust, primarily on STM32. Our embedded engineers have gone through the learning curve and know where the pitfalls are. We put that experience to work for your project.

Frequently asked questions

What does firmware development cost?
That depends on the complexity and scope of your project. A simple firmware project starts around €5,000, while more complex projects with multiple interfaces, protocols, or certification requirements can cost €15,000 to €40,000 or more. After a no-obligation intake meeting, we provide a quote per project phase, so you know upfront what to expect.
How long does a firmware project take?
A small firmware project can sometimes be done within 1 to 2 weeks. Larger projects with multiple iterations, hardware integration, and field testing can take 3 to 6 months. Firmware development often runs in parallel with PCB design. We provide a realistic timeline at the start.
Why Rust instead of C?
Rust prevents entire categories of bugs at the compiler level that are common in C: null pointers, buffer overflows, race conditions, and use-after-free. That means less debugging, more stable firmware, and faster turnaround. Rust also offers modern tooling for dependency management, testing, and CI. We've been working with Rust on embedded for over five years and are more productive in it than in C.
Can I maintain the firmware myself later?
Yes, that's an explicit goal. We document the architecture, the build environment, and the development workflows. The code is readable and structured so your own team can continue with it. If desired, we also offer guidance and knowledge transfer.
Do you also work with existing C codebases?
Yes. We have extensive experience with C on embedded. Do you have an existing C codebase that you want to extend or maintain? Then C is often the logical choice. For new projects, we recommend Rust for its higher quality and productivity, but the choice is yours.
How do firmware updates work in the field (OTA)?
OTA (Over-The-Air) updates make it possible to update firmware remotely, without needing physical access to the device. We implement this with a secure bootloader that verifies the integrity of the update before applying it.
What exactly is firmware?
Firmware is software that runs directly on a microcontroller or processor, close to the hardware. It controls sensors, communication interfaces, actuators, and other peripherals. Unlike 'regular' software on a computer or phone, firmware has direct control over the hardware and often runs without an operating system.
What's the difference between firmware and software?
Firmware runs directly on the hardware (microcontroller) and has direct control over physical components like sensors and motors. Software runs on an operating system like Windows, Linux, or Android. The distinction isn't always clear-cut: embedded Linux systems sit somewhere in between. At Jitter, we use 'firmware' for anything that runs bare-metal or on an RTOS.
What is an RTOS?
RTOS stands for Real-Time Operating System. It's a lightweight operating system for microcontrollers that can execute tasks with strict timing guarantees. Think of reading a sensor exactly every millisecond, or responding to an interrupt within a fixed deadline. Well-known examples are FreeRTOS and Zephyr. In our Rust projects, we often use RTIC or Embassy, async frameworks that offer similar functionality without the overhead of a traditional RTOS.
What is bare-metal firmware?
Bare-metal means the firmware runs directly on the microcontroller, without an operating system in between. Your code has full control over the hardware. This delivers the lowest latency and smallest memory footprint. For simpler systems, bare-metal is ideal. For more complex systems with many parallel tasks, we prefer an RTOS or async framework.
What does 'embedded' mean?
An embedded system is a computer built into a larger device that performs a specific task. Think of the electronics in a washing machine, a medical device, or an industrial sensor. Unlike a general-purpose computer, an embedded system is designed for a single purpose, with constraints on memory, processing power, and energy consumption.

Facing a firmware challenge?

Get in Touch