Firmware that keeps your device working for years

You have designed a device, or you already have one. A sensor hanging in a greenhouse, a controller in a machine, a small box in the utility closet at your client. The hardware works on the bench. But the code on it grew out of example code from the chip manufacturer, and nobody dares touch it anymore. Every now and then the device freezes, and someone has to drive over to pull the plug. We write the firmware that makes your device do what it should, reliably, for years on end.

Firmware starts with failure behavior

Every microcontroller comes with example code. It is meant to show that the chip works, not to run for five years in a damp shed. It has no error handling, no watchdog, and no way to see what went wrong when the device stopped in the middle of the night. As long as you have one prototype on your desk, you barely notice. Once a hundred are out at clients, every freeze is a drive in the car.

We build firmware the way we build software: with a clear structure, with tests, and with log lines you can actually read later. The hardware drivers sit in a separate layer, so a different sensor or a new circuit board does not mean starting over. We make a deliberate choice between a bare loop, a small real-time operating system, or Linux on a module, depending on what the device has to do and how much power it may use.

Code that matches the hardware

We start with what the device has to do in practice, not with the chip. Which sensors do you read, how often, what happens during a power outage, and what must the device still do when the network drops? Then we look at the schematic and the circuit board. If that does not exist yet, we work on a development board with the same microcontroller and join PCB and electronics design, so what we discover in the software still makes it into the design.

Within ten business days, a first version runs that does the core of the device: measure, control, store, or send. Not a finished product, but something you can run in your own setup. You see right away whether the behavior is right and where it pinches. From that version we build on, function by function, and throw out what turns out to be unnecessary.

Tested on the real device

A device at a client cannot simply be restarted. That is why we build in a bootloader from the start that checks a new version first and falls back to the previous one if the new one does not boot. If the device is on a network, updates go over the air, in line with what we set up under IoT devices and sensors. If it is standalone, they go through a cable or a memory card a technician brings along.

Testing is not only checking whether the light comes on. We set up a bench that automatically pushes the firmware through the situations that matter: a sensor drops out, the power supply dips, the memory fills up. For a larger product, that grows into a full automated test system. And because we know what a certification will ask later, we already account for the requirements of CE and EMC certification while writing, such as the behavior after a reset or a disturbance on the power supply.

Source code you can maintain

Firmware that only compiles on one developer's laptop is a risk to your business. We deliver the source code, the complete build environment, and the documentation of the architecture and the hardware drivers. Anyone who comes after us can build and understand the code. You are not tied to us, not to one specific development environment, and not to a vendor that changes its license model.

Want more later? Image recognition or a small language model on the device itself we handle through Edge AI. A second circuit board, a different sensor, a new client request: the structure is already set up for it. And if the device does not exist at all yet, we start together with Hardware prototyping, and the firmware grows with every version of the hardware.