Microvium: JavaScript minúsculo para firmware em C
O Microvium segue uma filosofia diferente do Espruino. Enquanto o Espruino é muito forte na experiência interativa, com console e prototipação direta no dispositivo, o Microvium foi pensado para inserir pequenos trechos de scripting JavaScript dentro de um firmware predominantemente escrito em C. A própria descrição do projeto apresenta o Microvium como uma engine JavaScript muito pequena, com menos de 16 kB de tamanho compilado, voltada a microcontroladores e capaz de executar um subconjunto útil da linguagem JavaScript. (GitHub)
A ideia central do Microvium é o uso de snapshots. Em vez de carregar todo o código-fonte JavaScript no microcontrolador e interpretá-lo diretamente a partir do texto, parte do trabalho é feita antes, no ambiente de build. O código JavaScript é processado, a máquina virtual é colocada em um estado inicial e esse estado é salvo como uma imagem compacta. Depois, no firmware embarcado, o runtime do Microvium restaura essa imagem e continua a execução a partir dela. A documentação oficial descreve snapshotting como a capacidade de capturar o estado de uma máquina virtual JavaScript, incluindo módulos, funções, variáveis e objetos, para restaurá-lo posteriormente em outro ambiente. (GitHub)
Essa abordagem é extremamente interessante para microcontroladores pequenos, porque remove do dispositivo parte do peso normalmente associado a uma engine JavaScript completa. O microcontrolador não precisa necessariamente carregar um parser grande, lidar com todos os detalhes de análise do código-fonte ou manter estruturas complexas que poderiam ter sido resolvidas durante a etapa de build. Em termos práticos, o Microvium tenta transformar JavaScript em uma camada de scripting mais previsível e compacta, adequada para firmwares onde cada kilobyte de Flash e RAM importa.
O uso típico do Microvium não é substituir todo o firmware por JavaScript. A arquitetura mais natural é ter um firmware em C responsável por drivers, periféricos, protocolos, inicialização do hardware, watchdog, temporização e tarefas críticas. O Microvium entra como uma camada de script para pequenas regras de comportamento. Por exemplo, um produto pode ter sensores, atuadores e comunicação implementados em C, mas permitir que certas regras sejam escritas em JavaScript: quando acionar uma saída, como reagir a um evento, qual política aplicar diante de uma leitura ou como adaptar uma lógica de produto sem alterar todo o firmware.
Essa proposta tem uma vantagem importante: o firmware hospedeiro controla quais funções são expostas ao script. A documentação de introdução mostra o conceito de funções importadas do host firmware e chamadas pelo script, além de explicar que o runtime em C deve ser compilado junto ao firmware hospedeiro. (Microvium) Isso cria uma fronteira arquitetural útil. O JavaScript não precisa ter acesso irrestrito ao hardware; ele chama apenas aquilo que o firmware decidiu disponibilizar. Em produtos mais sérios, essa separação pode ser usada para aumentar segurança, testabilidade e controle.
A principal vantagem do Microvium, portanto, é permitir scripting em dispositivos onde uma engine JavaScript maior seria inviável ou exagerada. O autor do projeto afirma que a engine foi desenhada desde o início para ser pequena, mencionando menos de 16 kB de ROM e consumo mínimo de RAM quando a VM está ociosa. (Coder Mike) Para quem trabalha com microcontroladores de menor porte, isso é um diferencial relevante. Mesmo em dispositivos maiores, como ESP32 ou STM32 com mais memória, uma engine pequena pode ser interessante quando o projeto já está carregado de pilhas de comunicação, criptografia, armazenamento, RTOS e aplicação.
Por outro lado, essa economia vem com limitações. O Microvium executa apenas um subconjunto de JavaScript, não a linguagem completa como usada em navegadores modernos ou no Node.js. A própria documentação alerta que nem todos os recursos de JavaScript são suportados e que novos recursos são adicionados gradualmente. (Microvium) Isso significa que o desenvolvedor precisa escrever scripts pensando no ambiente embarcado, evitando assumir que bibliotecas comuns do ecossistema JavaScript funcionarão diretamente.
Outro ponto é que o modelo por snapshot muda o fluxo de desenvolvimento. No Espruino, a experiência pode ser bastante interativa. No Microvium, o fluxo tende a ser mais parecido com um processo de build: escreve-se o script, gera-se a imagem ou bytecode, integra-se ao firmware e executa-se no dispositivo. Isso pode ser menos confortável para prototipação educacional rápida, mas é mais coerente com produtos embarcados que precisam de footprint controlado e integração forte com C.
Também é preciso ter cuidado para não confundir “pequeno” com “adequado para qualquer tarefa”. Mesmo sendo muito compacto, o Microvium continua sendo uma máquina virtual executando uma linguagem dinâmica. Para controle motor em alta frequência, leitura determinística de ADC, malhas de controle rápidas ou rotinas com requisitos rigorosos de tempo real, C ainda será a escolha mais segura. O Microvium faz mais sentido como camada de decisão, configuração, automação e regras de aplicação, não como substituto de drivers ou rotinas críticas.
Em resumo, o Microvium é uma opção muito interessante quando o projeto precisa de scripting JavaScript, mas não pode pagar o custo de uma engine grande. Sua força está no modelo de snapshot, no pequeno footprint e na integração com firmware em C. Sua fraqueza está no suporte parcial à linguagem, no fluxo de build menos interativo e no fato de que, como qualquer engine embarcada, precisa ser usada com disciplina arquitetural. Em um firmware bem projetado, o Microvium pode funcionar como uma pequena camada programável acima de uma base nativa robusta.
