⏱️ Lectura: 12 min
En su blog personal, el ingeniero Maurycy logró algo que parece absurdo en 2026: hospedar un sitio web funcional en un microcontrolador de 8 bits que cuesta un dólar y solo tiene 8 KB de RAM. Sin chip dedicado de Ethernet, sin sistema operativo y sin librerías externas de red. Solo un AVR64DD32, un cable serial y una implementación artesanal del stack TCP/IP.
📑 En este artículo
El proyecto, publicado entre el 11 y el 14 de mayo de 2026, recorre los puntos donde la ingeniería embebida choca con protocolos pensados para máquinas mil veces más potentes. De paso demuestra que, con creatividad, hasta un chip de ocho bits puede vivir en el internet moderno.
TL;DR
- Maurycy hospedó un sitio web en un AVR64DD32: microcontrolador de 8 bits, 24 MHz, 8 KB de RAM, 64 KB de flash, $1.
- Descartó Ethernet porque 10BASE-T exige 20 Mbps en el cable (Manchester encoding), fuera del alcance del chip.
- Usa SLIP (RFC 1055, de 1988), un protocolo serial que Linux todavía soporta nativo con slattach.
- Implementó IP y TCP a mano en C; HTTP es una respuesta hardcoded para una sola URL.
- Para exponerlo en internet, tunelizó tráfico con WireGuard hacia un VPS en Helsinki bajo /mcu.
- El chip se alimenta del riel de 5 V del adaptador USB-serial: una sola cable, sin componentes externos.
- El demo está vivo en el blog del autor y puede caerse si recibe demasiado tráfico desde Hacker News.
El experimento: una web en un microcontrolador de 8 bits
Maurycy abre su artículo con la frase dumb things to do with an AVR microcontroller (cosas tontas que hacer con un microcontrolador AVR), pero el experimento es cualquier cosa menos tonto. Es un ejercicio brutalmente educativo sobre cuántas capas damos por sentadas cada vez que escribimos curl https://.... Cuando uno desciende al nivel de un microcontrolador de 8 bits, esas capas dejan de ser invisibles: hay que escribir cada una.
El reto se enuncia en una sola frase: que un chip de un dólar sirva una página HTML por TCP/IP. Pero cada palabra de esa frase esconde una pelea distinta. Servir exige un loop de eventos. Página exige memoria para almacenarla. TCP exige una máquina de estados con retransmisiones. IP exige campos de cabecera y checksums. Y todo eso, encima de un procesador con menos RAM que un mensaje de WhatsApp con video.
El resultado funciona. Una URL pública, un proxy de por medio y un microcontrolador respondiendo HTTP. La fuente C del firmware ocupa www.c y la web está disponible en /mcu del propio blog del autor.
El hardware: AVR64DD32, $1 y 24 MHz
El protagonista es el AVR64DD32 de Microchip, primo cercano del clásico ATmega328 que popularizó Arduino. Su hoja de datos es modesta hasta el delirio: un núcleo AVR de 8 bits a 24 MHz máximo, 8 KB de SRAM estática, 64 KB de flash, 256 bytes de EEPROM y un rango de voltaje de 1.8 a 5.5 V. Cuesta alrededor de un dólar en cantidades pequeñas.
Comparado con el ATmega328, los AVR DD aportan tres ventajas: son más baratos a la misma capacidad de memoria, usan un solo pin para programación (UPDI en vez de SPI con seis pines) y tienen periféricos más modernos. La trampa, advierte Maurycy, es que aunque la CPU corre a 24 MHz, los periféricos y pines de IO se topan en 12 MHz. Ese techo es el que mata cualquier sueño de Ethernet.
El consumo es ínfimo: pocos milivatios. Eso permite alimentar el chip directamente desde el riel de 5 V del adaptador USB-serial, sin fuente externa. La placa final tiene el microcontrolador, dos LEDs blinkenlights, un diodo de protección contra inversión de polaridad y poco más. Es difícil construir un servidor más austero.
Por qué no Ethernet (y por qué SLIP)
La opción obvia para meter un dispositivo en internet es Ethernet. El estándar más lento que sigue vivo, 10BASE-T, corre a 10 megabits por segundo. Pero esos 10 Mbps son la velocidad de datos, no la velocidad en el cable: 10BASE-T usa Manchester encoding, que codifica cada cero como 10 y cada uno como 01. El cable, en realidad, lleva 20 Mbps.
Para un microcontrolador de 8 bits limitado a 12 MHz en sus pines, generar esa señal es físicamente imposible sin un chip dedicado. Maurycy menciona que comprar un PHY de Ethernet por DigiKey es lo correcto, pero significa semanas de espera. Optó por una solución más vieja, más rara y más elegante: SLIP, el Serial Line Internet Protocol descrito en el RFC 1055 de 1988.
SLIP es ridículamente simple. Envuelve cada paquete IP entre bytes 0xC0 como delimitadores. Si el paquete contiene un 0xC0 natural, lo reemplaza por 0xDB 0xDC. Si contiene un 0xDB, lo reemplaza por 0xDB 0xDD. No tiene autenticación, no tiene checksum, no negocia parámetros. Pero funciona.
📌 Nota: SLIP existía antes de PPP. En los 90, cuando uno se conectaba a internet por dial-up, el módem creaba un enlace serial sobre la línea telefónica y SLIP (o más tarde PPP) movía paquetes IP encima. El soporte nunca se quitó del kernel de Linux.
El bonus es que el lado Linux no necesita nada especial. Un adaptador USB-serial cualquiera y dos comandos bastan para que el sistema operativo trate al microcontrolador como una interfaz de red más:
# Configurar el puerto serial
stty -F /dev/ttyUSB0 115200 raw cs8
# Crear interfaz de red SLIP
slattach -m -F -L -p slip /dev/ttyUSB0
# Asignar IP al enlace y rutearlo
ip addr add 10.0.0.1/24 dev sl0
ip link set sl0 upDespués de eso, hablar con el AVR es indistinguible de hablar con un servidor Linux vecino: ping, curl, nmap, todo funciona.
IP y TCP escritos a mano
Tener un enlace de datos no es tener internet. Para que una página llegue de un servidor a un navegador, cada paquete viaja con una cabecera IP de unos 40 bytes que contiene dirección de origen, destino, TTL y otros campos. La buena noticia es que la versión moderna de IP se simplificó mucho. La fragmentación, que en los 90 obligaba a reensamblar paquetes en memoria, está deshabilitada por defecto en todos los sistemas operativos modernos. IPv6 ni siquiera la incluye.
Eso permite que el AVR implemente IP de la forma más perezosa posible: cuando llega un paquete, intercambia las direcciones de origen y destino, resetea el contador TTL y devuelve eso como cabecera de respuesta. Fin del IP.
TCP es otro animal. Es el protocolo que garantiza que los bytes lleguen, en orden y sin pérdida, sobre un IP que no garantiza nada. Para eso necesita una máquina de estados completa (LISTEN, SYN_SENT, ESTABLISHED, FIN_WAIT, etc.), retransmitir paquetes que se perdieron, descartar duplicados, manejar ventanas de congestión y lidiar con un universo de casos límite.
Maurycy estima que le tomó varios días llevarlo a un estado funcional, y reconoce que su implementación todavía tiene bugs. HTTP, en cambio, lo despachó en un párrafo: el servidor envía siempre una respuesta hardcoded. Una sola URL, una sola página. Suficiente para que el experimento sea real.
El truco final: WireGuard hacia un VPS
El microcontrolador ya habla TCP/IP, pero solo dentro de la red local del autor. Para que cualquier persona en internet pueda visitarlo hace falta una dirección IPv4 pública y enrutable. Esas direcciones son caras, escasas y, para colmo, Maurycy no tiene buena conexión desde su casa (la nota incluye un jab a Starlink).
La salida es un VPS en Helsinki que sí tiene IP pública. Pero conectar la máquina Linux de casa a ese VPS sin abrir puertos requiere otra herramienta del cinturón de utilidades de Linux: WireGuard. Crea una red virtual encriptada por encima de internet, atraviesa NAT y CGNAT sin drama y se levanta con un par de archivos de configuración.
El flujo final luce así:
graph LR
A["AVR64DD32"] --> B["USB-Serial"]
B --> C["Linux con SLIP"]
C --> D["VPS Helsinki por WireGuard"]
D --> E["nginx /mcu"]
E --> F["Navegador del visitante"]Como no quería que el sitio del MCU se comiera la URL principal del VPS, Maurycy configuró el servidor para proxiar bajo /mcu hacia un bloque de direcciones locales del túnel. Los visitantes no hablan directamente con el stack TCP del AVR, lo cual también lo aísla parcialmente de paquetes maliciosos.
💡 Tip: Si querés replicar el experimento desde LATAM, donde las conexiones residenciales rara vez ofrecen IPv4 pública estable, WireGuard hacia un VPS en DigitalOcean, Hetzner o un proveedor regional es el camino más simple. Cuesta menos de $5 al mes y se levanta en una tarde.
Lecciones para makers y devs embebidos en LATAM
El proyecto tiene poco valor comercial directo. Nadie va a hospedar producción en un microcontrolador de 8 bits cuando un ESP32 cuesta tres dólares y trae Wi-Fi, BLE, doble núcleo y soporte para FreeRTOS. Pero el experimento es enormemente valioso como ejercicio pedagógico y como recordatorio de cuánta complejidad enterramos debajo de tres líneas de Python con flask run.
Para quien recién entra al mundo embebido en la región, la lectura del código fuente de Maurycy es una clase magistral en presupuestos de memoria. Cada estructura tiene que justificar sus bytes, cada buffer tiene que cerrarse, cada flag de TCP que se ignora es un caso límite que tarde o temprano explota. El stack TCP/IP, que muchos cursos universitarios cubren en abstracto, se vuelve concretísimo: este es el código que decide qué hacer cuando llega un RST inesperado.
También hay una moraleja sobre IPv6. Maurycy cierra su nota notando que todo el rodeo con WireGuard y proxies existe porque el mundo nunca terminó de migrar a IPv6, donde cada dispositivo (microcontrolador incluido) podría tener una dirección global única. En LATAM la situación es peor que en Europa: la región adopta IPv6 más lento que el promedio mundial, y muchos ISPs siguen sin entregar IPv6 nativo a clientes residenciales.
💭 Clave: Si IPv6 estuviera realmente desplegado, cada AVR de un dólar podría tener su propia dirección pública y conversar directo con el internet. La carencia no es técnica: es de despliegue.
Para quien quiera ir más allá, el autor también referencia el Vape Server (ewaste.fka.wtf), un sitio hosteado en un microcontrolador de 32 bits sacado literal de la basura electrónica. Si un AVR de 8 bits puede servir HTTP, un MCU rescatado de un cigarrillo electrónico desechable también. El mensaje es claro: el hardware que ya consideramos basura tiene capacidad de cómputo suficiente para tareas no triviales.
📖 Resumen en Telegram: Ver resumen
Preguntas frecuentes
¿Qué es un microcontrolador de 8 bits?
Es un chip cuyo procesador maneja datos en palabras de 8 bits (un byte) por operación. Son más baratos, consumen menos energía y tienen menos memoria que CPUs de 32 o 64 bits, pero suficientes para tareas como leer sensores, controlar motores o, como demostró Maurycy, servir páginas web simples.
¿Por qué no usar un ESP32 o una Raspberry Pi?
Porque no es el punto. Un ESP32 trae Wi-Fi integrado y un stack TCP/IP ya escrito, así que el experimento se vuelve trivial. El AVR64DD32 obliga a implementar todo a mano, que es donde está el aprendizaje. También cuesta menos: $1 contra $3-5 del ESP32 y mucho más de una Raspberry Pi.
¿Qué es SLIP y por qué Linux lo soporta todavía?
SLIP (Serial Line Internet Protocol, RFC 1055) es un protocolo de 1988 para enviar paquetes IP sobre un enlace serial. Lo usaron los módems dial-up de los 80 y 90. Linux conserva el soporte porque ocupa poco código, no estorba y permite proyectos como este sin instalar nada adicional.
¿Puedo replicar el proyecto en casa?
Sí. Necesitás un AVR64DD32 (o un ATmega328 con adaptaciones), un adaptador USB-serial, una máquina Linux y opcionalmente un VPS para exponerlo a internet. El código fuente C está publicado en el blog del autor. La curva de aprendizaje es alta, pero todo el material para hacerlo está disponible.
¿El experimento es seguro de cara a internet?
No mucho. Un stack TCP/IP escrito en pocos días por una sola persona tiene casi con certeza bugs explotables. Maurycy mitiga el riesgo proxiando el tráfico bajo /mcu en su VPS y limitando lo que llega directamente al chip. Para un servidor real no se recomienda exponerlo sin esa capa intermedia.
¿Tiene sentido productivo o solo es un hack?
Como producto comercial, ninguno: hay opciones mejores y más baratas. Como ejercicio educativo y prueba de concepto, mucho. Ayuda a entender redes, embebidos y los compromisos de diseño de TCP/IP a un nivel que pocos cursos llegan a tocar.
Referencias
- Hosting a website on an 8-bit microcontroller — Maurycy’s blog — Artículo original con código fuente, video y demo en vivo.
- RFC 1055 — A Nonstandard for Transmission of IP Datagrams over Serial Lines: SLIP — La especificación oficial de SLIP, publicada en 1988.
- Serial Line Internet Protocol — Wikipedia — Resumen histórico y contexto del protocolo SLIP.
- WireGuard — sitio oficial — Documentación del protocolo VPN usado para exponer el MCU.
- lcamtuf: PSA — if you’re a fan of ATmega, try the AVR Dx line — Comparación entre la serie ATmega y los nuevos AVR Dx.
📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.
0 Comentarios