Alguien a usado el modulo CTMU de los PIC18F ??

[rivale]

si, el timer1 tiene interrupcion, puedes usar esa.

en cada lectura despues de leer el valor pones a cero el timer y asi comienza tu timer para que leas correctamente los valores, si se desborda en el inter usas la interrupcion del t1 para contar lo acumulado y sumarlo con lo que leas al momento de la captura

[Picuino]

Si tiene interrupción y te puede servir para aumentar el contador de desbordamientos.

Uno de los problemas que puedes encontrar es, por ejemplo:
   Llega un flanco cuando el Timer1 vale 65530.
   Se captura el valor y se activa la interrupción del CCP1
   Saltas a la rutina de interrupción.
   A estas alturas el Timer1 vale 00002 y se ha producido desbordameinto.
   En la rutina de interrupción primero se comprueba el flag de interrupción del Timer1 y se actualiza el valor del contador de desbordamientos.
   A continuación se comprueba el flag de interrupción del CCP y se toma el dato de la captura y del contador de desbordamientos (que vale uno más de lo que debería)

Cuando quieras hacer cálculos, resulta que no son correctos.
Si cambias el orden del tratamiento de las interrupciones no lo solucionas, se puede dar otro error contando uno menos de lo que se debería.

Saludos.

[jukinch]

Hola MGLSOFT:
           No lo he implementado nunca al tema del cronómetro pero recuerdo este hilo que te va a ser de ayuda. Cito a Reiniertl.
               un abrazo.
                    Jukinch

Y además debes utilizar el TIMER en modo comparador con autorecarga. Es algo que TIMER1 puede hacer perfectamente. Así nunca tienes que volver a poner el valor de recarga en el TIMER por software.

Siendo el TIMER1 de 16 bits con dos registros de 8 bits (asumo que usas un PIC de 8 bits) no puedes actualizar la llamada set_timer1(65480); dentro de la ISR porque siempre  se consume tiempo en atender una ISR, lo peor es que nunca el tiempo es el mismo. Aunque el mecanismo de atención del uC siempre lleve el mismo tiempo, las interrupciones pueden estar temporalmente deshabilitadas, puede que el uC esté atendiendo otra interrupción cuando llega la solicitud de TIMER1, etc.

Lo mejor es que utilices el hardware con las configuraciones adecuadas, ello evitará tener que utilizar la recarga por software del temporizador, muy aconsejable si lo que intentas diseñar e implementar es un cronómetro.

Luego te queda aplicar las recomendaciones de jukinch

Un saludo
Reinier

[Picuino]

En este caso lo mejor creo que es no recargar nada en el Timer.

Dejas que el timer se desborde y siga contando desde cero. Otro contador de 32 bits puede contar los desbordamientos.

En total tendrás 16bits del timer + 32 bits del contador de desbordamiento = 48 bits.

Si cuentas pulsos a 16Mhz, podrás contar tiempos hasta 203 días.

Para sumar y restar números de 48 bits puedes utilizar parte del código que he utilizado para mi frecuencímetro:

Firmware frecuencímetro YAF v0.8


El código del frecuencímetro todavía no está completo, pero ya funciona lo que está y funcionan las rutinas matemáticas de 48 bits.


Edito: Necesitas los ficheros que comienzan con math48 Eliminando el include al fichero "rs232.h"  (no debería estar ahí, ya lo he quitado para la próxima versión)

Saludos.

[MGLSOFT]

Pensaba, despues de hacer algunas experiencias, hacer que el timer desborde, y en la interrupcion sumarle 65535 al registro de tiempo (de 32 bits), esto me permitiria almacenar muchos desbordamientos, que en mi caso me permitirian medir tiempos de hasta 150 milisegundos con buena precision.
Eso me alcanza bien.
Matematicamente, podria resolverlo mejor si en vez de guardar los 65535 guardo el valor en microsegundos equivalente, que debera estar en float, eso me dejaria mas rango al final, y con solo convertir el valor de la ultima captura y sumarlo tendria el tiempo de pulsos, no?

Seria algo asi:

| desborde 1  | desborde 2  | desborde 3  | desborde 4  | desborde 5  | desborde N  | intCCP y captura |
| acc tiempo1 | acc tiempo2 | acc tiempo3 | acc tiempo4 | acc tiempo5 | acc tiempoN | acc tiempo captura |

[Picuino]

No entiendo bien qué quieres hacer.
Si quieres medir en microsegundos (y perder resolución) debes dividir el reloj de entrada al CCP para que llegue 1 pulso por microsegundo. Por ejemplo con reloj de 16Mhz divide por 16.

Te recomiendo que mantengas las cuentas con enteros siempre que puedas. En ocasiones son más precisos.

Si no quieres demasiado rango puedes sumar los desbordamientos en un entero de 16 bits cada desbordamiento del timer de 16 bits. Los dos juntos dan un entero largo de 32bits y no necesitas rutinas especiales.
Con pulsos cada microsegundo, podrás contar hasta 4000 segundos (una hora y pico)

