Service
Embedded Systems Development
We write firmware and embedded Linux software for devices that must run unattended for months, for hardware teams in the Greater Vancouver Area and remotely across Canada, the US, and Europe.
Firmware & RTOS development
Firmware in C, C++, and Rust for STM32 and ESP32 microcontrollers, on FreeRTOS or bare metal, within tight memory budgets and hard real-time deadlines.
Embedded Linux & IoT
Kernel drivers and userspace services on Raspberry Pi and other Linux boards. Devices report to the cloud securely and take over-the-air updates through AWS IoT.
Edge AI & computer vision
On-device inference with ONNX and OpenCV, and real-time video pipelines with GStreamer and ROS 2, so decisions happen on the device instead of a server.
Built: CAN bus blackbox recorders for automotive incident replay on STM32 and ESP32 · a Linux framebuffer driver for the SH1106 OLED · a ROS 2 vision-tracking turret.
Who this is for
- A prototype works on the bench but now has to run unattended in the field for months.
- Firmware was written for one board revision, and every new revision breaks something.
- Devices are deployed, and updating them means a site visit.
- Your device has to decide on its own because the network is slow, costly, or absent.
How an engagement runs
- 01
Read the hardware
We start from schematics, datasheets, and any existing firmware, and bring up the board ourselves to see how it actually behaves.
- 02
Set the budgets
Memory, power, timing, and update size are written down as limits before code is, so the design fits the part you chose.
- 03
Build and test on the target
Firmware is developed against real hardware, with automated tests on the host where possible and logging that records what the device was doing when it failed.
- 04
Deploy and update
Secure provisioning and over-the-air updates through AWS IoT, so fixes reach devices without a site visit.
Questions
- Which hardware do you work with?
- Mostly STM32 and ESP32 microcontrollers, on FreeRTOS or bare metal, and Raspberry Pi and other Linux boards where the device needs a full operating system.
- C, C++, or Rust?
- C and C++ for existing codebases and vendor SDKs. Rust where memory safety matters and the toolchain supports the part, which now includes STM32 and ESP32.
- Can you take over existing firmware?
- Yes. We start by building and reading the current code, then fix and extend it rather than rewrite, unless a rewrite is clearly cheaper.
- Do you write Linux drivers?
- Yes. We have written kernel drivers, such as a framebuffer driver for the SH1106 OLED display, along with the userspace services that sit on top of them.
- Can you build the cloud side too?
- Yes. Devices report through AWS IoT with per-device credentials, and the same team builds the backend, so the firmware and the cloud agree on the protocol.