Express Intervention

Embedded systems and IoT engineering, from firmware to monitoring.

Somewhere there's a box bolted inside a cabinet that nobody will open for years, and it has to do its job every single day without being asked. We write the software that lives inside a device like that and connects it to the rest of your business, and we hand it over tested on your hardware, with its source code and documentation.

Tell us about your device

The computer nobody looks at

An embedded system is a small computer sealed into a piece of equipment to do one job: a meter that takes readings, a controller that runs a production line, a box that watches a tank. There's no keyboard and nobody sitting in front of it. It boots on its own and has to keep going for years, often with less memory than one song on your phone takes up.

Firmware is the software living in there. It reads sensors, drives motors and relays, and keeps an eye on its own errors. Writing it feels nothing like writing an app, because every byte is a decision, and one more feature can cost you the room you needed to hold on to a reading. When the program hangs, there's nobody around to restart the machine, so how it recovers has to be in the code ahead of time. We love this work for exactly that reason. IoT, the Internet of Things, adds a network on top, so you can track, configure and update those devices from anywhere.

For that firmware, embedded C++ is what we'd propose first, and we have our reasons. It lets you decide exactly what sits in memory and when code runs, it's available on most microcontrollers, and it lets you build on the code you already have rather than start over. Rust comes in where it earns its place, such as a new network-facing component, as long as the chip supports it.

We're a French company, and we'll be straight about where we stop: what we write is software. Board design, power electronics, machine safety functions and certification are different trades with different responsibilities, and they need a separate scope and specialized partners. We'd rather tell you that in the first conversation than have us both find out halfway through the project.

Fig. 02Connected controller
Connected controllerCTRL / REV. AMCUCTRL / 24 V DC
Assembled

The enclosure and spacers support and protect the circuit. This model excludes power electronics.

Educational low-voltage controller: aluminium enclosure, PCB mounted on spacers, microcontroller, power supply, terminal block and network interface. This is not a manufacturing schematic.

From first boot to a fleet in the field

An embedded project has several layers, and you may not need help with all of them. You can hand us just one, like the firmware for a product your team otherwise owns, or the whole thing.

Firmware and embedded C++

We can write firmware in C++, with C when a driver or the chip vendor's kit calls for it and Rust where it helps. One habit we hold on to: code that touches the hardware stays apart from the device's logic. When a part goes out of stock and has to be replaced, most of the rework lands in that one area.

  • New firmware development
  • Taking over and stabilizing existing firmware
  • Embedded C++ firmware
  • Embedded Rust, where the target supports it
  • Drivers: the code that talks to each component

Microcontrollers and hardware resources

A microcontroller packs a small processor, its memory and its inputs and outputs onto one chip. Those are the pins it uses to touch the real world. Everything on it is budgeted. A memory leak you'd never notice on a laptop will eventually hang a device like this, sometimes weeks later, which is why it's so hard to catch. So we design the software around those limits and measure what it really uses on the target.

  • Microcontroller software design
  • Managing hardware resources and peripherals
  • Memory and performance optimization
  • Keeping power consumption in check
  • Hardware and software integration, working from your schematics and datasheets

IoT and connectivity

The network is going to drop at some point, and a well-written device expects that. It keeps working, sets its readings aside and sends them when the connection comes back, with nobody stepping in. We write that behavior, along with the gateway that links your machines to your network and your software.

  • Communication between devices
  • Gateways between machines and software
  • Defined behavior during network outages
  • Collecting the readings your devices send

Industrial protocols

A protocol is the language two pieces of equipment use to understand each other, and machines on the same floor rarely share just one. Our instinct is to start with what they already speak. Switching protocols because another one looks newer is expensive, and it often does nothing for the person watching those machines.

  • MQTT: lightweight messages from a device to a server, even over a shaky network
  • Modbus: reading and writing values on controllers, meters and sensors, an old and very common standard
  • OPC UA: structured data exchange between machines and software from different manufacturers
  • CAN: a shared cable that lets the electronic modules in a machine or vehicle talk to each other

Device security and remote updates

Pushing an update to a device sitting out in a field is scary, and it should be. If it dies halfway, the device may not boot again, and now someone has to drive out there, maybe once per device. A well-designed over-the-air (OTA) update keeps the old version next to the new one, so if the new version fails, the device returns to the previous one. Once that way back exists, you finally dare to ship fixes. Security belongs in the same conversation, and it comes down to two questions: who's allowed to talk to the device, and what software it agrees to run.

  • Over-the-air updates with rollback
  • Checking where an update came from
  • Device identity and encrypted communication
  • Fewer open doors on the device

Diagnostics and monitoring

When a device acts up on the other side of the country and has recorded nothing, all you've got is a secondhand story and a road trip. So we build in readable logs and monitoring software that respects a distinction people tend to skip. Sending the command to open a valve doesn't tell you the valve is open. A reading, a requested command and a state the device has confirmed are three different things.

  • Useful logs and error codes
  • Configuration and maintenance tools
  • Fleet monitoring with alerts
  • Defined behavior on reconnection

Firmware acting strange?

A device that reboots for no apparent reason, a bug that shows up once a week. We can debug that kind of problem remotely, depending on the access we can get and the hardware available. The scope is confirmed before work starts, and if yours needs the hardware in hand, we'll tell you. Fixed price, from €149 for a diagnosis. VAT not applicable, art. 293 B CGI.

Get an Express Intervention

From factory floors to measuring instruments

