Programación de código reubicable

1. Programación de código reubicable

2. Programación ubicada • Tenemos que decidir en qué direcciones de memoria vamos a situar nuestro código (directiva org obligatoria) • Tenemos que decidir y gestionar el limitado espacio de direcciones de memoria de datos • Tenemos que construir el programa en un único módulo • Aunque el uso de la directiva ‘ include’puede dar una apariencia de modularidad

3. Programación ubicada • Añadir código obliga a un proceso de integración que evite conflictos por • repetición de símbolos • solapamiento de direcciones de localización de código • uso múltiple (y no previsto) de la misma localización de memoria • El código desarrollado es difícilmente utilizable por otra persona • (o le implica un trabajo de análisis antes de incluirlo en su propio código)

4. Código reubicable • No se localiza el código hasta el mismo momento de creación del archivo objeto • El programador deja en manos del programa linkador la gestión de la memoria de datos (declaración de variables) • Podemos distribuir el código en varios módulos modificables y compilables separadamente. • Algunos de estos módulos pueden ser librerías ya precompiladas

5. Código reubicable • El proceso de añadir código es mucho más simple al liberarnos de la localización • Los símbolos definidos en cada módulo son independientes (y por lo tanto su coincidencia no genera conflictos) • El linkador gestiona las variables del conjunto de los módulos liberando al programador de la tarea • Cada módulo es creado con una interfaz de uso que facilita su reutilización.

6. Homogeneización de código • Con el propósito de homogeneizar lo más posible el lenguaje de programación utilizado con los PIC es conveniente utilizar los recursos estándares: #include ”p16f84.inc” • Aquí se definen todos los símbolos estándares del pic. Su uso dota a nuestro código de un carácter más homogéneo • uso de mayúsculas para nombrar los registros estándares

7. Directiva CODE • Se sustituye la directiva ORG por la directiva CODE • CODE 0 • goto inicio • Continua CODE • inicio movlw 56h

8. Directiva CODE • CODE no requiere especificar la dirección de ubicación • pero es posible hacerlo y en el caso de la dirección cero es necesario. • Cada sección CODE es localizada por separado • si hay más de una sección CODE en un módulo debe tener nombre • el nombre por defecto de una única sección CODE es .code

9. Localización en RAM • Se reserva espacio para cada variable a manejar. • Las reservas se agrupan en secciones según el tipo de variable. • Las mismas secciones en diferentes módulos son tratadas conjuntamente aunque cada una de ellas ubicadas por separado

10. Sección UDATA • Datos no inicializados. Se reserva espacio para cada variable • Una sola sección UDATA en cada módulo de nombre .udata • Si hay varias, cada sección debe llevar un nombre UDATA V RES 1 SigV RES 1 V1 RES 1 SigV1 RES 1 V2 RES 1 SigV2 RES 1 DUMB RES 1 Oper RES 1

11. Sección UDATA_OVR • UDATA overlayed o solapada. Se refiere a que variables en diferentes secciones (o la misma) UDATA_OVR pueden compartir la misma dirección de memoria. • Se utilizará para definir variables temporales de uso muy localizado

12. Sección UDATA_SHR • UDATA shared o compartido. Localiza estas variables en los bancos solapados de memoria. • Podría permitir una compartición selectiva de variables entre programas • En el pic16f84 los dos únicos bancos de memoria de datos están en realidad solapados, así que esta especificación es redundante

13. Sección IDATA • Se declaran variables inicializadas. • La inicialización de variables es un proceso complicado. Recuérdese que la memoria de programas y la de datos están separadas. • La sección IDATA provoca que el linkador cree código de inicialización que luego debe ser leído por un programa de inicialización

14. Directiva GLOBAL • Una vez que hemos creado un módulo debemos crear su interfaz. • La interfaz son las variables y las etiquetas (puntos de entrada a rutinas) que son accesibles desde el exterior CODE .... retardo movlw 56h GLOBAL retardo

15. Directiva EXTERN • Para que un módulo pueda acceder a los símbolos definidos en otro módulo, debe declararlos previamente EXTERN retardo CODE .... call rertardo

16. Directiva BANKSEL • Al utilizar las variable ignoramos en qué bancos han sido declaradas ¿qué bits activar de: STATUS(RP0,RP1,IRP)? • BANKSEL lo soluciona EXTERN variable CODE ... BANKSEL variable movwf variable el lincador, conociendo la localización de variable genera bsf STATUS (RP0, RP1,IRP) según corresponda

17. Directiva PAGESEL • Al utilizar etiquetas, también se ignora dónde han sido localizadas • El PC tiene 13 bits, pero en CALL sólo caben 11 EXTERN etiqueta CODE ... PAGESEL etiqueta call etiqueta el lincador, conociendo la localización de etiqueta modifica convenientemente PCLATH

18. Generar un ejecutable • Primero hay que editar el proyecto • En las Node Properties...

19. Generar un ejecutable • Cambiar el Language Tool a MPLINK • Incluir en Additional Command Line Options el archivo de comandos de linkado: • lnk16f84.lkr

20. Generar un ejecutable • Añadir los archivos de los módulos • También aquí se pueden incluir librerías precompiladas

21. Generar un ejecutable • Finalmente se trabaja como hasta ahora: • Make: compila sólo los módulos modificados desde la última ejecución de este comando y general el ejecutable • Build All: compila nuevamente todos los módulos y genera el ejecutable • Build Node: compila el módulo enfocado

22. Librerías • Las librerías son archivos que contienen módulos ya compilados. • Al utilizar una librería, el linkador únicamente enlaza aquellos módulos de la librería que son efectivamente utilizados • Para crear una librería basta tener un conjunto de módulos compilados (creados naturalmente en código reubicable) e invocar al programa mplib [/q/(ctdrx) librería (modulo1,modulo2... ModuloN)