Embedded software that ships and survives the field.
Firmware and embedded systems development in C/C++ for STM32, Atmel/Microchip and BLE platforms — HAL and driver layers, RTOS-based applications, and connected devices for automotive and IoT. Nearshore from Tunis for companies in France and Europe.
Firmware & HAL development
Bare-metal and RTOS firmware in C/C++ on STM32 and Atmel/Microchip MCUs. We write and maintain hardware abstraction layers and peripheral drivers (UART, SPI, I2C, CAN) that keep application code portable across boards.
Connected devices & BLE
Bluetooth Low Energy and connected-product development end to end: the embedded stack, the companion mobile app (Flutter), and the cloud backend — one team for the whole device-to-cloud chain.
Automotive & industrial
Embedded work to automotive and industrial standards: deterministic behavior, watchdogs and fail-safes, diagnostics, and OTA update strategies that don't brick devices in the field.
Testing & hardware bring-up
Board bring-up, hardware-in-the-loop test rigs, and unit-tested driver code — so regressions are caught on the bench, not at the customer.
The questions that come before a contract.
- What parts of an embedded product do you work on?
- The software: firmware on microcontrollers in C and C++, with or without an RTOS; embedded Linux with Yocto or Buildroot and the drivers around it; connectivity over BLE, Wi-Fi, serial or MQTT; and the companion app and cloud side when a device needs one. We work from your schematics, datasheets and requirements.
- Do you design the hardware as well?
- No. We write the software and work alongside your hardware engineers or your manufacturer, which lets us review a schematic for firmware impact and ask for test points and a debug header early. Choosing a software-only partner also means we have no stake in which board you build.
- How do you test firmware without the hardware in front of you?
- We separate logic from hardware behind an abstraction layer, so protocol and state-machine code is unit-tested on a host machine. Anything timing- or peripheral-dependent runs on real boards on the bench, which is why we need at least one sample early. Where the volume justifies it, we set up an automated hardware-in-the-loop rig.
- Can the devices be updated in the field?
- Yes, and it has to be designed in from the start rather than bolted on. That means signed images, an A/B partition scheme or equivalent with automatic rollback, resumable transfers over an unreliable link, and secure boot where the threat model calls for it. Retrofitting field updates onto a device that has already shipped is expensive, when it is possible at all.
- Can you help with certification and audits?
- We produce what the software side of an audit asks for: requirements traceability, design and interface documentation, test evidence, static analysis and coding-standard reports, and the release history. The certificate itself is issued by your notified body or test house, not by us, and we do not claim otherwise.
- How does the engagement run, and who owns the firmware?
- You own the sources, the toolchain configuration and the build scripts, in a repository you control. We are in Tunis on UTC+1, so the day overlaps fully with European teams, calls happen in English, French or Arabic, and you get a demo on real hardware at the end of each sprint rather than a status report.