donde regresa despues de un Sleep??

[Cryn]

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????

[Lorenzo]

Hola, retorna a la siguiente instrucción que ve después de Sleep.
Gracias y saludos.

[BrunoF]

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.

[Cryn]

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

[BrunoF]

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.

[Cryn]

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

[BrunoF]

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.

[maunix]

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

[BrunoF]

Tenes razon maunix.
Pero...¿no se graban instrucciones ADDLW  0xFF(opcode: 0x3FF) en todas las posiciones restantes que no se utilizan?
Saludos.

[Lorenzo]

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.

[maunix]

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.

Código: ASM

1. org     0x0000
2. _BOOT:
3.         goto    _INICIO
4.  
5.         org     0x0040
6. _INICIO:
7.         nop
8.         nop
9.         nop
10.         movlw   0x04
11.         call    _NADA
12.         call    _NADA
13.         call    _NADA
14.         call    _NADA
15.         goto    _CONTINUA
16.  
17.  
18.         ORG     0x0090
19. _NADA:
20.         movlw   0x05
21.         return
22.  
23.  
24.         ORG     0x0066
25. _CONTINUA:
26.         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

[BrunoF]

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.
Saludos.

[maunix]

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.
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