Firmware and embedded software
Firmware determines what the product does and how it behaves. We write software for resource-constrained microcontrollers and for embedded Linux systems, and we build the tooling that keeps it maintainable.
Capabilities
Bare-metal firmware where it fits, or RTOS-based platforms (such as FreeRTOS) where task scheduling and timing demand it. ARM Cortex-M and Cortex-R parts from TI, NXP and ST, and MSP430.
Embedded Linux on custom hardware and on off-the-shelf platforms including NVIDIA Jetson and the BeagleBoard family (BeagleBone AI, PocketBeagle): device trees, board support, application software, model deployment and update infrastructure.
Modern C++ (11 through 23, with or without exceptions and RTTI) and C for production firmware. Python for tooling, test and automation.
Build and test tooling
Our pipelines are composed from open source tools with decades of development behind them: GCC and Clang toolchains, GNU Make, clang-tidy and clang-format, CppUTest, GDB and Jenkins. Builds are reproducible, static analysis runs on every commit, and nightly hardware-in-the-loop regression runs against real hardware. Multi-MCU products are packaged into a single versioned release artifact. Open source toolchains also lower the total cost to our customers after firmware handover: no per-product or per-seat licence fees.
This approach costs less than proprietary toolchains, is not tied to a vendor’s roadmap and produces firmware that has been checked by the same tools on every build. The result is faster development and fewer defects reaching the field.
AI-assisted development
We use AI tooling to shorten time to market: prototyping work, test authoring, documentation and routine refactoring go faster. Every line produced this way is reviewed by a developer, runs through the same static analysis and test pipeline as hand-written code and is held to the same standard. The tools accelerate the work; the people remain responsible for it.
Communication protocols
We have deep experience with the buses that industrial, automotive and energy products depend on: CAN 2.0B, J1939, UDS diagnostics, CANopen, RS-485 and Modbus, Ethernet including FreeRTOS-TCP, MQTT over TLS, and the standard peripheral set of I2C, SPI, UART and USB.
Protecting your product
Secure boot and signed binaries ensure the device runs only authorized firmware. Where the threat model calls for it, we use modern Trusted Platform Modules (TPM) or integrated MCU security features to hold device identity and keys in hardware. Current and upcoming TPM hardware also supports the latest post-quantum cryptography algorithms now being standardized for applications requiring forward secrecy.
Practices
Version control, code review, automated testing and reproducible builds are standard on every project. Documentation is treated as a deliverable alongside the code. Where appropriate, project deliverables include full build and signing toolchains, security tokens, programming rigs, factory test automation and calibration jigs, along with support to hand these systems over or keep them running.