Software · System software

Device drivers

Kernel and user-mode drivers that let an operating system talk to your own hardware safely and quickly.

A new board or instrument is only useful once the operating system can drive it. We write drivers for Linux, Windows and real-time systems that handle interrupts, DMA and power states correctly, expose a clean interface to applications, and survive suspend, hot-plug and kernel upgrades without taking the machine down.

What we build

Linux kernel modules for PCIe, USB, I2C, SPI and UART peripherals
Windows drivers built on KMDF and UMDF, prepared for Microsoft signing
Device tree bindings and board support for embedded Linux boards
DMA and interrupt handling tuned for high-throughput data capture
User-space libraries and command-line tools that wrap the driver interface
Automated tests on real hardware covering load, unload, suspend and hot-plug

DemoInteractive · sample data

Try it live.

A working sample with made-up data. It runs in your browser; nothing is sent anywhere.

Loading a PCIe capture driversample data

dev@rig-01:~/acqcard$ make -C /lib/modules/$(uname -r)/build M=$PWD
  CC [M]  acqcard_main.o
  CC [M]  acqcard_dma.o
  LD [M]  acqcard.ko
Build finished: 0 warnings
dev@rig-01:~/acqcard$ sudo insmod acqcard.ko && dmesg | tail -4

What it does well

Kernel-safe code

Locking, memory and error paths are reviewed so a faulty device cannot crash the host.

Upstream-friendly

Linux drivers follow kernel coding style and can be submitted upstream if you want.

Power management

Suspend, resume and runtime power states are handled so machines sleep and wake properly.

Clean interfaces

Applications use a documented ioctl, sysfs or library API instead of raw registers.

Signed and packaged

Builds ship as DKMS modules or signed Windows driver packages, ready to install.

Hardware-in-loop tests

Every change runs against the real device on a test rig before it ships.

Questions

Do you work on both Linux and Windows drivers?

Yes. On Linux we write kernel modules and device tree bindings; on Windows we use the KMDF and UMDF frameworks from the Windows Driver Kit. We pick the framework by what the device needs, and keep shared logic in one place where the platforms allow it.

Can a driver be written in Rust?

For new Linux drivers it is now an option in some subsystems, and it removes whole classes of memory bugs. Where the subsystem or your kernel version does not support it yet, we write careful C and check it with sparse, KASAN and static analysis.

What do you need from us to start?

The hardware itself or a development board, its datasheet and register map, the target operating systems and kernel versions, and any existing vendor code. If the documentation is thin, we can work from bus captures and the vendor reference driver.

Services that go with it

Custom software developmentSoftware designed and built around the way your business works, shown to you working at every review.Code reviewAn independent review of your codebase, with clear findings ranked by risk and a recommended fix for each.Maintenance and supportOngoing fixes, updates and small improvements for software already in use, with a clear way to ask for help.

Related software

Embedded firmwareDependable code for the microcontrollers inside your product, from first board bring-up to updates in the field.Operating systemsLean, hardened operating system images built for your hardware, your product and your update process.IoT platformsConnected devices onboarded securely, monitored live and updated remotely from one platform.System utilitiesSmall, dependable tools that install, check, clean and maintain the machines your business runs on.