CircuitPython

Olá, daqui é o Alex do DEV STORIES DOT EU. CircuitPython, episódio 1 de 7. Se vens do mundo dos sistemas embebidos tradicionais, configurar uma toolchain normalmente demora mais tempo do que escrever o primeiro programa. Passas horas a lutar com compilers, device drivers e flashing utilities dedicados só para testar uma única linha de lógica. A drive CIRCUITPY ignora tudo isso por completo. Os developers de sistemas embebidos muitas vezes procuram instintivamente por uma flash tool, um compiler ou um IDE específico quando começam um novo projeto. Com o CircuitPython, não precisas deles. Não há um passo de compile. O file system do sistema operativo trata do processo de deploy. Quando ligas um microcontrolador compatível com CircuitPython ao teu computador com um cabo USB, a board apresenta-se ao teu sistema operativo como um dispositivo standard de USB mass storage. Esta drive amovível é montada automaticamente e chama-se CIRCUITPY. Para o teu computador, quer uses Windows, macOS ou Linux, parece exatamente uma pen drive normal. Podes abri-la no teu file explorer, ver os conteúdos e modificá-los. Dentro desta drive, o ficheiro mais importante é um ficheiro de texto normalmente chamado code dot py. Este ficheiro serve de entry point para a tua aplicação. Podes abri-lo em qualquer editor de texto standard. Não precisas de uma aplicação especializada; um editor de texto básico funciona perfeitamente. Quando escreves um programa simples — talvez um loop que faz print de texto ou interage com a board — e fazes save, o ciclo de deploy começa automaticamente. Aqui está o ponto chave. Não precisas de clicar num botão de build nem de correr um utilitário de command line para fazer push do código para o hardware. No momento em que guardas o ficheiro, o microcontrolador deteta a atividade do file system através da ligação USB. Este comportamento é controlado por um mecanismo chamado auto-reload. O CircuitPython monitoriza ativamente o estado da ligação de USB mass storage. Quando inicias uma operação de save no teu editor de texto, o computador escreve os dados na drive CIRCUITPY. O CircuitPython espera até que a escrita no file system esteja concluída. Assim que a escrita do ficheiro termina, o sistema de auto-reload aciona um soft reboot do microcontrolador. Este soft reboot é extremamente rápido. Interrompe o que quer que o microcontrolador estivesse a fazer, faz o tear down seguro do estado atual e limpa completamente a memória. A seguir, faz o parse e executa imediatamente o ficheiro code dot py recém-guardado, desde o início. O mecanismo de auto-reload cria um iteration loop muito apertado. Editas o código, fazes save do ficheiro e vês o hardware a responder em menos de um segundo. Se houver um syntax error no teu código recém-guardado, a execução para de forma segura. Podes ver o output do erro através de uma ligação serial. Corriges o typo, fazes save do ficheiro novamente e a board faz reboot instantaneamente para testar o código atualizado. A drive CIRCUITPY também é o mecanismo para gerir dependencies. Se o teu projeto precisar de código auxiliar externo para hardware específico, não usas um package manager de command line. Basta fazeres drag and drop dos ficheiros de library necessários diretamente para uma pasta designada chamada lib na drive CIRCUITPY. O sistema de auto-reload também segue as alterações nesta diretoria. Antes de terminarmos, se gostas destes episódios técnicos e queres apoiar o programa, podes procurar por DevStoriesEU no Patreon. A mudança fundamental aqui é que o próprio file system atua como o deployment pipeline, transformando qualquer máquina com um editor de texto básico e uma porta USB numa workstation de desenvolvimento embebido totalmente capaz, sem instalar um único driver. É tudo por este episódio. Obrigado por ouvires, e continua a desenvolver!

