TODOPIC
Microcontroladores PIC => Almacén del Assembler => Mensaje iniciado por: Cryn en 07 de Agosto de 2006, 18:34:24
-
Hola saludos a todos tengo una pregunta algo confusa, beuno debo saberlo para corregir un error de un programa creo que pueda ser por eso, hago un sleep, y despiertop el pic con RB0/INT, hace la rutina de interrupcion y al finalizar con RETFIE en la rutina de interrupcion a donde vuelve?? al Sleep o al inicio de programa principal????
-
Hola, retorna a la siguiente instrucción que ve después de Sleep.
Gracias y saludos.
-
Hola. Es una muy buena pregunta la que has hecho.
Te dire lo que me parece a mi hasta donde dan mis conocimientos.
Al producirce una instruccion SLEEP. El microcontrolador Pre-cachea las proximas 2 instrucciones.
Ej:
SLEEP
nop
nop
movf PORTB,W
......
Por lo tanto, los 2 nop serán almacenados temporalmente dentro del micro antes de entrar a dormir.
Cuando produces la interrupcion por RB0, el pic despierta, por lo que sale del SLEEP, y probablemente ejecute las 2 lineas de codigo que tenia guardadas(los 2 nop) y luego atienda a la interrupcion.
Antes de ingresar a la interrupcion, guarda la posicion de la linea movf PORTB,W en el STACK(PILA) e ingresa a la interrupcion(0x004). Una vez ejecutado el comando RETFIE(volver y habilitar interrupciones globales) deberia volver a la linea movf PORTB,W y seguir ejecutando el codigo normalmente.
Es una buena pregunta, y puede que esté equivocado. Veremos que dicen los demas usuarios.
Saludos.
-
ahora me salio otra duda, de este sleep, por ejemplo:
ciclo
sleep
goto ciclo ; hace dormir al pic, es eso correcto, o:
ciclo1
bsf portb,1
sleep ; y aca el pic se queda durmiendo hasta esperar ser despertado ya sea por interrupcion o reseteo
bcf portb,1 ;y esta linea no se ejecutaria
goto ciclo1
hay algo malo, me explican que hice, osea si esta bien los comentarios que coloque, gracias
-
Fijate que cuando lo mandas a dormir, te conviene que las dos siguientes instrucciones al Sleep sean dos lineas insignificantes(como las instrucciones "nop"), despues sí, hacelo hacer lo que quieras.
bcf portb,1 ;y esta linea no se ejecutaria
Esa linea se ejecutaría luego de que el PIC salga del SLEEP, pero quedaría lista para ser ejecutada ni bien el PIC salga del sueño.
Saludos.
-
gracias, te entendi, pero creo tu no me entendiste bien, que pasa una vez ejecutado el sleep, se queda ahí dormido y no ejecuta ninguna instrucción mas hasta ser despertado o sigue ejecutando pero ya no tienen efecto?? digamos:
inicio
codigo
....
....
....
sleep ; lo mando a dormir y que pasa, ya no se ejecuta mas?? y se queda trucado ahi, hasta recibir una interrupcion
nop
nop
bsf porta,1 ; o ejecuta las instruciones pero no tienen efecto
clrf portb ; y sgue ejecutando
end ; encuentra el end y termino el programa ya ni con interrupcion se lo despierta solo con reset??
o para mandarlo a dormir es necesario el ciclo que escribi antes:
inicio
codigo
...
ciclo
sleep
goto ciclo
end
-
Hola Cryn. En cuanto se ejecuta una instruccion SLEEP el PC(Program Counter) del PIC se detiene, juntos con muchos otros de sus módulos, por lo tanto, la ejecución se detiene hasta que ocurra una interrupción, un RESET,o un BODEN(si esta activado),etc.
Por lo tanto, para que duerma siempre y solo se levante para ejecutar el codigo ante una interrupcion, el segundo algoritmo es el que te sirve.
El primero solo lo hace dormir una vez, y luego de despertarse y volver, el END finaliza la ejecucion del programa.
Saludos.
-
Amigos el END no termina nada, no hace que el pic deje de ejecutar.
El END se usa para indicar al ensamblador que termine de ensamblar.
De hecho podemos poner cualquier cosa debajo del end que no se ensamblará.
El PIC continuará ejecutando lo que siga en la memoria de programa, si es algo no válido se ejecutarán nops.
Todo depende del programa que uno haya hecho. Si por ejemplo uno tiene cosas hechas en la pagina 1 y en la pagina 0, y el end, está en un código que hemos hecho enl a página 0, entonces el pic seguirá ejecutando todo lo que siga después. El program counter se incrementará indefectiblemente o cambiará si en la memoria de programa a la que apunta el program counter hay alguna instrucción válida que lo haga cambiar (goto, call, movwf PCL, movwf PCLATH).
Espero se me haya entendido.
Saludos
-
Tenes razon maunix.
Pero...¿no se graban instrucciones ADDLW 0xFF(opcode: 0x3FF) en todas las posiciones restantes que no se utilizan?
Saludos.
-
Hola, después de la orden Sleep, el pic duerme, todo los temporizadores duermen, se para el oscilador, es decir, no se ejecutan ordenes, excepto el perro guardián watchdog, el cual al resetearse lo hace justamente a la orden siguiente que va después de la orden Sleep. Si se produce un reset externo se ejecuta al principio del programa. Si lo despierta una interrupción, que es lo normal, se ejecuta la rutina de interrupción, y cuando retorna de ésta, se ejecuta la siguiente orden que va después del Sleep. Por lo menos así lo tengo y lo explica el manual que tengo.
Gracias y saludos.
-
Tenes razon maunix.
Pero...¿no se graban instrucciones ADDLW 0xFF(opcode: 0x3FF) en todas las posiciones restantes que no se utilizan?
Saludos.
Si, en realidad el pic como cualquier memoria se 'inicializa' con todos unos. '1'. Al ser de 14 bits el pic16, queda como xx111111 11111111 = 0x3FFF
Ahora bien, imaginemos que puede pasar en 2 casos:
1er Caso: El pic queda grabado ordenadamente (toda sus primeras datos con el software y luego todas 3FFF)
Ahora bien, si ponemos un END al final del código en el mejor de los casos el pic seguirá ejecutando instrucciones hasta el final donde el Program Counter rebase y se haga 0, lo que hará un efecto 'similar' a resetear el PIC. Lo cual no es lo que se pretende, en este caso.
Es por eso que lo mejor es siempre un loop infinito, tal cual como en C es obligación hacer un while(1) {} , bueno en ensamblador se hace un loop en algún lado para que el control del Program Counter no quede al azar.
2do Caso: El código no está hecho en orden, lo cual es perfectamente normal y técnicamente correcto.
org 0x0000
_BOOT:
goto _INICIO
org 0x0040
_INICIO:
nop
nop
nop
movlw 0x04
call _NADA
call _NADA
call _NADA
call _NADA
goto _CONTINUA
ORG 0x0090
_NADA:
movlw 0x05
return
ORG 0x0066
_CONTINUA:
movlw 0x05
El ejemplo es bastante grosero por cierto pero es solo a los fines de ejemplificar y explicar mi punto. De todas formas, es común que cuando alguien incluye código con "include" pueda darse este y otros casos.
El código ensamblador quedará asi:
_BOOT ( en 0x0000)
_INICIO ( en 0x0040)
...
código
...
0x3FFF
0x3FFF
0x3FFF
0x3FFF
...
_CONTINUA (en 0x0066)
...
código
...
0x3FFF
0x3FFF
0x3FFF
0x3FFF
...
_NADA (en 0x0090)
movlw 0x05
return
El programa no terminará en _CONTINUA sino que irá ejecutando los sucesivos 0x3FFF hasta que llegue a _NADA y ejecutará el return, y como no hay nada en el stack el pic cargará el PC con 0x0000 nuevamente haciendo el efecto de reset.
Y esto en el mejor de los casos!! Puede hasta ser peligroso para el hardware si el pic comienza a ejecutar por ejemplo una rutina de inicialización de una eeprom externa! borrando la misma. También pudiera caer en alguna parte donde encenderemos un motor que no debiamos encender! dañando cosas muy costosas.
Y como eso, todo lo que la imaginación pueda darnos.
Como vemos, el dejar sin control a un firmware puede llegar a producir cosas nefastas realmente. :?
Saludos
-
jeje perfecto Mauricio.
En todo estamos de acuerdo. Cometi un error basico y grave de decir que al poner un END, y el pic ejecutar esa linea(que en realidad no se ensambla) el programa se detenia. Se me ha escapado, pero creo que ya todo ha quedado claro.
Nadie es perfecto...y yo no estoy excento a la regla. :mrgreen:
Saludos.
-
jeje perfecto Mauricio.
En todo estamos de acuerdo. Cometi un error basico y grave de decir que al poner un END, y el pic ejecutar esa linea(que en realidad no se ensambla) el programa se detenia. Se me ha escapado, pero creo que ya todo ha quedado claro.
Nadie es perfecto...y yo no estoy excento a la regla. :mrgreen:
Saludos.
No hay problema, todos nos equivocamos y nadie aquí duda de tus conocimientos en la materia ;)
Es que tener tannnta información en la cabeza a veces es complicado. A pesar de trabajar seguido con los pics recurro a los datasheets con mucha frecuencia.
Son tanntos los detalles a recordar!!! Me pasa constantemente :) :)
Gracias que existe el simulador! sino, ya hubiera incendiado medio millar de pics :)