Hospedar un sitio web en un cigarrillo electrónico desechable

 (bogdanthegeek.github.io)
28 puntos por GN⁺ 2025-09-16 | Aún no hay comentarios. | Compartir por WhatsApp
  • Proyecto experimental que ejecuta un servidor web usando el microcontrolador ARM Cortex-M0+ de baja potencia integrado en un cigarrillo electrónico desechable
  • Se analizó el chip PY32F002B de PUYA, con 24KiB de flash y 3KiB de RAM, e implementó conectividad de red mediante SLIP
  • Usando Semihosting, el protocolo SLIP y la pila TCP/IP uIP, se porteó comunicación TCP/IP y funcionalidad de servidor HTTP a través de un tty virtual
  • Al principio era muy lento, pero mediante optimización de búferes y mejoras en el manejo de datos se incrementaron mucho la velocidad de respuesta y la carga de páginas
  • Incluso en un entorno de memoria muy limitada, se logró ejecutar código dinámico del servidor y ofrecer endpoints de API
  • El código está publicado; el hosting real es posible, pero las limitaciones de recursos como la memoria son grandes

Introducción

  • Antes que nada, el autor aclara que este texto no está siendo servido directamente desde el servidor web ejecutándose en el cigarrillo electrónico desechable, sino que el mismo contenido se ofrece desde un servidor aparte
  • Se puede ver un ejemplo de funcionamiento real en http://ewaste.fka.wtf/

Contexto

  • Durante varios años, el autor reunió cigarrillos electrónicos desechables de conocidos con el objetivo de reutilizar sus baterías
  • Últimamente le llamó la atención que estos dispositivos se han ido sofisticando y han empezado a incluir USB-C y baterías recargables
  • Mientras los desmontaba, encontró un microcontrolador ARM Cortex-M0+ con flash integrada de una marca llamada PUYA, un chip bien conocido dentro de los microcontroladores de bajo costo
  • Recolectó estos microcontroladores de varios modelos y, como tenían etiquetados los pines de depuración, resultó fácil analizarlos

Hardware utilizado

  • La marca del chip era PUYA C642F15, pero se estima que en realidad pertenece a la familia PY32F002B
  • Especificaciones principales:
    • Núcleo Cortex-M0+ a 24MHz
    • 24KiB de flash
    • 3KiB de RAM
    • Hay varios periféricos, pero no se usaron en este proyecto
  • Aunque su rendimiento es bajo comparado con un smartphone común, en un entorno embebido es totalmente posible construir un servidor web simple

Conexión de red

  • No fue una idea completamente original, pero al experimentar con el concepto de semihosting surgió la idea de ejecutar un servidor web
  • Semihosting es una forma de simular syscalls en sistemas ARM embebidos
    • Se colocan valores o punteros en registros y, al invocar un breakpoint, el depurador lo interpreta y procesa la operación
    • Normalmente se usa para enviar logs, pero también permite comunicación de datos bidireccional
  • Los dispositivos USB serial admiten el protocolo SLIP (Serial Line Internet Protocol), y eso se aprovechó para usarlos como interfaz de red
  • En Linux (y en algunos macOS), se construyó un entorno de red SLIP mediante tty virtual usando slattach y socat, entre otros 
    pyocd gdb -S -O semihost_console_type=telnet -T $(PORT) $(PYOCDFLAGS) &  
socat PTY,link=$(TTY),raw,echo=0 TCP:localhost:$(PORT),nodelay &  
sudo slattach -L -p slip -s 115200 $(TTY) &  
sudo ip addr add 192.168.190.1 peer 192.168.190.2/24 dev sl0  
sudo ip link set mtu 1500 up dev sl0
  • Se eligió uIP como pila TCP/IP porque es muy pequeña, no requiere RTOS y es fácil de portar
  • Se aprovechó el ejemplo de servidor HTTP de uIP y se porteó el código de SLIP al esquema de semihosting, logrando arrancar el servidor web
  • Debido a un problema de alineación de 16 bits en la arquitectura ARM, se modificó el script de generación del filesystem y se hizo una conversión con Perl

Optimización de velocidad

  • En el estado inicial, mostraba una respuesta extremadamente lenta: ping de 1.5 segundos, 50% de pérdida de paquetes y más de 20 segundos para cargar la página
  • La causa era el gran overhead de la entrada/salida por bytes individuales
  • Aprovechando al máximo los 3KiB de RAM, se añadió un ring buffer y se mejoró la estructura para suministrar datos por bloques a las funciones SLIP
  • La escritura también se dividió en lotes para procesar la transmisión y permitir una limpieza rápida
  • Como resultado de la optimización, se alcanzó ping de 20ms, sin pérdidas, y carga de página en 160ms
  • Uso total de RAM y flash:
    • Flash: 5,116B de 24KB (20.82%)
    • RAM: 1,380B de 3KB (44.92%)
  • Incluso todo el contenido del blog puede servirse sin problemas, y también es posible ejecutar código C del lado del servidor

Otras funciones y cierre

  • Se implementaron directamente endpoints de API que devuelven el número de solicitudes a la página principal y el ID único del microcontrolador
  • Es un experimento que llegó a implementar un servidor web dinámico y una API con hardware de prestaciones extremadamente limitadas y la mínima memoria posible

Referencia

Lecturas relacionadas

Aún no hay comentarios.

Aún no hay comentarios.