Firmware, hardware and embedded systems consultancy in Cleveland, Ohio. We take on bring-up, inherited codebases, and the bugs that only appear on real hardware.
Tools we built because we needed them on real projects. Each README opens with the problem that produced it.
| stm32-hardfault-handler | A Cortex-M fault handler that decodes the fault and reports it, instead of spinning silently in while (1). Survives the reset, so field units can tell you what killed them. |
| fw-package | Firmware image packaging done the boring correct way: encrypt-then-MAC, separate derived keys, authenticate before you decrypt. |
| can-id-map | One YAML message map generates the CAN ID header, the RX dispatch table and the protocol document — so the three can't drift apart. |
| bench-vv | pytest plugin for hardware V&V. Every report records the CRC32 and SHA-256 of the image it tested, because a report that doesn't name its binary proves nothing. |
| pinmap-lint | Diffs a CubeMX .ioc against the schematic pin map in CI. Header pin numbers are not GPIO numbers. |
| git-binary-guard | Catches EOL filters silently corrupting committed firmware binaries — the failure where git status says clean and a fresh clone gets a broken image. |
| kyros-engineering-tools | Fifteen browser-based tools: power budget, BOM cost, protocol decode, timing diagrams, filter design, EMC pre-compliance. No install, no data leaves your machine. |
Embedded firmware (STM32, FreeRTOS, CAN/FDCAN, bootloaders and secure update paths), board bring-up and hardware debug, and engineering for regulated products where the verification evidence matters as much as the code.
We're usually brought in on one of three things: a board that doesn't work yet, a codebase somebody else wrote, or a deadline that needs more hands than the team has.