CircuitPython

Hola, soy Alex de DEV STORIES DOT EU. CircuitPython, episodio 1 de 7. Si vienes del mundo de los sistemas embebidos tradicionales, configurar un toolchain suele llevar más tiempo que escribir el primer programa. Pasas horas lidiando con compiladores, drivers y flash tools específicas solo para probar una línea de lógica. El drive CIRCUITPY evita todo eso por completo. Los desarrolladores de sistemas embebidos suelen buscar instintivamente una flash tool, un compilador o un IDE específico al comenzar un nuevo proyecto. Con CircuitPython, no los necesitas. No hay paso de compilación. El sistema de archivos del sistema operativo se encarga del proceso de deploy. Cuando conectas un microcontrolador compatible con CircuitPython a tu ordenador mediante un cable USB, la placa se presenta al sistema operativo como un dispositivo de almacenamiento masivo USB estándar. Este drive extraíble se monta automáticamente y se llama CIRCUITPY. Para tu ordenador, ya sea Windows, macOS o Linux, se ve exactamente como un pendrive estándar. Puedes abrirlo en tu explorador de archivos, ver su contenido y modificarlo. Dentro de este drive, el archivo más importante es un archivo de texto, generalmente llamado code punto py. Este archivo actúa como entry point para tu aplicación. Puedes abrirlo con cualquier editor de texto estándar. No requiere una aplicación especializada; un editor de texto básico funciona perfectamente. Cuando escribes un programa sencillo —quizás un bucle que imprime texto o interactúa con la placa— y lo guardas, el ciclo de deploy comienza automáticamente. Aquí está la clave: no necesitas hacer clic en un botón de build ni ejecutar una utilidad de command line para enviar el código al hardware. En el momento en que guardas el archivo, el microcontrolador detecta la actividad del sistema de archivos a través de la conexión USB. Este comportamiento se basa en un mecanismo llamado auto-reload. CircuitPython monitoriza activamente el estado de la conexión de almacenamiento masivo USB. Cuando inicias una operación de guardado en tu editor de texto, el ordenador escribe datos en el drive CIRCUITPY. CircuitPython espera hasta que se complete la escritura en el sistema de archivos. Una vez finalizada la escritura del archivo, el sistema de auto-reload inicia un soft reboot del microcontrolador. Este soft reboot es extremadamente rápido. Interrumpe la actividad que el microcontrolador estuviera realizando, elimina de forma segura el estado actual y borra completamente la memoria. A continuación, parsea y ejecuta inmediatamente el archivo code punto py recién guardado desde el principio. El mecanismo de auto-reload crea un iteration loop muy rápido. Editas el código, guardas el archivo y observas la respuesta del hardware en menos de un segundo. Si hay un error de sintaxis en el código recién guardado, la ejecución se detiene de forma segura. Puedes ver la salida de error a través de una conexión serial. Corriges el error, guardas el archivo de nuevo y la placa se reinicia instantáneamente para probar el código actualizado. El drive CIRCUITPY también es el mecanismo para gestionar las dependencias. Si tu proyecto requiere código auxiliar externo para hardware específico, no necesitas usar un package manager de command line. Simplemente arrastra y suelta los archivos de la library necesarios directamente en una carpeta designada llamada lib en el drive CIRCUITPY. El sistema de auto-reload también registra los cambios en este directorio. Antes de terminar, si disfrutas de estos episodios técnicos y quieres apoyar el programa, puedes buscar DevStoriesEU en Patreon. El cambio fundamental aquí es que el propio sistema de archivos actúa como pipeline de deploy, convirtiendo cualquier máquina con un editor de texto básico y un puerto USB en una estación de trabajo de desarrollo embebido completamente funcional sin necesidad de instalar un solo driver. Eso es todo por hoy. ¡Gracias por escuchar y a seguir creando!