Olá, daqui é o Alex da DEV STORIES DOT EU. CircuitPython, episódio 2 de 7. Escreves um script para acender uma luz, guardas o ficheiro, e a luz pisca por uma fração de segundo antes de se apagar imediatamente. O teu código está perfeito. O problema é que, quando um script chega ao fim e termina, o sistema faz reset automaticamente ao estado do hardware. Para manter um dispositivo a funcionar, tens de impedir que o script termine. É aqui que entra o conceito de Hardware as Code. Na programação tradicional, o teu código manipula dados em memória. Na programação embebida, o teu código manipula sinais elétricos físicos. O CircuitPython abstrai esta complexidade usando três módulos built-in: board, digitalio e time. Não precisas de os instalar. Estão embutidos diretamente no firmware. O módulo board funciona como um mapa de hardware para o teu microcontrolador específico. Sabe que routing interno corresponde aos pins físicos. Quando referencias board dot LED, estás a ir buscar o endereço de hardware correto para a luz integrada, independentemente do modelo físico da board que tenhas efetivamente nas mãos. O módulo digitalio fornece as classes necessárias para controlar o fluxo de eletricidade. Traduz objetos Python em sinais digitais. Por fim, o módulo time gere o ritmo. Os microcontroladores executam milhões de instruções por segundo. Sem o módulo time para pausar a execução, uma luz a piscar alternaria tão depressa que pareceria apenas continuamente fraca a olho nu. Eis como estes três módulos trabalham em conjunto para fazer piscar um LED integrado. Primeiro, importas o board, o digitalio e o time. A seguir, configuras o hardware. Crias um novo objeto usando a classe DigitalInOut do módulo digitalio, e passas-lhe o pin board dot LED. Agora tens um objeto Python a representar essa ligação física específica. Os pins podem ficar à escuta de eletricidade a entrar, ou enviar eletricidade. Tens de dizer explicitamente ao CircuitPython o que este pin deve fazer. Defines a propriedade direction do teu novo objeto pin para output. Isto diz ao microcontrolador para enviar tensão para o LED. Aqui está a ideia chave. Assim que o pin estiver configurado como output, controlar o sinal elétrico físico é exatamente como atribuir um valor a uma variável. Para acender o LED, defines a propriedade value do teu objeto pin para True. Internamente, o CircuitPython traduz essa simples atribuição booleana num sinal de alta tensão, empurrando a eletricidade através do circuito e iluminando o LED. Para o apagar, defines a propriedade value para False, o que faz cair a tensão para zero. Agora, voltando ao problema com que começámos. Se simplesmente definires o value para True, e depois para False, o script termina. O CircuitPython faz a limpeza ao fazer reset a todos os pins, e a tua board desliga-se. Para fazer o LED piscar continuamente, tens de prender a sequência de execução. Envolves os teus comandos num loop infinito while True. Dentro desse loop, defines o value do pin para True. Depois, usas o time dot sleep para pausar o script durante meio segundo. Defines o value do pin para False. Pausas por mais meio segundo. Como é um loop infinito, o script nunca chega ao fim, o hardware nunca faz reset, e o LED continua a piscar enquanto a board tiver energia. Quando escreves hardware as code, não estás apenas a mover bytes. Estás fisicamente a abrir e a fechar portas elétricas ao atribuir True e False a objetos Python. Obrigado por ouvires. Até à próxima!