These are examples of what can be built in each sector, and they aren't a client list. Your equipment may look like one of them or like none of them, and that's where the conversation starts.

  • Manufacturing and industry

    Sometimes a person is still writing down values the machines could hand over on their own. A gateway can read them over Modbus or OPC UA and feed them to your software, without replacing those machines.

  • Automation

    The software for a control unit or a control sequence, with every state, error and recovery path written down before it can turn into a surprise. Machine safety functions stay outside this scope.

  • Connected commercial equipment

    You sell or lease a device, and your first sign of trouble is a customer on the phone. With the right firmware and a network link, you can track your fleet remotely, push an update and spot a problem without waiting for that call.

  • Electronics and smart devices

    Your team or a hardware design firm draws the board, and we write what brings it to life, from the first prototype that boots to a version you can maintain. We can add a configuration app if you need one.

  • Measurement systems

    A missed reading is rarely recoverable. An instrument or data logger can read its sensors on a schedule, hold on to the data through an outage and send it afterward, with logic designed to avoid duplicates and gaps in the series.

  • Vehicles and electric mobility

    One sector among the others, with languages of its own: firmware and CAN communication in a vehicle, and EV charger monitoring over OCPP, the standard protocol between a charger and its server.

C++ first, and good reasons to stray from it

The right language depends on your chip and the code you already have. We won't touch firmware that works just to try something newer.

  • C++

    What we'd propose first for firmware. You decide what sits in memory and when code runs, and it's available on most microcontrollers.

  • C

    It's still everywhere: in drivers, in chip vendors' kits, in existing code that needs picking up.

  • Rust

    A memory bug can sleep for months before it hangs a device. For a new component where that would be expensive, if the chip supports it, Rust has a real advantage: the compiler, the tool that turns code into a program, rejects a large share of those bugs up front.

  • MQTT, Modbus, OPC UA, CAN

    The languages your equipment speaks, picked based on what your machines already use.

  • Rust, Java or C# on the server

    For the monitoring software, where device data lands and becomes something your people can read.

From your schematics to firmware you can keep

  1. 01

    Learn the target

    We start by reading your schematics, datasheets and existing code. Then we pin down hardware access, resource limits and, above all, what the device should do when something goes wrong, a question that tends to get put off.

  2. 02

    Separate hardware from logic

    The architecture isolates hardware access, so part of the code can be tested without the board. That saves a lot of back-and-forth when boards are scarce or haven't been built yet.

  3. 03

    Prove it on real hardware

    Firmware that works when everything's fine hasn't proved much. We push it on the chosen hardware where it can break: errors, memory limits, network dropouts and updates, following scenarios agreed with you.

  4. 04

    Hand it all over

    As set out in the quote, you get the source code, the steps to rebuild the firmware, the validation scenarios, the diagnostic tools and the documentation. Firmware only its author can rebuild is a debt, and we don't want to leave you with it.

When the equipment drives or charges

A real server and a teaching model

Let's be clear about what you're looking at. This controller is an illustrative model of a low-voltage device. It's there to show how a device is organized, and it isn't a manufacturing schematic or customer equipment. The rest you can look up yourself.

Three ways to get going on your firmware

Firmware project

Roughly €5,000 to €30,000

Writing or taking over the firmware for a device, with source code, test scenarios and documentation. The exact price comes in a written quote, based on the hardware and scope. VAT not applicable, art. 293 B CGI.

Send a brief

Express Intervention

From €149

A remote diagnosis or debugging session on one specific problem, at a fixed price, depending on access and available hardware. VAT not applicable, art. 293 B CGI.

See Express Intervention

Senior consulting day

€900

A day to settle an architecture, protocol or language decision, or to get a firmware reviewed. VAT not applicable, art. 293 B CGI.

See the consulting day

Frequently asked questions

Yes, depending on what the project needs. Hardware access is agreed project by project: for example, a development board shipped to us or remote access to your test bench, if either option works for you. Part of the code can be tested without the board. Final validation has to happen on the real hardware, because a real chip does things no simulation will show you. We agree up front on who runs it and how.

No, and we'd rather say that right away. Codetics writes the software. Board layout, power electronics and manufacturing belong to your team, a hardware design firm or specialized partners. We work from their schematics and datasheets. Talking early about memory, inputs and outputs, and debug access can save you from respinning a board over a detail nobody thought of.

We don't keep a closed list. What really matters is that the chip has available documentation, a build toolchain and a way to debug it. If you've already picked one, name it in your brief and we'll tell you before any quote whether we can work on it. If the choice is still open, a consulting day is a good time to think it through together.

Codetics doesn't certify products and doesn't hold certifications of that kind. Machine safety functions and qualification testing need a separate scope and specialized partners. Our part is the software, tests and documentation that process will call for. Bring it up on day one: we need those requirements before the first line gets written, because finding them at the end can mean redoing a lot of work.

Yes, and that fear is healthier than it sounds. It often means the firmware works and nobody remembers why. We won't start by rewriting it, because that old code may hold years of fixes no one recalls making. We read it, find what makes it fragile, then add tests and diagnostic tools so it can be changed without breaking everything else. For a first answer on a specific problem, Express Intervention starts at €149 (VAT not applicable, art. 293 B CGI).
Software project

Tell us what your device does.

What it does, which chip it uses if you know, what's keeping you up. You don't need a spec. We'll reply with what we can do, what calls for a different specialist, and a price.

  1. 01You describe the need
  2. 02We clarify the scope
  3. 03You receive a detailed quote
Discuss a project

What do you need to ship?

Pick whatever comes closest. The brief opens on that subject, and we'll sort out the details together.

  • A clarified scope
  • A detailed quote
  • Direct contact with the engineer