Embedded Firmware Development for IoT Products

    Firmware for connected hardware, from board bring-up and low-power control to wireless connectivity, edge processing, and secure OTA updates.

    Firmware is where hardware starts behaving like a product. It manages sensors, power states, connectivity, data, and recovery logic that must keep working long after the prototype leaves the bench.

    Our embedded engineers develop IoT firmware across Nordic nRF, ESP32, and ARM Cortex-M platforms, working alongside the hardware and cloud teams so the device is designed as one system.

    Our Firmware Capabilities

    Nordic nRF52/53

    Zephyr RTOS, nRF Connect SDK, Bluetooth LE, Thread, Zigbee

    ESP32 Family

    ESP-IDF, FreeRTOS, Wi-Fi, Bluetooth Classic and BLE

    STM32 & ARM Cortex-M

    HAL, CMSIS, bare-metal and RTOS

    Ultra-Low Power

    Sleep mode optimisation, duty cycling, current profiling

    Sensor Fusion

    IMU algorithms, environmental data pipelines, GNSS processing

    Wireless Protocols

    BLE GATT, LoRaWAN, LTE-M, NB-IoT, MQTT, CoAP

    Edge AI/ML

    TensorFlow Lite Micro, sensor-driven inference on constrained devices

    Security & OTA

    Secure boot, encrypted OTA, DFU over BLE, FOTA over cellular

    From Board Bring-Up to Production Firmware

    Firmware is not an afterthought at Insyght. It is developed in parallel with hardware. Our embedded engineers are involved from the requirements phase, choosing MCUs based on peripheral needs, selecting RTOS architecture, and defining the power budget that drives hardware decisions. This co-design approach eliminates the friction of handing off a PCB to a separate firmware team.

    1

    Architecture & toolchain setup

    Firmware architecture, RTOS selection (or bare-metal for simple devices), development toolchain, and CI pipelines for automated testing. A clear architecture early makes later hardware, connectivity, and power decisions easier to change without rewriting the firmware underneath them.

    2

    Peripheral drivers & board support

    Drivers for every peripheral on your board: I2C sensors, SPI displays, UART modems, ADC inputs, PWM outputs, and all wireless interfaces. Every driver verified on hardware before moving to application layer.

    3

    Application logic & power management

    Core product behaviour: measurement sequences, connectivity management, data buffering, error handling, and the state machine. Power management designed in, not patched in. Current consumption profiled on real hardware.

    Battery life is a firmware problem too

    Sleep states, wake-up timing, sensor duty cycles, radio behaviour, and retries can dramatically change battery life. We profile current on the actual hardware rather than estimating it from component datasheets alone.

    4

    Cloud connectivity & OTA

    Full connectivity stack from device to cloud: protocol selection, message serialisation, authentication, and OTA updates. We can connect devices to Insyght Console, AWS IoT Core, your existing cloud backend, or standard MQTT/API infrastructure.

    5

    Validation & production firmware

    Memory usage, timing margins, power consumption, edge case behaviour, and production test mode. We write production firmware variants for factory testing and mass programming.

    Firmware That Connects to Insyght Console

    Devices built on our firmware stack can connect directly to Insyght Console for OTA updates, telemetry, and production traceability. Factory results can follow each serial number from production into the field.

    Firmware Built Around Real Constraints

    PadelPlay: reliable BLE under real-world interruptions

    A sensor inside a padel racket must manage motion sensing, multiple power states, and a Bluetooth connection that doesn't behave the same way it does on a desk. PadelPlay runs on an nRF52840 with Zephyr RTOS, with buffering and reconnection logic that preserves session data when the phone connection drops.

    Read the PadelPlay case study

    MedeMeter: continuous sensing on a solar power budget

    MedeMeter must analyse environmental sound continuously while running on harvested solar energy. Its firmware uses event-driven processing, low-power cellular modes, and local buffering so the processor and modem can sleep whenever possible.

    Read the MedeMeter case study

    Frequently asked questions

    Which microcontrollers and RTOS platforms do you work with?

    Our main embedded platforms include Nordic nRF52/53, ESP32, and STM32/ARM Cortex-M, with experience in Zephyr, FreeRTOS, vendor SDKs, and bare-metal development where appropriate.

    Do you develop low-power firmware for battery-operated IoT devices?

    Yes. Power budgeting, sleep states, sensor duty cycles, and radio behaviour are designed alongside the hardware and measured on the real device rather than treated as a final optimisation step.

    Can you add OTA firmware updates?

    Yes. Depending on the device and connectivity, this can include secure boot, firmware verification, and update delivery over BLE or cellular/cloud connectivity.

    Can the firmware connect to our existing cloud platform?

    Yes. Insyght Console is one option, but the firmware can also integrate with an existing IoT backend, MQTT infrastructure, or cloud platform, as required.

    We had this idea for a sensor that fits inside a football shoe and tracks your performance in real time. Insyght took it from concept all the way to a working product: the hardware, the ML firmware, production, everything. What sold us is that they had done it before and knew what to do. The product ended up being picked up by 433 and scaled further.

    David Dwinger
    David DwingerFounder at JOGO (now 433)
    Read the case study

    Explore More Services

    Tell Us About Your Firmware Project

    From ultra-low-power sensors to edge AI devices. We build the firmware that makes it work.