Olá, daqui é o Alex da DEV STORIES DOT EU. CircuitPython, episódio 3 de 7. A maior parte do debugging em sistemas embebidos envolve ajustar uma linha de código, esperar por um recompile, fazer flash à board, e ter esperança que o teu output log apanhe o bug. Mas e se pudesses pausar a execução e comandar o hardware em tempo real? É exatamente isso que a Serial Console e o REPL te permitem fazer. Quando ligas uma board CircuitPython ao teu computador, ela estabelece uma ligação serial bidirecional por USB. Podes aceder a isto usando um programa de terminal como o PuTTY no Windows, ou o comando screen no macOS e Linux. Muitas ligações seriais exigem que correspondas a um baud rate específico, tipicamente 115200. O CircuitPython na verdade ignora esta configuração por USB, mas é prática comum configurares o teu terminal para essa velocidade de qualquer forma. A Serial Console é a tua principal janela de texto para a board. Sempre que o teu script executa um print statement, o output aparece aqui. Mais importante ainda, se o teu código encontrar um erro fatal e fizer crash, o traceback de Python é impresso nesta consola. Sem uma ligação serial aberta, uma board que tenha feito crash não te dá qualquer informação de diagnóstico. Simplesmente para de funcionar. A Serial Console é também a tua porta de entrada para o REPL. REPL significa Read, Evaluate, Print, Loop. É um prompt interativo de Python a correr diretamente no próprio chip do microcontrolador. O desenvolvimento tradicional de firmware exige escrever código numa máquina host, compilá-lo e transferir o binário. O REPL muda essa dinâmica por completo. Tu digitas um comando, a board lê-o, avalia a lógica, faz print do resultado, e faz loop de volta para esperar pelo teu próximo comando. Considera um cenário prático. Tens um script a correr na tua board, mas precisas de descobrir qual pin de hardware controla o LED integrado. Abres o teu terminal serial e pressionas Control C. Isto interrompe instantaneamente o script que está a correr. É-te pedido para pressionares qualquer tecla, o que te deixa no REPL. Sabes que estás no sítio certo quando vês o prompt standard de Python, que são três parênteses angulares. Agora, digitas import board. Para descobrires que hardware está disponível, passas o module board para a função built-in dir. O REPL faz print de uma lista com o nome de cada pin ativo para o teu hardware específico. Vês o pin do LED na lista. Mesmo ali no prompt, importas o module digital IO. Crias um pin object para o LED, defines a sua direção para output, e defines o seu valor para true. O LED físico na tua secretária acende instantaneamente. Acabaste de comandar o hardware manualmente, uma linha de cada vez. Aqui está o ponto chave. O código digitado no REPL é efémero. Existe apenas na memória ativa dessa sessão atual. Se desligares a board ou a reiniciares, tudo o que digitaste desaparece. O REPL é uma ferramenta exploratória. É uma sandbox onde podes testar os limites do hardware, verificar nomes de pins, ou verificar a sintaxe on the fly. Assim que encontrares a sequência exata de comandos que atinge o teu objetivo, tens de recriar manualmente essa lógica dentro do teu ficheiro code dot py na drive USB para a tornares permanente. Quando terminares os testes, sais do REPL e reinicias o teu código guardado pressionando Control D. Isto desencadeia um soft reboot, recarregando o teu ficheiro code dot py do zero. O REPL muda o desenvolvimento de hardware de um ciclo lento de adivinhação para uma exploração instantânea e interativa. Obrigado por ouvirem, happy coding a todos!

Olá, daqui é o Alex da DEV STORIES DOT EU. CircuitPython, episódio 4 de 7. Os microcontroladores têm uma RAM incrivelmente limitada, o que significa que um script relativamente curto pode, de repente, causar um crash total na tua board por falta de memória, antes mesmo de executar um único comando. O culpado é muitas vezes a forma como a board processa o código externo que importas, e resolver esse bottleneck de memória é exatamente o objetivo do The Library Ecosystem. O CircuitPython vem com core modules integrados no firmware, mas para hardware específico, como sensores de temperatura ou displays LED, precisas de libraries externas. Ao contrário de um ambiente Python standard de desktop, não existe um package manager. Não corres um comando para ir buscar um driver automaticamente. A gestão de dependências aqui é manual by design. Quando ligas o teu microcontrolador por USB, ele aparece como uma flash drive. Na root desta drive, há um diretório chamado simplesmente lib. Esta pasta é o local dedicado para todas as tuas dependências externas. Para a preencher, fazes o download do Adafruit Library Bundle, um enorme ficheiro ZIP que contém centenas de drivers oficiais e helper modules. Aqui está o insight principal. Quando fores fazer o download deste bundle, vais ver várias versões disponíveis. Um erro frequente é simplesmente fazer o download do bundle mais recente na página. Se a tua board estiver a correr o CircuitPython versão oito, mas fizeres o download do bundle da versão nove, o teu código vai falhar. A major version do bundle tem de corresponder exatamente à major version do firmware CircuitPython instalado na tua board. Se não corresponderem, o sistema lança erros de bytecode incompatível e recusa-se a correr. Dentro desse bundle correspondente, vais encontrar as libraries oferecidas em dois formatos de ficheiro distintos: ficheiros ponto py standard e ficheiros ponto mpy. Os ficheiros ponto py são source text Python raw, legível por humanos. Embora a tua board os consiga correr, o microcontrolador tem de carregar todo esse raw text para o seu pequeno espaço de RAM e compilá-lo em bytecode on the fly. Este overhead de compilação consome memória incrivelmente rápido. Os ficheiros ponto mpy resolvem este problema. Eles são bytecode pré-compilado. O passo pesado de tradução já foi feito num computador antes sequer de fazeres o download do ficheiro ZIP. Quando o microcontrolador carrega um ficheiro ponto mpy, ele executa as instruções diretamente, ignorando completamente a fase de text parsing. Imagina que estás a ligar uma fita LED NeoPixel à tua board. Escreves o teu script de controlo, mas o sistema precisa do driver de hardware para saber como comunicar com esses LEDs específicos. Abres o teu library bundle com a versão correta, localizas o ficheiro chamado neopixel ponto mpy, e arrastas diretamente para o diretório lib na board. Se tivesses arrastado o ficheiro raw neopixel ponto py em vez disso, o teu microcontrolador podia facilmente ficar sem memória só a tentar interpretar o código do driver. Ao usar o ficheiro ponto mpy pré-compilado, a board poupa RAM crítica para a tua application logic e acende os pixels imediatamente. Gerir dependências manualmente força-te a ser altamente intencional sobre que código vive no teu dispositivo. Depender de bytecode pré-compilado é a única maneira de abstrair operações complexas de hardware sem esgotar instantaneamente o minúsculo memory footprint de um microcontrolador. É tudo por este episódio. Obrigado por ouvires, e keep building!