Hola, soy Alex de DEV STORIES DOT EU. CircuitPython, episodio 2 de 7. Escribes un script para encender una luz, guardas el archivo y la luz parpadea durante una fracción de segundo antes de apagarse inmediatamente. Tu código está perfecto. El problema es que cuando un script llega al final y termina, el sistema resetea automáticamente el estado del hardware. Para que un dispositivo siga funcionando, tienes que evitar que el script termine. Aquí es donde entra en juego el concepto de Hardware as Code. En la programación tradicional, tu código manipula datos en la memoria. En la programación de sistemas embebidos, tu código manipula señales eléctricas físicas. CircuitPython abstrae esta complejidad mediante tres módulos integrados: board, digitalio y time. No necesitas instalarlos. Están integrados directamente en el firmware. El módulo board actúa como un mapa de hardware para tu microcontrolador específico. Sabe qué enrutamiento interno corresponde a los pines físicos. Cuando haces referencia a board punto LED, estás obteniendo la dirección de hardware correcta para la luz integrada, independientemente del modelo de placa física que tengas realmente en las manos. El módulo digitalio proporciona las clases necesarias para controlar el flujo de electricidad. Traduce los objetos de Python a señales digitales. Por último, el módulo time gestiona el ritmo. Los microcontroladores ejecutan millones de instrucciones por segundo. Sin el módulo time para pausar la ejecución, una luz parpadeante cambiaría de estado tan rápido que se vería continuamente tenue al ojo humano. Así es como estos tres módulos trabajan juntos para hacer parpadear un LED integrado. Primero, importas board, digitalio y time. A continuación, configuras el hardware. Creas un nuevo objeto usando la clase DigitalInOut del módulo digitalio, y le pasas el pin board punto LED. Ahora tienes un objeto de Python que representa esa conexión física específica. Los pines pueden escuchar la electricidad que entra, o enviar electricidad hacia fuera. Tienes que decirle explícitamente a CircuitPython qué se supone que debe hacer este pin. Estableces la propiedad direction de tu nuevo objeto pin en output. Esto le indica al microcontrolador que envíe voltaje hacia el LED. Aquí está la clave. Una vez que el pin está configurado como output, controlar la señal eléctrica física es exactamente igual que asignar una variable. Para encender el LED, estableces la propiedad value de tu objeto pin en True. Internamente, CircuitPython traduce esa simple asignación booleana en una señal de alto voltaje, haciendo circular electricidad por el circuito e iluminando el LED. Para apagarlo, estableces la propiedad value en False, lo que baja el voltaje a cero. Ahora, volvamos al problema con el que empezamos. Si simplemente estableces el valor en True y luego en False, el script termina. CircuitPython hace limpieza reseteando todos los pines, y tu placa se apaga. Para hacer que el LED parpadee continuamente, tienes que atrapar la secuencia de ejecución. Envuelves tus comandos en un loop while True infinito. Dentro de ese loop, estableces el valor del pin en True. Luego, usas time punto sleep para pausar el script durante medio segundo. Estableces el valor del pin en False. Pausas durante otro medio segundo. Como es un loop infinito, el script nunca llega al final, el hardware nunca se resetea, y el LED sigue parpadeando mientras la placa tenga energía. Cuando escribes Hardware as Code, no solo estás moviendo bytes. Estás abriendo y cerrando físicamente puertas eléctricas al asignar True y False a objetos de Python. Gracias por escucharnos. ¡Hasta la próxima!

