Skip to content

Services

Software we write.

Five disciplines. All of them software. If the work is the board, the enclosure, or the factory, it is out of scope — that box is at the bottom of this page. Reading a schematic to write a driver is in scope.

  1. 01

    Firmware

    We write the firmware that boots, talks to peripherals already on the target, manages power states in software, and meets the timing the product requires. The work is the code — not the part number, and not the board it sits on.

    If you can name the microcontroller and how it is wired, we can talk about the firmware. We do not select silicon as a hardware consultancy, and we do not draw the schematic. We will read a schematic or a datasheet when that is what it takes to write the firmware.

    What this includes

    • Boot and update code that lives in firmware
    • Application firmware for peripherals already on the target
    • Power-state handling in software
    • Timing-sensitive control in firmware

  2. 02

    Embedded Linux

    We work on Linux as software on hardware you own: kernel configuration, userspace, images, and the services the product needs to start and stay up. We do not sell an operating system, and Linux is not a product of ours.

    We also do not take a bare board and turn it into a hardware platform. You own the target. We work on the Linux software that runs there.

    What this includes

    • Kernel configuration for a target you supply
    • Userspace, init, and product services
    • Image build and the notes needed to rebuild it
    • Integration of existing in-tree or vendor software you provide

  3. 03

    Drivers and connectivity

    We write device drivers and the software that uses buses and radios that are already on the product. Typical links include USB, UART, I2C, SPI, Ethernet, Wi-Fi, and Bluetooth.

    Driver bring-up is software work. We read schematics and datasheets to write the driver, map registers, and get the peripheral talking. We do not design the transceiver, the module, or the antenna, and we do not sell connectivity hardware.

    What this includes

    • Kernel or userspace drivers for peripherals already on the product
    • Schematic and datasheet reading in service of a driver
    • Software for buses and radios that are already fitted
    • Protocol handling on the software side of a link

  4. 04

    Application software

    We write the application layer on the product and the companion software that operators or users actually use: on-device applications, control interfaces, and the logic that sits above the drivers.

    This software belongs to your product. We do not ship a consumer device of our own, and we are not an app-store brand.

    What this includes

    • On-device application logic
    • Control and operator interfaces
    • Companion software that belongs to your product

  5. 05

    Embedded GUI

    We write the firmware that owns the screen: widget tree, screens, input, fonts, and the path from a framebuffer to a panel that is already on the product. Typical work sits in an LVGL-class stack. We have also evaluated Qt for MCUs and STM32 TouchGFX when a target and a constraint set called for that comparison.

    We do not design the display module, the backlight, or the enclosure. The panel and the MCU are yours. The GUI firmware is the work.

    What this includes

    • Embedded GUI firmware on an MCU you supply
    • Screen flow, widgets, and input handling
    • Integration with existing display hardware and firmware
    • A stack recommendation against memory, vendor, and workflow constraints

Start a project conversation