Servidor web en un chip de USD 2: cómo funciona
Un servidor web en microcontrolador 8 bits es exactamente lo que suena: una computadora del tamaño de una uña, con 384 bytes de RAM y 32 KB de Flash, sirviendo páginas HTML por TCP/IP. El proyecto de Maurycy con el AVR64DD32 lo prueba en 2026: arranca un stack HTTP mínimo sobre SLIP serial y le da acceso a cualquier browser. No es para producción. Es para entender cómo funciona la web desde los cimientos.
En 30 segundos
- El AVR64DD32 tiene 384 bytes de RAM, 32 KB de Flash y corre a 24 MHz máximo, con periféricos I/O limitados a 12 MHz.
- Ethernet 10BASE-T usa Manchester encoding y opera a 20 Mbps reales en la línea, demasiado rápido para el AVR. SLIP sobre serial es la alternativa funcional.
- SLIP (RFC 1055) envuelve paquetes en bytes 0xC0 y escapa caracteres especiales con 0xDB. Sin overhead de negociación, sin estado: ideal para hardware limitado.
- El AVR64DD32 cuesta menos que modelos anteriores como el ATmega328, con más memoria para el mismo precio.
- El caso de uso real es IoT local, paneles de configuración embebidos y demostraciones técnicas, no tráfico público.
¿Por qué hostear un sitio web en un microcontrolador?
El AVR64DD32 es un microcontrolador de 8 bits de la familia AVR, similar al ATmega328 que popularizó Arduino pero más moderno y barato. Tiene un único core AVR corriendo a 24 MHz máximo, 384 bytes de RAM, 32 KB de Flash, 512 bytes de EEPROM, y usa un solo pin de programación en vez de los tres del protocolo ISP clásico. Comparado con el ATmega328, ofrece más memoria por el mismo precio.
¿Y qué hacés con eso? Bueno, si sos Maurycy, le ponés un servidor web.
La pregunta real es: ¿tiene sentido? Y la respuesta depende de para qué. Para hobby engineering puro, para entender TCP/IP desde cero, para armar un panel de control embebido que no depende de nada externo, sí. Para hostear tu portfolio, obvio que no. El punto es que se puede, y entender cómo funciona enseña más sobre redes que leer cinco libros de teoría.
Limitaciones del hardware y decisiones de diseño
Arrancemos con los números que mandan:
- CPU: 8 bits, 24 MHz máximo
- RAM: 384 bytes
- Flash: 32 KB
- I/O y periféricos: máximo 12 MHz
Con 384 bytes de RAM, el stack TCP/IP tiene que ser microscópico. Cada variable que declarás es un byte que le sacás al buffer de red. No hay margen para librerías pesadas ni frameworks.
Ethernet era la opción obvia para conectarlo a internet, pero el problema es físico: según el proyecto de Maurycy, 10BASE-T (la versión más lenta de Ethernet) corre a 10 Mbps, pero como usa Manchester encoding, en la línea son 20 Mbps reales. Los periféricos del AVR no llegan a 12 MHz. Matemáticamente, es imposible generar esa señal sin un chip dedicado como el ENC28J60. Y comprar ese chip implica esperar semanas. Acá viene la decisión que hace interesante al proyecto.
SLIP: el protocolo de los años ’80 que resuelve el problema
SLIP es Serial Line Internet Protocol, definido en RFC 1055 en 1988. El protocolo más simple que existe para correr redes sobre serial. Las reglas son tres:
- Antes de mandar un paquete, envolvelo en bytes 0xC0.
- Si el paquete contiene algún byte 0xC0, reemplazalo con 0xDB 0xDC.
- Si el paquete contiene un byte 0xDB, reemplazalo con 0xDB 0xDD para evitar ambigüedad.
Eso es todo. Sin handshake, sin negociación de velocidad, sin estado. Un receptor lee bytes, arma paquetes entre 0xC0s, y los pasa al stack IP. La UART del AVR maneja esto sin drama a 9600-115200 baud, velocidades que el hardware puede generar sin problemas.
Frente a PPP (otra alternativa para enlaces seriales), SLIP gana por simplicidad. PPP es más correcto, soporta autenticación, negociación de IP. Pero para un microcontrolador con 384 bytes de RAM, PPP es un lujo que no cabe. SLIP zafa perfectamente para el caso de uso. Sobre eso hablamos en cómo registrar y configurar tu dominio.
Hardware requerido: comparativa de métodos de conexión
| Método | Hardware adicional | Velocidad | Complejidad | Compatible con AVR básico |
|---|---|---|---|---|
| Ethernet (ENC28J60) | Chip SPI dedicado, ~USD 3-5 | 10 Mbps | Alta (driver SPI, stack completo) | Sí, con chip |
| SLIP serial | Solo UART (ya integrada) | 115.2 kbps máximo | Mínima | Sí, sin nada extra |
| WiFi (ESP8266/ESP32) | Módulo externo, ~USD 2-4 | 54 Mbps (802.11g) | Media (AT commands) | Parcialmente |
| Bluetooth | Módulo HC-05/HC-06 | 3 Mbps (BT 2.0) | Media | No práctico para web |
El AVR64DD32 tiene UART integrada. Con SLIP, el único cable que necesitás es un convertidor USB-serial de unos pocos pesos, o directamente un cable null-modem a otro equipo. El costo de entrada es casi cero (el microcontrolador sale menos de USD 2 en volumen).
Implementación técnica: stack TCP/IP que entra en 32 KB
Ponele que llegaste hasta acá y querés probarlo. El desafío no es SLIP, es meter un stack TCP/IP funcional en 32 KB de Flash con 384 bytes de RAM.
Hay implementaciones históricas que muestran que es posible. El proyecto de tuxgraphics implementó un servidor web sobre ATmega88 (mismo tamaño de Flash que el AVR64DD32) que sirve cientos de páginas por segundo en condiciones de tráfico mínimo. El truco: el HTML se almacena en Flash (no en RAM), la RAM solo tiene buffers de red y variables de estado.
Para Arduino hay librerías modernas. EthernetWebServer en GitHub soporta ATmega328, ESP8266 y una docena de plataformas más. El ejemplo mínimo arranca en menos de 10 KB de Flash. Lo que limita no es el servidor en sí, sino cuánto contenido podés servir: con 32 KB de Flash compartido entre código y datos, el HTML real que podés almacenar es del orden de 5-10 KB comprimidos.
Subís el HTML a Flash, compilás el servidor, flasheás el chip, lo conectás por serial, configurás SLIP en el host, le asignás una IP, y de repente tenés una dirección HTTP que sirve contenido real desde un chip que corre a 24 MHz y consume menos de 50 mA. (Sí, en serio.)
Ejemplos de implementaciones reales
mcusite de Maurycy (AVR64DD32, 2026)
El proyecto más reciente y documentado. Usa el AVR64DD32 con SLIP serial, sin hardware adicional. La página está viva en producción (aunque con la advertencia de que puede caerse si se postea a Hacker News, lo cual dice bastante sobre la capacidad de concurrencia). El código es de una persona, sin dependencias externas, construido desde cero para demostrar el concepto.
tuxgraphics ATmega88 web server
Proyecto histórico de 2006 que sigue siendo referencia. El ATmega88 tiene las mismas limitaciones de la familia AVR. Implementa un stack TCP/IP mínimo con Ethernet via ENC28J60, sirve páginas estáticas con buena velocidad para el hardware. La documentación original explica la arquitectura del stack en detalle. Lo explicamos a fondo en despliegues automatizados en dispositivos embebidos.
Arduino con Ethernet Shield
El más accesible. ATmega328 + Wiznet W5100 o W5500. El W5100/W5500 maneja el stack TCP/IP por hardware, así que el AVR solo escribe bytes por SPI y lee respuestas. Más caro (el shield sale USD 5-15), pero más simple de programar. Sirve para entender HTTP sin tener que implementar TCP desde cero.
Casos de uso prácticos y limitaciones reales
¿Y quién usaría esto en la práctica? Hay casos legítimos.
El más claro es IoT local: un microcontrolador que controla una bomba de riego, un sensor de temperatura, o un relay, con una interfaz web mínima para configurar parámetros sin tener que flashear el dispositivo. Sin nube, sin dependencias externas, sin suscripción mensual.
¿Cuántos usuarios puede servir? Uno a la vez, o dos si el timing es generoso. No hay concurrencia real. El stack TCP/IP mínimo maneja una conexión, termina la respuesta, y queda libre para la siguiente. Para configuración de dispositivos donde nunca hay más de una persona conectada, alcanza perfectamente.
Las limitaciones son claras: seguridad mínima (no hay recursos para TLS), contenido estático solamente (no hay memoria para generar HTML dinámico complejo), y velocidad limitada por el link serial. Tampoco es algo que querrías exponer a internet pública. Para tráfico interno, en una red local, para un caso de uso específico, funciona.
Si lo que necesitás es hosting real, con dominio, tráfico variable y disponibilidad 24/7, la respuesta correcta es un proveedor de hosting como donweb.com y no un microcontrolador en un cajón.
Comparativa: microcontrolador vs hosting tradicional
| Criterio | Microcontrolador AVR | Hosting web tradicional |
|---|---|---|
| Costo hardware | USD 2-15 (único pago) | USD 0 (ya tenés computadora) |
| Costo mensual | USD 0 | Desde USD 3-5/mes |
| Usuarios concurrentes | 1-2 (sin concurrencia real) | Cientos a miles |
| Contenido soportado | HTML estático, ~5-10 KB | Sin límite práctico |
| TLS/HTTPS | No factible | Incluido |
| Mantenimiento | Cero (una vez flasheado) | Actualizaciones, monitoreo |
| Consumo energético | Menos de 50 mA | N/A (VPS compartido) |
| Caso de uso ideal | IoT local, config embebida | Cualquier sitio público |
Qué está confirmado y qué no
Confirmado
- El AVR64DD32 puede correr un servidor HTTP funcional usando SLIP serial, según el proyecto documentado de Maurycy.
- SLIP (RFC 1055) es el protocolo correcto para este caso: mínimo overhead, implementable en cientos de bytes de código.
- Implementaciones similares existen desde 2006 (tuxgraphics) y siguen siendo funcionales.
- El límite de contenido es de aproximadamente 5-10 KB de HTML en Flash, con el código del servidor ocupando el resto de los 32 KB.
No confirmado / hay que verificar
- La velocidad real de respuesta del proyecto de Maurycy no está documentada con benchmarks específicos.
- Cuántas requests por segundo puede manejar el AVR64DD32 con SLIP a 115200 baud (el proyecto no publica métricas).
- Si alguna versión futura del AVR podría manejar Ethernet sin chip externo, por ahora no hay candidatos viables.
Errores comunes al implementar esto
Usar RAM para almacenar el HTML
El error más frecuente en proyectos AVR para principiantes. Con 384 bytes de RAM, si metés el HTML ahí, no queda espacio para buffers de red ni variables. El HTML tiene que vivir en Flash usando PROGMEM en AVR-GCC. Es una diferencia de diez líneas de código que hace posible el proyecto. Esto se conecta con lo que analizamos en comparativa entre hosting propio y servicios gestionados.
Intentar Ethernet sin chip dedicado
Los periféricos del AVR llegan a 12 MHz. Ethernet 10BASE-T necesita 20 MHz en la línea. No hay workaround de software que resuelva esto. Si querés Ethernet, necesitás un chip como el ENC28J60 o el Wiznet W5500. Con SLIP serial evitás la discusión.
Asumir que podés servir contenido dinámico
Generar HTML dinámico en runtime implica strings, concatenaciones, buffers temporales. Con 384 bytes de RAM, eso no existe. Lo que podés hacer es tener placeholders fijos en el HTML y reemplazar bytes específicos (por ejemplo, el valor actual de un sensor), pero no renderizar templates. Ajustá las expectativas antes de empezar.
Olvidarse de configurar SLIP en el host
El AVR habla SLIP, pero el host que lo conecta (tu computadora, una Raspberry Pi, lo que sea) también tiene que hablar SLIP. En Linux se configura con slattach y ifconfig. Si saltás ese paso, tenés bytes seriales que no se convierten en paquetes IP y el servidor no responde a nada. La mitad de los proyectos que “no funcionan” están en este paso.
Si querés profundizar, tenemos un artículo sobre Hosting a website on an 8-bit microcontroller.
Preguntas Frecuentes
¿Se puede hostear un sitio web en un microcontrolador de 8 bits?
Sí. El AVR64DD32 con 32 KB de Flash y 384 bytes de RAM puede correr un servidor HTTP mínimo usando SLIP como protocolo de red. El contenido HTML se almacena en Flash para no consumir RAM. El resultado es funcional para un usuario a la vez en red local, pero no sirve para tráfico público.
¿Cuál es la diferencia entre Ethernet y SLIP para microcontroladores?
Ethernet 10BASE-T usa Manchester encoding y opera a 20 Mbps reales en la línea, más rápido que los periféricos del AVR (12 MHz máximo). SLIP corre sobre UART serial a velocidades de hasta 115200 baud, completamente manejable por el hardware. Ethernet requiere un chip dedicado como el ENC28J60; SLIP solo necesita la UART integrada. Ya lo cubrimos antes en optimizar contenido multiidioma en tu sitio.
¿Cuántos usuarios puede servir un servidor web en AVR?
Uno a la vez, en la práctica. Los stacks TCP/IP mínimos para microcontroladores no implementan concurrencia real: atienden una conexión, terminan la respuesta, y quedan libres. Para casos de uso de IoT o configuración de dispositivos donde nunca hay más de una persona conectada simultáneamente, alcanza perfectamente.
¿Qué hardware se necesita para hacer un servidor web con Arduino?
Con un Arduino UNO (ATmega328) y un Ethernet Shield basado en Wiznet W5100 o W5500, tenés todo lo necesario. El W5100/W5500 maneja el stack TCP/IP por hardware y se comunica con el AVR por SPI. El shield sale entre USD 5 y USD 15. Alternativamente, con SLIP solo necesitás un convertidor USB-serial de unos pocos dólares.
¿Por qué alguien querría hostear un sitio en un microcontrolador?
Hay razones prácticas: dispositivos IoT que necesitan una interfaz de configuración sin depender de la nube, equipos embebidos con panel de control web, o proyectos de aprendizaje donde el objetivo es entender TCP/IP desde los fundamentos. No es para sitios públicos. Es para casos donde el hardware ya existe, no hay conectividad a internet, y necesitás una UI mínima accesible desde la red local.
Conclusión
El servidor web en microcontrolador 8 bits es un ejercicio de ingeniería que enseña más sobre cómo funciona internet que la mayoría de los tutoriales de redes. El AVR64DD32 con SLIP serial lo logra sin hardware adicional, con menos de USD 2 de costo, y con un stack TCP/IP que entra holgadamente en 32 KB de Flash. La clave es SLIP como protocolo (simple, sin overhead, compatible con UART) y el almacenamiento de HTML en Flash en vez de RAM.
¿Alguien lo usaría en producción para un sitio público? No, y no debería. Pero para IoT local, para entender redes desde los cimientos, o para demostrar que la complejidad de la web moderna no es inevitable, es un proyecto que vale la pena.
Lo que muestra este tipo de implementación es que HTTP es un protocolo de texto plano sobre TCP, y TCP puede correr sobre casi cualquier cosa que pueda mover bits de un lado al otro. El resto es software. Y con 32 KB de Flash, ese software alcanza.
Fuentes
- Maurycy — Hosting a website on an 8-bit microcontroller (proyecto original AVR64DD32)
- RFC 1055 — Serial Line Internet Protocol (SLIP, especificación original)
- tuxgraphics — ATmega88 web server (implementación histórica de referencia)
- EthernetWebServer — Librería Arduino para servidor HTTP en AVR y ESP
- Academia.edu — AVR Microcontroller Based Web Server (paper técnico)