Hola, soy Alex de DEV STORIES DOT EU. CircuitPython, episodio 3 de 7. La mayor parte del debugging en sistemas embebidos implica modificar una línea de código, esperar a que recompile, flashear la placa y esperar que tu log de salida pille el bug. Pero, ¿y si pudieras pausar la ejecución y controlar el hardware en vivo? Eso es exactamente lo que te permiten hacer la Serial Console y el REPL. Cuando conectas una placa CircuitPython a tu ordenador, se establece una conexión serie bidireccional por USB. Puedes acceder a esto usando un programa de terminal como PuTTY en Windows, o el comando screen en macOS y Linux. Muchas conexiones serie requieren que configures un baud rate específico, normalmente 115200. CircuitPython en realidad ignora esta configuración por USB, pero es una práctica habitual configurar tu terminal a esa velocidad de todos modos. La Serial Console es tu ventana principal basada en texto hacia la placa. Cada vez que tu script ejecuta un print, el output aparece aquí. Más importante aún, si tu código encuentra un error fatal y crashea, el traceback de Python se imprime en esta consola. Sin una conexión serie abierta, una placa crasheada no te da ninguna información de diagnóstico. Simplemente deja de funcionar. La Serial Console también es tu puerta de entrada al REPL. REPL significa Read, Evaluate, Print, Loop. Es un prompt interactivo de Python ejecutándose directamente en el propio chip del microcontrolador. El desarrollo de firmware tradicional requiere escribir código en una máquina host, compilarlo y transferir el binario. El REPL cambia esa dinámica por completo. Escribes un comando, la placa lo lee, evalúa la lógica, imprime el resultado y hace un loop para esperar tu siguiente comando. Imagina un escenario práctico. Tienes un script ejecutándose en tu placa, pero necesitas averiguar qué pin de hardware controla el LED integrado. Abres tu terminal serie y pulsas Control C. Esto interrumpe instantáneamente el script en ejecución. Se te pide que pulses cualquier tecla, lo que te mete en el REPL. Sabes que estás en el lugar correcto cuando ves el prompt estándar de Python, que son tres símbolos de mayor que. Ahora, escribes import board. Para descubrir qué hardware está disponible, pasas el módulo board a la función built-in dir. El REPL imprime una lista de cada nombre de pin activo para tu hardware específico. Ves el pin del LED en la lista. Justo ahí en el prompt, importas el módulo digital IO. Creas un objeto pin para el LED, configuras su direction a output, y estableces su value a true. El LED físico en tu escritorio se enciende al instante. Acabas de controlar el hardware manualmente, línea a línea. Aquí está la clave. El código escrito en el REPL es efímero. Solo existe en la memoria activa de esa sesión actual. Si desconectas la placa o la reinicias, todo lo que escribiste desaparece. El REPL es una herramienta exploratoria. Es un sandbox donde puedes probar los límites del hardware, verificar los nombres de los pines o comprobar la sintaxis sobre la marcha. Una vez que encuentras la secuencia exacta de comandos que logra tu objetivo, debes recrear manualmente esa lógica dentro de tu archivo code dot py en la unidad USB para hacerla permanente. Cuando terminas de probar, sales del REPL y reinicias tu código guardado pulsando Control D. Esto desencadena un soft reboot, recargando tu archivo code dot py desde cero. El REPL cambia el desarrollo de hardware de un ciclo lento de adivinanzas a una exploración interactiva e instantánea. Gracias por escuchar, ¡happy coding a todos!

Hola, soy Alex de DEV STORIES DOT EU. CircuitPython, episodio 4 de 7. Los microcontroladores tienen una RAM increíblemente limitada, lo que significa que un script relativamente corto puede hacer que tu placa crashee por quedarse completamente sin memoria antes de ejecutar un solo comando. El culpable suele ser cómo la placa procesa el código externo que le metes, y solucionar ese cuello de botella de memoria es exactamente de lo que va el ecosistema de librerías. CircuitPython viene con módulos core integrados en el firmware, pero para hardware específico, como sensores de temperatura o pantallas LED, necesitas librerías externas. A diferencia de un entorno de Python de escritorio estándar, no hay un package manager. No ejecutas un comando para bajarte automáticamente un driver. Aquí, la gestión de dependencias es manual por diseño. Cuando conectas tu microcontrolador por USB, aparece como un flash drive. En el root de esta unidad hay un directorio llamado simplemente lib. Esta carpeta es el lugar dedicado para todas tus dependencias externas. Para llenarla, te descargas el Adafruit Library Bundle, un archivo ZIP enorme que contiene cientos de drivers oficiales y módulos helper. Aquí está la clave. Cuando vayas a descargar este bundle, verás varias versiones disponibles. Un error frecuente es simplemente descargarse el bundle más reciente de la página. Si tu placa está corriendo la versión ocho de CircuitPython, pero te descargas el bundle de la versión nueve, tu código fallará. La major version del bundle debe coincidir exactamente con la major version del firmware de CircuitPython instalado en tu placa. Si no coinciden, el sistema lanza errores de bytecode incompatible y se niega a ejecutarse. Dentro de ese bundle correspondiente, encontrarás las librerías en dos formatos de archivo distintos: archivos punto py estándar y archivos punto mpy. Los archivos punto py son texto fuente de Python en crudo, legible para humanos. Aunque tu placa puede ejecutarlos, el microcontrolador tiene que cargar todo ese texto en crudo en su diminuto espacio de RAM y compilarlo a bytecode al vuelo. Este overhead de compilación se come la memoria increíblemente rápido. Los archivos punto mpy solucionan este problema. Son bytecode precompilado. El pesado paso de traducción ya se ha hecho en un ordenador antes de que te descargaras el archivo ZIP. Cuando el microcontrolador carga un archivo punto mpy, ejecuta las instrucciones directamente, saltándose por completo la fase de parsing de texto. Imagina que estás conectando una tira de LEDs NeoPixel a tu placa. Escribes tu script de control, pero el sistema necesita el driver de hardware para saber cómo comunicarse con esos LEDs específicos. Abres tu library bundle con la versión correcta, localizas el archivo llamado neopixel punto mpy, y lo arrastras directamente al directorio lib de la placa. Si en su lugar hubieras arrastrado el archivo neopixel punto py en crudo, tu microcontrolador podría quedarse sin memoria fácilmente solo intentando interpretar el código del driver. Al usar el archivo punto mpy precompilado, la placa ahorra RAM crítica para la lógica real de tu aplicación y enciende los píxeles de inmediato. Gestionar las dependencias manualmente te obliga a ser muy intencional sobre qué código vive en tu dispositivo. Depender de bytecode precompilado es la única manera de abstraer operaciones complejas de hardware sin agotar al instante el diminuto memory footprint de un microcontrolador. Eso es todo por este episodio. Gracias por escuchar, y ¡sigue programando!