Olá, daqui é o Alex da DEV STORIES DOT EU. CircuitPython, episódio 5 de 7. Às vezes, apagar uma library do teu microcontrolador faz mesmo com que o teu projeto corra melhor. Removes uma grande dependência da tua drive, reinicias a board, e o teu code magicamente continua a funcionar. Isto acontece graças a uma feature chamada Frozen Libraries. Os microcontroladores, especialmente os mais pequenos, como o Circuit Playground Express, operam sob limitações de hardware extremas. Cada ficheiro de standard library na tua pasta lib ocupa espaço de armazenamento físico na pequena flash drive. Mais importante ainda, quando o teu code corre, o dispositivo tem de carregar esse ficheiro inteiro para a sua random access memory. Se carregares demasiados ficheiros, ou ficheiros demasiado grandes, ficas sem memória e o programa crasha. Os developers de firmware resolvem isto congelando as core libraries diretamente na build do CircuitPython. Em vez de existir como um ficheiro independente na tua USB drive visível, o code da library é pré-compilado e empacotado diretamente no ficheiro de firmware base que carregas inicialmente na board. Isto oferece uma vantagem enorme. As frozen libraries ocupam zero espaço no teu filesystem visível. Como fazem parte da core system image, o microcontrolador executa o code diretamente da flash memory. Ignora completamente o processo de copiar a library para a random access memory. Isto leva a uma armadilha comum. Muitos developers fazem o download de um library bundle enorme, copiam tudo o que acham que precisam para a sua pasta lib, e duplicam acidentalmente libraries que já estão frozen no seu firmware. Isto desperdiça espaço precioso no filesystem. Se apagares uma library da tua pasta lib e o teu projeto continuar a correr sem problemas, essa library estava frozen. Aqui está o ponto chave. Para perceberes como evitar esta sobreposição, precisas de entender a import priority order controlada pelo system path. Quando o teu code faz o import de um module, o CircuitPython não agarra simplesmente na primeira correspondência que vê. Ele pesquisa as localizações numa sequência estrita. Primeiro, verifica a root directory da tua drive. Segundo, verifica a pasta lib. Terceiro, e apenas se não conseguir encontrar a library nas duas primeiras localizações, verifica as frozen libraries escondidas dentro do firmware. Esta priority order significa que qualquer ficheiro que coloques na tua drive faz override à versão frozen. Se colocares uma versão desatualizada ou custom de uma library na tua pasta lib, o CircuitPython corre esse ficheiro. Ele ignora completamente a versão frozen otimizada e eficiente em termos de memória dentro do firmware. Estás a pagar o custo de memória por um ficheiro que não precisavas de fornecer. Dentro dessas diretorias, as extensões de ficheiro também seguem uma regra de prioridade estrita. Um source file de texto simples tem sempre prioridade sobre um ficheiro compilado. Se tiveres tanto um ficheiro de texto standard como uma versão compilada da mesma library exatamente na mesma diretoria, o CircuitPython carrega o ficheiro de texto não compilado. Se quiseres saber exatamente o que está embutido na tua board específica, podes abrir o prompt interativo e escrever a palavra help, passando a palavra modules dentro dos parênteses. Isto imprime uma lista completa de todas as frozen libraries disponíveis para ti de origem. A maneira mais inteligente de gerir a memória num dispositivo limitado é deixar o firmware fazer o trabalho pesado. Saber exatamente o que já está frozen evita ficheiros duplicados, impede overrides acidentais, e mantém a tua memória disponível livre para a tua verdadeira application logic. Obrigado por ouvirem. Fiquem bem, pessoal.

