TODOPIC
Microcontroladores PIC => - Niple - => Mensaje iniciado por: narigon en 06 de Julio de 2012, 01:40:54
-
Hola a la comunidad, tal vez se me esta pasando algo por alto. tengo un problema al usar la memoria interna eeprom del pic en la version 5.5 que no la tenia en la 5.2, resulta que cuando arranca el programa la eeprom se carga con el valor inicial de la declaracion, esto es que si grabo un valor en el programa por ejemplo algun valor entrado por teclado etc. etc cuando lo apago y lo prendo vuelve a cargar el valor inicial que solo deberia cargarlo en el primer encendido teoricamente. la version 5.2 no carga ningun valor inicial, es decir guarga los valores cargados dentro del programa. saludos a todos.
-
Hola Narigon
Me da la impresión de que no guardas en EEPROM, lo mejor seria que adjuntaras el proyecto y encantado le meteré un vistazo.
au cacau
-
Hola a todos, Narigon, Juanfra y los que leen. Debes estar metiendo un valor al inicio del programa en la eeprom, y cada vez que reinicia se carga ese valor. Yo declaro los registros en la eeprom y los inicializo, los leo y cargo en otros que serán los que trabaje, y grabo nuevos valores en una función o rutina cuando lo necesito, así no carga el programa un valor fijo al iniciar. En este proyecto lo hice, pero no se si lo veas, esta en 5.6.2. pero podes simularlo y ver lo que hace. Un abrazo. Santiago
-
El link: http://www.todopic.com.ar/foros/index.php?topic=37755.0
-
Ante todo gracias por las prontas respuestas a Juanfra y santiago. Les adjunto unas capturas de imagenes una para la version 5.2 que anda perfecto (simulado en proteus) y otra en la 5.5 la cual me obliga a poner el valor inicial para avanzar y no anda, es decir carga el valor de inicio lo cual para una eeprom es un sinsentido ya que se usa para resguardar variables cuando se apaga entre otras cosas.
Un abrazo y nuevamente gracias.
-
Ok, te paso lo que hice en imágenes. Podes ver que declaro los espacios eeprom e inicializo, Cuando arranca el programa carga el valor que contiene la eeprom en registros de la ram, si quiero cambiar el valor de los registros en la eeprom lo hago en una rutina (y cargo el valor nuevo en los que uso en la ram). Esto funciona bien.
-
Santiago, lo probe asi y no me anda cada vez que arranca toma los valores iniciales. debe ser un bug de la version que tengo yo. vos tenes la 5.6? voy a tener que volver a usar la vieja 5.2
gracias nuevamente.
-
Si pones el .npl lo compilo y veo que pasa con esta versión. Por lo que decís que hiciste, como te lo mostré, me parece que no guarda el nuevo valor en la eeprom, sino el antiguo ya no podría ser leído, estaría sobre escrito. Otra cosa que se me ocurre es que sea que en la simulación, si es así, te carga el valor por defecto cada vez que lo simulas, está correcto, probalo reiniciando. Cada vez que apagas la simulación y la ejecutas de nuevo es como si recién quemaras el chip, y la eeprom tiene valor inicial. Lo mejor sería que pongas lo hecho para verlo. Un abrazo
-
buenas tarde mira no se como utilizar este medio pero tengo un problema con una eeprom no se como hacer una interrupcion para desplegar un fallo en la lcd trabajo con configuracion i2c y el pic 16f877 con entrada de el boton de falla en el rc5 te agradeceria tu colaboracion
-
Hola eduardopopayan, un gusto. Lamentablemente soy neófito en esto y no he trabajado con i2c, por lo que no creo poder ayudarte. Sin embargo se me ocurre que: si existe un cambio en algún registro,indicando cuando el fallo se produce, con el puedes disparar la visualización previo haber inhabilitado las interrupciones desde el general, con ello tenes una interrupción por fallo. Me pondré a ver i2c y si veo algo te comento, por ahora es solo una idea. Un abrazo.
Nota: FerTaca ha vuelto al ruedo y seguro el te encaminará por la solución.
-
Santiago aca te adjunto los archivos tipo ejemplo para que los veas con las dos versiones de niple. fijate de compilar el de 5.5 con tu version, debido a la simpleza del ejemplo vas a tener que pausar y ver los registros en el debug.
Cargale los .hex de la version 5.2 y fijate que los registros se mantienen y cada vez que lo prendes y como incrementa 1 cada vez que vez se guarda con un valor mas alto,
En cambio la version 5.5 si bien deberia incementar y guardar, siempre arranca en cero y cuando llega al nop se queda siempre con el mismo valor.
Si podes mandame poneme el .hex que resulte de este ejemplo con tu version asi si anda ya lo reclamo niplesoft que me emparchen esta version.
Saludos a todos, gracias
-
Hola narigón, como estás? Le hice una mirada a los ejemplos, imagino que lo que visualizas es tecla_1 y 2, no me queda claro si en algún momento toma el valor de algún pulsador, creo que no por ser todo salida, lo que veo es: a- inicializás la eeprom, b- copiá los valores a tecla 1 y 2, c- sumás 11 y 22 al valor de tecla_1 y 2 y los guardás en 2 temporales que no entiendo porqué tienen en común a dd, d- copiás los valores de los temporales a la eepron y de ellas a tecla_1 y 2, queda ahí sin más por hacer. Si resetéas el programa debería darte el ultimo valor de la eeprom copiado a tecla, pero si no reseteas sigue mostrando valor de la suma de tecla + 11 o 22, según sea, una sola vez. Lo compilé en 5.6 v2 y te paso el hex y asm, simulalo. Hoy difícil que pueda hacerlo yo,. Un abrazo y comentame que pasó.
-
Nota: FerTaca ha vuelto al ruedo y seguro el te encaminará por la solución.
Un poqito de calma muchachos mañana empezaré de lleno, espero que despues de estos meses no se me haya quedado la memoria (E2prom) en blanco. :D
f.
-
Santiago, es tal cual lo interpretaste no hay intercambio de datos en la simulacion de hecho no le pongo ningun accesorio en proteus , solo el pic. la suma tienen en comun una variable porque es para rellenar la suma pero como para probar nunca desborda no me importa el segundo byte. ......A todo esto el .hex que me mandaste no funciona, es decir no guarda los valores cuando le pongo stop y luego play me vuelve a crgar el valor inicial. La UNICA forma de que ande es editando en el .asm la ultima parte donde pone los datos luego del rotulo "datos en la memoria eeprom" los borro a todos, lo compilo y asi si me anda. Asi que es cuestion de hablar con Canito a ver que opina de esto.
fijate por curiosidad. gracias a todos los que colaboraron y de paso prueben sus versiones nunca saben cuando lo pueden necesitar.
-
Hola narigon, buenas noches. Si pones stop a la simulacion y luego la inicias de nuevo te pone el valor por defecto, el que pusiste al hacer el programa. Si haces reset sin parar la simulación deberias ver al principio el valor guardado de la suma anterior, reset via ra5 MCLR, no parar e iniciar pues ahí carga el hex igual a la primera vez, no se si me entiendes. Un abrazo
-
Santiago, el proteus guarda en el mismo archivo los valores de las EEprom aunque lo apagues con stop o aunque cierres el programa y lo abras al mes siguiente, la forma de volver al pic recien encendido por primera vez es haciendo click en "reset persistent model data" dentro del debug. proba editando el asm como te dije y lo vas a ver.
Yo lo descubri de casualidad porque hice un aparatito que personalizabas con el nombre en el display y lo guardaba en una eeprom, y sorpresa me lo lleve al archivo en un pendrive al laburo y cuando lo simule alla estaba con los valores que yo le habia cargado simulando con botoncitos en el proteus
con el mclr hace lo que decis pero se ve que no es lo mismo que apagarlo
Te mando un abrazo.
-
Hola narigón, y gracias por el dato, ya probaré lo que me decís. En las simulaciones que he hecho con eeprom jamás me guardó el valor cuando apagué la simulación, ha no puede de hecho modificar el .hex y es este el que carga cuando le das star, el programa se ejecuta a nivel de ram y se pierde al stop según sé, pero tu dato me deja desconcertado. Para que eso ocurra debe guardar el valor en algún archivo del Proteus. También puede que sean versiones distintas, uso una 7.7, no se vos. Un abrazo
-
Perdon por la intromision.
No se si lo teneis ya solucionado. Tampoco se si proteus guarda los valores en la eeprom como decis. Puedo probarlo si adjuntais el fichero de proteus y de Niple con lo ultimo que tengais.
De momento si puedo deciros algo, al parecer estais trabajando partiendo de una version como la 5.2. Para que Niple trabvaje correctamnete con las memorias EEprom no solo sirve el que al abrir el proyecto hagais la actualixacion automatica que te indica Niple al inicio.
la forma de trabajar a partir de la version 5.5 es que hay que indicarle exactamnete que dispositivo se va a utilizar y hay que cambiar/actulìlar algunos bloques de los accesos a la memoria EEprom.
Para ello en el explorador de la derecha, al lado de "diagramas", pulsar la tecla y seleccionar "dispositivos". A continuacion en Nuevo dispositivo teneis que seleccionar, cualquiera de las 2 opciones de trabajo con la EEprom y establecer los valores de las lineas a utilizar, asi como el tipo de memoria EEprom.
A partir de ahi debeis continuar con el programa.
F.
-
Fer: la eeprom que debe guardar el valor es la del pic, por eso no se declara una externa, al menos así entendí yo. No he podido hacer como dice narigon, que Proteus guarde el valor una vez cambiado y tras detener la simulación, a mi entender no es así pues cada vez que comienza la simulación carga el .hex tal y como lo compilamos, sin guardar un cambio de la simulación.
-
Bueno pues las neuronas fallaron en lo de la eeprom interna. Un punto para ti, es lo que tiene separado de los queridos pic's.
Respecto a Proteus creo y opino que deberia de ser como dices no lo guarda en la eeprom interna. Lo que no tengo muy laro es si cada vez que paras la simulacion y la arrancas de nuevo lo hace con lor valores que tenias en la eeprom. Tampoco se exactamente si cad vez que arrancas la simulacion carga el hexadecimal, reo que si, por eso no guarda dichos valores.
Seuro que hay quien sepa mas de ese fenomeno de Proteus.
F.
-
Fermin, es muy facil comprobarlo, mas arriba subi dos ejemplos para santiago, carga el que esta hecho con la version 5.2 fijate que tambien esta el .npl asi te fijas lo que tiene que hacer y podras comprobar que guarda los valores de las eeprom aunque cierres el archivo y lo vuelvas a abrir porque con cada simulacion modifica el .dsn, fijate que en el ejemplo lee una variable de la eeprom le suma 1 y la vuelve a escribir, con el debug fijate que el mapa de eeprom siempre se va modificando con cada arranque y lo hace persistir aunque lo abras en otra compu etc. por esto me di cuenta que las versiones sucecivas como la 5.5 y la 5.6 no lo hacen, es decir cargan la eeprom con el valor inicial cosa que no tiene sentido ya que es lo mismo que escribirlo en la memoria de programa, se supone que la eeprom es una eeprom.
seria una buena inquietud para plantearle a Jorge Cano.
Santiago, la version de proteus que tengo es la 7.6.
Saludos.
-
Puedo probarlo si adjuntais el fichero de proteus y de Niple con lo ultimo que tengais.
De momento si puedo deciros algo, al parecer estais trabajando partiendo de una version como la 5.2. Para que Niple trabaje correctamnete con las memorias EEprom NO solo sirve el que al abrir el proyecto hagais la actualizacion automatica que te indica Niple al inicio.
La forma de trabajar a partir de la version 5.5 es que hay que indicarle exactamnete que dispositivo se va a utilizar y hay que cambiar/actulìlar algunos bloques de los accesos a la memoria EEprom.
Para ello en el explorador de la derecha, al lado de "diagramas", pulsar la tecla y seleccionar "dispositivos". A continuacion en Nuevo dispositivo teneis que seleccionar, cualquiera de las 2 opciones de trabajo con la EEprom y establecer los valores de las lineas a utilizar, asi como el tipo de memoria EEprom.
A partir de ahi debeis continuar con el programa.
F.
Me reitero en lo de la cita, para probarlo neesitaba que adjuntaseis el fichero, al menos de Proteus y junto con el de Niple puedo verificarlo.
Tener en cuenta lo expuexto en la cita y subrayado.
F.
-
Fermin, te lo adjunto pero es solo el chip sin periferia.
Saludos.
-
Descargado y a probar......................
-
Fermin, te lo adjunto pero es solo el chip sin periferia.
Saludos.
Mira lo estoy venga a probar y bajo mi corto entender :(, y que no dudo que asi sea, por mas que pruebo, mi opinion es que es cosa de proteus :(.
he cogido el programa de la version 5.2 que has adjuntado y el fichero del proteus. Los cargo en mi pc y abro proteus tengo la version 7.7SP2 y Niple 5.6.2 Empiezo a simularlo, decirte que solo modifique el fichero de Niple sacando lo del bucle NOP y de forma que incremente el calor del valor de tecla 1. Ejecuto en run paso a paso el programa y observo que proteus incrementa el valor lo piedes ver marcado en rojo en la figura adjunta en la zona de memoria EEprom, pero por alguna extraña razon ese valor no lo graba "Proteus, fijate en ell valor de la derecha, siempre está en "..........". para cada valor debe de corresponder un caracter distinto a la derecha, ver recuadros en amarillo de la figura dentro del "PIC CPU Memory DATA".
Por este motivo creo que te está pasando ese efecto.
Soo me queda ver el tiempo que está puesto para realizar el tiempo de grabacion en la EEprom no sea que esté puesto muy corto, pero no creo.
Por otra parte desconozco si proteus guarda los valores de las eeprom simulados en el fichero de DSN. lo que si es cierto que siempre que arrancas el run se produce una compilacion del programa.
Seguiré informando
F.
-
Hola de nuevo.
Acabo de probar que si ejecutas el programa por un tiempo mas largo, si aparecen valores que no aparecian antes puedes verlos en la figura adjunta.
pero siempre que paras el programa y lo vuelves a ejecutar no queda grabado nada.
-
he revisado el asm, generado por NIPLE, el proceso de grabacion en la eeprom y es el correcto.
Adjunto el codigo generado.
grabar_eeprom
;escribir el dato en la eeprom
bsf status,rp0 ;cambiar a banco 3
bsf status,rp1
bcf eecon1,eepgd
bsf eecon1,wren
movlw 0x55
movwf eecon2
movlw 0xaa
movwf eecon2
bsf eecon1,wr
esperar_fin_escritura
btfsc eecon1,wr
goto esperar_fin_escritura
bcf eecon1,eeif
bcf eecon1,wren
bcf status,rp0 ;cambiar a banco 0
bcf status,rp1
return
F.
-
Hola a todos, buenas noches. También estuve debaugeando el desarrollo del programa simulado y no pude hacer que Proteus guarde el valor una vez parada la simulación. Si lo hace o no no lo sé, tampoco me preocupa, hasta ahora, pues si "resetéo el pic" y se guardó el cambio de valor está haciendo lo que deseo, en lo físico significará que apagando el circuito y encendiéndolo el seteo se hará con el valor que se introdujo a la eeprom en ultima instancia. Si alguien guarda el valor es Proteus, en archivo propio, no modifica el .hex o el .asm para nada. A mi pobre entender no es un bug de Niple como creías, ni cosas de la versión. Un abrazo a todos
-
Hola a todos, buenas noches. También estuve debaugeando el desarrollo del programa simulado y no pude hacer que Proteus guarde el valor una vez parada la simulación. Si lo hace o no no lo sé, tampoco me preocupa, hasta ahora, pues si "resetéo el pic" y se guardó el cambio de valor está haciendo lo que deseo, en lo físico significará que apagando el circuito y encendiéndolo el seteo se hará con el valor que se introdujo a la eeprom en ultima instancia. Si alguien guarda el valor es Proteus, en archivo propio, no modifica el .hex o el .asm para nada. A mi pobre entender no es un bug de Niple como creías, ni cosas de la versión. Un abrazo a todos
esto mismo es lo que he intentado explicar en mis ultimos post.
Lo importante es que la forma de grabacion es la correcta y Niple lo hace bien en "el mundo real". De hecho hay algun tema por ahí de un programa tipo de cerradura electronica con clave, que funciona perfectamente guardandola en la eeprom.
F.
-
Ok gente, voy a sacar la protoboard a ver como anda, lo que me enfurece es no poderlo emular como yo quiero. o como lo hacia antes.
Santiago probate esto que te mando porque el proteus te tiene que andar, instale la version 7.9 y tambien me anda.
pregunta aparte, trataron de editar el asm antes de compilarlo sacandole las lineas de los valores de eeprom del final? porque asi si me funciona.
Muchas gracias por el esfuerzo, saludos.
-
Hola a todos nuevamente. Ok narigon, comprobado que Proteus guarda el nuevo valor en un archivo propio. También comprobé que no toca el .hex, después de hacer que guardara un valor distinto los comparé a uno sin simular y al que sí y no cambio nada. Desconozco si algún dia me será de utilidad esto que me has mostrado, y que te agradezco, pero por el momento sigo tratando de aprender a usar el Niple que no es poco, me encuentro liado con la necesidad de operar registros de 24 bits, no usar, dividir específicamente, y no esta soportado. Deberé rever estas operaciones con binarios nuevamente, :D :D., en fin, años de inactividad hacen telarañas en la azotea :5] :5]. Un abrazo
-
probado en el hardware, ....anda bien.
Saludos.
-
probado en el hardware, ....anda bien.
Saludos.
¿el programa de la version 5.5, solo la 5.2 o ambos ?
-
Ambos andan bien en el hard. Es un detalle para comentarle a la gente de proteus que cuando la eeprom arranca con un valor inicial lo toma siempre, cuando pague el proteus lo voy a reclamar :D
-
Entonces, or lo visto Niple está correcto.
Eso es lo que tienen los simuladores soft.
No hay nada mejor como probar en la realidad. ;-)
F.