Hola, soy Alex de DEV STORIES DOT EU. CircuitPython, episodio 5 de 7. A veces, eliminar una librería de tu microcontrolador hace que tu proyecto funcione mejor. Eliminas una dependencia grande de tu drive, reinicias la placa y, por arte de magia, tu código sigue funcionando. Esto pasa por una feature llamada Frozen Libraries. Los microcontroladores, especialmente los más pequeños como el Circuit Playground Express, funcionan con limitaciones de hardware extremas. Cada archivo de librería estándar en tu carpeta lib ocupa espacio de almacenamiento físico en el pequeño flash drive. Y lo que es más importante, cuando tu código se ejecuta, el dispositivo tiene que cargar ese archivo entero en su memoria RAM. Si cargas demasiados archivos, o archivos demasiado grandes, te quedas sin memoria y el programa crashea. Los desarrolladores de firmware solucionan esto congelando las librerías core directamente en la build de CircuitPython. En lugar de existir como un archivo independiente en tu drive USB visible, el código de la librería se precompila y se empaqueta directamente en el archivo de firmware base que cargas inicialmente en la placa. Esto supone una ventaja enorme. Las frozen libraries ocupan cero espacio en tu filesystem visible. Como son parte de la imagen core del sistema, el microcontrolador ejecuta el código directamente desde la memoria flash. Se salta por completo el proceso de copiar la librería a la memoria RAM. Esto lleva a una trampa muy común. Muchos desarrolladores descargan un bundle de librerías enorme, copian todo lo que creen que necesitan en su carpeta lib y, sin querer, duplican librerías que ya están congeladas en su firmware. Esto desperdicia un espacio precioso en el filesystem. Si borras una librería de tu carpeta lib y tu proyecto sigue funcionando a la perfección, esa librería estaba congelada. Aquí está la clave. Para entender cómo evitar este solapamiento, necesitas entender el orden de prioridad de los import controlado por el system path. Cuando tu código importa un módulo, CircuitPython no pilla simplemente la primera coincidencia que ve. Busca en las ubicaciones siguiendo una secuencia estricta. Primero, comprueba el directorio raíz de tu drive. Segundo, comprueba la carpeta lib. Tercero, y solo si no consigue encontrar la librería en las dos primeras ubicaciones, comprueba las frozen libraries ocultas dentro del firmware. Este orden de prioridad significa que cualquier archivo que pongas en tu drive sobrescribe la versión congelada. Si metes una versión desactualizada o custom de una librería en tu carpeta lib, CircuitPython ejecuta ese archivo. Ignora por completo la versión congelada, optimizada y eficiente en memoria, que está dentro del firmware. Estás pagando el coste de memoria por un archivo que no necesitabas proporcionar. Dentro de esos directorios, las extensiones de archivo también siguen una regla de prioridad estricta. Un archivo fuente de texto plano siempre gana a un archivo compilado. Si tienes tanto un archivo de texto estándar como una versión compilada de la misma librería en exactamente el mismo directorio, CircuitPython carga el archivo de texto sin compilar. Si quieres saber exactamente qué viene integrado en tu placa en concreto, puedes abrir el prompt interactivo y escribir la palabra help, pasándole la palabra modules entre paréntesis. Esto imprime una lista completa de todas las frozen libraries que tienes disponibles de fábrica. La forma más inteligente de gestionar la memoria en un dispositivo limitado es dejar que el firmware haga el trabajo pesado. Saber exactamente qué está ya congelado evita archivos duplicados, frena los overrides accidentales y mantiene tu memoria disponible libre para la lógica real de tu aplicación. Gracias por escuchar. Cuidaos todos.

