TODOPIC
Microcontroladores PIC => Almacén del Assembler => Mensaje iniciado por: Nab15 en 25 de Mayo de 2011, 16:46:58
-
Hola... hace un tiempo para aca me empezo intersar el lenguaje ensamblador... y buscando encontre la maravillosa funcion de la memoria eprom...pero estuve haciendo unas practicas con estoo pero no me a podido funcionar.. en varios sitios e encontrado codigos diferentes pero no encuentro el que me funcione... agradeceria ue me ayudaran con esto xD
__CONFIG _CP_OFF & _WDT_OFF & _PWRTE_ON & _XT_OSC
LIST P=16F84A
INCLUDE <P16F84A.INC>
BcF STATUS, RP0 ; Bank 1
MOVLW 0x00
MOVWF EEADR ; Escribe la dirección en EEADR
MOVlw .9
MOVWF EEDATA
BsF STATUS,5
BSF EECON1, WREN ; Enable Write
MOVLW 55h ;
MOVWF EECON2 ; Write 55h
MOVLW h'AA' ;
MOVWF EECON2 ; Write AAh
BSF EECON1,WR ; Set WR bit
BCF EECON1,WREN ; Permiso de escritura desactivado
BCF STATUS,5 ; Selecciona el banco 0
end
-
En el mismo datasheet se muestra ejemplo de código que debe ser utilizado... Podrías revisarlo ;-)
Saludos!
-
e seguido todo del datasheet pero no logro q funcione.... este codigo q postee es guiado del data sheet... y en el mplab el dato .7 no es guardado en la direccion 00h ..
Gracias...
-
Este es el codigo que yo uso para el PIC 16f628a que quizas sea el mismo:
WriteEEPROM
BSF STATUS, RP0 ;Bank 1
BSF EECON1, WREN ;Enable write
BCF INTCON, GIE ;Disable INTs.
MOVLW 55h ;
MOVWF EECON2 ;Write 55h
MOVLW 0xAA ;
MOVWF EECON2 ;Write AAh
BSF EECON1,WR ;Set WR bit
;begin write
BSF INTCON, GIE ;Enable INTs
RETURN
Esta es una rutina de escritura que usa la anterior para escribir un dato:
;Rutina para escribir un dato en la memoria EEPROM
;El dato y la direccion se deben definir en el banco 1
;Una vez cargado dir y dato se llama a la rutina escribirDato
;
escribirDato
bsf STATUS, RP0 ;Bank 1
movf dir,w
movwf EEADR;cargo direccion a escribir
movf dato,w
movwf EEDATA; cargo dato a escribir
bcf STATUS, RP0 ; Bank 0
call WriteEEPROM
call RETARDO4MS
return
-
Noooooo :cry: :cry: :cry: no me funcionaaa u.u el EEDATA keda con 255... y trato de guardar el .9... u.u GRACIAS x responder...
(http://img51.imageshack.us/img51/3128/dibujoepq.png)
-
Podrías probarlo en hardware real, luego para saber si se ha grabado leer el microcontrolador con un programador ;-) Puede ser solo problema de simulación.
Saludos!
-
Podrías probarlo en hardware real, luego para saber si se ha grabado leer el microcontrolador con un programador ;-) Puede ser solo problema de simulación.
Saludos!
El MPSIM por suerte resuelve bien el tema de grabación en la eeprom y con esos pics en específico sobre todo (lo probé personalmente). Debe haber algun tema en el código o tal vez el usuario no está esperando el tiempo suficiente.
Nab15, ese es todo tu código? porque no te veo esperando a que la escritura finalice y tu código si termina allí, no hará mas que seguir andando...
El mpsim no solo te simula la grabación, también el tiempo que demora en grabarse (más o menos tampoco pretendas un timing super preciso pero le hace bastante caso a los 4mseg )
-
Pero en la rutina de soymoe agrega los 4ms, podrías esperar el doble en todo caso, como para comprobar ese detalle.
Saludos!
-
Pero en la rutina de soymoe agrega los 4ms, podrías esperar el doble en todo caso, como para comprobar ese detalle.
Saludos!
Una cosa es el código de syomoe y otra es lo que hizo Nab15 a quien no le anda :mrgreen:
Pero si no veo mal en el código que se ve en la imagen, hay
bsf EECON1, WR
;begin write
BSF INTCON,GIE ;enable INTs
movwf PORTB
end
y al llegar al encendido de la interrupcion global pretende que ya este grabada la eeprom , por eso le pregunto si esto es todo su codigo...
-
Pero en la rutina de soymoe agrega los 4ms, podrías esperar el doble en todo caso, como para comprobar ese detalle.
Saludos!
Una cosa es el código de syomoe y otra es lo que hizo Nab15 a quien no le anda :mrgreen:
:D Tenes razón, pobre syomoe se esfuerza al gas, se podría decir :mrgreen:
-
:D Tenes razón, pobre syomoe se esfuerza al gas, se podría decir :mrgreen:
Demosle un voto de confianza a Nab15, tal vez es novato y como muchos de nosotros cuando empezamos, eran mas las ganas de codificar y de que ande que de pensar en lo que hacíamos jiji
-
:D Tenes razón, pobre syomoe se esfuerza al gas, se podría decir :mrgreen:
Demosle un voto de confianza a Nab15, tal vez es novato y como muchos de nosotros cuando empezamos, eran mas las ganas de codificar y de que ande que de pensar en lo que hacíamos jiji
Yo ya no programo mas en asm pero el codigo me funcionaba.
-
Los procedimientos presentados en el archivo adjunto corresponden con ligeras modificaciones a los que utilizo en una línea de contadores digitales que comercializo. Esto significa que es código de producción real y que funciona al 100%.
El procedimiento de respaldo está optimizado de manera que verifica cada registro de tal forma que si la información ya almacenada es igual a la nueva entonces el registro no se reescribe. Con eso se alarga algo la vida de la eeprom.
La manera como se presentan los procedimientos es que al actuar PA<0> se realiza la recuperación de los datos en la eeprom copiándolos a la ram. Cuando es PA<1> la actuada se realiza el respaldo transfiriéndo la ram a la eeprom.
En mi caso utilizo la misma señal para ambos procedimientos. La señal que me hace esto posible es un monitor del voltaje alterno de la alimentación al contador.
Cuando está funcionando el equipo, al apagarlo el monitor indica eso y una entrada en el pic lo registra. Es como una interrupción aunque yo la utilizo como polling (disculpen el anglicismo). Al haberse registrado el apagado se apaga el display para ahorro de energía y se realiza el respaldo de los datos del contador. Como el procedimiento es rápido y la carga en la fuente CD es suficiente no hay problema. Tengo tiempo de sobra.
Cuando el equipo se prende en cuanto el monitor indica que la alimentación está ok se realiza la recuperación de los datos del contador y después se procede a la operación del programa principal.
Para mis clientes y para mí salvar esta información es muy importante dado que estos equipos se usan en conteo de piezas en bandas transportadoras y en cortadores a longitud. El desperdicio por pérdida de la cuenta o el que se entregue más material que el comprado por un cliente puede ser importante.
Algo que se me ha hecho interesante es que los primeros contadores de este tipo ya están llegando a los 15 años y aún no se ha requerido cambiar ningún PIC. Esto lo digo porque como mínimo es una vez diaria que se realiza el encendido y apagado de los equipos y no creo que en 15 años no hallan habido fallas eléctricas. Como dije, se me hace interesante y curioso. Voy a tratar de investigar a este respecto.
Por favor échenle un vistazo al archivo. Traté de documentarlo lo mejor posible pero si surgieran dudas postéenlas.
Sólo como dato curioso dejo el link a una foto del display de uno de mis modelos de contadores. Tal vez le de ideas a alguien.
http://www.imageshack.com/i/f5e5kpj
Un saludo.
-
Saquemos una cuenta:
Si haces un apagado-encendido por dia, son 365 o mas por año.
Pongamos que en 2,5 años haces 1.000 operaciones de apagado - encendido.
Cada 10 años son 4.000 operaciones de este tipo.
Resultado:
Tu PIC va a dejar de ser util dentro de unos 250 años, je..je ! :D :D :D ((:-)) ((:-))
-
Amigo MGLSOFT, tal vez más de 250.
Platicando con dos de mis clientes siempre antes de apagar las máquinas tienen por norma resetear los contadores poniéndolos a cero. Entonces la mayoría de las veces al apagar los contadores resultará que el valor en la eeprom es cero y el nuevo también por lo que no reescribe nada. El tener que restablecer a cero los contadores está en la lista de operaciones que tienen que realizar para detener los procesos.
Un saludo.