A smart bed that reads 10,756 pressure points and moves 46 actuators to correct posture. When I joined Water™ Robotics it collected pressure data and did nothing with it. This note is the ledger: what existed on day one, what shipped, and the four problems that stood between them.
Line by line, what the product could do when I arrived and what it could do on the show floor. Everything in the right-hand column is firmware, host software or tooling I wrote.
The original scan walked every sensing point in turn: select the point, drive it, wait for the converter to settle, read it, move on. The settling wait dominated everything, and multiplying it by 10,756 made the product impossible on hardware that was already fixed.
Rebuilt the acquisition path as a pipeline: both sensor buses on a core driven concurrently by DMA so multiple rows are in flight at once, settling delays timed off a hardware cycle counter instead of generic scheduler sleeps, and rows beyond the tallest active zone on that board skipped entirely rather than scanned and thrown away.
Each core runs its own kernel at its own clock on its own power domain, sharing only a small window of memory. One core could read that window while the other was still mid-write. Worse, the faster core caches aggressively — a write could sit in cache and never reach the memory the other core was reading. Intermittent, load-dependent, and invisible in a debugger.
Made every cross-core exchange take a hardware semaphore first — a silicon peripheral, not a software mutex, because a mutex only means something inside one core’s scheduler. Paired it with explicit cache maintenance so a write actually lands in physical memory, and memory barriers so the processor cannot reorder the release ahead of the data.
The corruption class disappeared. The pattern then became the standard for every cross-core access on the platform — the same discipline is in the aggregator, the bootloader and, later, the chair.
A single failed write is a service call at best. Updating a dual-core chip adds a second problem: the other core must stop touching flash before the write starts, or it corrupts the bank it is running from.
Built the update path end to end: A/B flash slots with a guarded boot record, chunked transfer with missing-piece tracking, verification of the image in memory and again after it is written, a handshake that quiesces the second core before any erase, and automatic fallback to the previous image if the new one does not confirm a healthy boot.
Images are encrypted and signed. Rollout is staged in groups so no board is ever asked to overwrite the slot it is currently running. Underneath it all, one bare-metal bootloader, deployed identically to all five boards.
The obvious route is four hardware variants with four firmware builds. That is four things to fab, four to flash correctly on the line, four to keep in step for the rest of the product’s life — and a mis-flashed board that looks fine until it moves the wrong zone.
One PCB and one firmware image. At boot each board reads its identity from jumper pins and configures itself from a static topology table — which zones it owns, which sensors and actuators map to them, which identifier it uses on the bus.
One image to build, sign, test and ship. The factory cannot flash the wrong one, because there is only one.
Launched publicly at CES 2026 as a shipping consumer device — full sensing, actuation, secure updates and app connectivity. The company raised its next round shortly after the show. The architecture carried straight into the second product line: the smart chair reuses the same wire protocol, the same motor-driver integration and the same cross-core discipline.