Firmware written to the standard the stage deserves. A proof of concept should be fast and disposable; production firmware should survive a hostile input, a half-finished update, and a decade in the field. I write both, and I am explicit about which one you are getting.

• Bare metal, FreeRTOS, Zephyr, embedded Linux
• Board bring-up, drivers, board support packages
• Bootloaders, secure boot, signed images, anti-rollback
• Low-power design and power-budget work
• Networking stacks on constrained targets, including IoT platforms

Most embedded products are made expensive by decisions taken in the first three weeks: the wrong part, a debug strategy nobody can use in the field, a security model bolted on after certification. I work through those decisions with you and leave behind a document your team (or your contract manufacturer) can build against.

• Silicon selection, system topology, power budget
• Security model: root of trust, key hierarchy, secure boot
• Update and recovery architecture, including rollback safety
• Interface and protocol design between subsystems
• Provisioning, device identity, and fleet onboarding where relevant

Every hardware company eventually discovers that the bottleneck is not the firmware; it is the fact that nobody can flash, key, test, or debug a unit without a specific engineer being in the room. I build the tooling that removes that person from the critical path.

• Cryptographic key generation and custody workflows
• Factory provisioning and device-association processes
• Production test rigs and end-of-line QA fixtures
• Debug, tracing, and field-diagnostic tooling
• Build, sign, and release automation for embedded targets

Undocumented devices, discontinued suppliers, binaries with no build system, protocols nobody wrote down. I take embedded systems apart to work out what they do, whether the goal is to secure them, interoperate with them, maintain them, or replace them.

• Firmware extraction: flash, debug ports, bus capture
• Static and dynamic binary analysis (Ghidra, IDA, emulation)
• Undocumented protocol and wire-format recovery
• Regaining maintainability of source-less legacy firmware
• Interoperability with closed or abandoned devices

Useful early, when a design review is cheap and changing your mind is still free. Useful before production, when you want the security claims on your datasheet to be true. Useful after an incident, when you need to know how far it went. Scope and budget agreed up front; the report says what was attempted, what worked, and what to change first.

• Design and threat-model review
• Firmware, bootloader, and protocol audit
• Debug port, bus, and flash extraction analysis
• Pre-production security verification
• Post-incident analysis

Networking on hardware that has neither the memory nor the power budget for the easy answer. Wired or wireless, standard stack or something proprietary that predates you, including connecting devices to IoT platforms.

• TCP/IP and TLS on constrained stacks
• BLE, Wi-Fi, 802.15.4 / Thread, cellular (LTE-M, NB-IoT), LoRaWAN
• CAN, RS-485, and industrial fieldbus work
• Proprietary and undocumented protocol implementation
• Bringing existing fleets onto a platform without bricking them

Sessions built around your team's own hardware wherever possible, because generic embedded training does not survive contact with a real product. Delivered remotely or on site, usually over one to three days.

• Secure firmware development practices
• Threat modelling for embedded devices
• Attacking your own hardware: a practical introduction
• Firmware reverse engineering for embedded teams
• Key management and provisioning for engineers