Firmware Development ServicesFirmware That Runs On Real Hardware

• Hardware companies whose products carry a microcontroller and need complete firmware - from MCU selection and peripheral drivers to system integration - not a sample driver.

• Clients whose board is fixed but who lack a firmware team: hardware and BOM are frozen, and someone needs to take the firmware to delivery.

• Clients whose product must pass FCC or CE certification, where RF and power-related firmware decisions need to leave margin for certification early on.

• Clients for whom diagnosing devices is expensive, and who want a supplier that opens the firmware to find the fault rather than relaying the symptom.

This page covers three MCU families: STM32, ESP32 and BLE MCUs, on FreeRTOS or bare metal. Delivered projects also include AVR: the microscope motorized stage runs on an ATMEGA32U4, and the smart finger servo control system is built on Arduino and AVR. When the MCU has not been chosen, selection is part of the service - chips are picked for the product's needs, not for whichever dev board the team knows best.

The STM32 PLC industrial control system is the representative STM32 project. It drives the hardware through the STM32F407 HAL library, uses FreeRTOS for multi-task real-time scheduling, records data to SD card at high speed through the FatFS file system over SDIO, expands runtime memory with external SRAM, and uses UART for industrial communication. On the STM32F407 three requirements had to hold at once: real-time scheduling without missed tasks, FatFS running long-term without failure, and SDIO recording at speed without dropping data. The difficulty in STM32 firmware development is never blinking an LED; it is keeping real-time behaviour, file system stability and fast peripherals from stepping on each other.

The ESP32 air quality collector is the representative ESP32 project. The ESP32 board drives several air quality sensors, fuses their readings, and uploads the result over WiFi for environmental monitoring. The difficulty is not reading one sensor but fusing several and keeping WiFi transfer reliable - those two concerns set the firmware architecture. Environmental monitors often run in the field for long periods, so the reliability of the link directly decides whether the data is complete.

BLE MCU firmware is within this service. BLE devices are mostly battery powered, and sleep current, connection interval and advertising duty cycle fix the battery life at the firmware architecture stage, leaving little room to recover later. The core BLE trade-off is that frequent communication gives good responsiveness at a power cost, while longer intervals save power at the expense of experience. There is no general answer to this; it has to be calculated from the product definition.

For Bluetooth we work across Nordic nRF52 and nRF53, JL7018 and WCH CH58x/CH59x - from the premium end to cost-optimised domestic parts - and choose on requirements, not on which part the team happens to know best.

FreeRTOS is not the default, and bare metal is not the backward choice. The STM32 PLC industrial control system runs data logging, industrial communication and business logic in parallel, so FreeRTOS multi-task scheduling is right for it. A product with few tasks and simple timing is more compact on bare metal with interrupts, and saves the scheduler overhead. The choice between an RTOS and bare metal is fixed at the architecture stage and written into the proposal, not left for later rework.

Motor control firmware is its own class of problem, and XTELL has delivered two such projects. The microscope motorized stage runs 3CNC firmware on an ATMEGA32U4, driving its motors through A4988 and HR4988E stepper drivers expanded via an Arduino CNC Shield, for high-precision micro-motion of a microscope stage; the micro-platform PCB was designed alongside, and the structure was done in FreeCAD with STEP output. The smart finger servo control system targets a bionic finger: an Arduino and AVR microcontroller controls the servos, servo.ino sets multiple servo angles, a USBASP board handles programming, and the main board integrates the drive circuitry. Multi-axis coordination and precise position feedback were the shared challenge.

Most XTELL firmware runs on boards we designed. When a peripheral misbehaves we can check the schematic, put a scope on the signal and change the next board revision, instead of emailing a hardware supplier and waiting. PCB design is done in KiCad and mechanical design in FreeCAD, so firmware engineers and hardware design close the loop inside one team.

One team writes the firmware, the app and the backend. When a device misbehaves, a software-only supplier can only relay the symptom - the device didn't report. XTELL can open the firmware and see what the device actually sent and whether the server received it. Diagnosis needs no message-passing between two suppliers and integration needs no cross-company scheduling, which is one of the main reasons western B2B clients choose us.

Clients' products routinely need certification, and XTELL supports the FCC, CE and related work. Certification has real consequences for firmware: RF parameters, operating modes and power behaviour must be configurable and reproducible at the firmware level, and we prepare the test firmware builds and documentation the lab needs. Certificates are issued by accredited test labs; we make sure the device behaves consistently on the test bench.

• MCUs: STM32 (such as the STM32F407), ESP32, BLE MCUs (Nordic nRF52/nRF53, JL7018, WCH CH58x/CH59x), AVR and Arduino (such as the ATMEGA32U4)

• Operating systems: FreeRTOS, bare metal

• Storage and memory: FatFS, SDIO, SD card logging, external SRAM

• Communication: UART industrial communication, WiFi data upload

• Motor and motion control: A4988 and HR4988E stepper drivers, multi-channel servo control, Arduino CNC Shield, 3CNC firmware

• Languages and tools: C, Arduino, USBASP programming

• Hardware tools: KiCad for PCB design, FreeCAD for mechanical design

1. Requirements review: share the MCU, the schematic if it exists, and the functional requirements, and we confirm feasibility.

2. Proposal and contract: scope, milestones and engagement model are written down here. Whether source code and design files are delivered, and under an open or closed model, is agreed item by item in the contract. Nothing on this page constitutes a blanket commitment.

3. Development and integration: firmware and hardware are verified together, with measured data in place of assumptions.

4. Delivery: scope follows the contract. Timeline and price depend on scope and are given after assessment; this page does not fix numbers.

Within the Espressif family we select per product rather than per habit. The ESP32-S3 earns its place when the product has a colour screen, needs native USB, or runs on-device inference: its vector instructions, larger external PSRAM support and USB-OTG are what separate it from the original ESP32 and the cost-focused C3. For a plain sensor node that reads a value and publishes it, a cheaper part does the same job for less.

The engineering work on an S3 product concentrates in three places. PSRAM type and size have to come from a written memory budget before the interface is designed - quad versus octal decides whether a display tears under load. Display bandwidth is calculated from resolution, colour depth and frame rate before the panel is ordered, not discovered during bring-up. And battery life is budgeted from duty cycle - deep sleep current, the cost of associating and establishing a session, and the share of time the radio is actually transmitting - then corrected against measured current on real hardware.

XTELL (Shenzhen XTELL Future Technology) was founded in Shenzhen in 2016. Over the ten years since, it has delivered more than 100 projects, with clients predominantly western B2B companies. Its work covers every layer from circuit board to cloud: PCB design, FPGA, embedded firmware, Linux BSP, device interfaces, mobile apps, backends and IoT platforms.