Embedded & Firmware
Firmware and embedded software development for connected products
Indeema is a custom firmware development company for makers of connected devices: we take responsibility for the software inside the device, from board bring-up and drivers to BLE, Wi-Fi and LTE connectivity, field updates and the contract with your cloud and apps. 230+ engineers and 200+ connected-product projects mean you can bring us one component, the whole embedded layer, or the device’s place in the full system.
See what we take responsibility forWhere firmware problems begin
When do teams need outside firmware engineers?
The board exists and no one owns its software.
The firmware works in the lab and is fragile in the field.
The prototype has to become a product you can update.
The device and the cloud disagree about state.
Your team has no RTOS, radio or low-power specialist.
You have to choose the platform before you commit to it.
What Indeema takes responsibility for
What does firmware development cover?
Embedded software fails at its edges as often as in its code, so responsibility covers both. Indeema holds the verbs that fit your product, on the parts you choose.
ArchitectImplementIntegrateEvolve
Inside the device
What runs on the board.
- Architect the runtime: task structure, RTOS choice, memory and power behavior.
- Implement board bring-up, drivers and the application logic.
- Integrate sensor acquisition and signal processing with the code that uses it.
- Evolve the software as hardware revisions arrive.
At the boundaries
Where the device meets everything else.
- Integrate the hardware interface: buses, pinout, timing and power.
- Implement radio and protocol stacks such as BLE and Wi-Fi, and wired industrial links such as RS-485 and Modbus.
- Architect the contract with cloud and applications: protocol, versioning and failure states.
- Integrate protected pairing and encrypted communication where the product needs them.
Across product life
What keeps a shipped device working.
- Architect update and recovery, so a failed update does not leave a unit unusable.
- Implement over-the-air updates over the networks the device has.
- Integrate validation on real hardware into the release path.
- Evolve the firmware through updates and maintenance after release.
Interfaces Indeema owns explicitly
- HardwarePinout, timing and power.
- Radio and networkProtocols and how they behave when coverage drops.
- Cloud and applicationProtocol, versioning and failure states.
- FactoryTest and provisioning.
- FieldUpdate and rollback.
The work touchesRTOS (FreeRTOS, ThreadX)ESP-IDFBLEWi-FiRS-485 and ModbusMQTT over TLSOver-the-air updatesSPI and UART
Firmware drawn as the layers above the board it runs on.
Platforms and interfaces
What we build on: MCUs, RTOS and interfaces
Where a published project shows the work, it is linked beside the line; the other lines come from client projects under NDA.
| Area | Technology | Where |
|---|---|---|
| Microcontrollers and SoCs | ESP32, ESP32-C6, ESP32-P4 and ESP32-PICO on ESP-IDF | Elevator monitoring, Connected ventilation, Video intercom, Spraying drone link |
| Microcontrollers and SoCs | Renesas RA | Vehicle telemetry |
| Microcontrollers and SoCs | STM32, Nordic nRF52, nRF53 and nRF91 | Client projects under NDA |
| Microcontrollers and SoCs | NXP i.MX, Kinetis and LPC; TI CC26xx and CC13xx; Microchip SAM and PIC | Client projects under NDA |
| Microcontrollers and SoCs | Arm Cortex-M microcontrollers and Cortex-A application processors | Client projects under NDA |
| RTOS and operating systems | FreeRTOS | Elevator monitoring, Connected ventilation |
| RTOS and operating systems | ThreadX | Vehicle telemetry |
| RTOS and operating systems | Zephyr and bare-metal firmware | Client projects under NDA |
| RTOS and operating systems | Embedded Linux with Yocto and Buildroot | Client projects under NDA |
| Wireless and smart home | BLE | Connected ventilation, Sensor unit |
| Wireless and smart home | Wi-Fi, including Wi-Fi 6 | Elevator monitoring, Air purifier, Connected ventilation |
| Wireless and smart home | Matter, Thread and Zigbee | Connected ventilation |
| Wireless and smart home | UDP over a Wi-Fi soft access point | Spraying drone link |
| Wireless and smart home | LoRaWAN, NB-IoT and LTE-M | Client projects under NDA |
| Cloud messaging | MQTT and MQTT over TLS | Air purifier, Elevator monitoring |
| Wired and peripheral interfaces | RS-485 and Modbus | Elevator monitoring |
| Wired and peripheral interfaces | SPI, QSPI and UART | Spraying drone link |
| Wired and peripheral interfaces | USB configuration from a PC | Vehicle telemetry |
| Wired and peripheral interfaces | MIPI DSI and CSI, LCD, H.264 and RTSP streaming, a custom audio driver | Video intercom |
| Wired and peripheral interfaces | CAN and CAN FD, Ethernet, I2C, ADC and DAC | Client projects under NDA |
| Sensors and controllers | ATmega328P controller with an ADXL345 accelerometer | Vibration diagnostics |
| Sensors and controllers | Air-quality and airflow sensor integration | Air purifier, Connected ventilation |
| Boot and update | MCUboot and custom bootloaders, A/B updates with rollback, secure boot | Client projects under NDA |
| Board bring-up and testing | STM32F405 flight controllers and Silicon Labs EFM8 ESCs, brought up and tested with existing flight firmware | Drone R&D |
Scope of responsibility
How much of the device software should Indeema own?
Scopes, not tiers. Embedded firmware development can start at any of them, including modernizing firmware that already ships.
Discipline
One component, done properly.
- A driver, a protocol stack, an update mechanism or a port to a new microcontroller
Layer
The whole embedded software of a device.
- Runtime, drivers, application logic and updates
Connected layers
The firmware and its contract with cloud and apps.
- Device identity, protocol, versioning, failure states and app pairing
Whole product
The device as one part of the whole product.
- Electronics, firmware, cloud and applications under one architecture
At every scopeArchitectImplementIntegrateEvolve
Scope follows where the problem is, not the size of the engagement.
Method and handover
How does firmware development work from prototype to field updates?
Eight gates, from constraints to the field. Each ends with something your team can read, run or check.
- ConstraintsConstraint record
- ArchitectureArchitecture record
- Bring-upBoards running, with notes
- ImplementationReviewed source and build instructions
- IntegrationInterface specification
- Validation on hardwareTest reports
- Release and updateRelease and update plan
- Field supportDocumented recovery path
Handover is planned from the first gate, including how over-the-air updates and recovery will work. Contents are agreed for each engagement.
Test and release
How firmware is tested and released
Validation is tailored to the project: builds are checked against agreed acceptance criteria, interfaces are measured on hardware, and updates are designed to recover when a connection drops.
Milestone builds checked against agreed acceptance criteria, with contributions reviewed before merge
Vehicle telemetryInterface throughput and data transfer measured on hardware with a high-speed logic analyzer
Spraying drone linkAutomated firmware builds in a CI/CD pipeline
Video intercomTesting across the device, the cloud platform and the app, not only the firmware
Air purifierOver-the-air updates over LTE or Wi-Fi
Elevator monitoringOver-the-air updates over BLE through the mobile app
Sensor unitAn update flow designed so an interrupted connection cannot leave the unit unusable
Vehicle telemetryFirmware unit tests and hardware-in-the-loop test benches
Static analysis, including MISRA checks and cppcheck
A/B updates with rollback, and secure boot so only signed firmware runs
What this has looked like
Four situations, and what Indeema owned in each
- LayerRescuing existing firmware
A telemetry unit had hardware, but only very basic embedded software.
- Indeema owned
- The firmware architecture and an RTOS real-time application: modem start-up, a telemetry queue for coverage gaps, and an update flow designed not to brick the unit.
- What changed
- The basic code was replaced by an application with the features the product needed.
- Connected layersFirmware with field updates
An elevator-monitoring device had to stay connected and current over LTE or Wi-Fi.
- Indeema owned
- An embedded framework on an RTOS with trip-detection logic, an RS-485 link to an energy meter, and over-the-air updates over either network.
- What changed
- A maintenance plan built around regular firmware updates.
- LayerPlatform validation to prototype
A proposed system-on-chip had not been proven for streaming analog camera video.
- Indeema owned
- Display, camera and audio bring-up, video encoding, and a custom streaming component where the vendor’s fell short.
- What changed
- A working prototype showed the platform was suitable, with the architecture laid out for what followed.
- LayerModernizing a shipped device
A sensor unit’s firmware sat on an older framework and could not be re-flashed once assembled.
- Indeema owned
- USB programming without opening the enclosure, a move from serial Bluetooth to BLE with protected pairing, and migration to the chip vendor’s native framework.
- What changed
- The firmware became updatable, including over the air, and pairing became secure.
Reading: Solving drone firmware integrity and connectivity
Firmware that already ships, or a prototype that has to? We start by reviewing the code, the build and the hardware it runs on, then fix, extend or migrate it while keeping devices in the field updatable. Discuss your firmware
FAQ
Firmware development questions
What is the process of firmware development?
Firmware development starts with the system requirements and the hardware, then moves through architecture, implementation, board bring-up, testing and debugging on the target hardware, integration with the rest of the product, and release. After release, firmware needs maintenance and over-the-air updates for as long as devices are in the field.
How long does it take to develop custom firmware?
It ranges from a few weeks for a bounded change to many months for a new product, depending on the hardware maturity, connectivity, the number of features, the update mechanism and the validation required. We plan in stages, with working firmware on the target early.
What are the benefits of working with an external firmware development team?
A specialist team brings established processes for architecture, testing on hardware and release, which reduces the risk of errors and delays, and lets your own engineers concentrate on the product. It helps most when the team also understands the hardware, the connectivity and the cloud the firmware works with.
Do you develop firmware with an RTOS?
Yes. Firmware for connected products is often built on a real-time operating system, with tasks for connectivity, sensing and control, and a defined approach to timing, memory and power. The choice of RTOS follows the microcontroller and the product’s requirements.
Can you take over existing firmware?
Yes. We start by reviewing the code, the build and the hardware it runs on, then fix, extend or migrate it, for example to a current framework, while keeping devices already in the field updatable.
Ways to work with Indeema
Start with your device
Engineering ownership
Indeema is accountable for a defined scope, from architecture to evolving what it built. You decide at agreed gates.
Joint product team
Indeema engineers work inside your product team, on your roadmap and against interfaces you both own.
Also available: specialist team extension. One scarce specialty joins a team you lead.
Bring us
- The board, or the plan for one
- What it must do, and where it fails
- The radio, cloud and app interfaces you have
- The part you want owned
What happens next. Our engineering team reads your enquiry and replies by email. The first conversation covers the product goal, what exists today and the decision you need to make next. If the problem needs it, a discovery phase follows; it does not commit you to building with Indeema. How a first engagement works
Where the boundary sits
- IoT Product Engineering The whole product, electronics included.
- Cloud & Connected Systems The device-to-cloud contract and fleet.
- Applications & Experience Pairing and state in the app.
- DevOps Services The pipeline behind updates.
- Maintenance & Support Supporting a shipped product.
- Product Discovery & Technical Strategy Before you commit to a platform.
- AI for IoT & Edge AI Intelligence within device limits.
- Autonomous & Intelligent Physical Systems Control that acts within set limits.
- Connected Product Engineering Firmware as one product layer.
Sector context: Drones & UAV · Smart home · Energy