Embedded systems and firmware

The equipment is there, but it's "mute": data isn't collected, devices aren't connected, diagnostics are done by hand. Finding a team that understands both hardware and code is next to impossible. We cover exactly that seam — from firmware to a system that shows you the data off your devices.

Firmware and drivers for microcontrollers and ARM. Data collection from sensors and equipment. Communication protocols and integration with higher-level systems. Device monitoring and diagnostics. Optimization for tight memory and power budgets.

Embedded development lives at the seam between two worlds: you have to understand the hardware (memory, power, and real-time constraints) and at the same time write reliable code that runs for years without a reboot. A web developer can't carry this, and a "hardware person" rarely takes the data all the way to a system and a dashboard. Keeping both skill sets in-house is nearly impossible — which is why we match specialists to your specific platform and protocol and own the entire data path as one team.

C/C++, Rust, assembly; ARM, microcontrollers; IoT protocols (MQTT, Modbus, proprietary); integration with cloud and on-premise. Language and platform are chosen for the task and the hardware constraints. (see the matrix: Services)

We work by the "10% Path," as in the rest of our development: the task assessment, concept, and a working prototype are on us; the first working result (MVP) is 10% of the agreed estimate; then stage by stage. For hardware, the first stage often includes checking which signals can even be pulled off the device. Details — how we work.

The typical architecture we build to make "mute" equipment start giving up its data:

1. Sensor / device — captures a physical reading (temperature, vibration, a counter, a state).
2. Firmware — digitizes, filters out noise, packages it; operates within tight memory and power limits.
3. Gateway — collects data from several devices, buffers it when the link drops, transmits it over a protocol (MQTT/Modbus/proprietary).
4. Server / cloud — ingestion, storage, stream processing, threshold-based alerts.
5. System / dashboard — equipment status in real time, history, predictive diagnostics; integration with your accounting.

Key design decisions: what to compute on the device versus on the server; how to behave when the link is lost (buffering at the gateway); how to avoid draining a battery-powered device with unnecessary transmissions.

A company has bought standalone metering devices (say, meters or sensors at remote sites), but readings have to be taken by hand, driving from point to point. Here's how we usually handle it: a free assessment — which controller and protocol are inside, what can be read → firmware to digitize and package the readings → economical transmission over the link so the battery isn't drained → ingestion on the server and automatic collection of readings. The goal is to drop the manual rounds and get the data off the devices by itself. A close industry example with a production line is on the manufacturing and IoT page.

A working "equipment → data → system" chain, the firmware source code and the rights to it, and documentation of the protocols and architecture. No technical lock-in to us: from there the system can be developed by your own team or with us.

• Will you connect our equipment to our accounting system? Yes — that's a typical task: from firmware to integrating the data into your system and dashboard.
• Our equipment is old and "closed" — is it really possible to pull data off it? Often yes: in the free assessment we evaluate which signals are available and how to read them safely.
• Do you work with rare platforms and protocols? Yes — language, platform, and protocol are chosen for the task, all the way down to assembly and proprietary protocols.
• Is payment the usual way? Yes — the 10% Path: assessment, concept, and prototype on us, MVP at 10%.