Cómo alojar un sitio web en un microcontrolador de 8 bits

 (maurycyz.com)
1 puntos por GN⁺ 1 시간 전 | 1 comentarios | Compartir por WhatsApp
  • Se alojó un sitio web usando únicamente un MCU de 8 bits AVR64DD32, funcionando en un entorno pequeño de CPU a 24MHz, 8KB de RAM y 64KB de Flash
  • Como incluso 10BASE-T es demasiado rápido para generar señales Ethernet directamente, se usó un enlace USB-Serial como si fuera una interfaz de red mediante SLIP compatible con Linux
  • SLIP es un método simple que envuelve los paquetes con 0xC0 y escapa bytes especiales, por lo que resulta adecuado para conectar un MCU con Linux moderno
  • La parte de IP se simplificó gracias a que la fragmentación está desactivada, pero la implementación de TCP requirió manejar estados de conexión, retransmisiones y casos excepcionales; tomó varios días y aún tiene errores
  • El acceso externo usa una estructura indirecta con VPS, WireGuard y proxy que solo reenvía solicitudes a /mcu, y deja en evidencia que el costo de IPv4 pública y la ausencia de IPv6 son las limitaciones clave

Configuración para alojar un sitio web con un AVR de 8 bits

  • El AVR64DD32 es un MCU de la familia AVR de 8 bits, similar al Atmega328 conocido por Arduino, pero más barato para la misma cantidad de memoria y con un solo pin de programación y mejores periféricos
    • Núcleo AVR único de 8 bits de hasta 24MHz
    • 8KB de RAM estática, 64KB de Flash, 256 bytes de EEPROM
    • Rango de voltaje de 1.8~5.5V, precio de entre $1 y $2
  • Para conectar el MCU directamente a Internet solo con el propio chip, habría que generar señales Ethernet, pero incluso el 10BASE-T más lento es demasiado rápido para este entorno
    • 10BASE-T funciona a 10Mbit/s y, por la codificación Manchester, en la línea real se convierte en 20Mbit
    • La CPU del AVR64DD32 puede llegar hasta 24MHz, pero los periféricos y pines de IO tienen un reloj máximo de 12MHz, así que generar la señal directamente es difícil
    • La forma correcta sería usar un chip Ethernet dedicado, pero había que esperar varias semanas para completar el proyecto
  • Como alternativa se usó SLIP (Serial Line Internet Protocol, RFC 1055) para montar la red sobre un enlace serial
    • Envuelve cada paquete al inicio y al final con el byte 0xC0
    • Dentro del paquete, 0xC0 se reemplaza por 0xDB 0xDC, y el 0xDB original por 0xDB 0xDD para evitar ambigüedades
    • Esto continúa la lógica de los antiguos módems dial-up, que creaban un enlace serial sobre la línea telefónica y dejaban que la computadora manejara la red encima de eso
    • Linux moderno también soporta SLIP, así que un adaptador USB-Serial puede convertirse en una interfaz de red
    • Ejemplos de uso: stty -F /dev/ttyUSB0 115200 raw cs8, slattach -m -F -L -p slip /dev/ttyUSB0
  • El hardware del lado del MCU es simple y puede funcionar incluso sin componentes externos
    • www.c: código fuente
    • www.elf: binario precompilado
    • Se agregaron un LED y un diodo para evitar la conexión inversa de la alimentación
    • El consumo es de apenas unos pocos mW, así que el servidor puede funcionar solo con el riel de 5V del adaptador USB-Serial

Implementación de protocolos y manejo del acceso público

  • La implementación de IP se vuelve simple gracias a las restricciones del entorno moderno
    • Para que una página web llegue a la computadora del usuario, los paquetes deben pasar por varias redes, y cada paquete necesita un encabezado IP de 40 bytes con la dirección de origen, destino y otros datos
    • El IP antiguo requería bastante memoria para manejar correctamente funciones como la fragmentación de paquetes
    • Los sistemas operativos modernos desactivan la fragmentación, e IPv6 la eliminó, así que no hace falta manejarla directamente
    • Se puede crear el encabezado de respuesta intercambiando el origen y el destino del paquete recibido y reiniciando el contador TTL
  • La implementación de TCP es mucho más difícil porque requiere seguimiento del estado de la conexión, retransmisión de paquetes perdidos y manejo de muchos casos excepcionales
    • Tomó varios días lograr que una implementación TCP personalizada funcionara suficientemente bien, y todavía quedan algunos errores
    • HTTP no se implementó por separado; el servidor siempre envía una “respuesta” codificada de forma fija al cliente
    • Si el sitio solo tiene una URL, este enfoque funciona lo bastante bien
    • El proceso de carga puede verse en Video 3
  • Para el acceso externo se necesita una dirección IPv4 pública enrutable, pero el costo y la calidad de la conexión residencial a Internet son obstáculos
    • La máquina con dirección pública enrutable está en un VPS de un centro de datos cerca de Helsinki
    • Con WireGuard en Linux se crea un enlace de red virtual sobre Internet, que funciona incluso si uno de los lados está detrás de CGNAT
    • El resultado es una caja router Linux conectada al VPS para obtener una conexión a Internet más adecuada
  • Como el MCU sigue sin tener una IP pública propia, reenviar todas las solicitudes a la dirección del VPS rompería el sitio web existente
    • En su lugar, se configuró el servidor para hacer proxy solo de las solicitudes bajo /mcu hacia el servidor MCU usando un bloque de direcciones local
    • Los visitantes no se conectan directamente a la pila TCP/IP del MCU, pero es un esquema similar al de Vape Server
    • Hace que sea un poco más difícil romperlo con paquetes SYN, pero en la práctica sigue siendo vulnerable a DDoS porque es un servidor sobre una conexión casi de dial-up
  • La ausencia de IPv6 sigue siendo la causa de fondo de toda esta estructura indirecta