Hola, soy Alex de DEV STORIES DOT EU. CircuitPython, episodio 6 de 7. Miras un proyecto de hardware y ves que los desarrolladores eliminaron deliberadamente funciones avanzadas, como las hardware interrupts, del core language. Puedes pensar que esto perjudicó a la plataforma, pero en realidad la hizo muchísimo más exitosa. Esta es la divergencia arquitectónica entre CircuitPython y MicroPython. Los desarrolladores suelen asumir que estas dos plataformas son idénticas. Ambas ejecutan Python en microcontroladores, y CircuitPython empezó originalmente como un fork de MicroPython. Sin embargo, tienen filosofías completamente diferentes. MicroPython está diseñado para exponer la potencia bruta y las características específicas del microcontrolador subyacente. CircuitPython está diseñado para imponer un estándar estricto y unificado en todo el hardware. La primera diferencia que vas a notar es la standard library. MicroPython usa una convención de nombres que pone el prefijo u a los módulos estándar para indicar una versión micro. Importas uos o utime. CircuitPython prescinde por completo de esto. Impone la nomenclatura estándar del CPython de escritorio. Simplemente importas os o time. Si eres un desarrollador portando un script de MicroPython a CircuitPython, tendrás que renombrar esos imports. A cambio de este pequeño ajuste, tu código se vuelve altamente portable. Esa portabilidad es la core feature de CircuitPython. MicroPython expone hardware registers específicos y números de pin específicos del chip. CircuitPython abstrae el hardware por completo usando una API unificada centrada en un módulo llamado board. En lugar de escribir código que haga toggle en el pin GPIO 15 de un ESP32, le dices a CircuitPython que haga toggle en board punto D4. Si mueves ese mismo script a una arquitectura de microcontrolador completamente diferente, como un chip ARM Cortex estándar, el código de hardware se ejecuta exactamente igual, sin cambios. Para mantener esta consistencia, CircuitPython fuerza ciertas decisiones arquitectónicas que MicroPython deja como opcionales. Por ejemplo, MicroPython te permite compilar el firmware sin soporte de floating-point para ahorrar memoria. CircuitPython exige soporte de floating-point en cada una de las builds. Las operaciones matemáticas se comportan exactamente igual, independientemente de lo limitado que esté el hardware. CircuitPython también estandariza los mensajes de error, proporcionando texto detallado y localizado en lugar de fallos de memoria bare metal escuetos. Aquí está la clave. La diferencia más polarizante es cómo los dos gestionan la concurrencia. MicroPython soporta totalmente las hardware interrupts. Una interrupt permite que un cambio físico en un pin pause inmediatamente el programa principal, ejecute una función específica y luego lo reanude. Esto proporciona un timing de alto rendimiento, pero también introduce race conditions complejas y estados de memoria impredecibles que son increíblemente difíciles de debuggear. CircuitPython elimina deliberadamente el soporte para hardware interrupts. No puedes lanzar código Python directamente desde un pin de hardware interrupt. En su lugar, impone el cooperative multitasking. Gestionas la concurrencia usando características estándar de asyncio o comprobando los estados secuencialmente en tu main loop. Al abandonar las interrupts, CircuitPython garantiza que el flujo de ejecución siga siendo totalmente predecible y elimina una categoría enorme de silent crashes. MicroPython te da las llaves del bare metal, priorizando el rendimiento bruto y el control del hardware. CircuitPython intercambia ese control por un entorno donde tu código es completamente portable, predecible y se comporta exactamente igual que el Python estándar que ejecutas en un ordenador de escritorio. ¡Gracias por escuchar, happy coding a todos!