Olá, daqui é o Alex do DEV STORIES DOT EU. CircuitPython, episódio 6 de 7. Olhas para um projeto de hardware e percebes que os developers removeram deliberadamente features avançadas, como hardware interrupts, da linguagem principal. Podes pensar que isso prejudicou a plataforma, mas, na verdade, tornou-a muito mais bem-sucedida. Esta é a divergência arquitetónica entre o CircuitPython e o MicroPython. Os developers costumam assumir que estas duas plataformas são idênticas. Ambas correm Python em microcontroladores, e o CircuitPython começou originalmente como um fork do MicroPython. No entanto, servem filosofias completamente diferentes. O MicroPython foi desenhado para expor o poder bruto e as features específicas do microcontrolador subjacente. O CircuitPython foi desenhado para impor um standard rígido e unificado em todo o hardware. A primeira diferença que vais notar é a standard library. O MicroPython usa uma convenção de nomenclatura que adiciona o prefixo u aos módulos standard para indicar uma versão micro. Importas uos ou utime. O CircuitPython abandona isto completamente. Impõe a nomenclatura standard do CPython de desktop. Simplesmente importas os ou time. Se fores um developer a fazer o porting de um script de MicroPython para CircuitPython, vais precisar de renomear esses imports. Em troca deste pequeno ajuste, o teu código torna-se altamente portátil. Essa portabilidade é a core feature do CircuitPython. O MicroPython expõe hardware registers específicos e números de pinos específicos do chip. O CircuitPython abstrai o hardware completamente, usando uma API unificada centrada num módulo chamado board. Em vez de escreveres código que faz toggle do pino GPIO 15 num ESP32, dizes ao CircuitPython para fazer toggle do board ponto D4. Se moveres esse exato script para uma arquitetura de microcontrolador completamente diferente, como um chip ARM Cortex standard, o código de hardware corre sem qualquer alteração. Para manter esta consistência, o CircuitPython força certas escolhas arquitetónicas que o MicroPython deixa como opcionais. Por exemplo, o MicroPython permite-te compilar firmware sem suporte a floating-point numbers para poupar memória. O CircuitPython exige suporte a floating-point em todas as builds. As operações matemáticas comportam-se exatamente da mesma maneira, independentemente do quão limitado seja o hardware. O CircuitPython também standardiza as mensagens de erro, fornecendo texto verbose e localizado, em vez de memory faults de bare metal sucintos. Aqui está o ponto chave. A diferença mais polarizadora é como os dois lidam com a concurrency. O MicroPython suporta totalmente hardware interrupts. Um interrupt permite que uma mudança física num pino pause imediatamente o programa principal, execute uma função específica e, depois, retome. Isto proporciona um timing de alta performance, mas também introduz race conditions complexas e estados de memória imprevisíveis que são incrivelmente difíceis de fazer debug. O CircuitPython remove deliberadamente o suporte para hardware interrupts. Não podes fazer trigger de código Python diretamente a partir de um pino de hardware interrupt. Em vez disso, impõe cooperative multitasking. Geres a concurrency usando features standard do asyncio ou verificando estados sequencialmente no teu main loop. Ao abandonar os interrupts, o CircuitPython garante que o fluxo de execução permanece totalmente previsível e elimina uma categoria massiva de silent crashes. O MicroPython dá-te as chaves para o bare metal, priorizando a performance bruta e o controlo de hardware. O CircuitPython troca esse controlo por um ambiente onde o teu código é completamente portátil, previsível e se comporta exatamente como o Python standard que corres num desktop. Obrigado por ouvirem, happy coding a todos!

