14.5. Conclusión

Ha recorrido el ciclo de vida de una cámara que pasa de un script de banco de pruebas funcional a un producto distribuido:

  • Compilaciones de firmware personalizado – el entorno de desarrollo, la construcción de la imagen de firmware a partir del código fuente, su grabación en flash en una cámara, y la vía de depuración desde Cortex-Debug de VS Code hasta gdbrunner en línea de comandos cuando algo va mal del lado del firmware.

  • Distribución de la aplicación – la incorporación del código de la aplicación al firmware mediante módulos congelados, la incorporación de recursos a una imagen ROMFS, y el orden de búsqueda que determina qué copia de un archivo carga realmente el runtime en el arranque. La división que resulta: boot.py para la configuración del entorno previa al REPL, main.py como punto de entrada de la aplicación, main.py congelado para la entrada y ROMFS para todo lo demás.

  • Endurecimiento para producción – la biblioteca logging que escribe en una ruta conocida, un machine.WDT alimentado una vez por iteración del bucle principal, un try / except de nivel superior que convierte los fallos en eventos registrados en lugar de reinicios, la higiene del sistema de archivos que mantiene rápidas las operaciones de archivos a medida que la aplicación acumula registros durante meses en el campo, y –cuando el producto lo requiere– la protección de lectura de la memoria flash.

  • Material avanzado – certificados TLS para cámaras que necesitan autenticarse ante servicios de red y cifrar el tráfico con ellos.

Una cámara distribuida tiene todo esto en su sitio: su código de aplicación se ejecuta desde la imagen de firmware, su watchdog se alimenta una vez por iteración del bucle principal, su registro se guarda en un directorio fechado en la tarjeta SD, y –cuando el producto lo requiere– su memoria flash ha sido bloqueada contra lectura.

14.5.1. Hacia dónde continuar desde aquí

Producción es el último capítulo del tutorial. A partir de aquí, la documentación se divide en material de referencia:

  • La referencia de bibliotecas es la vista alfabética de «cuál es el nombre exacto de esta llamada» de cada módulo que expone la cámara: machine, logging, os, csi, image, ml y el resto.

  • Las páginas de referencia rápida por placa cubren los detalles específicos de cada cámara de la línea de productos OpenMV: asignaciones de pines, buses montables, identificadores de placa, disponibilidad de periféricos y las pequeñas diferencias que importan cuando la aplicación tiene que ejecutarse en una pieza concreta.

  • Las páginas de referencia de sensores y las páginas de referencia de shields cubren los sensores de imagen individuales y los shields complementarios que una cámara puede llevar: las especificaciones por pieza, las asignaciones de pines y las notas que la aplicación necesita al elegir sensores y shields para una compilación.

  • La referencia del lenguaje MicroPython cubre el lenguaje en sí: las diferencias de sintaxis con respecto a CPython, los detalles de implementación que importan cuando un script se mueve entre ambos, y la referencia del ensamblador en línea para el caso poco frecuente en que Python es demasiado lento.

El tutorial es el camino desde «tengo una cámara nueva en la mano» hasta «he distribuido un producto». A partir de aquí, la cámara es una pieza de un sistema mayor del que es responsable la aplicación, y el trabajo es propio de la aplicación.