Firmware Development Services

XTELL writes production firmware for microcontroller-based products. We work on STM32 across the F4 and other series, ESP32 and ESP32-S3, Nuvoton N76E003, Ambiq Apollo2, the AVR and Arduino families including the ATMEGA32U4, and 8051-family parts including STC devices. Where the MCU has not been chosen yet, selection is part of the engagement rather than something you have to settle first.

We use an RTOS where the product needs one and bare metal where it does not. The STM32F407 industrial PLC controller we built runs FreeRTOS for multi-task scheduling, FatFS over SDIO for persistent high-speed data logging, external SRAM to expand runtime memory, and UART for the industrial communication link. A battery-powered air quality node on ESP32, by contrast, is dominated by sleep behaviour and radio duty cycle — a different set of decisions entirely.

Arduino comes up more often than people expect on production work, and not only for prototypes. The microscope motorized stage runs 3CNC firmware on an ATMEGA32U4 with A4988 and HR4988E stepper drivers over an Arduino CNC Shield; a servo control system uses Arduino and AVR with a USBASP programming board; a multi-channel data acquisition card was built on an Arduino-compatible Edison module handling temperature, humidity and pressure over ADC with GPIO control. Where the ecosystem gets a product to market faster we use it, and where it runs out of headroom we say so and move to bare-metal AVR or a different part.

Most of our firmware runs on boards we also designed, which shortens the debugging loop considerably. When a peripheral misbehaves we can check the schematic, scope the trace and change the layout in the next revision rather than negotiating with a separate hardware vendor about whose problem it is.

We also take over existing codebases. Inherited firmware often arrives with multi-version hardware and a toolchain requirement that spans Keil, IAR and GCC simultaneously — we maintained exactly that arrangement on an Ambiq Apollo2 low-power terminal, where several board revisions had to build from one source tree.

If your product needs field updates, say so early. OTA, bootloader design and rollback handling affect flash partitioning, which in turn affects MCU selection — a decision that is awkward to revisit once the board is laid out.

Validation is part of the deliverable rather than something left to your team. We measure actual power consumption across operating modes, verify timing on the hardware with a scope rather than in simulation, and report the flash and RAM headroom that remains — numbers that matter when a later feature request arrives and someone has to decide whether it fits. For battery products the sleep current figure is usually the one that determines whether the product meets its runtime specification, and it is rarely what the datasheet implies once real peripherals are attached.