A Microcontroller Is Not a Sensor

Part of a series on building Vinver, solo, from the manifold to the microcontroller. The no-addresses post was about the Fabric that carries computation with no addresses. This one goes to the smallest thing on it.

The industry treats a microcontroller as a sensor on the end of a wire. It reads a value, ships it somewhere smarter, and waits to be told what to do. That is a waste of a computer, and a $15 ESP32 is a computer.

On the Fabric it is not a sensor. It is a peer. An Edge Atom: it runs real logic, holds its own cryptographic identity, and keeps working when the network is gone. Making that true, making a chip with a few hundred kilobytes of RAM a first-class citizen instead of a second-class endpoint bridged in through some gateway, was most of the work. None of it was glamorous, and all of it is the kind of problem the cloud lets you forget exists.

A computer, not a thermometer

The intent model from the no-addresses post makes one promise that sounds small and is not: the same call works whether it runs on a cloud GPU or on a microcontroller three meters away. The developer emits a Pulse and does not know or care which world answered.

For that promise to hold, the device cannot be special-cased. It cannot be a thing you talk to through a translator while the real computers talk to each other directly. It has to speak the same protocol, run real sandboxed code, and be addressable by intent like everything else. The asymmetry between a server and a sensor has to live below the call, not in the developer's head. Pushing it there is the job.

The RAM wall

First hard problem. You want to run a sandboxed unit of logic, a WASM Atom, on a device that measures its memory in kilobytes. The obvious way to run WASM is to load the bytecode into RAM and execute it. You do not have the RAM. On this class of device the bytecode alone would not fit beside everything else that has to stay resident.

The way through is to stop copying. The module lives in flash and executes in place, mapped and read directly, never pulled into the heap. The runtime interprets it where it sits. The whole firmware is about a megabyte and a half, and the headroom that buys is the difference between "can run a real Atom" and "can blink an LED." This is unglamorous systems work, and it is the entire reason a four-dollar part can host logic at all.

TLS does not fit, so we built what does

A peer that holds identity needs authenticated, encrypted communication. That is not optional. A device you can spoof is a device you cannot trust with anything.

The standard answer, TLS or its datagram cousin, does not fit. A handshake wants tens of kilobytes of RAM, and on this device the budget for cryptography is under two. So the transport had to be rebuilt for the constraint instead of shrunk down from a desktop assumption. We call it VLP, the Vinver Link Protocol: authenticated encryption for a microcontroller, with a fixed overhead of forty-one bytes and no handshake round trip at all.

To be clear about the part that makes security people flinch: the cipher is not homemade. VLP is built on a standard, audited authenticated-encryption construction from the ChaCha20-Poly1305 family, the same AEAD lineage behind WireGuard and libsodium. What is ours is the envelope around it and the way the protocol does without a handshake on a device that cannot afford one. We did not invent new cryptography. We packaged proven cryptography to fit two kilobytes, and that packaging is the part that stays in-house.

What matters here is the shape of the win. A constrained device gets real, modern authenticated encryption that a desktop protocol could not have given it, because the desktop protocol was built for a machine with memory to burn and this one has none.

The power can die mid-sentence

Here is a class of problem that does not exist in the cloud. A server crashes and comes back to a clean slate. An edge device loses power in the middle of anything, at any moment, forever, and has to come back correct.

The cruelest version of this is replay protection. Security depends on never accepting the same message twice, which depends on a counter that only ever moves forward. That counter lives in flash, and the power can cut in the microsecond between advancing it and using it. Get this wrong and the device either reuses a value it must never reuse, or bricks its own security on the first brownout. Making replay protection survive arbitrary power loss, on both ends of the link, with a recovery path for when the two sides drift apart, was a multi-week problem hiding inside a feature that sounds like a footnote. In the cloud it is a footnote. At the edge it is the whole game.

Updating a thing you cannot reach

You cannot SSH into a sensor on a utility pole. If an update bricks it, the fix is a person, a ladder, and a cable, or the device is simply gone. So updates are dual-partition with automatic rollback: the new firmware has to boot and prove itself, and if it does not, the device reverts to the version that worked. The update path has to assume its own failure, because the cost of assuming success is a truck rolling out to a field somewhere.

Reach without a network

WiFi assumes an access point. A lot of the edge has no access point, no cellular, nothing. LoRa buys kilometers at kilobits, and a device can relay for its neighbors without ever decrypting what it forwards, extending the Fabric one hop past the last piece of infrastructure. The mesh does not have to stop where the WiFi stops.

Why this is one system, not a bridge

The point of all of it is what is not there. No separate edge stack bolted onto a cloud stack. No protocol translator in the middle. No second SDK. The same Pulse, the same identity, the same fabric. The five orders of magnitude between a data-center GPU and a four-dollar chip are real, and they are pushed underneath the invocation so the developer never has to hold them. One call. The fabric sorts out that this time it landed on something with two kilobytes to spare.

That is the difference between a device that participates and a device that reports. A thermometer reports. A peer participates. The whole point was to make the small thing a peer.

What is real, and what is hard

It runs, across four chip families, over WiFi, LoRa, cellular, and Ethernet, behind a test suite over a thousand strong plus fuzzing, with thirty-odd hardware drivers. The encryption gap is closed and the protocol works in the field. What stays hard is everything adjacent to power loss: the failure modes that only show up after the ten-thousandth brownout are the ones you find last, and I assume there are more of them waiting.

A computer is a computer whether it costs fifteen thousand dollars or fifteen. Treating the cheap one as a sensor is a habit, not a law of nature, and the habit is expensive. It is why so much of the physical world still cannot act on its own without phoning home first. Make the small thing a peer and the network stops ending at the data center.

Next I will go the other direction, up the stack, to what actually runs on this fabric and why it thinks in geometry instead of text.

If you build embedded systems, edge runtimes, or Rust infrastructure, or you're hiring someone who has built the whole path from the microcontroller up, I want to hear from you. [email protected]