Embedded Software Development ServicesFrom Firmware to Cloud

We build four kinds of embedded software: firmware and RTOS development, low-power management, communications and positioning, and device interfaces. This is the overview page for embedded software - firmware implementation details are on the firmware development page, and Linux kernel and driver work on the Linux BSP page. Not sure which layer your need falls into? Start by asking here and we will tell you.

As an embedded software development company, XTELL works mostly for western B2B companies, most of them building hardware products that will be sold and must pass certification. Product types delivered include IoT terminals reporting over GPRS/GPS, electric two-wheeler dashboards and wearables such as smart watches. FCC/CE certification is the normal constraint on these projects, not the exception.

This is our biggest difference from software-only suppliers. When a device misbehaves, a software-only company can only relay the symptom - "the server received no data"; we open the firmware and see what the device actually sent and at which layer it was lost. Diagnosis happens inside one company, not in email threads between several suppliers.

Tech stack: C, Apollo2, Keil/IAR/GCC, GPRS, GPS, RTC, ADC.

Challenge: ultra-low-power deep sleep on the Apollo2 platform while keeping GPRS/GPS communication.

Approach: use the Apollo2's low-power modes, wake on an RTC timer, and activate GPRS/GPS only when needed; Flash and a watchdog keep the system reliable - the devices are deployed unattended, where nobody can be counted on to press reset.

Hardware: Apollo2 (Cortex-M4), a 240x240 colour touch screen, heart rate, accelerometer and gyroscope sensors, Bluetooth 5.0 and WiFi. Software: C on an RTOS, with a companion phone app.

Challenge: conventional smart watches typically need charging daily, which is a poor experience; cutting power significantly without losing functionality was the core problem.

Approach: a multi-level power management strategy - optimised hardware selection plus tuned software algorithms, with intelligent sleep and wake, to stretch battery life as far as possible.

Platform: STM32 with TouchGFX.

Challenge: vehicle screens have limited resolution, yet information must be clear and interaction animation smooth.

Approach: a dark theme suited to the in-vehicle environment; smooth transitions with frame sequences and MP4 animation; a systematic icon set; and interaction prototype documents that were not discarded once drawn, but directly guided the implementation.

The method has three main lines: start from low-power chip selection (parts like the Apollo2); multi-level power management with tiers by device state; and RTC timed wake-up with the radio activated only on demand.

The costs need stating too: during deep sleep the device is offline and cannot respond at any moment, and battery life has to be traded against functionality. We put these trade-offs on the table at the requirements stage rather than telling you at delivery.

Embedded software is rarely delivered on its own: a watch needs a phone app, and a terminal reports data to a server and an IoT platform. Mobile apps, backends and IoT platforms are all within our work, and come from the same team as the firmware. For the client it means cross-layer integration needs no second supplier.

What is listed here has been used on real projects, not copied from a generic list:

• Language and runtime: C, RTOS

• Build environments: Keil, IAR, GCC

• MCUs: STM32, Apollo2 (Cortex-M4)

• Peripherals and connectivity: ADC, RTC, GPRS, GPS, Bluetooth 5.0, WiFi

• Device interfaces: TouchGFX

• Adjacent layers: KiCad for PCB, FreeCAD for mechanics, and the vendor toolchains Vivado, Quartus, Libero and Diamond for FPGA - there are no substitutes at that layer

We offer both open and closed engagement models. Delivery scope - including whether source code and design files are included - is agreed item by item in the contract for each project, and this page makes no blanket commitment. The reason is simple: intellectual property arrangements differ greatly between projects, and settling them before work starts is more reliable than a nice sentence on a web page.

• Requirements: power budget, certification requirements, hardware platform and delivery boundaries

• Proposal and prototype: as on the electric vehicle dashboard project, an interaction prototype comes first, then development

• Development and integration: firmware, app and backend integrated by the same team

• Certification support: clients' products routinely need FCC, CE or similar certification, and we carry the related development work

• Delivery: in the scope and form agreed in the contract

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. For an embedded systems development company, cross-layer capability is not a bonus - when a device fails, it decides whether diagnosis happens in-house or bounces between suppliers.