Lecturas relacionadas

1 comentarios

 
GN⁺ 1 시간 전
Comentarios de Hacker News

  • Hace más de 25 años hubo una competencia de exhibicionismo para crear el servidor web más pequeño: https://web.archive.org/web/20000815063022/http://www-ccs.cs...
    La “ganó” alguien que usó un microcontrolador ACE1101; no pude encontrar el artículo original, pero también está esto: https://conceptlab.com/fly/
    Era un servidor web sobre una mosca

    • Yo hice la versión ACE1101 y envié por correo chips preprogramados a un artista en Saskatoon. La explicación original sigue en Archive.org: https://web.archive.org/web/20020605032321/http://d116.com/a...
      Fue muy divertido comprimir el código, y al eliminar ping quedó espacio para agregar I2C bit-banging y subida por UDP al EEPROM, y aun así seguía siendo de menos de 1024 bytes
    • Recordé ese pequeño servidor web hace unos días y también lo publiqué aquí, pero no recibió mucha reacción. Me sigue pareciendo bastante impresionante, tanto entonces como ahora

  • Me gustan las series AVR DD, EA y EB, pero los lanzamientos más recientes de chips de Microchip se ven un poco preocupantes para los fans de AVR: https://www.microchip.com/en-us/products/microcontrollers/32...
    El PIC32 CM tiene la mayoría de las funciones del AVR DD, como sistema de eventos, MVIO y operación a 5V, pero además ofrece un núcleo ARM M0+ de 32 bits más grande y estándar
    Por eso preocupa que el AVR DD haya quedado algo anticuado. El AVR EA y el AVR EB parecen más seguros porque tienen ADC de 12 bits con ganancia programable de 16x, y aunque tienen algo de ruido, son sensibles hasta unos 50 microvoltios, así que son ADC/sensores de corriente ridículamente buenos
    Por otro lado, esto también podría volver más popular a la familia AVR. Me pregunto si el hecho de tener un ARM32 Cortex M0+ compatible a nivel de pines aumenta o reduce la probabilidad de construir sobre la plataforma AVR
    Personalmente creo que lo más importante son los periféricos. El AVR DD probablemente consuma menos energía, especialmente operando a 1.8V, pero no sé si eso basta
    El proyecto en sí es muy interesante, y de todos modos el AVR DD es un gran chip, así que da gusto verlo usarse de verdad
    10BASE-T funciona a 10 megabits/s y, por la codificación Manchester, eso se convierte en 20 megabits sobre la línea; el AVR EB tiene temporizadores PLL x2, así que quizá, con suficiente trabajo, podría sacar codificación Manchester
    Combinando LUT, periféricos UART y circuitería de temporizador acelerada por PLL, parecería posible empujar codificación Manchester de alta velocidad, aunque habría que pensar más si llegaría a 20 Mbit

    • Microchip es conocida por dar soporte a sus chips durante más tiempo que la mayoría de las empresas. Básicamente los siguen fabricando mientras haya demanda, y la serie Dx es bastante reciente
      Jugar con la ruta Cortex-M0 podría ser una señal de que no quieren seguir desarrollando generaciones de plataformas de 8 bits después de Dx. Si llevan las mismas capacidades a otro núcleo de CPU, me parece bien

  • Me gustó poder ver cómo el HTML se transmitía en tiempo real en la página. Me recordó a la época del acceso telefónico, cuando las imágenes se dibujaban lentamente de arriba hacia abajo

    • Qué recuerdos. El terrible acceso telefónico de la escuela era insoportablemente lento comparado con el ISDN 128 del trabajo de mi padre
      Ahí podías bajar varias canciones en una sola conexión, primero por FTP y después por Napster

  • Al ver el título, lo primero que pensé fue: “muchos dispositivos embebidos/IoT hacen algo así”
    Aquí hay un ejemplo de 8051 con Ethernet 10/100 integrado: https://www.asix.com.tw/public/index.php/en/product/Microcon...

  • Me parecieron interesantes dos cosas. Primero, hay una fe de erratas de 2025 para el RFC 1055 que no está en el www.c de aquí. Esa fe de erratas muestra de forma bastante convincente cómo cambia el algoritmo de decodificación, y en este caso el otro extremo del enlace realmente es Linux
    Segundo, el siguiente destino probablemente sea RFC 1144

  • La combinación ENC28J60 + PIC18 era exactamente la configuración que hacía esto mismo en los demos que Microchip distribuía comúnmente hace 20 años

  • Me gusta que el proxy no haya sobrescrito el encabezado server: de la página

  • Hace tiempo hice algo parecido con un Arduino Mega. Me sorprendió que pudiera verse bastante convincente porque el cliente hace mucho trabajo; el controlador solo servía contenido desde una tarjeta uSD