Olá, daqui é o Alex da DEV STORIES DOT EU. CircuitPython, episódio 7 de 7. Passas dias a escrever e a testar código de interação com hardware para um sensor num minúsculo microcontrolador de cinco dólares. Mais tarde, os requisitos do projeto mudam e, de repente, precisas do poder de processamento de um computador Linux completo para registar esses dados numa base de dados remota na cloud. Normalmente, passar de um microcontrolador bare-metal para um sistema operativo completo significa reescreveres completamente o teu código de hardware. A tua plataforma de destino agora tem um kernel do sistema operativo a gerir o acesso ao hardware, exigindo drivers e libraries totalmente diferentes. Mas e se exatamente o mesmo script Python pudesse correr sem alterações em ambas as plataformas? É exatamente isso que o Adafruit Blinka te permite fazer. Antes de explicar como funciona, vamos esclarecer um equívoco comum. O Blinka não substitui o sistema operativo Linux do teu Raspberry Pi, BeagleBone ou outro single-board computer. Não fazes flash de um ficheiro de firmware CircuitPython para um cartão SD como fazes com um microcontrolador. Em vez disso, o Blinka é simplesmente um package Python. Instalas-o usando o pip standard. Funciona como uma compatibility layer que corre dentro do CPython standard de desktop. O seu único trabalho é traduzir as API calls do CircuitPython nas system calls standard do Linux necessárias para controlar o hardware. Quando escreves código de hardware num microcontrolador, o CircuitPython trata do acesso direto ao hardware. Num sistema Linux, o kernel do sistema operativo controla o hardware, e os programas do utilizador têm de pedir acesso. O Blinka faz a ponte entre os dois. Quando o teu código faz import do module board ou usa o module digitalio para fazer toggle de um pino, o Blinka interceta esses comandos. Ele mapeia os nomes dos pinos do CircuitPython para o hardware layout específico do teu single-board computer, encaminhando o request através dos subsistemas Linux necessários. Pensa em como isto funciona na prática com o nosso sensor de temperatura. No pequeno microcontrolador, o teu código faz import do board, configura um bus I2C e lê continuamente os valores de temperatura. Para escalar esta operação para um Raspberry Pi 5, ligas fisicamente o sensor aos header pins do Pi. Depois, dentro do teu terminal Linux, usas o pip para instalar o Adafruit Blinka e o driver Python específico para o teu sensor de temperatura. Copias o teu script Python original, sem alterar uma única linha. Quando executas o script usando o Python 3 standard, o module board deteta dinamicamente que está a correr num Raspberry Pi 5. Ele fornece automaticamente as definições de pinos corretas para essa board específica. O module busio traduz de forma transparente os teus read requests I2C em device calls I2C standard do Linux. O teu script lê os dados do sensor exatamente como antes. É aqui que a coisa fica interessante. Como agora estás a correr o CPython standard numa máquina Linux completa, já não estás limitado pelas restrições de memória de um microcontrolador. O teu script pode ler o sensor de hardware usando a translation layer do Blinka e, de seguida, passar esses dados imediatamente para libraries de desktop pesadas. Podes usar network requests standard para enviar as métricas para uma base de dados na cloud, processar a telemetria com ferramentas de data science, ou até mesmo servi-la através de uma web framework local. Aqui está o ponto-chave. O código de interação com o hardware permanece idêntico em arquiteturas de computação completamente diferentes. Ao desacoplar a lógica do sensor do sistema operativo subjacente, o Blinka permite-te fazer protótipos de forma barata em bare-metal e escalar para ambientes Linux completos com zero reescritas de código de hardware. Isto conclui a nossa série sobre CircuitPython. Encorajo-te a ler a documentação oficial, a tentar configurar um sensor com o Blinka de forma hands-on, ou a visitar devstories dot eu para sugerir tópicos para futuras séries. É tudo por agora. Obrigado por ouvires, e continua a desenvolver!