Hola, soy Alex de DEV STORIES DOT EU. CircuitPython, episodio 7 de 7. Pasas días escribiendo y probando código de interacción de hardware para un sensor en un pequeño microcontrolador de cinco dólares. Más tarde, los requisitos del proyecto cambian y de repente necesitas la potencia de procesamiento de un ordenador Linux completo para registrar esos datos en una base de datos remota en la nube. Normalmente, pasar de un microcontrolador bare-metal a un sistema operativo completo implica reescribir por completo tu código de hardware. Tu plataforma de destino ahora tiene un kernel de sistema operativo que gestiona el acceso al hardware, lo que requiere drivers y librerías totalmente diferentes. Pero, ¿y si el mismo script de Python pudiera ejecutarse sin cambios en ambas plataformas? Eso es exactamente lo que te permite hacer Adafruit Blinka. Antes de explicar cómo funciona, aclaremos un malentendido común. Blinka no reemplaza el sistema operativo Linux de tu Raspberry Pi, BeagleBone u otro ordenador de placa única. No flasheas un archivo de firmware de CircuitPython en una tarjeta SD como haces con un microcontrolador. En su lugar, Blinka es simplemente un paquete de Python. Lo instalas usando pip estándar. Actúa como una capa de compatibilidad que se ejecuta dentro del CPython de escritorio estándar. Su único trabajo es traducir las llamadas a la API de CircuitPython a las llamadas de sistema estándar de Linux necesarias para controlar el hardware. Cuando escribes código de hardware en un microcontrolador, CircuitPython gestiona el acceso directo al hardware. En un sistema Linux, el kernel del sistema operativo controla el hardware, y los programas de usuario deben solicitar acceso. Blinka hace de puente. Cuando tu código importa el módulo board o usa el módulo digitalio para alternar un pin, Blinka intercepta esos comandos. Mapea los nombres de los pines de CircuitPython a la disposición de hardware específica de tu ordenador de placa única, enrutando la petición a través de los subsistemas de Linux necesarios. Piensa en cómo se ve esto en la práctica con nuestro sensor de temperatura. En el pequeño microcontrolador, tu código importa board, configura un bus I2C y lee continuamente los valores de temperatura. Para escalar esta operación a una Raspberry Pi 5, conectas físicamente el sensor a los pines del header de la Pi. Luego, dentro de tu terminal de Linux, usas pip para instalar Adafruit Blinka y el driver de Python específico para tu sensor de temperatura. Copias tu script de Python original, sin alterar ni una sola línea. Cuando ejecutas el script usando Python 3 estándar, el módulo board detecta dinámicamente que se está ejecutando en una Raspberry Pi 5. Proporciona automáticamente las definiciones de pines correctas para esa placa específica. El módulo busio traduce sin problemas tus peticiones de lectura I2C en llamadas de dispositivo I2C estándar de Linux. Tu script lee los datos del sensor exactamente igual que antes. Aquí es donde se pone interesante. Como ahora estás ejecutando CPython estándar en una máquina Linux completa, ya no estás limitado por las restricciones de memoria de un microcontrolador. Tu script puede leer el sensor de hardware usando la capa de traducción de Blinka, y luego pasar esos datos inmediatamente a librerías de escritorio pesadas. Puedes usar peticiones de red estándar para enviar las métricas a una base de datos en la nube, procesar la telemetría con herramientas de data science, o incluso servirla a través de un framework web local. Aquí está la clave. El código de interacción con el hardware permanece idéntico en arquitecturas de computación completamente diferentes. Al desacoplar la lógica del sensor del sistema operativo subyacente, Blinka te permite prototipar de forma barata en bare-metal y escalar a entornos Linux completos con cero reescrituras de código de hardware. Con esto terminamos nuestra serie sobre CircuitPython. Te animo a leer la documentación oficial, a probar a configurar un sensor con Blinka de forma práctica, o a visitar devstories dot eu para sugerir temas para futuras series. Eso es todo por este episodio. ¡Gracias por escuchar, y sigue construyendo!