SIMULACIÓN 16F188xx en Proteus

[Fermin]

Amigos,
Comunicarles que la simulación paso a paso en Proteus con pics de la familia descrita no se puede hacer fácilmente debido a que Proteus cambia y asigna de forma aleatoria las direcciones de las variables en la memoria RAM.
Esto es debido entre otras cosas al uso de 16 posiciones de memoria compartida dentro de todos los bancos y que se mapean como si estuvieran todas en el mismo banco.
Además para el resto y según el banco de memoria en que se encuentren las mapea con un offset.
Por tanto es muy lioso el poder visualizar los valores que van tomando las variables según se vaya ejecutando el programa debido a que es preciso conocer en todo momento en que dirección se encuentra cada una de las variables declaradas.

Por ejemplo una variable situada en la dirección 0x23 la mapeará a la dirección 0x03 de la memoria RAM compartida y si tenemos otra variable en la dirección 0x73 también la va a mapear en la dirección 0x03.
Por otra parte si la variable esta en la dirección 0xA9(banco 1) la pondrá en la dirección 0x59; la 0x129(banco 2) la pondrá en el banco 0xA9 y así sucesivamente para cada banco.

¡¡¡ Vamos todo muy lioso"

Fermín

[Fermin]

Como continuación al post anterior adjunto un pequeño estudio de como se corresponden las asignaciones entre las distintas posiciones de memoria al usar Proteus usando esta familia de microcontroladores pic.

Esta realizado para los bancos de memoria 0, 1 y 2. Para el resto de bancos la dinámica es la misma.

Decir que esto hasta ahora solo me ha pasado con esta familia y que para el resto de pics comprobados la asignación de memoria por parte de Proteus se realiza de forma natural, es decir la memoria asignada a cada variable no cambia nunca.

Fermín

[tsuelectronica]

interesante el detallito en proteus con la familia, ya cuando incorpore niple estos micros los checaremos pero aunque como siempre niple ya lo tendrá optimizado y listo para funcionar y por el momento solo podemos ver tu avance ya que no podríamos checarlo con niple por el momento.

[Fermin]

Aaron,
No solo es cuestión de Niple, lo descrito sucede se cual sea la forma en que vayas a simular y con el código que simules.
Por ejemplo que yo sepa existen varias formas de poder simular un circuito en Proteus (pic16F188xx).

1ª.- Adjuntando el fichero *.cof en las propiedades del microcontrolador:
La simulación rápida y paso a paso funciona pero se tiene el problema descrito con las asignación de las variables en las distintas posiciones de memoria.

2ª Creando un proyecto dentro de Proteus:
Aquí hay que adjuntar el fichero *.asm. Con esto Proteus al empezar la ejecución de la simulación SIEMPRE compila ese fichero asm.
Bien pues NUNCA realiza la compilación indicando que no reconoce esos modelos de pics.
Pero si además el asm adjuntado al proyecto creado es el generado por NIPLE, el resultado es peor, porque además de no reconocer el modelo de pic, da error de la memoria EEPROM y este erro ultimo solo se evita borrando la asignación de los valores 0xff a todas las posiciones de memoria que crea NIPLE al final del fichero ASM.
Por tanto NI FUNCIONA LA SIMULACIN RÁPIDA Y LA SIMULACION PASO A PASO.

3ª Sin crear un proyecto en Proteus y asignando el fichero *.hex a las propiedades del microcontrolador:
Aquí la simulación paso a paso NO funciona.
La simulación rápida funciona pero se tiene el mismo problema descrito en los post anteriores con la asignación de las variables.

RESUMIENDO:
Para esta familia de pics opino que Proteus debería de realizar algún cambio para poder trabajar con las variables y sus pociones de memoria de forma directa.
No he querido mandad ninguna información a LABCENTER sobre este problema debido a que mi Proteus tiene "medicina".

Fermín

[tsuelectronica]

hola amigo fer, y ya intentaste depurar con el .elf en muchos videos es con el que depuran en proteus y también no será que como esta familia ya esta optimizada para lenguaje c y no para ensamblador será hay donde esta el detalle no se si puedas probar tus programas pero en c para que se descarte como son micros de nueva generación están hechos para trabajar en c y ya no en ensamblador.

[Fermin]

No sé si será eso que comentas pero no lo entendería porque al final C hay que pasarlo al hex.

Fermín

[tsuelectronica]

ahorita que comentaste que hay que pasar al .hex no se si también ya checaste en la ventana del código hay se puede ver paso a paso las líneas del código también en ves de ponerle el hex poner el código e ir paso a paso.

[Fermin]

Esa opción no la he comprobado. No sé si se podrá hacer.

Fermín