Por que o Arduino não é essas coisas todas

Um conhecido de twitter, o @technoberto, apontou um artigo no blog Leptoniando criticando a subcultura Arduino e da "computação física". Resumindo o artigo, a "computação física" não passa da mesma tecnologia embarcada da década de 1960, utilizando um microcontrolador da família AVR, que existe desde 1996.

Para quem não conhece, o Arduino, sucessor do Wiring, é uma placa mãe que contém o microcontrolador, o circuito de clock, um botão de reset e uma interface USB (que na verdade é uma RS232C). Essa placa foi desenhada como controlador de baixo custo para a automação de pequenas "obras de arte" ou para permitir o sensoreamento do mundo físico com nossos computadores de uma forma simples.

Para quem não se lembra, houve uma época que um computador pessoal não era muito diferente de um microcontrolador atual. Veja bem: um ZX80, de 1981, tinha 4KB de ROM e 1KB de RAM; seu processador, o Z80A, era de uma arquitetura CISC, cujas instruções podiam ocupar até quatro bytes; seu clock de 3.25MHz era calculado para que a geração de uma linha vídeo coincidisse com um número certo de instruções. Um microcontrolador PIC16F ou AVR facilmente supera estas especificações: podem ter até 64KB de ROM em flash para instruções, cada instrução ocupa especificamente 2 bytes (nestas arquiteturas) e podem ter até 8KB de RAM, executando programas em clocks de até 20MHz. É bem verdade que podíamos colocar programas em linguagem de máquina diretamente na RAM de um ZX80, mas a memória flash compensa isto, permitindo que tudo seja reprogramado rapidamente. Outra vantagem é o tamanho: em um DIP de 28 pinos, temos tudo (e mais) que um computador que pesava quase um quilo! Além da RAM e ROM, um microcontrolador também inclui diversos periféricos, como geradores de sinal PWM, conversores A/D e interfaces de comuicação em série, além de I/O direto pino a pino!

Uma das atrações destes computadores de 8 bits da década de 1980 era a facilidade que podia-se construir uma placa de expansão, para, por exemplo, controlar um sistema de alarme doméstico. Os manuais traziam diagramas detalhados de todas as portas de I/O, incluindo, às vezes, diagramas de tempo das memórias e das portas.

O leitor deve então estar imaginando que eu sou daqueles que não sente saudades dos velhos micros de 8 bits, que tenho Java correndo nas veias, e que nem quero saber de sistemas de baixo nível. Não é nada disso. O que me incomoda é ver um bando de gente vendo o Arduino, e imaginando que é algo revolucionário; mais grave ainda é alguém imaginar que pode automatizar uma grande indústria com um sistema destes. Para um Arduino servir industrialmente, deve ser imune a ruído e intrinsecamente robusto (dois processadores em fail-over é o mínimo).

O Arduino é um "brinquedo", no máximo uma ferramenta educativa; e mesmo nestas funções, é apenas mediano. A base em que a plataforma se apoia é sua principal fraqueza. Primeiramente, o Arduino, para dispensar ferramentas de programação específicas, se vale de um bootloader que ocupa 2KB da memória. Hoje, com 32KB de flash, isto já não representa uma fraqueza tão grande, mas até a última versão o processador tinha apenas 8KB. Ou seja: um quarto da memória era apenas usada para carregar o programa na memória! O bootloader também afeta a latência da interrupção, pois, em controladores tão simples como os AVR, é necessário identificar qual programa estamos executando e fazer um jump para o tratamento correto. A segunda fraqueza diz respeito a linguagem Wiring usada. Levei um tempo para sacar, mas essa linguagem é essencialmente o C! O Arduino utiliza o GCC-AVR com uma libc simplificada e com rotinas especializadas para acessar os periféricos embutidos do microcontrolador. O problema: quando ligamos a rotina principal à biblioteca, o loader do GCC não separa o código não utilizado, e a memória efetivamente disponível para programas ainda é menor. A terceira, e última fraqueza também tem a ver com o Wiring: como não podemos editar o assembly diretamente, não podemos tratar as interrupções. O Arduino resolve isso com variáveis globais que são preenchidas em uma rotina de tratamento da interrupção na biblioteca do Wiring. O código então tem que fazer polling nessas variáveis para poder obter os valores dos sensores conectados aos seus pinos de I/O. Hard real-time se torna impossível.

Não posso encerrar só com críticas: o sucesso do Arduino é sua arquitetura de hardware. Os conectores posicionados de uma forma padronizada facilitaram a construção de inúmeras placas de expansão (os shields) que simplificam o acesso da plataforma a pessoas com apenas um mínimo de conhecimento de eletrônica. O uso do C também é um ponto alto, apesar das limitações que citei; ele permite que o usuário não sofra com uma programação em baixo nível, mesmo sacrificando algumas capacidades do processador.

Fiz este post, pois não aguento ouvir coisas do tipo "Cara, você fala isso por que nunca viu um!" toda vez que digo que não acho que o Arduino seja grande coisa. Explicar tudo isso em uma conversa rápida é impossível. De agora em diante, posso passá-lo para quem quiser saber meus motivos!