programación de código reubicable. programación ubicada n tenemos que decidir en qué direcciones...

Programación de código reubicable

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

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)

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

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.

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

Directiva CODE

Se sustituye la directiva ORG por la directiva CODE

CODE 0goto inicio

Continua CODEinicio movlw 56h

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

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

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

UDATAV RES 1SigV RES 1V1 RES 1SigV1 RES 1V2 RES 1SigV2 RES 1DUMB RES 1Oper RES 1

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

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

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

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

Directiva EXTERN

Para que un módulo pueda acceder a los símbolos definidos en otro módulo, debe declararlos previamente

EXTERN retardoCODE....call rertardo

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

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

Generar un ejecutable

Primero hay que editar el proyecto

En las Node Properties...

Generar un ejecutable

•Cambiar el Language Tool a MPLINK

•Incluir en Additional Command Line Options el archivo de comandos de linkado:

lnk16f84.lkr

Generar un ejecutable Añadir los archivos de

los módulos También aquí se

pueden incluir librerías precompiladas

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

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)