Firmware that runs for years between power cycles
Microcontrollers are the right answer when Linux is too much: hard real-time control, battery operation measured in years, sub-dollar silicon, instant-on behavior. What this service removes is the failure modes that plague amateur firmware — devices that lock up until someone cycles power, batteries that die in months instead of years, and field units that can never be updated.
Willowark selects silicon for the job — peripherals, power budget, and longevity — and writes firmware with the discipline embedded work demands: defensive state machines, watchdogs that are actually fed correctly, and update paths designed before the first unit ships.
IoT & Smart SystemsHow the work gets done
The same way every time: scope, build, hand over.
Platform choice comes first: STM32 for rich peripherals and industrial temperature ranges, ESP32 where integrated Wi-Fi and Bluetooth earn their power cost, Nordic parts for low-energy wireless. Architecture follows the requirements — bare-metal, interrupt-driven loops for simple deterministic devices, FreeRTOS or Zephyr where concurrency justifies an RTOS. The reliability layer is not optional: independent watchdog timers, brownout detection, defensive handling of every bus error, and a DFU bootloader with rollback so firmware updates in the field cannot strand a device. Communications cover the industrial staples — CAN, RS-485 with Modbus RTU, I2C, SPI — and low-power designs are measured, not estimated, with sleep currents verified in microamps on the bench.
Before release, firmware goes through soak testing: days of continuous operation under power cycling, bus noise, and boundary conditions, because a bug that appears once a week per unit appears hourly across a fleet. Production units keep diagnostic access — a serial console or network log path — so field behavior can be understood without guesswork.
Early work happens on evaluation boards and off-the-shelf modules so the firmware can be proven before a custom board exists. A commercial radio module or a vendor dev kit on the bench answers the risky questions — does the protocol behave, does the power budget hold, does the sensor front end resolve what you need — for the cost of a few parts. Only then does the custom board get designed, and it inherits pinouts and a working firmware image from the prototype. That sequencing keeps the first board revision close to right, and short-run assembly of a small batch lets field trials start before production tooling is committed.
Everything needed to build, flash, and test the firmware is delivered as source in a repository you own: the code, the build system, unit and hardware-in-the-loop tests, and a documented toolchain so a new engineer can produce an identical binary years later. We avoid vendor-locked IDE projects where a plain build with a standard compiler will do. Handover includes the schematic and layout files, a bill of materials with alternates for the parts most likely to go scarce, production programming and test procedures, and a maintenance note explaining how to cut a new firmware release and push it through the bootloader safely.
Scope it in writing
What we agree before work starts
- Microcontroller selection and system architecture
- Production firmware with RTOS or bare-metal design as appropriate
Build with checkpoints
Working results, not slide decks
- Bootloader with safe field update and rollback
- Industrial communications: CAN, RS-485, Modbus RTU, I2C, SPI
Hand over something you own
Documentation, source, and training
- Power budget analysis with measured sleep currents
- Soak test results and diagnostic tooling
Sound familiar?
Where microcontroller systems earns its keep.
Battery-powered wireless sensor nodes with multi-year life
Motor, actuator, and valve control boards
Retrofit controller boards replacing obsolete electronics
Protocol bridges between legacy equipment and modern networks
Ask about Microcontroller Systems
Describe the problem. Get a straight answer.
One line is enough. An engineer replies within a business day.
Related work
Radar centering system for steel mills
Components:
- Radar sensors (strip position): Non-contact radar reading strip edge position in a hot, dusty, vibrating environment where optical sensors fail.
- Edge controller (signal processing): Turns raw radar returns into a clean lateral offset in real time.
- Mill PLC (centering actuators): The mill's existing controller: receives the offset and drives the centering actuators.
- Operator HMI (live position): Live strip position for the operator.
Connections:
- Radar sensors to Edge controller (raw returns)
- Edge controller to Mill PLC (offset)
- Edge controller to Operator HMI
A steel-mill systems provider · Steel manufacturing
Radar-based centering system for steel mills
End-to-end engineering of a radar sensing system that measures and centers material on steel mill lines — from equipment assessment through hardware selection, electrical engineering, software, installation, and commissioning.
Read the case study →Common questions
Asked before every microcontroller systems project.
ESP32 or STM32 — which is right for our product?
ESP32 wins when the product needs Wi-Fi or Bluetooth and can afford the power draw; the integrated radio saves cost and board space. STM32 wins on peripheral richness, low-power precision, industrial temperature options, and long-term part availability. Many products use both — an STM32 doing the real work with a radio module alongside. The requirements decide.
Can microcontroller firmware be updated in the field?
Yes, with a properly engineered bootloader. Updates arrive over the device's network link or a service port, install to a staging area, verify by checksum and signature, and roll back automatically if the new firmware fails to run. We build this before first shipment, because retrofitting an update path onto deployed units is somewhere between painful and impossible.
Do you handle the electronics, or firmware only?
Both. We design boards and firmware together — schematic review, hardware bring-up, and board-level debugging are part of the work, and firmware always goes better when the same team understands the circuit. If you have an existing board or an EE partner, we integrate with that arrangement too.
Can you work with firmware someone else wrote?
Yes. Inherited firmware is common — a departed engineer, a contractor, a vendor reference design that grew — and the first step is getting it to build reproducibly from source under version control. From there we fix the specific problems you are seeing, add the missing safety nets like watchdog handling and a proper bootloader, and improve structure only where it reduces risk. A rewrite is sometimes the honest recommendation, but usually it is not, and we will tell you which.
How do you handle parts shortages and end-of-life components?
By designing for substitution from the start. Where a family of parts exists — regulators, transceivers, memory — the footprint and firmware are chosen so a second source drops in, and the bill of materials lists approved alternates. For the microcontroller itself, we favor families with long-term availability programs and keep hardware access behind a thin abstraction layer so a pin-compatible or near-compatible part is a firmware port, not a redesign. We also check lifecycle status on key parts before a board is released.
Where this sits
Microcontroller Systems, inside a iot & smart systems system.
The whole system this service belongs to. Hover or focus a component to see what it is and what it talks to.
Hover or focus a component to see what it is and what it talks to. Arrow keys move between them.
Field sensors report through an edge gateway to a broker; a time-series store feeds dashboards, and rules raise alerts that reach a person.
Components:
- Sensors (field): Temperature, vibration, level, current — wired or wireless.
- Edge gateway (DIN rail): Reads the sensors, buffers when the link is down, speaks MQTT upward.
- MQTT broker: Pub/sub hub; many gateways, many consumers.
- Time-series store: Every reading, retained for the trend and the audit.
- Rules engine (thresholds): Thresholds, rates of change, missing-heartbeat detection.
- Dashboard: Live and historical views.
- On-call phone: The alert reaches someone who can act.
Connections:
- Sensors to Edge gateway over Modbus
- Edge gateway to MQTT broker over MQTT
- MQTT broker to Time-series store over MQTT
- MQTT broker to Rules engine over MQTT
- Time-series store to Dashboard over REST
- Rules engine to On-call phone over push
Strategy. Software. Systems.
Have a system that should exist?
Tell us what your operation is doing manually, what isn't connected, or what you're trying to build. We'll tell you plainly whether and how we can help.