Firmware Development
Firmware written by the people who designed the board so the hardware/firmware boundary stops being somebody else's problem.
![](data:image/svg+xml,<svg display="block" id="4238997430" role="presentation" viewBox="0 0 973 4" xmlns="http://www.w3.org/2000/svg"><path d="M 0 1.999 C 0 0.895 0.895 0 1.999 0 C 49.383 0 923.497 0 970.991 0 C 972.097 0 973 0.903 973 2.009 C 973 2.009 973 2.01 973 2.01 C 973 3.109 972.109 4 971.01 4 C 923.73 4 49.389 4 2 4 C 0.895 4 0 3.105 0 2 C 0 2 0 2 0 1.999 Z" fill="rgb(204, 204, 204)" height="4px" id="hRZSFU08U" width="973px"/></svg>)
When the electronics and the firmware come from two different suppliers, the difficult faults land in the gap between them. A sensor reads correctly on the bench and drifts once it is inside the enclosure. A device wakes reliably for a month of testing and then hangs in the field. Each supplier can demonstrate that their part works, and the schedule goes while the two of them establish whose it is.
We design the board, write the firmware, build the enclosure and develop the app. When a fault sits on the boundary it is still ours, and there is nobody for us to escalate it to.
Six years on one device, from first prototype to deployed product
FeelTect came to us with a concept and nothing else: measure the pressure under a compression bandage, which until then had been estimated by hand. We built the first prototypes, and we have been the electronics, firmware and app team on Tight Alright ever since, now the world's first connected‑health system for measuring sub‑bandage pressure during compression therapy. The firmware drives a flex‑PCB pressure sensor array under live clinical use, holds its accuracy across the full clinically relevant pressure range, and feeds a companion app that shows a nurse the reading while they are still applying the bandage.
"IMME Design have been with us since the very beginning, when we had nothing more than a concept for Tight Alright. IMME built our first prototypes and helped us turn concept into a working device. Over the past six years IMME have remained a core partner across our electronics, firmware and app development."
Darren Burke, CTO & Co‑founder, FeelTect
An engineering decision we changed our mind on
Tight Alright was originally designed around Qi wireless charging. After practical testing we moved it to USB‑C, because reliability, everyday usability and manufacturing simplicity all improved together.Revisiting a decision that late in a programme costs something. Shipping a medical device that charges unreliably costs considerably more.
What we do
![](data:image/svg+xml,<svg display="block" id="2331059170" role="presentation" viewBox="0 0 262 4" xmlns="http://www.w3.org/2000/svg"><path d="M 0 1.999 C 0 0.895 0.895 0 1.999 0 C 24.892 0 237.077 0 259.996 0 C 261.101 0 262 0.899 262 2.004 C 262 2.005 262 2.005 262 2.005 C 262 3.107 261.107 4 260.005 4 C 237.136 4 24.895 4 2 4 C 0.895 4 0 3.105 0 2 C 0 2 0 2 0 1.999 Z" fill="rgb(204, 204, 204)" height="4px" id="hcyQGd7cR" width="262px"/></svg>)
First power‑on of a new board, when nobody yet knows whether the fault is silicon, layout or code. On‑target debugging over JTAG, SWD and serial. This is the work that goes fastest when the same team drew the schematic.
Real-time and sensor firmware
Timing‑critical control loops, state machines and sensor acquisition. Sensor selection, calibration and validation across the range the product actually has to hold — as on Tight Alright, where readings had to stay consistent under varying applied pressure.
Power and battery life
Sleep‑state architecture, duty cycling and peripheral power management, with current draw measured rather than estimated.
Connectivity that works for a non-technical user
BLE and wireless links, pairing that succeeds first time for a nurse or a consumer, and data integrity when a connection drops halfway through a reading.
Firmware your own team can take over
Bare‑metal and RTOS development, hardware abstraction layers, documented code structure, reproducible version‑controlled builds, toolchain and release management. Written so that your engineers, or your next supplier, can pick it up without us.
Verification and traceability
Unit and integration testing of firmware modules, hardware‑in‑the‑loop and software‑in‑the‑loop testing, regression testing in CI, timing and memory‑usage analysis, and root‑cause analysis when something fails.
Talk to whom you will be working with
![](data:image/svg+xml,<svg display="block" id="3466557371" role="presentation" viewBox="0 0 730 4" xmlns="http://www.w3.org/2000/svg"><path d="M 0 1.999 C 0 0.895 0.895 0 1.999 0 C 42.569 0 687.328 0 727.991 0 C 729.097 0 730 0.903 730 2.009 C 730 2.009 730 2.01 730 2.01 C 730 3.109 729.109 4 728.01 4 C 687.529 4 42.575 4 2 4 C 0.895 4 0 3.105 0 2 C 0 2 0 2 0 1.999 Z" fill="rgb(204, 204, 204)" height="4px" id="j7DaIfjlS" width="730px"/></svg>)
Garrett Brennan
Software Engineer
Garrett is a Vancouver based software engineer who has been writing embedded software since 1990, most of it in cyber security and fire detection systems, heavy industrial and marine control systems, drivetrain electronics for heavy equipment and defence manufacturers, and more recently connected IoT products. He also works in PLC and structured text, SQL, and iOS and Android, so on a connected product the firmware and the app it talks to can come from the same engineer.
Frequently Asked Question
What exactly is firmware, and why does it matter for my product?
Firmware is the software that lives directly on your device and controls how the hardware behaves. It is what makes buttons respond, sensors read correctly, and systems run reliably. Good firmware is often invisible to users, but if it is poorly designed, problems show up very quickly.