Saludos.

[MGLSOFT]

Creo que le voy agarrando la mano.
Partiendo de los ejemplos de Manolo, esto es lo que llevo hasta el momento:

Las constantes que uso:

Código: C

1. float const uSxTick = 0.0625;       // Microsegundos por Tick de TMR1 a 64 Mhz
2. float const uSxDesborde = 65535.0 * uSxTick;// Microsegundos a sumar en cada desborde
3. float const mSxDesborde = 65535.0 * uSxTick / 1000.0;// Milisegundos a sumar en cada desborde

La interrupcion de Timer 1 acumula los milisegundos por desborde.

Código: C

1. #INT_TIMER1    // Timer 1 overflow
2. void handle_int_Timer1()
3.    {
4.      acc_useg_aux += mSxDesborde;                      
5.    }

Cuando llega un flanco, acumula segun donde se haya predeterminado, en mi caso quiero el ancho del pulso en ON y el ancho del pulso total (Ton + Toff).
Eso lo hago en la captura, se que me querran matar porque tardo en hacer cuentas en la interrupcion, pero aun no se como hacerlo bien...

Código: C

1. #int_ccp2
2. void handle_ccp2_int()
3. {
4.   if(flagToggleFlanco==0)
5.      {      // He recibido Flanco de Subida          
6.        t1=get_timer1();            // Guardo en t1 el valor de TMR1 al Flanco de Subida  
7.        mseg_S_On = acc_useg_aux +( t1 * uSxTick / 1000.0);  // Tiempo de señal ON  
8.        setup_ccp2(CCP_CAPTURE_FE); // Configuro para capturar siguiente flanco de Bajada                                
9.        flagToggleFlanco=1;         // Indico que el siguiente flanco será de Bajada  
10.      }
11.   else
12.      {                      // He recibido Flanco de Bajada
13.        t2=get_timer1();            // Guardo en t2 el valor de TMR1 al Flanco de Bajada
14.        mseg_ep = acc_useg_aux +( t2 * uSxTick / 1000.0);  // Tiempo de pulso completo
15.        setup_ccp2(CCP_CAPTURE_RE); // Configuro para capturar siguiente flanco de subida      
16.        flagToggleFlanco=0;         // Indico que el siguiente flanco será de Subida
17.        set_timer1(0);              // Reinicio TMR1  
18.        acc_useg_aux = 0;           // y contador de tiempos.
19.        if(flagHayDatos==0)
20.           {        // Si los datos anteriores han sido procesados ...
21.             flagHayDatos=1;           // Indico que ya hay nuevos datos de flancos para calcular
22.           }
23.       }                                  
24. }

Luego mando por serie los datos...

Código: C

1. if(flagHayTransmitir==1)
2.         { // Si hay algo pendiente de transmitir ...
3.  
4.           printf("| TPulso: %6.3f miliseg.| TEPulsos: %6.3f miliseg.| \r\n",mseg_S_On, mseg_ep);
5.           flagHayTransmitir=0;    // Indico que ya he transmitido lo pendiente.
6.  
7.            FLASH;                       // Reproduzco la entrada mediante un LEd en E0;
8.         }

Si me lo revisan y comentan me haran gran favor...

[rivale]

Exacto MGLsoft, a eso me referia, en cada interrupcion solo incrementas los segundos correspondientes al desbordamiento del t1.

creo que estas midiendo tu tiempo alrevez, cuando "flagToggleFlanco==0" estarias leyendo el tiempo del pulso en bajo, no el tiempo en alto, ya que entro a esa condicion en flanco de subida

[MGLSOFT]

En realidad tengo una entrada que funciona invertida, por eso lo di vuelta, pero eso va a ser diferente despues...
Buena vista para ver un detalle pequeño !!

[Picuino]

Creo que tendrías más precisión si lees CCPR1H y CCPR1L.



Es mucho más rápido:

Código: C

1. #define TOSC  (1.0/16000000)
2.  
3. long int acc_tmr1, t1;
4.  
5.  
6. #INT_TIMER1    // Timer 1 overflow
7. void handle_int_Timer1()
8. {
9.     acc_tmr1 += 65536;                      
10. }
11.  
12.  
13. #int_ccp2
14. void handle_ccp2_int()
15. {
16.     if (flagToggleFlanco==0)
17.     {      // He recibido Flanco de Subida          
18.         t1 = get_timer1();            // Guardo en t1 el valor de TMR1 al Flanco de Subida  
19.         ticks_On = acc_tmr1_aux + t1;  // Tiempo de señal ON
20.  
21.         //
22.         //
23.         // AQUÍ TIENES QUE ASEGURARTE DE QUE SI LEES  t1 = 10,   SE HA ACTUALIZADO YA  acc_tmr1_aux
24.         //
25.         //
26.  
27.  
28.  
29.         setup_ccp2(CCP_CAPTURE_FE); // Configuro para capturar siguiente flanco de Bajada                                
30.         flagToggleFlanco=1;         // Indico que el siguiente flanco será de Bajada  
31.     }
32.          
33. ...
34.  
35.  
36.     if(flagHayTransmitir==1)
37.     {     // Si hay algo pendiente de transmitir ...
38.         printf("| TPulso: %6.3f miliseg.| TEPulsos: %6.3f miliseg.| \r\n", ticks_On * (TOSC * 1000), ticks_ep * (TOSC * 1000));
39.         flagHayTransmitir=0;    // Indico que ya he transmitido lo pendiente.
40.  
41.         FLASH;                       // Reproduzco la entrada mediante un LEd en E0;
42.     }

Todo queda en dos multiplicaciones en coma flotante (mucho más rápidas que las divisiones).
Vas a tener problemas si utilizas las mismas variables para capturar eventos y para transmitir. Tienes que utilizar diferentes variables y copiarlas deshabilitando interrupciones.

Saludos.

[MGLSOFT]

Creo que tendrías más precisión si lees CCPR1H y CCPR1L.

Te refieres a que en estos registros se carga el valor del timer en el momento de la interrupcion de CCP, no es asi ??

Si, es posible, tampoco me molesta tener corridos unos microsegundos mi cuenta de tiempo, ya que sera mas o menos siempre el mismo corrimiento.
Igual es mas exacto hacerlo como dices.

Respecto a porque no guardo el valor del timer directamente, es porque de esta forma en 32 bits (una Float en CCS) puedo guardar mucho mas tiempo acumulado que si guardo y acumulo el valor entero del timer, para darte una idea un desborde del timer vale 65535 y el tiempo equivalente que guardo son 4,095 milisegundos.
Es decir, si lo hago con enteros es mejor y mas preciso, pero acumulo menos tiempo, se entiende??

[Picuino]

Te refieres a que en estos registros se carga el valor del timer en el momento de la interrupcion de CCP, no es asi ??

Eso es.

Si, es posible, tampoco me molesta tener corridos unos microsegundos mi cuenta de tiempo, ya que sera mas o menos siempre el mismo corrimiento.

Tienes un  error de 1 ciclo (porque si la interrupción llega en medio de una instrucción de 2 ciclos, tarda un ciclo más en saltar)
Eso teniendo en cuenta que otras interrupciones no te afecten más.

Respecto a porque no guardo el valor del timer directamente, es porque de esta forma en 32 bits (una Float en CCS) puedo guardar mucho mas tiempo acumulado que si guardo y acumulo el valor entero del timer, para darte una idea un desborde del timer vale 65535 y el tiempo equivalente que guardo son 4,095 milisegundos.
Es decir, si lo hago con enteros es mejor y mas preciso, pero acumulo menos tiempo, se entiende??

No lo termino de entender. Con un float tienes una resolución total de 24 bits (el resto es el exponente)
Como yo te decía tienes una resolución total de 32 bits (16 del timer + otros 16 del contador de desbordamiento)

Es verdad que con el float no tienes límite de tiempo, pero para tiempos mayores de un segundo, comienzas a tener error (aunque es verdad que es muy pequeño).

Con entero de 32bits tienes un límite de 256 segundos y precisión total.

Saludos.

[MGLSOFT]

Voy a hacerlo como dices, no me retes mas...

[Picuino]

El frecuencímetro que estoy haciendo utiliza enteros de 48 bits. Puede contar pulsos de 80Mhz de forma seguida durante 40 dias.
La aritmética de coma flotante la he tenido que rehacer para que trabaje con 40 bits de mantisa y conseguir así suficiente precisión.
Aunque sea un reto y me divierta, me ha llevado mucho tiempo. Sobre todo corregir pequeños errores y decidir qué tenía que hacer cada rutina.

Si lo que haces es un trabajo y por ahora funciona, también puedes olvidarte de retos y seguir la máxima:  "Si funciona, no lo toques"

Los técnicos tenemos la manía de buscar soluciones tecnicas elegantes, potentes, caras y que el cliente no desea en absoluto.


Saludos.

[MGLSOFT]

Toma en broma mis comentarios !!
Me gusta hacer chistes para que no sea demasiado formal el foro !!
Agradezco desde el alma toda la ayuda que me dieron, y por supuesto voy a depurar bien y comentar muy bien mi codigo, ya que dentro de un año ni yo voy a saber que hice aqui o que quise hacer...

Siempre en el arranque voy en forma desprolija, hago comentarios de rutinas completas pero no las saco del codigo, por las dudas aun las necesite, recien cuando le encuentro la vuelta comienzo a revisar bien y comentar todo.

Para los que comienzan:
Esto que escribi arriba es lo que NO HAY que hacer, especialmente cuando arrancan a programar, acostumbren a comentar hasta las instrucciones de reset del Watchdog...