Problema simulando PIC16F648 en Proteus 7

[garocco]

Buenas noches. Antes que nada quisiera felicitarlos a todos por este espacio de intercambio y aprendizaje que han sabido desarrollar y mantener. Es una fuente constante de consulta, y aunque la mayoría de las veces he encontrado soluciones a problemas similares a los que se me han presentado, no he podido hacerlo en este caso.

Paso a comenta mi problema:
Estoy desarrollando un control de temperatura pid y comencé a hacerlo con un 16F628. Casi sobre el final tuve que agregar un poco más de operaciones matemáticas y me quedé sin memoria disponible por lo que me compré un 16F648A. Todo igual me dije, solo que más memoria de programa...
El software lo he desarrollado en lenguaje C, con el compilador CCS V.4.093. Para simular utilizo el Proteus 7.4 SP3. El problema ocurre cuando trato de simular en Proteus. Cuando compilo, el "main()" del programa el compilador me lo ubica a partir de la dirección 0x894h, pero cuando lo cargo en el proteus es como que no me reconoce direcciones mayores a 0x7ffh, pues el salto inicial, en vez de hacerlo a 0x894 lo hace a 0x094. Llama la atención que en el listado del compilador las direcciones de memoria superiores a 0x7ff aparecen correctamente, pero en la ventana de código del proteus, las direcciones superiores a esta aparecen sin valor asignado, com pueden ver en la imágen que he llamado consulta1.jpg adjunta (http://img12.imageshack.us/img12/285/consulta1.jpg). en la otra imágen muestro el listado generado por el compilador ccs (http://img23.imageshack.us/img23/476/consulta2.jpg). Si utilizo el mismo circuito, pero al micro 16f648 le cargo el mismo .hex que usaba con el 16f628 funciona a la perfección (aunque sin la ultima parte matemática que agregué, por problema de espacio). Probé con el proteus 7.5, el 7.6 sin resultados positivos. Como dato adicional, si lo simulo con el  PIC simulator IDE funciona bien, pues si me reconoce la escritura del dato 0x08 en el PCLATCH, por lo que si puede direccionar desde la posición 0x800. Si alguien puede sugerirme por favor algún procedimiento o pruebas que pueda realizar, o si necesitan que les explique mas en detalle algo, quedo a vuestra disposición. Muchas gracias.

[garocco]

Sigo creyendo que el problema es que el Proteus no me registra las modificaciones del PCLATCH, y por lo tanto no salta a la porción por encima de los 2K de memoria...

 Aparentemente es lo mismo esta porción de código:

BCF    0A.3
GOTO   689
BSF    0A.3

que esta otra:

GOTO   689

Consulta:

1) ¿Existe una directiva del compilador con la cual le puedo indicar que al compilar un fragmento de código lo haga en la posición 0x850, por ejemplo? Probé con #org 0x850 , pero me dice que no es válida esa dirección...
2) ¿Puedo ejecutar el código en ensamblador para hacer el debug en proteus? (es decir ejecutar paso a paso el archivo .lst o .asm en vez del código en C?
Muchas gracias.
Saludos.
Gustavo.

[Suky]

En CCS para indicar posición de una función hay que indicarlo con #org Inicial, final. Hay que indicar los 2 parámetros.

En proteus, pulsando CTRL + D puedes ver el código en asm realizado por el C.


Saludos!

[garocco]

Hola Suky. Muchas gracias por contestar tan rápidamente. Excelente lo del CTRL+D en Proteus! Respecto del #org aparentemente no lo estoy utilizando bien...

Generé una función con la directiva de la sgte. manera:

#ORG 0X800,0X805
void nada(void){
#ASM
   NOP
   NOP
   NOP
#ENDASM
}

con el solo fin de hacer un debug del soft. Defino el prototipo en el archivo de cabecera, y llamo a nada() al comienzo del main() (como primera instrucción). Cuando intento compilar me aparece un "error 166: Invalid overload function nada" y luego un error43: expecting definition por cada una de las líneas de codigo siguientes.

Tomo el programa que corría en el 16f628, le agrego un poco de procesamientos adicionales con el fin de que el tamaño del programa exceda los 2KB y me voy a simular en el Proteus. El comienzo del programa (en la dirección cero aparece el siguiente fragmento:

0000:  MOVLW  08
0001:  MOVWF  0A
0002:  GOTO   094
0003:  NOP
.................

y en la dirección 0x894 (dirección del main), el siguiente:

.

................... void main()
.................... {
*
0894:  CLRF   04
0895:  BCF    03.7
0896:  MOVLW  1F
..........

Cuando el Proteus ejecuta el goto 094, con el PCLATCH = 8, hace un salto a la posición 0x894, pero no encuentra código!!!
Aparece la pantalla vacía con el siguiente mensaje en el medio:
"No source line at PC address [PC=0894]"
lo que se condice con el hecho de no tener dirección de memoria asignado main en la imágen consulta1 del primer post...
Toda  sugerencia es bienvenida. Nuevamente gracias por tomarte la molestia de leer y contestar.

Saludos.

Gustavo.

[Suky]

Si sale Invalid overload function nada estas obligado a aumentar el tamaño a 0x806 o 0x807, porque hay que tener en cuenta la directiva return.

Después si en proteus estas usando el 648 y salta el problema, claramente es un bug, que no esta considerando el tamaño correcto de memoria de ese micro. que versión es?


Saludos!

[garocco]

Probé aumentar el tamaño y el error de "invalid overload..." persiste. De todos modos estoy casi seguro de que el problema se debe a un bug en el modelo del 16f648. Lo raro es que no existen reportes en internet acerca de esto. En este momento estoy usando el Proteus 7.4 SP3, aunque lo he probado también en la versión 7.6 portable y me ocurre lo mismo.
Mientras tanto para poder hacer las pruebas, he sacado los "chiches" adicionales del código y he dejado solamente la parte necesaria para que funcione el control que deseo probar. Luego voy a habilitarlo de nuevo, compilarlo y grabarlo en el pic. Debería funcionar. Estoy buscando información para poder editar la librería pic16.dll para ver si puedo hacer algo para corregir este problema. Aparentemente es posible hacerlo con el visual c++. Los mantendré al tanto de las novedades.

Saludos.

[garocco]

Antes que nada quiero comentarles de que estaba equivocado en las conclusiones a las que llegué anteriormente. Si bien no entiendo que es lo que está fallando con mi código en particular, lo cierto es que cree un proyecto muy simple en mplab, usando los fragmentos de código que les mostré en el post #4 y cargué el archivo.cof en el proteus y anduvo sin problemas (es muy elemental y no contiene saltos ni llamadas a interrupciones). Luego siguiendo el consejo de Suky puse un #ORG 0X800,0X8FF en el main de mi programa original, no dió errores y me lo ubicó en ese segmento sin problemas. A la hora de ejecutarse se me llena el "simulation log" de errores por:

"Stack  underflow executing RETLW instruction"
"Stack  overflow executing CALL instruction"

(unos 900 mensajes en 4 segundos, se me resetea el pic... todo un lío!)
No se a que se deben todavía, pero podría sospechar que es  producido por problemas de paginación?

Suky: si no es inconveniente para vos puedo hacerte una consulta sobre la teoría de control de uno de tus desarrollos (me interesa particularmente consultarte sobre el anti-windup). Si se pudiera, indícame por favor en que parte del foro debería realizar la consulta. Muchas gracias.

Saludos.

Gustavo.

[garocco]

El problema del stack under y overfolw se producía porque al aumentar la cantidad de memoria ram utilizada, el compilador me utilizaba el banco que estaba en la otra página. Cuando se producía una interrupción el bit de status,rpx era salvado pero no modificado para trabajar en el banco 0. Estaba utilizando el código recomendado por microchip para salvar contexto en una interrupción, solo había que agregarle al código " clrf  STATUS"  despues de haber salvado dicho registro, para de esta manera seleccionar el banco cero.
Al no hacer esto, quedaba direccionado otro banco y no podía limpiar los flags de interrupción, por lo que se quedaba colgado en dicha rutina.
Les comento por si les llega a suceder.

Saludos.