Secuencias de comandos para automatizar proyectos con herramientas de microchip

Realmente no puedes escribir el IDE. No está diseñado para eso. Por supuesto, puede ejecutar el compilador, el ensamblador, el bibliotecario y el vinculador directamente sin utilizar el IDE. De hecho, así es como construyo todos mis proyectos PIC. Yo uso el IDE sólo para la depuración. La razón por la que hago esto es para permitir compilaciones automáticas de firmware PIC como parte de un proceso más amplio, y para aplicar algunas de mis propias herramientas en la cadena desde el código fuente hasta el archivo HEX. Por ejemplo, ejecuto todo mi código fuente ASM30 y MPASM a través de mi preprocesador .

Para saber cómo ejecutar las diversas herramientas directamente, lea el manual, que en este caso es MPLAB ASSEMBLER, LINKER AND UTILITIES para MCU PIC24 y dsPIC DSCs Guía del usuario , DS51317.

Sin embargo, reconstruir el firmware cada vez suena más complicado de lo necesario. Si solo está cambiando algunos datos en una ubicación conocida en la memoria del programa, entonces puede hacerlo con un simple programa de edición de archivos HEX. Hago este tipo de cosas de vez en cuando, a menudo para crear un archivo HEX con un número de serie único de un archivo HEX maestro. Hago un programa que lee un archivo HEX en arreglos en la memoria, generalmente uno para la memoria del programa ejecutable, los bits de configuración, los datos iniciales de EEPROM y las ubicaciones de ID de usuario. Luego, el programa modifica los datos según sea necesario y escribe el resultado en un nuevo archivo HEX.

Por lo general, es una buena idea colocar la información del firmware en una dirección fija conocida al hacer esto. Por lo general, coloco el ID de tipo de firmware, el número de versión y el número de secuencia en los tres bytes de la palabra de memoria del programa a las 800 h. Eso es lo suficientemente extenso en el código ejecutable para que la sección entre inicio y 800 h sea lo suficientemente grande como para utilizar de manera eficiente, pero no tan lejos como para haber pasado el final de la memoria del programa para cualquier PIC razonable. Convierte esto en una sección de código fijo y deja que el enlazador coloque secciones reubicables a su alrededor. Aquí hay un ejemplo de un proyecto reciente:

;*******************************************************************************
;
;   Constants in program memory so that HEX file editing tools know the version
;   of this firmware.
;
.section .fwinfo, code, address(0x800)
         .pword  fwtype | (fwver << 8) | (fwseq << 16)

Esto permite que la herramienta de archivo HEX pueda verificar que está trabajando en el tipo correcto de archivo HEX y mostrar esta información en tiempo de ejecución.

De hecho, puedes escribir tus propias herramientas personalizadas para eso. Llamar a las herramientas de microchip desde la línea de comandos no es trivial y probablemente tenga que hacer un esfuerzo (valioso) para configurar todo.

Hice varios de estos y puedo decir que:

1. Es muy útil aprender un lenguaje de scripting como Python, Perl, etc;
2. Tener un conocimiento profundo de los archivos por lotes de Windows o los scripts de shell en Linux también ayuda mucho;
3. Escribir herramientas personalizadas lo ayuda a aprender todo el proceso;
4. Vale la pena invertir tiempo en crear un sistema de compilación decente, especialmente si el firmware forma parte de un proyecto más grande (piense en Scons, CMake, etc.);

Para sus necesidades específicas, puede crear un pequeño programa que use una C-define para cambiar la dirección de lo que quiera cambiar la dirección. ¿Cómo se borra la EEPROM? ¿La MCU le envía comandos? ¿Por qué no se escribe una herramienta de GUI sofisticada para eso que se comunica con un firmware de servicio (o pone su firmware actual en modo de servicio, si hay espacio para eso)? Solo necesitas un RS232 que funcione para hacer eso.

Soy un gran fan de escribir código personalizado para hacer que los procesos sean más rápidos y menos propensos a errores.