Estou numa fase idIoTa
Estou numa fase idIoTa
No momento estou com a febre do IoT, planejando caixinhas e circuitinhos para controlar bomba de água, irrigador automático, entre outras coisas. Às vezes me sinto um idiota, pensando que deveria jogar tudo fora e comprar equipamentos ModBus, que fazem as mesmas coisas de forma mais confiável. Mas a felicidade está na jornada, não no destino.
Então vamos aproveitar o embalo para pontuar algumas coisas aleatórias, antes de enjoar (novamente) do brinquedo.
Desenvolvimento IoT é mais difícil que desenvolvimento para computação geral (Web, apps de celular, ERP, essas coisas mundanas). Mas isto não se traduz em salários maiores. Desenvolvimento geral dá muito mais dinheiro, a demanda por tais desenvolvedores é muito maior, ponto. E isso é no mundo todo.
Em particular no Brasil, é quase impossível viver de IoT, não interessa quão bom você seja. Um amigo meu mexe com eletrônica e informática desde criança (na época em que comecei a programar em BASIC num Sinclair, ele já construía periféricos), mas praticava advocacia para pagar as contas. Acabou emigrando para finalmente fazer o que gosta.
Levando isso em conta, faz sentido ensinar robótica e Arduino nas escolas? Acho que sim, mas pelo mesmo motivo que todas as demais matérias escolares existem: para mostrar aos alunos como o mundo funciona. É importante que saibam que, embutido em cada objeto aparentemente simplório, tem um computador rodando o software escrito por alguém.
Mas não devemos nos iludir. Piscar um LED no Arduino da escola não significa empregabilidade imediata na formatura. Se você quer ganhar dinheiro com IoT no curto prazo, abra uma loja de componentes, ministre treinamentos ou escreva livros. Sabe como é: em havendo uma corrida do ouro, venda pás e lenços.
Então, por que um desenvolvedor de computação geral deveria meter-se com IoT, se não ganha nada com isso?
Um aspecto é que IoT ensina disciplina. Todas aquelas boas práticas de desenvolvimento (controle de versão, commits pequenos, testes unitários, testes de cobertura) que na computação geral são recomendáveis mas ainda podemos passar sem elas, em IoT é obrigatório.
Em IoT, as ferramentas de depuração são muito escassas. Se você não tiver disciplina, vai acabar com um monolito de código que não funciona, e descobrir por quê vai custar quase o mesmo que uma reescrita.
Programação embarcada embute um paradoxo. Por um lado, ferramentas de desenvolvimento piores e mais escassas, trabalhadas por desenvolvedores mal pagos. Por outro lado, exigência muito maior de confiabilidade. Imagine que seu carro tivesse um problema misterioso que faz ele pegar fogo, e a "solução" é desconectar a bateria uma vez por semana. Seria motivo para devolver o carro e processar a montadora até a falência.
Mas esse fio da navalha tem seu lado interessante. Gente rica anda de barco à vela por motívos análogos: competir, experimentar o risco, exercitar a capacidade de improvisação, conectar-se ao passado da navegação onde "homens eram homens".
IoT apura o seu faro de fuçador, pois você terá de caçar "aqueles" bugs misteriosos, que talvez nem sejam por culpa sua. Documentação, bibliotecas e até componentes de hardware também têm bugs! Isso acontece menos na computação geral, mas também acontece, e um pouco de exercício nunca faz mal.
Em IoT, a disciplina de testar frequentemente e desenvolver incrementalmente estende-se ao hardware. Assim como no software, tudo pode dar errado também no hardware, e dá mais trabalho descobrir e arrumar. Até mesmo chaves liga/desliga dão problema, que são a última coisa que você espera que incomode (pergunte como eu sei).
Um aspecto divertido e relaxado em programar microcontroladores é poder monopolizar a CPU. Aplicações de tempo real são fáceis de fazer. Práticas como bit banging e busy loops podem e são usadas impunemente. É algo que remete ao MS-DOS e aos computadores antigos, onde essas práticas eram normais e as CPUs nem precisavam de dissipador de calor.
Se você faz questão de caprichar, há interrupções e modos de hibernação, mas não há penalidade em rodar a CPU em 100%, e o consumo de energia ainda será relativamente baixo. Em alguns chips como o ESP32, você pode simplesmente reduzir o clock, reduzindo muito o consumo sem mexer em nenhuma linha de código.
(Note que isso é válido para microcontroladores tipo AVR, ESP8266, ESP32, etc. Placas tipo Raspberry Pi 4 ou Zero, que rodam Linux, gastam muita energia e dissipam muito calor se forem forçadas. Para estas últimas, o estilo de programação deve seguir o da computação geral.)
Tenho uma certa birra com C/C++. É no IoT que a inconveniência do C++ se revela mais abertamente. Não é uma linguagem aceitável no estado atual da tecnologia.
Sim, eu sei, C++ é rápido, é conhecido, é suportado por todas as plataformas, etc. Eu uso C++ nos meus projetos, ainda prefiro ele ao MicroPython/CircuitPython, por questões de maturidade do ecossistema e também da velocidade.
O problema é que C++ é inseguro. Por mais que o código compile, e você use as boas práticas do C++, sempre pode haver um vazamento ou ponteiro perdido. O jeito que eu dou, é rodar os testes no Valgrind. Isso implica haja testes suficientes para cobrir 100% do código. (Sim, já me aconteceu de ter 99.9% de cobertura e justo no 0.1% descoberto havia vazamento, então tem de ser 100%.)
Mas não tem Valgrind para plataformas IoT. É preciso rodar os testes num PC, com mock-ups para as interfaces de hardware. O Arduino (plataforma que eu utilizo para IoT) não usa STL, e a classe String do Arduino é sui generis. Isso traz complicações adicionais na hora de valgrindear seu código. Uma alternativa é simplesmente não usar essa classe (que de todo modo é desaconselhada por fragmentar o heap).
Sim, ajuda bastante adotar as boas práticas. RAII, smart pointers, vetores em vez de matrizes, etc. Restringir ou banir o uso de new e delete. Embora o Arduino não possua STL, não é difícil achar implementações avulsas de smart pointers e containers.
Mas a indústria está madura para uma linguagem nova, cuja segurança seja garantida em tempo de compilação, sem a necessidade de seguir as receitas de bolo do Effective C++. Sim, estou falando de Rust, a grande desafiante do C++ no momento. Pretendo começar a brincar com Rust + IoT; os toolchains já existem, embora sejam bastante "verdes".
Tenho muita curiosidade em saber como se desenvolve software para aviônicos, por exemplo. É um nicho bem fechado, mas diz-se que usam ferramentas estilo low-code e em particular o Simulink. A linguagem Ada tem lugar cativo em partes especialmente críticas como o piloto automático.
Podemos dividir as plaquinhas no estilo Arduino e Raspberry em dois grandes grupos:
Existem algumas nuances aqui. Algumas placas do tipo I são muito limitadas em memória ou armazenamento, e pedem versões especializadas de Linux (e.g. OpenWRT). Por outro lado, ESP32 possui uma MMU simples e roda o sistema operacional FreeRTOS, que não é de uso geral, mas implementa multitarefa preemptiva.
Ao lado desta classificação principal, corre outra, acessória, porém não menos importante: conectividade de rede. Qualquer projeto maker digno desse nome vai envolver conexão à Internet. Sob esse prisma, um ESP32 "vale mais" que um Raspberry Zero não-W.
A nomenclatura microcontrolador × microcomputador é usual, mas considero-a incorreta. Historicamente, "microcontrolador" é um chip que embute CPU, memória e outros circuitos de apoio num mesmo chip. Hoje em dia, isso é chamado de system-on-a-chip (SoC), e mesmo computadores maiorzinhos são baseados em SoCs. Por outro lado, já existiram inúmeros microcomputadores sem MMU. Mas enfim, ruminações de um velho.
O que interessa é que plaquinhas do tipo I são melhores para certas tarefas, enquanto as do tipo II são melhores para outras. A minha plaquinha dos sonhos seria uma mistura das duas:
A BeagleBone é a que mais se aproxima desse ideal; infelizmente é muito cara. Outras que chegam perto: Raspberry Zero, ESP32 e Raspberry Pico.
Na verdade, a "plaquinha dos sonhos" é realmente uma utopia. Um SBC (single-board computer) capaz de rodar Linux vai ter tamanho, consumo e dissipação sensivelmente maiores que um Arduino Mini. Ainda não chegamos no ponto em que uma SBC com tamanho e preço de um Arduino Mini seja capaz de rodar Linux.
Também é preciso contestar se rodar Linux é realmente necessário numa aplicação embarcada. Por exemplo, já me arrependi de ter construído o controlador de bomba de água de forma tão elaborada; a próxima versão vai ser meramente um transdutor dos sensores para MQTT. Toda a "inteligência" estará num computador separado.
O controlador de irrigação já vai nessa direção, sendo quase completamente "burro". E para este caso de uso um ESP32 ou ESP8266 rodando código bare metal é perfeitamente suficiente.
Em termos de custo/benefício, nada supera o ESP32 no momento. Rápido, barato, fácil de achar, Wi-Fi embutido, I/O generoso, consumo baixo e "melhorável" se necessário, toolchain ativamente desenvolvido e gratuito (embora não livre, que eu saiba). Algumas placas baseadas em ESP32 têm inclusive Ethernet, PoE e slot MicroSD.
Gostaria de brincar mais com Raspberry Zero e CM4, sou muito fã do ecossistema Raspy, mas os preços estão absolutamente irreais neste momento. Sai mais barato comprar um Intel NUC e conectar um Arduino na porta USB para bucha de canhão I/O.
E o Raspberry Pico? Ele é menos poderoso e mais caro que o ESP32. Por outro lado, o histórico da fundação Raspberry é bom: hardware e software livres, com excelente suporte e documentação, o que tende a fomentar um aftermarket vibrante (pelo menos foi o que aconteceu com os demais Raspies). Vi hoje mesmo que já apareceu um "HAT" Ethernet para ele.
Existem muitas outras plaquinhas além das mencionadas acima. Só na seara do "tipo I", capaz de rodar Linux, há muitas SBCs no nível do Raspberry Pi 1/2/3/4/Zero: Orange Pi, Banana Pi, Nano Pi, Pine, entre outras.
Em geral, são mais baratas e mais prontamente disponíveis que as equivalentes Raspberry. Também vêm em sabores muito mais variados. Você quer montar um roteador com 3 portas Ethernet? Fazer isso com Raspberry exigiria usar adaptadores Ethernet-USB. Mas existem Orange Pi's e Banana Pi's com 2, 3, 4, 5, até 6 portas Ethernet de fábrica.
Então, por que alguém ainda compraria Raspies!? A grande questão é o suporte: documentação, distribuições Linux disponíveis, clareza sobre o status de propriedade intelectual do software envolvido. Em 2022, você tira da gaveta um Raspberry Zero comprado em 2017, e você encontra documentação e imagem Linux atualizada, como se fosse um produto novo. (Arduino é outro exemplo de ecossistema bem-sucedido pela mesma razão.)
Já as placas "alternativas" pecam muito no suporte. A documentação é difícil de achar, um simples pinout está enterrado num site obscuro ou num documento escrito em chinês. O kernel do Linux é desatualizado, é um arremedo de código que o fabricante "jogou para a comunidade" e não quis pagar um centavo para alguém manter.
Isto quer dizer que devemos evitar esses SBCs como a peste? Não necessariamente. Eu mesmo tenho dois Orange Pis, a distribuição Armbian faz um excelente trabalho suportando plaquinhas ARM menos famosas. Os SBCs alternativos não são uniformemente ruins no quesito suporte; Orange Pi é o melhorzinho.
A questão é que você deve comprar com os olhos abertos: pesquisar antes se as informações necessárias a seu projeto estão disponíveis, se o Linux está razoavelmente atualizado, etc. E consciente que, daqui a 5 anos, talvez o suporte àquela plaquinha não exista mais. São preocupações que, no ecossistema Raspberry, você não tem.
Por último, é interessante lembrar que esse problema das distribuições Linux suportarem as placas ARM de forma desigual, é em parte culpa da própria plataforma.
Uma distribuição Linux x86 roda em praticamente qualquer x86, seja um SBC, seja um supercomputador, pois todos eles implementam um núcleo duro de padrões (ACPI, UEFI, BIOS, etc.) que conhecemos como IBM PC. Não interessa quem fabricou, há quanto tempo, se o fabricante já faliu. Um PC é um PC, ontem, hoje e sempre.
Por outro lado, cada plaquinha ARM (ou MIPS) é uma plataforma sui generis. Iniciativas como DeviceTree e SystemReady estão procurando mitigar esse problema. Então a tendência é de melhora, e um dia poderemos comprar plaquinhas sem depender do fabricante para obter suporte. Mas ainda não chegamos lá.
Falando em PC, não é por ser maker que você é obrigado a usar computadores não-PC! Tem gente montando cluster de Raspberry no YouTube como se fosse o ó do borogodó, mas nem de longe são soluções custo-efetivas ou confiáveis. Um mini-PC estilo Intel NUC tem custo-benefício excelente. Só se justifica usar plaquinhas SBC quando a aplicação exige poucos recursos computacionais, e aí um computador menor que um PC e mais barato que um PC dá conta do recado. (E se a Intel não tivesse marcado passo, os x86 dominariam também entre os SBCs.)
UPDATE: onde lia-se "automação residencial", substituímos por "domótica", por sugestão do amigo LVR. Graças a ele, Se você não aproveitar mais nada desse artigo, pelo menos terá aprendido uma palavra nova!
Assim como todo nerd, sonhei em "automatizar" a casa inteira, ligando luzes pelo celular, etc. Mas acabei desistindo. Para não ficar completamente baunilha, empreguei relês de impulso, eletromecânicos, que facilitam coisas como chaves paralelas e controle de mais luzes com menos interruptores físicos. Os dois Sonoff Mini que comprei para iniciar os testes, estão aí jogados numa caixa. Mas por que traí o movimento?
A resposta curta: não enxerguei valor. Custo maior, estresse com mão-de-obra, expectativa de mais manutenção (a região aqui tem muitos raios), a troco de quê? Para fazer o mesmo que interruptores e fotocélulas já fazem há 100 anos de forma muito mais barata e confiável. Sim, talvez esteja sendo reacionário nesse ponto, mas é isso.
Por mais que IoT seja um hobby para mim (pelo menos no momento), não quero ser obrigado a mexer com isso porque as luzes da casa pararam de acender. Usar comandos de voz para ligar luzes também é algo que não me atrai, e é uma violação potencial de privacidade. Talvez seja algo válido num cenário tipo deficiência física severa.
Automação residencial de iluminação é muito comum, mas não porque é especialmente útil. É porque é fácil de fazer, e dá um resultado bem visível com pouco esforço. É análogo a piscar LED no Arduino. Faz parte do jogo? Faz, para quem parte do zero absoluto. Aprendi um bocado sobre MQTT enquanto brincava com meus Sonoff Mini, que atualizei o firmware para Tasmota para evitar o ecossistema proprietário.
Mas é ilusão achar que vai rachar de ganhar dinheiro com isso, assim como piscar LED no Arduino da escola não lhe garante um emprego tecnológico. Conforme dissemos antes, não há dinheiro nisso, lembra? E "isso" inclui o supostamente gigantesco mercado da domótica. (É curioso como um nicho de mercado pode parecer promissor, sem realmente ser.)
Como disse um cara no YouTube (ainda não achei o vídeo para linkar) a lâmpada elétrica já é ela mesma a automação; é a solução perfeita e acabada para o problema de usar lamparinas a querosene ou ir dormir com as galinhas. Existem outros problemas que podem ser resolvidos pela domótica? Claro que há.
Um exemplo que esse mesmo YouTuber citou foi a máquina lava-e-seca da LG, de popularização relativamente recente. Entra roupa suja, sai roupa pronta para guardar. Isso é domótica: uma máquina multiplicando o seu tempo livre, diminuindo o tempo e esforço despendido em trabalhos repetitivos e chatos.
Recentemente, instalei uma fechadura eletrônica. Nada sofisticado, não tem câmera nem conexão à Internet, mas é algo que poupa tempo e te liberta de carregar uma chave quando sai de casa por curtos períodos. É outro exemplo de automação bem-sucedida.
Então, para alguém que já passou da fase de piscar LEDs, qualquer iniciativa na área da domótica deve ser orientada pelo valor que entrega, quanto tempo ela vai economizar para você, qual a melhoria de qualidade de vida que a automação vai proporcionar.
Hoje em dia a moda é "desapegar", acumular o mínimo possível, doar ou vender tudo que não precisamos imediatamente. Rimos dos nossos pais e avós que guardavam tudo, até tampas de margarina. De um ponto de vista moderno, eram todos doentes mentais, com transtorno de acumulação. Estamos na era de resolver tudo por software, por download imediato, "there's an app for that".
Mas, como bem ensina este episódio da série Night Visions, as lendas, os mitos e os hábitos têm raízes reais. Nossos pais guardavam potes de margarina porque adquirir embalagens era difícil, longe e/ou caro. Nossos pais também tinham o hábito de consertar e remendar coisas, eram muito mais "makers" do que nós, e de forma natural, sem fazer força. Para fazer isso, tinham de usar o que estava à mão. Não havia Mercado Livre com entrega Full.
Para ser "maker", você tem de reaprender a acumular. Às vezes, aquele pote de margarina é o recipiente com tamanho e formato exatos para acomodar seu projeto. (Embalagens de comida delivery também são muito boas.) Ou você precisa de um simples pedaço de plástico ou metal, mas no sábado à noite nem o Mercado Livre entrega, então ou você acumula uns cacarecos, ou tem de esperar mais uma semana para prosseguir.
Em geral, peças de eletrônica são muito baratas, o frete é que é relativamente caro, principalmente ao comprar da China. Então aproveite e compre logo meia dúzia de cada item. Diferente do desenvolvimento de software, mancadas de hardware custam a queima de peças, então não tem como escapar de estocar sobressalentes.
Pessoal que mexe com mecânica tem esse cacoete de guardar tudo que é parafuso, porque existem milhões de tipos e tamanhos diferentes, e muitos não se encontram para comprar. Em IoT acontece o mesmo: você está usando ESP32, então deveria jogar fora todos os ESP8266 e AVRs do estoque? É claro que não; um dia, aparece uma tarefa que só um microcontrolador "velho" resolve, ou pelo menos resolve melhor.
O mesmo vale para cabos, conectores, tomadas, etc. Nunca jogue nada fora, por mais obsoleto que pareça, pois grande é a chance de precisar no futuro, e aí não vai ser fácil de achar. Isso vale até para computadores velhos (uma workstation antiga é um bom servidor, um servidor velho pode ser um bom computador embedded). Até monitores velhos são úteis (apesar de infelizmente volumosos) quando você encarar "aquele" equipamento que só tem porta VGA, ou na hora de montar aquele projeto c00l-retro que gera sinal VGA usando bitbanging.
Qualquer tecnologia que um dia atingiu massa crítica de popularidade ficará conosco para todo o sempre. Em tantos anos nessa indústria vital, só observei uma exceção: a porta paralela.
A outra faceta da boa acumulação é não jogar tudo fora quando enjoar ou ficar frustrado com a eletrônica. Já fiz isso umas 3 ou 4 vezes. Lá se foram Arduinos, Raspberries (quem ia saber que um Raspberry em 2022 custaria tão caro quanto um computador inteiro?) e muitos componentes.
Livrar-se de tudo é um ato de iconoclastia; a intenção é eliminar aquilo da nossa vida, para nunca mais voltar. Porque, tendo descartado tudo, teria de comprar tudo de novo, e quem faria isso? Mas aí a "febre" volta e a gente compra tudo de novo mesmo... um ato irracional não coloca outro ato irracional na balança.
Por vezes a eletrônica é frustrante mesmo, então o negócio é aprender a estivar tudo num canto escuro, porque dali a meses ou anos você vai querer voltar.