Embedded & Firmware
Firmware and embedded engineering 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.
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.
What this has looked like
Four situations, and what Indeema owned in each
Client names and figures are not shown.
- 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.
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
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