Hire a freelance embedded engineer

Almost all of it is still written in C, with C++ increasingly common where the compiler and the flash budget allow and where a class per peripheral makes a large codebase survivable. The language is the easy part. What distinguishes an embedded engineer is everything around it: reading a datasheet and a reference manual rather than a tutorial, understanding what the hardware does while the CPU is asleep, knowing which of the chip vendor’s libraries can be trusted and which are a trap, and being able to put a scope or a logic analyser on a bus and find out why a sensor is returning zeros.

Two architectural choices shape every project. Bare-metal means a main loop plus interrupt service routines — small, predictable, cheap in memory, and perfectly adequate for a device doing three things. An RTOS such as FreeRTOS or Zephyr buys you tasks, priorities, queues and timers, which is what you want once there are concurrent responsibilities — radio stack, sensor sampling, display, logging — and it brings its own problems with it: stack sizing, priority inversion, and bugs that only appear under a particular interleaving. An engineer who can argue for either choice on the merits of your device is worth more than one who always reaches for the same answer.

Then the parts clients forget to ask for. A bootloader, so the product can be updated after it has shipped — and with it the question of whether updates are delivered over USB, over the air, or from an SD card, whether an image is signed and verified, and whether a failed update leaves a brick or rolls back. Low-power design, where the battery life on the datasheet is decided by how long the microcontroller spends in its deepest sleep state, not by how fast the code runs. Production support: a test fixture, a way to program and calibrate at end of line, serial numbers and keys. None of these are optional on a real product, and all of them are cheaper designed in than retrofitted.

Bring-up deserves its own mention, because it is where firmware and hardware stop being separate projects. The first boards back from the fab are where schematic errors, swapped pins, bad decoupling and optimistic crystal choices surface, and the person debugging them needs to be comfortable saying the hardware is wrong. If your board has not been built yet, an engineer who has done bring-up before will also review the schematic — which is the cheapest engineering you will buy on the whole project.