14.2. Entregando a aplicação¶

Um script funcionando na bancada e um produto entregue não são a mesma coisa. Uma câmera que vai a campo precisa funcionar por conta própria pelo tempo em que o produto estiver instalado – meses, anos – sem operador no console, sem IDE conectada e sem nenhum especialista em Python por perto quando algo parar de funcionar. As páginas desta seção abordam o que muda na aplicação quando o objetivo é um produto entregue em vez de uma demonstração de mesa.

14.2.1. Uma lista de verificação pré-voo¶

Antes de uma câmera deixar a bancada, esta é a lista curta de coisas que deveriam ser verdadeiras:

O código da aplicação está na compilação, não no sistema de arquivos. Módulos congelados e uma imagem ROMFS cobrem código e ativos. O armazenamento na flash e no cartão SD é apenas para estado de runtime e arquivos de log. O usuário final não pode editar, apagar ou substituir a aplicação sem regravar o firmware.
Um watchdog executa continuamente. O machine.WDT é iniciado no topo do main.py e alimentado uma vez por iteração do loop principal. Qualquer travamento mais longo que o timeout configurado causa um reset de hardware e a câmera volta a funcionar.
A aplicação registra logs em um destino recuperável. A biblioteca logging grava registros com um nível, um timestamp e um destino que pode ser recuperado em campo a partir do cartão SD. O print() é apenas para o tempo de desenvolvimento – seu destino padrão é a stdout USB, que nenhum produto entregue lê.
A flash e o SD são tratados como passíveis de falha. A flash interna guarda pequenos registros de tamanho fixo (configuração, última calibração conhecida); o SD guarda arquivos volumosos e de tamanho variável (capturas de imagem, arquivos de log); operações em qualquer um deles são envolvidas em tratamento de erros, e a aplicação tem um fallback definido quando qualquer um estiver indisponível.

14.2.2. Incorporando a aplicação à compilação¶

Dois mecanismos complementares colocam arquivos na imagem do firmware: