PIC18 TIMER0

[superprp]

Buenas, toy usando un PIC de la gama de los 18, y estos tienen en el timer0 la posibilidad de configurar el timer con 16 bits en lugar de 8 bits. Usando este modo, lo configuro para que desborde cada 0.5 segundos, pero me tarda mas de 50 segundos!!, con el máximo de cuenta desbordaría cada 6 segundos o cosa así.. por lo que viendo en el debuger del MPLAB he visto que el valor de TIMER0H no se inmuta, mientras TIMER0L se mueve de forma muy extraña, ya que de vez en cuando se pone el solo a un valor (no determinado por mi). ¿sabeis a que puede ser debido?

[maunix]

Buenas, toy usando un PIC de la gama de los 18, y estos tienen en el timer0 la posibilidad de configurar el timer con 16 bits en lugar de 8 bits. Usando este modo, lo configuro para que desborde cada 0.5 segundos, pero me tarda mas de 50 segundos!!, con el máximo de cuenta desbordaría cada 6 segundos o cosa así..

Para saber en mas detalle, habría que revisar tu código. 

por lo que viendo en el debuger del MPLAB he visto que el valor de TIMER0H no se inmuta, mientras TIMER0L se mueve de forma muy extraña, ya que de vez en cuando se pone el solo a un valor (no determinado por mi). ¿sabeis a que puede ser debido?

El simulador funciona como el micro.  El TMR0H será actualizado cuando escribas en el TMR0L o cuando lo leas, si te fijas el datasheet el funcionamiento del PIC en modo 16bits es ese.  Es para evitar que las transacciones sean por partes (primero el resgistro alto y luego el bajo).  De esa forma, en una sola operación puedes leer/grabar el registro

[superprp]

pero, internamente, ¿el se incrementa? en el stopwatch no se ve que aumente el registro timer0, y además, en la simulación al igual que en el montaje de prueba me tarda 50 segundos en detectar el flag de desbordamiento, es algo muy raro porque no puede contar tanto el timer, aquí pongo el código:
tengo definida una variable sensor y otra contador

        movlw 0x97
   movwf T0CON
   movlw 0xF0
   movwf TMR0H
   movlw 0xBE
   movwf TMR0L
inicio
        btfss PORTB, 0         
   goto x0
   btfss PORTB, 1
   goto _1s
   goto on
x0
   btfsc PORTB, 1
   goto _0.5s
   goto off
fin
        goto inicio




off
   bcf LATC, 6
   bcf LATC, 7
   bcf INTCON, 2         ;reseteo el buffer del TMR0
   goto fin


on
   bsf LATC, 6
   bsf LATC, 7
   bcf INTCON, 2         ;reseteo el buffer del TMR0
   goto fin


_0.5s
   btfss INTCON, 2              ;compruebo si se ha desbordado el TMR0
   goto fin
   btfsc sensor, 0               ;cambia de estado la variable sensor (apagado=0, encendido=1)
   goto ponera0
   goto ponera1
ponera0
   bcf sensor, 0
   goto sigue
ponera1
   bsf sensor, 0
sigue
   btfsc sensor, 0             ;actuo sobre las salidas dependiendo de la variable sensor
   goto off
   goto on


_1s
   btfss INTCON, 2
   goto fin
   btfsc contador, 0
   goto cont0
   goto cont1
cont0
   incf contador
   goto fin
cont1
   decf contador
   goto _0.5s


QUIERO QUE DEPENDIENDO DE RBO,RB1, ME SAQUE EN RC6 Y RC7 O UN 1,1, UN 0,0, O QUE OSCILE DURANTE 0.5SEG O 1SEG

[maunix]

pero, internamente, ¿el se incrementa? en el stopwatch no se ve que aumente el registro timer0, y además, en la simulación al igual que en el montaje de prueba me tarda 50 segundos en detectar el flag de desbordamiento, es algo muy raro porque no puede contar tanto el timer, aquí pongo el código:
tengo definida una variable sensor y otra contador

Esperate , vamos por partes.  El TRM0H internamente se incrementa , siempre y cuando lo tengas en modo 16 bits.
¿El stopwatch? Eso no tiene nada que ver, eso marca el tiempo transcurrido de la simulación pero allí no podras ver el estado el timer0 ni de ningún otro registro.

Creo que tu código es algo incompleto, es decir, si quieres que lo revise y/o simule, te pido que subas el proyecto.  Ando con poco tiempo y ponerme a armar todo para probar eso, sería muy tedioso.  ¿Con qué pic trabajas?

Algo que te ayudará es usar los marcos para código fuente, y es lo siguiente

Pones:

[ code = asm ]

... aquí va tu código

[ /code ]

[superprp]

en el stopwatch es donde veo que a los 50 segundos es cuando se activa el flag de desbordamiento del timer, uso el 18f2331,  donde veo el valor del timer0 es con el watch, lo simulo con el mplab sim, ¿que ves incompleto? así a primera vista ves porque puede ser que tarde tantísimo en entrar en el bucle? ¿alguna cosa que veas mal a primera vista que me pueda ayudar a solucionarlo? muchas gracias.

PD: no te puedo poner todo el código porque es extralargo, esta es la parte en la que uso el timer0, espero que puedas ayudarme aunque sea un poquito, gracias de todas formas

[maunix]

superprp lo que veo es que la lógica del timer viene también supeditada a cómo estén unos pines de entrada.

¿no vendrá por allí el tema?

[superprp]

a que te refieres? los tengo configurados unos como entrada y otros como salida, eso lo tengo correcto, hay algo mas de los pines que deba revisar? alguna configuración de algun puerto?

[maunix]

a que te refieres? los tengo configurados unos como entrada y otros como salida, eso lo tengo correcto, hay algo mas de los pines que deba revisar? alguna configuración de algun puerto?

Me refiero a que si los pines de entrada (RB0 y RB1) no están en el estado que deben estar la cuenta sigue y sigue (el timer no se detiene) y por eso tal vez estes demorando los 5 segundos que mencionas.

[superprp]

vamos a ver, yo configuro el timer0 para 16bits, y el solo una vez está inicializado, TMR0 register se incrementa cada ciclo de instrucción, hasta ahí bien, se va incrementando poco a poco el TMR0L que es la parte baja de TMR0, pero cuando llega a FF y le toca el paso a TMR0H éste no se incrementa, es decir, TMR0 pasa de por ejemplo:

TMR0 EEFF

EN EL SIGUIENTE CICLO DE INSTRUCCIÓN A:

TMR0 EE00

y debería ser:

TMR0 EF00

lo que viene a ser que TMR0H no se incrementa y TMR0L si, y ya no se como hacerlo, porque así nunca me llega a desbordar TMR0IF, ¿alguna idea de porque puede ser?

[PerriPic]

LLevo varios dias con el mismo problema pero con el timer1 y tp sé como solucionarlo.Espero q alguna alma caritativa nos eche una mano...

[maunix]

LLevo varios dias con el mismo problema pero con el timer1 y tp sé como solucionarlo.Espero q alguna alma caritativa nos eche una mano...

En tu código probá leer el registro TMR1L y verás como el TMR1H se actualiza.

[superprp]

pero si el timer0 va solo aumentando cuando realizo la lectura de tmr0L para que tmr0H se actualice???? cuando tmr0L llegue a FF??

[maunix]

pero si el timer0 va solo aumentando cuando realizo la lectura de tmr0L para que tmr0H se actualice???? cuando tmr0L llegue a FF??

Recién me mencionaste el timer1  y ahora el timer 0.

El registro H del timer se actualiza , pero no lo vas a ver actualizado hasta no leer el TMR0L porque en modo 16bits se leen de una sola vez, en un solo paso y el contenido del TMRxH interno se copia al TMRxH que vos lees con una operación de lectura sobre el TMR0L

En cuanto al momento de la lectura, lo podes leer cuando quieras.

[PerriPic]

A mi ahora me va perfectamente, asi q muxas gracias x tu consejo.

Ahora viene otro problema, yo kiero utilizar el timer1 para q me cuente 1min y mientras q cuenta no hago nada, asi q kiero poner el micro a dormir y q despierte con cada interrupcion hasta llegar al minuto.¿como hago eso?xq si pongo el readtimer1 despues del sleep no va a actualizar el timer1 mientras duerme.mi codigo es este:(solo la parte de iniciar el timer y mandar a dormir)

   OpenTimer1(TIMER_INT_ON &
            T1_16BIT_RW &
            T1_SOURCE_INT &
            T1_PS_1_2 &
            T1_OSC1EN_OFF &
            T1_SYNC_EXT_OFF);
   
   RCONbits.IPEN = 0;                  //Deshabilito la prioridad en las interrupciones
   INTCONbits.PEIE=1;                  //Habilito todas las interrupciones
   INTCONbits.GIE=1;                  //Habilito todas las interrupciones


//   Comando_LCD(CLEAR);                  //Borro LCD
   
/******************************************************************************
PASAMOS LOS DATOS DE LA PROGRAMACION
*******************************************************************************/

   while (TIEMPO<TIEMPO_MAX)
   {
//      Comando_LCD(DOFF);                  //Borro LCD
      ReadTimer1 ();
      Sleep();

   }

Si kito el sleep() va perfectamente...

[maunix]

Qué pic estás usando ? Te lo pregunto para saber qué eventos hacen despertar a ese modelo de pic de un sleep.

Hasta ahora no he usado el sleep en mis aplicaciones ya que hasta ahora las mismas deben esta siempre disponibles (y no hay problemas de consumo ni mucho menos, de hecho el pic consume menos del 1% de lo que consume todo lo demás).

De todas formas podemos ir viendo juntos cómo encontarle la vuelta a tu problema.

Saludos