Serving Web Pages from a PIC16F84: When Every Byte Counts

Serving HTTP/1.1 from a 68-Byte RAM Microcontroller: A Study in Humiliation

Forget react-dom hydration times and the latest CSS-in-JS bundle bloat. For a moment, let’s talk about genuine resource constraint. Imagine needing to serve a basic status page from a PIC16F84. If that sentence made you recoil, you’re in the right place. This isn’t about the novelty of a tiny chip speaking HTTP; it’s about the sheer, unadulterated engineering required to make it not immediately die, and what that implies for anyone who thinks their 8KB microcontroller project is “tight.”

The common narrative around embedded web servers often glosses over the terrifying reality of minuscule RAM budgets. A recent demonstration might showcase an AVR64DD32 with its comparatively opulent 8KB of SRAM and 64KB of Flash. That’s a spacious mansion compared to the PIC16F84’s typical 68 bytes of RAM and 1-2KB of program memory. Serving even a single byte of HTTP data from that PIC requires a level of byte-level frugality that makes optimizing Rust’s jemalloc feel like a casual Tuesday afternoon.

The Protocol as a Wire Frame: SLIP

Modern web development exists atop layers of abstraction designed for speed and convenience. An embedded system, especially one pushing the boundaries of the absurd like the PIC16F84, rips all of that away. We’re talking about a raw serial link, typically using Serial Line Internet Protocol (SLIP), RFC 1055. SLIP isn’t a protocol in the modern sense; it’s a framing mechanism for IP packets over serial lines. It’s brutally simple: data is framed by a special byte, 0xC0. If a 0xC0 byte appears in the payload, it’s escaped by a preceding 0xDB byte and a special end-of-byte marker (0xDC for 0xC0, 0xDD for 0xDB).

This simplicity is its only virtue when your CPU runs at 12 MHz and your RAM is measured in tens of bytes. It avoids the overhead and complexity of protocols like PPP, which offers more features but demands more resources. On the receiving end, a host system can attach this serial port as a network interface using tools like slattach on Linux. The system then dutifully adds IP and TCP headers. A standard IPv4 header alone is 20 bytes, and a TCP header is another minimum of 20 bytes. Even if SLIP could somehow accommodate them, that’s 40 bytes of overhead for every single packet.

Under-the-Hood: The escape mechanism itself is a subtle trap. To insert a 0xC0 (END frame byte) into the payload, the sender must replace it with 0xDB 0xDC. Similarly, to insert a 0xDB (ESCAPE byte) into the payload, it must be replaced with 0xDB 0xDD. This means that even a perfectly formed data byte that happens to be 0xC0 or 0xDB will consume two bytes of transmission bandwidth and require extra processing time for both escaping on transmit and unescaping on receive. For a system where every clock cycle and every RAM location is accounted for, this is a significant consideration.

The Harsh Realities: PIC16F84 vs. AVR64DD32

Let’s be clear: the AVR64DD32 example, with its 8KB RAM, is already an exercise in extreme restraint. The engineers there are meticulously crafting “clean, minimal implementations.” Now, imagine trying to run any sort of network stack – even a fragmented one – on 68 bytes of RAM.

A typical TCP/IP stack requires buffers for both transmit and receive. Even a tiny IP packet (say, 40 bytes of headers plus a few bytes of payload) would struggle to fit. Storing the SLIP frame bytes, managing the TCP state machine, and handling application data simultaneously is likely impossible. The PIC16F84’s program memory (1-2KB) is also a severe limitation. You can’t just “include” a TCP/IP library. You’re likely hand-rolling assembly for critical path functions, minimizing function call overhead, and praying you don’t overflow the stack with a single interrupt.

The concept of “bundle size” as we understand it in web development is an alien concept here. A “web page” served from a PIC16F84 wouldn’t be HTML with embedded CSS or JavaScript. It would be a string literal, probably containing sensor readings or a simple status code, transmitted with minimal HTTP headers. Anything more, and you’re out of RAM and Flash before you’ve even sent the first character.

Performance Metrics: Bytes Per Minute, Not Megabits Per Second

When you’re running an 8-bit microcontroller with a few KB of program space and tens of bytes of RAM, performance isn’t measured in latency percentiles. It’s measured in how long it takes to transmit enough data for the next state change.

Consider the serial link itself. A common baud rate for embedded systems might be 115,200 bits per second. If we assume a standard 10 bits per byte (8 data bits, 1 start, 1 stop), that’s roughly 11,520 bytes per second at best. Now factor in the SLIP framing, the IP/TCP headers, and the microcontroller’s own processing time. You’re looking at throughput likely measured in single-digit kilobytes per second, if you’re lucky.

A common SLIP datagram size limit is around 1006 bytes. After IP (20 bytes) and TCP (20 bytes) headers, you have perhaps 966 bytes for your application data. Transmitting this single packet could take upwards of a tenth of a second, not including the processing time on the PIC. This is why any discussion of “framework fatigue” or “client-side rendering” is laughably irrelevant. There is no client-side logic to render. The server sends bytes, and the client displays them as raw text.

Bonus Perspective: The Human Interface Problem

Beyond the raw technical hurdles, consider the user experience. A “web page” from a PIC16F84 would be a raw text stream. There’s no <h1>, no <p>, no semantic structure. Accessibility, in the modern sense of ARIA attributes and semantic HTML, is non-existent. A user would need to understand the exact format of the expected output to make any sense of it. This effectively turns the “web page” into a command-line interface exposed over HTTP, with all the usability drawbacks that entails. Anyone accessing this would likely be another embedded engineer or a hobbyist who knows precisely what to expect, probably by pre-arranging the IP address and the exact output format. This isn’t a user-friendly interface; it’s a low-bandwidth, high-friction data pipe.

Opinionated Verdict: When Is This Engineering Actually Warranted?

Serving a web page from a PIC16F84 is an engineering feat that borders on masochism. It’s a profound demonstration of what’s technically possible when you strip away every ounce of convenience. However, the practical application is vanishingly small. For any scenario where you can afford an 8KB RAM microcontroller (like the AVR64DD32 example), you can likely afford a more capable system that can run a lighter-weight network stack and serve more meaningful data.

This exercise is valuable primarily as a thought experiment, pushing the boundaries of resource constraints to understand the absolute minimum required for network communication. If your goal is simply to expose a status or sensor reading from a hyper-constrained device, a direct serial connection, a lightweight messaging protocol like MQTT over a point-to-point link, or even a simple UDP broadcast might be significantly more practical and reliable than attempting to implement a full TCP/IP stack and HTTP server on hardware that barely has enough RAM to store a single TCP segment. The real question isn’t “can we,” but “should we,” and the answer for anything beyond a highly specialized, deeply embedded niche is almost always no.