14.2. Expedir a aplicação

Um script a funcionar na bancada e um produto expedido não são a mesma coisa. Uma câmara que vai para o campo tem de funcionar por conta própria durante o tempo em que o produto estiver instalado – meses, anos – sem operador na consola, sem IDE ligado, e sem especialista em Python por perto quando algo deixar de funcionar. As páginas desta secção descrevem o que muda na aplicação quando o objetivo é produto expedido em vez de demonstração na secretária.

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

Antes de uma câmara sair da bancada, esta é a lista curta de coisas que devem ser verdadeiras:

  • O código da aplicação está na compilação, não no sistema de ficheiros. Módulos congelados e uma imagem ROMFS cobrem código e recursos. O armazenamento em flash e cartão SD destina-se apenas a estado de runtime e ficheiros de registo. O utilizador final não pode editar, apagar nem substituir a aplicação sem regravar o firmware.

  • Um watchdog está continuamente em execução. machine.WDT é iniciado no topo do main.py e alimentado uma vez por iteração do ciclo principal. Qualquer bloqueio mais longo do que o timeout configurado provoca um reset de hardware e a câmara volta a iniciar.

  • A aplicação regista para um destino recuperável. A biblioteca logging escreve registos com um nível, um timestamp e um destino que o campo pode recuperar do cartão SD. print() é apenas para desenvolvimento – o seu destino padrão é o stdout USB, que nenhum produto expedido lê.

  • A flash e o SD são tratados como podendo falhar. A flash interna guarda registos pequenos de tamanho fixo (configuração, última calibração conhecida); o SD guarda ficheiros volumosos e variáveis (capturas de imagem, ficheiros de registo); as operações em qualquer um deles estão envolvidas em tratamento de erros, e a aplicação tem um comportamento de substituição definido quando qualquer um estiver indisponível.

14.2.2. Incorporar a aplicação na compilação

Dois mecanismos complementares colocam ficheiros na imagem de firmware: