NODOMIC

Hardware / Firmware & Embedded Software

Firmware & Embedded Software

Real-time firmware and embedded software for microcontrollers and connected devices, from first bring-up to a stable, field-ready build. On boards we design with you, or on hardware that already exists or is being built elsewhere. If the board still needs designing too, that is Embedded Engineering.

What we build

How firmware gets to field-ready

Bring-up is not a step you skip because the schematic was right.

POWER ON

rails, clocks, and whether the part is alive at all

ONE AT A TIME

each peripheral proven alone before anything is integrated

DRIVERS

the sensor talked to properly, not by pasting an example

TIMING

the part that decides whether the data means anything

SOAK

left running for days, because the interesting failures are slow

FIELD IMAGE

what ships, with the debug paths still reachable

Stages two and five are the first to go when a schedule slips, and they are the two that decide whether the device survives its first month in the field.

Run on hardware we designed

Most embedded software is written by software teams that occasionally take on a hardware project. We are the reverse.

An acquisition board on a microscope stage during bring-up, a test probe touching one pad, a status LED lit, with a bodge wire and kapton tape from an earlier fix
Bring-upA board mid-debug: probe on the pad, status LED alive, and the bodge wire from the last thing we got wrong.
An oscilloscope showing two clock signals, one yellow and one blue, running in step after fifteen metres of cable between two sensor nodes
Timing, provenTwo nodes on one sampling clock after fifteen metres of ordinary cable.

The firmware on our own sensor nodes was written here, for boards designed here. It captures eight audio channels against a single sampling clock, does the processing on the device, and holds a second node in the same time domain over ordinary cable. None of it came out right the first time.

That is the part worth hiring for. Firmware that compiles is not an achievement. Firmware that still behaves on the two hundredth power cycle, in the cold, on a marginal supply, with a sensor that occasionally lies, is a different thing. It is reached by bringing the board up subsystem by subsystem, measuring instead of assuming, and writing down what the bench showed, including the findings that meant another board revision.

Very few products ask for eight channels in lockstep. They ask for a device that runs for a year on a battery, survives a cabinet in August and takes an update without a field visit. That is the same engineering, with more room.

See what it was measured doing →

What the work usually involves

Bring-up and board debug

First power-on, rails and clocks checked against the design, then each peripheral proven on its own. Where the board is wrong, we find it here rather than in the field.

Drivers and acquisition

Sensors talked to properly: register-level initialisation, the timing the datasheet actually requires, calibration, and a data path that does not drop samples under load.

Timing and synchronization

One sampling clock for every channel, and separate devices kept in one time domain. This is where multi-sensor products are won or lost.

Signal processing on the device

Filtering, spectral work, detection and estimation inside the power and latency budget of the microcontroller, rather than on a server.

Real-time and embedded Linux

Where the device is big enough to warrant it: kernel and userspace, device tree, boot and update strategy, and real-time paths that stay real-time.

Power behaviour

Duty cycling, sleep states and wake sources designed alongside the electronics, so battery life is a number rather than a hope.

Device to cloud

Transport, buffering and reconnection written on the assumption that the link will fail, because it will. And the service on the other end, when you need it.

Reliability over time

Watchdogs, error paths, and the failure modes that only appear after a week of running. Soak testing before shipping, not after.

Updates and recovery

Firmware that can be replaced in the field, and that comes back from a failed update rather than needing somebody on site with a programmer.

How engagements usually start

The decisions that cost you a year later (part choice, interfaces, update path, how the device is tested) are made in the first weeks.

  1. 01

    Read the hardware first

    Schematic, board, datasheets and whatever firmware exists. Before estimating anything, we want to know what we are actually being handed, and where a pin choice or a part will cost you in firmware later, we say so early.

  2. 02

    Bring-up or takeover

    Either a new board that has never run code, or an existing codebase that outgrew whoever wrote it. Both are normal; the second is more common.

  3. 03

    Make it measurable

    Instrumentation and tests that tell you whether the device works, rather than an impression that it seems to. This is where most embedded projects are quietly weakest.

  4. 04

    Harden and hand over

    Field conditions, edge cases, the update path, and documentation written as we go, so the work does not depend on us being available forever.

Related

PCB Design

When the board itself needs designing: schematic capture and layout.

Connected Device Development

When the device needs the service behind it: one product across all four layers.

Firmware that has to work unattended?

Send the board, the schematic, the repository or just the constraints, whichever exists. You get an honest read on what the part can do, what the timing allows, and where the risk actually sits.

Discuss a project →