IoT nodes
Sensor-to-cloud firmware handling connectivity, telemetry and OTA updates.
Firmware Design Services for ESP32 & STM32
Firmware design services covering C/C++ development for ESP32, ESP32-S3, STM32 and Arduino-compatible hardware — the drivers, protocols and application logic that make a board actually do something.
Overview
What this service covers
Firmware sits alongside PCB design as one of the two core engineering disciplines behind every product we build — and it gets its own page here because it's often the harder half of the job. We write embedded C/C++ for ESP32, ESP32-S3, STM32 and Arduino-compatible targets: sensor drivers, communication protocols, power management and the application logic that ties them together, developed and debugged on real hardware rather than left as a simulation.
Client Problems
Problems this service solves
- Hardware is built but there's no firmware for it yet.
- Existing firmware is unstable, undocumented, or was written by someone no longer available.
- A board needs a new communication protocol or sensor driver added.
- Firmware works on the bench but behaves inconsistently once it's actually in the field.
- A product needs OTA updates added after shipping without them.
Capabilities
What we do
- Embedded C/C++ firmware architecture
- ESP32, ESP32-S3, STM32 and Arduino-compatible firmware
- Device drivers for sensors, displays and motor controllers
- Communication protocols: SPI, I²C, UART, CAN, RS-485, BLE, Wi-Fi, LoRa
- MQTT integration for cloud-connected devices
- Device provisioning: unique credentials and per-unit configuration at flashing time
- State-machine based application logic
- Hardware-in-the-loop debugging, not just simulation
- Firmware optimisation for power and memory-constrained targets
- Secure OTA (over-the-air) update support
- Production flashing and test-jig support for manufacturing runs
Technologies
Tools & platforms
We build on the Espressif IDF and Arduino frameworks for ESP32/ESP32-S3, and STM32 HAL-based development for STM32 targets, with JTAG/SWD hardware debugging used to diagnose issues that only show up on the actual board.
ESP-IDFArduino FrameworkSTM32 HALBLE / Wi-Fi / LoRaMQTT
Development Process
How we approach a firmware project
- 01Requirements & interfaces
Confirm what the firmware needs to do and which peripherals/protocols it touches.
- 02Architecture & drivers
Design the firmware structure and the drivers it depends on.
- 03Implementation
Write and unit-test the firmware against the target hardware.
- 04Field validation
Debug on real hardware and confirm behaviour under actual operating conditions.
Deliverables
What you receive
- Firmware source code
- Build and flashing instructions
- Protocol and interface documentation
- Debugging and test notes
Testing & Validation
How firmware gets validated before delivery
Firmware is tested against the interfaces and conditions it actually has to run under, not just against a simulator. That means exercising each communication protocol against its real peripheral, confirming behaviour at power-up and after a brownout or reset, and checking OTA update and rollback behaviour before anything ships. Where a test jig or a set of test points is useful for production flashing and functional test, we design that into the process rather than treating it as an afterthought.
Getting Started
Information we need from you
To scope a firmware project accurately, it helps to know: what the device needs to do, the target MCU or a rough idea of the candidate hardware, which peripherals and communication protocols are involved, any power or memory constraints, and whether OTA updates or production flashing/test support are part of the scope. Existing schematics, datasheets or reference code are useful if you have them, but not required to start the conversation.
Applications
Where this is used
Industrial controllers
Firmware for automation hardware talking RS-485/Modbus on a plant floor.
Wireless & RF nodes
LoRa and UWB firmware for long-range telemetry and indoor positioning.
Hardware + Firmware
Why PCB and firmware co-development reduces risk
Firmware and PCB layout depend on each other more than a typical project plan admits. A pin assignment that looks fine on the schematic can make a communication protocol awkward to implement cleanly in firmware, and a firmware architecture decided in isolation can demand hardware changes once real timing or interrupt behaviour shows up on the bench. Designing both together means these conflicts get caught during schematic review, not after boards come back from manufacturing — a meaningfully cheaper time to fix them.
Related Services
Often paired with
PCB Design
The board this firmware runs on.
ESP32 & UWB Development
ESP32-specific firmware, ranging and wireless connectivity.
IoT Product Development
Firmware as part of a complete connected product.
Want more background first? Read Firmware Development Best Practices for Reliable Embedded Systems.
How We Can Help
How PAK-EL LAB Can Help
If your product needs embedded firmware — new development, a fix for unstable code, or OTA and provisioning added to something already shipping — our team can help with the firmware itself and, where useful, the schematic design, PCB layout, component selection and prototyping around it, since firmware rarely stands alone from the hardware it runs on. Scope, deliverables, schedule and quotation are confirmed after we've reviewed your specific requirements; every project's constraints on hardware, timeline and budget are different enough that a generic estimate isn't a useful starting point. We work with clients internationally and collaborate remotely as standard practice.
See also: Portfolio · PCB Design · Contact
FAQ
Frequently Asked Questions
Which microcontrollers do you write firmware for?
ESP32, ESP32-S3, STM32 and Arduino-compatible targets are our main platforms — we'll confirm fit during scoping if your hardware uses something else.
Can you add OTA updates to firmware that doesn't have them yet?
Yes, retrofitting secure OTA update support onto an existing, already-shipping product is common work, not just something built in from day one.
Do you write firmware without being involved in the PCB design?
Yes, we take on firmware-only projects against hardware you've already designed or had built elsewhere, alongside full PCB-and-firmware projects.
What if our existing firmware is unstable or undocumented?
Reviewing and stabilising existing firmware — including code left behind by a previous developer — is a common starting point, not a blocker.
Discuss Your Firmware Requirements
Send your hardware details and what the firmware needs to do.