TODOPIC
Simuladores, editores de PCB, etc => Simuladores de circuitos => Mensaje iniciado por: Fer_TACA en 06 de Septiembre de 2023, 12:59:35
-
Hola,
Estoy intentando comprobar un pequeño proyecto con el pic 16F18877 y al intentar simularlo al crear el proyecto me sale el mensaje de la imagen adjunta.
Luego después al dar OK al aviso, en la ventana de salida aparece otro mensaje en rojo. Justo el que he copiado al lado de la opción de dar OK.
¿me pueden indicar a que puede ser debido?
F.
-
En la línea de comando de MPASMWIN, debería ser /p16F18877 en lugar de /pp16F18877
Pareceria que el chip está mal declarado.
-
gracias Eduardo,
Pero esa línea de comando como y donde se podría encontrar para poder localizarla y corregirla.
estoy viendo en ISIS y no la encuentro por ningún sitio.
-
Estando en la pestaña Source Code:
Project -> Project Settings -> Pestaña Options
- Tienes que ingresar para ver archivos adjuntos -
Es raro, esto se genera al crear el proyecto.
-
Gracias de nuevo por la respuesta.
Eso lo vi al poco de responderte la primera vez y está tal como indicas.
Me supongo entonces que será algún problema de Proteus.
-
el detalle es en proteus, seria mejor que lo testearas en mplab yo eh encontrado varios detallitos en proteus y mejor o los checo en el pic en real o en mplab si hay errores.
-
al parecer ya tienes la nueva actualización con el pic esperemos que nos mande si es una actualización o a comprar si es una versión para poder testearla también.
-
Bueno, he compilado el fichero con MPLAB X IDE
Ahora al intentar ejecutar el programa me salen los mensajes adjuntos.
En el adjunto esta colocado el fichero .cof en el pic. Pero si coloco el .hex salen los mismos mensajes.
¿Alguien me puede decir a que se puede deber ?
¿Sera porque Proteus no puede simular este tipo de PIC?
Gracias
F.
-
al parecer estas cargando un pic 16 en un pic 18 bueno es lo que alcanzó a ver en la imagen
-
al parecer estas cargando un pic 16 en un pic 18 bueno es lo que alcanzó a ver en la imagen
No eso no es, seguro. No se porque hace eso, es el fichero cof creado por MPLAB.
El mensaje que sale con el hex es prácticamente igual en cuanto a la indicación de los errores .
-
si gustas manda el .cof o el .hex y te lo checo en el proteus que tengo, tengo la 8.16 a ver si es la versión u otra cosa
-
Te paso los archivos
-
Es como que en tu hex, está agregado algo en la EEPROM, pero no se si ese simulador tenga algún problema con esa región de la memoria de programa:
(https://pbs.twimg.com/media/F5oRuB6WcAAh3Ng?format=jpg&name=medium)
-
Bueno, he compilado el fichero con MPLAB X IDE
Ahora al intentar ejecutar el programa me salen los mensajes adjuntos.
En el adjunto esta colocado el fichero .cof en el pic. Pero si coloco el .hex salen los mismos mensajes.
¿Alguien me puede decir a que se puede deber ?
¿Sera porque Proteus no puede simular este tipo de PIC?
No creo, me inclino mas por los parámetros de compilación en MPLAB X IDE.
¿Por qué no creas el proyecto en Proteus y que compile con XC8?
-
Bueno, he compilado el fichero con MPLAB X IDE
Ahora al intentar ejecutar el programa me salen los mensajes adjuntos.
En el adjunto esta colocado el fichero .cof en el pic. Pero si coloco el .hex salen los mismos mensajes.
¿Alguien me puede decir a que se puede deber ?
¿Sera porque Proteus no puede simular este tipo de PIC?
No creo, me inclino mas por los parámetros de compilación en MPLAB X IDE.
¿Por qué no creas el proyecto en Proteus y que compile con XC8?
XC8 ¿tiene compilador de ASM?
-
El paquete de XC8 compila assembler con el pic-as
Pero mi comentario fue porque pensé que lo hacías en C, el Proteus no te permite un proyecto compilando con pic-as.
-
Yo creo que deberías hacer cualquiera de las siguientes opciones:
1. Intentar simular tu proyecto con MPLAB X, de esa manera se descarta un problema de ese lado, el cual estaría sólo en el simulador del proteus.
2. Compartir tu proyecto, para que alguien más pueda determinar si le sucede lo mismo.
3. Si no deseas compartir tu proyecto, podrías ir creando de nuevo tu proyecto de poco en poco, y cada por avance irías probando en el simulador que tienes problemas, hasta llegar a donde el proteus no puede cargar el archivo.
4. Algo que se me ocurre, es que posiblemente, el hex generado no es normalizado. Tal vez habilitando la opción mostrada en la siguiente imagen, genere un hexadecimal correcto para que el proteus lo comprenda
(https://microchip-mplab-harmony.github.io/bootloader_apps_usb/apps/docs/images/application_config_normalize_hex.png)
-
Gracias por las respuestas Dominus.
Ya chequeé esa opción que indicas y sigue todo igual.
En cuanto al proyecto, para intentar probar este error, lo estoy realizando con un programa tan simple como hacer parpadear un led.
Adjunto los ficheros asm y hex. No hay problemas por adjuntarlos.
Una cosa curiosa que he visto es que después de salir el error. Proteus me crea otro fichero asm que lo nombra como: ***. hex.asm
Pero si lo abro está vacío.
F.
-
Bueno sigo con ello
Lo que sí he conseguido es que se pueda simular paso a paso. Para ello he tenido que crear un nuevo proyecto con la versión 5.35 de MPLAB X IDE. Esta versión es la última que incluye el compilador mpasmwin.
Una vez compilado, le añado el fichero cof que genera MPLAB al pic en Proteus en lugar del hex. Con esto se puede simular paso a paso.
Lo que sucede es que no hay forma de que se muestren de forma real los valores internos del pics. Lo que realizo es añadir a la ventana watch windows la variables y la direcciones que están asignadas en Niple y que son las mismas del ASM. Pues bien cuando ejecutas el programa los valores que se muestran en estas variables son siempre fijos y no se corresponden en nada con lo que deberían de mostrar.
Las direcciones de las variables las he colocado de distintas formas y siempre indican el mismo valor, lo puedes ver en la captura adjunta.
-
...Lo que sucede es que no hay forma de que se muestren de forma real los valores internos del pics. Lo que realizo es añadir a la ventana watch windows la variables y la direcciones que están asignadas en Niple y que son las mismas del ASM. Pues bien cuando ejecutas el programa los valores que se muestran en estas variables son siempre fijos y no se corresponden en nada con lo que deberían de mostrar.
...
Por razones que desconozco, Proteus cambia la dirección a las variables según donde estén.
En particular, las variables ad0_l,ad0_h.... las tenés que declarar en RAM_SHARED y la dirección en lugar de 0x73,0x73... se pone 0x03,0x04...
-
Gracias por la respuesta Eduardo.
Lo que sucede es que este problema solo pasa con los pics de la serie16f188XX.
Con el resto de pics va bien y no hay problema en alojar en el WW las direcciones de igual forma a la indicada en la figura de mi post anterior.
De todas formas sigo sin entender lo que me explicas en la ultima respuesta. Por ejemplo dices que si la posición es la 0x73 debo poner 0x03. La pregunta seria ¿Y por que no 0x53 o 0x23?
Tampoco entiendo lo que me dices de colocar las variables en la RAM_SHARED. ¿Eso como se hace? En mi corta experiencia de programación es la primera vez que lo oigo, aunque en proteus si que he visto una zona de una ventana de visualización de esos valores, pero no se puede añadir nada en esa ventana dentro de la simulación.
F.
-
Gracias por la respuesta Eduardo.
Lo que sucede es que este problema solo pasa con los pics de la serie16f188XX.
Con el resto de pics va bien y no hay problema en alojar en el WW las direcciones de igual forma a la indicada en la figura de mi post anterior.
De todas formas sigo sin entender lo que me explicas en la ultima respuesta. Por ejemplo dices que si la posición es la 0x73 debo poner 0x03. La pregunta seria ¿Y por que no 0x53 o 0x23?
Tampoco entiendo lo que me dices de colocar las variables en la RAM_SHARED. ¿Eso como se hace? En mi corta experiencia de programación es la primera vez que lo oigo, aunque en proteus si que he visto una zona de una ventana de visualización de esos valores, pero no se puede añadir nada en esa ventana dentro de la simulación.
F.
Si es que no estoy mal, me parece que quiere decir que declares tus variables en la región de la memoria compartida o común, es decir que no importa en que banco estés, esa región es común, para todas.
(https://pbs.twimg.com/media/F6LQ2n5XcAAeDP9?format=jpg&name=medium)
Si proteus incrementa la dirección de las variables, posiblemente, lo haga por que necesita un espacio en la RAM para sus propias variables que serían útiles para esa depuración.
Algo similar es cuando en MPLAB depuras, tanto la RAM como la memoria de Programa incrementan un poco de tamaño, ya que se descarga un pequeño código en el microcontrolador, que envía y recibe información a través del programador/depurador para informar del estado de las variables, contador de programa, etc.
Posiblemente algo parecido sucede con proteus.
-
...
Lo que sucede es que este problema solo pasa con los pics de la serie16f188XX.
Con el resto de pics va bien y no hay problema en alojar en el WW las direcciones de igual forma a la indicada en la figura de mi post anterior.
Todo lo que te contesto es en base a problemas que ya he tenido con Proteus, el tener que buscar en que dirección me muestra una variable.
De todas formas sigo sin entender lo que me explicas en la ultima respuesta. Por ejemplo dices que si la posición es la 0x73 debo poner 0x03. La pregunta seria ¿Y por que no 0x53 o 0x23?
Tampoco entiendo lo que me dices de colocar las variables en la RAM_SHARED. ¿Eso como se hace? ...
Te muestro lo que hago porque con otros micros cambiarán los lugares.
- Para que me sirva de ejemplo, al programa prueba.asm que subiste le agregué variables a partir de la dirección 0x73
- Al iniciar paso a paso la ejecución voy a debug->PIC16
- Tienes que ingresar para ver archivos adjuntos -
- Fijate que la 1er duda es a qué memoria las habrá mandado. En este caso, en base a los valores que uno sabe que deberían tener , veo que están en RAM_SHARED y que la dirección no es 0x73... sino 0x03...
- Tienes que ingresar para ver archivos adjuntos -
- Abro la WW y en RAM_SHARED escribo el nombre de la variable en offse 0x03
- Tienes que ingresar para ver archivos adjuntos - - Tienes que ingresar para ver archivos adjuntos -
- Listo, ahora durante la ejecución la WW mostrará lo que debe.
- Tienes que ingresar para ver archivos adjuntos -
Saludos.
-
Muchas gracias Eduardo por la información.
Me ha quedado muy claro y l he probado funcionando perfectamente.
Permíteme una pregunta,:
He visto que la memoria RAM compartida es por todos los bancos de memoria y tiene una profundidad máxima de 16bytes.
Si quisiera ver mas variables que esa capacidad máxima, ¿Qué tendría que hacer? ¿Reubicar las anteriores en otras direcciones y colocar las nuevas en esas direcciones que quedaron libres?
F.
-
He visto que la memoria RAM compartida es por todos los bancos de memoria y tiene una profundidad máxima de 16bytes.
Si quisiera ver mas variables que esa capacidad máxima, ¿Qué tendría que hacer? ¿Reubicar las anteriores en otras direcciones y colocar las nuevas en esas direcciones que quedaron libres?
No sé si te entendí bien.
Las direcciones compartidas en ese micro son 16 , si necesitás ver mas las vas a tener en la ventana Memory RAM pero con otro offset.
Una variable en 0x3AC (Bank7) te va a aparecer en 0x23C.
Una variable en 0x23 la WW te la va a mostrar en 0x03 y una en 0x73 también en 0x03 !!!! --> Bagres los de Proteus porque no costaba nada aclarar que una se corresponde a la RAM y la otra a RAM_SHARED.
-
Gracias por las respuestas Eduardo, la verdad es que estoy aprendiendo cosas que desconocía de este pic y sobre todo de Proteus.
Cuando dices:
Una variable en 0x23 la WW te la va a mostrar en 0x03 y una en 0x73 también en 0x03 !!!!
Eso lo entiendo muy clarito. pero que pasaría si en mi programa tengo a la vez una variable en la dirección 0x23 y otra en la 0x73. Como las dos se representarían en la misma dirección de memoria compartida ¿Cómo crees que seria la representación de los valores de ambas variables a la vez?
Por otra parte en:
Las direcciones compartidas en ese micro son 16 , si necesitás ver mas las vas a tener en la ventana Memory RAM pero con otro offset.
Una variable en 0x3AC (Bank7) te va a aparecer en 0x23C.
Entiendo mirando el datasheet que las direcciones compartidas sean 16, pero lo del valor que indicas "con otro offset". ¿De donde sale el ese valor de 0x23C? ¿En que parte del datasheet puedo verlo? por que me supongo que si tengo dos variables una en 0x3AC y otra en 0x3AD las vería en 0x23C y 0z23D. Eso por estar contiguas, ¿Pero si no son contiguas como 0x3AC y 0x403 también serian representadas en 0x3AC y 0x3AD?
Fermin
-
...
Eso lo entiendo muy clarito. pero que pasaría si en mi programa tengo a la vez una variable en la dirección 0x23 y otra en la 0x73. Como las dos se representarían en la misma dirección de memoria compartida ¿Cómo crees que seria la representación de los valores de ambas variables a la vez?
Lo que es igual es la dirección que te aparece en la WW, que obviamente confunde porque no se sabe donde está. Es cuando agregás el ítem que se diferencia entre dirección de RAM y RAM_SHARED.
Entiendo mirando el datasheet que las direcciones compartidas sean 16, pero lo del valor que indicas "con otro offset". ¿De donde sale el ese valor de 0x23C? ¿En que parte del datasheet puedo verlo? por que me supongo que si tengo dos variables una en 0x3AC y otra en 0x3AD las vería en 0x23C y 0z23D. Eso por estar contiguas, ¿Pero si no son contiguas como 0x3AC y 0x403 también serian representadas en 0x3AC y 0x3AD?
Cada banco tiene 96 bytes de ram. 80 de usos generales que te aparecen contiguos en la ventana Memory RAM cuando en realidad no lo están.
De acuerdo al banco es el offset que vas a tener, la dirección 0x29 (bank0) la mapeará en 0x09 , la 0xA9 (bank1) en 0x59 , la 0x129 (bank2) en 0xA9 ....
En las ventanas de memoria el listado debería estar agrupado por bancos, no lo está y resulta confuso.
Esta ensalada con la memoria y variables es algo viejo en Proteus donde evidentemente cero interés en corregirlo.
Pero también están los bugs, donde con suerte los corrigen después de varias versiones. Así por ejemplo el Attiny10 es imposible de simular desde que salió (se ejecuta sin errores pero no hace nada y ni se tomaron la molestia de escribirle un "no simulator model"
A este micro nunca lo había simulado, no solo son los mismos problemas de siempre sino que también me encuentro con bugs.
En este ejemplo:
#include <xc.h>
#define ND 0x40
uint8_t datos[ND] = {17,18,19,20,21,22,23,24,25,26,27,28,29}; // Para verificar donde lo escribe
void main(void){
for(uint8_t k=0 ; k<ND ; k++)
datos[k] = k ;
while(1);
}
Si la longitud de datos[] es menor que 0x50 (80bytes, entra en un banco) , todo bien. Pero si ocupa mas de un banco... --> No da error, pero hace cualquier cosa, tanto si se compila con XC8 como con CCS.
Como en los dos casos el comportamiento es diferente, no sabés como repartir las culpas :(
-
¡¡¡ Vaya pavada!!!
Así es muy difícil enterarse donde están las cosas y por supuesto el hacer una buena simulación.
F.