tiempo de ejecucion codigo C en MPLAB

[AngelGris]

En la pantalla del StopWatch hay un botón de "zero" que tendrías que presionarlo justo despues de ejecutar la instrucción "set_timer0(0)" Porque es apartir de allí que empieza a contar nuevamente el Timer0.

Se me ocurre que podés sacar la instrucción "CycleTime= 0" del ciclo "while" y de esa manera lo enviado por la instrucción "PrintF" anterior al "for" sólo va a ser cero la primera vez, luego ya va a ir teniendo el valor que tome "CycleTime".

Habría que ver como está implementado el "PrintF". Quizá anula las interrupciones y por tal motivo el TMR0 nunca va a ir incrementando el valor de ContadorGlobal....

¿Como configuraste el puerto para la transmisión? Así hago las pruebas en casa a ver que resultado obtengo.

De paso te cuento que en otra prueba que hice saqué el "for" y dejé el "delay_ms(30)" y los valores fueron

StopWatch 30.358800(ms) y variable CycleTime 0.0300032012 (30.0032012ms)

[marito]

El tema de zerar la cuenta, lo hice en la primera instrucción dentro del while, colocando un breakpoint y cerando cada vez que se detiene. Haciendo la medición desde el Set_Timer0, la diferencia es pequeña (adjunto imagen)

Para recibir el valor de tiempo de ciclo en la PC, agregue un printf despues del bucle for:

while (1)
   {
      CycleTime = 0;
      ContadorGlobal = 0;
      set_timer0(0);
      //delay_ms(30);
      printf(" %f ", cycleTime);
      for (cuenta=400000; cuenta != 0; cuenta--);

      CycleTime=(float)(0.0000512*get_timer0()+0.0131072*contadorglobal);
      printf(" %f ", cycleTime);      //Valor de tiempo de ciclo enviado a la PC
   }


Cuando mido en el simulador, dejo el ultimo printf como comentario.

La configuración de del puerto que uso, para el PIC16F876A, es la siguiente:

#use rs232(baud=9600, xmit=PIN_C6, rcv=PIN_C7) //establezco el protocolo de comunicación RS232 a través del MAX232, usando el PIN_A1 para transmitir al PC y el PIN_A2 para recibir desde el pc

Como te comente anteriormente, las mediciones son las mismas, hasta el momento en el que agrego el printf para comunicación.

[AngelGris]

Te cuento...

Agregué esta línea a mi programa para configurar el USART del 16f628A "#use rs232(baud=9600, xmit=PIN_B2, rcv=PIN_B1)"

Y agregué dos instrucciones "PrintF", una después de la instrucción de delay (y comenté el "for") y una después de el cálculo del valor de CycleTime.... te adjunto imágen de la simulación

También lo simulé con el primer "PrintF" antes de la instrucción de delay y los valores de tiempo son los mismos.

Noté que en tu captura aparecía un mensaje relativo al conversor AD, ¿No habrá algún problema con ello?

[marito]

Los valores que te dan iguales están ambos en el simulador? En mplab?
Porque los valores que mido en mplab me dan iguales, la diferencia la observo con el valor enviado desde el pic, cuando este ejecuta el programa y envia el valor a la PC.
Estoy investigando el tema de los warnings que me aparecen en el simulador.

[AngelGris]

Ahora entiendo mejor y si, los valores que me dan similares es simulando en el MPLAB.

¿Porque no enviás otro dato que sea float y conocido y lo comparás con lo que te llega a la PC? Quizá es como vos dijiste y hay algún problema en el "PrintF"

[marito]

Intente enviando una constante float. Llega bien.

Lo que observo, es que el valor del ciclo se incrementa en el simulador, por cada printf que agrego, con respecto al valor calculado en el pic.

Por ejemplo, con un printf--> el pic envia a la PC 23ms y en el simulador mido 46ms aprox.


P.D. Según los datos que tengo de los warnings, son solo alarmas que no deberían afectar.

[AngelGris]

Pude simular la transmisión desde el MPLAB. En la pestaña Debuggerngs -> Settings; vas a la pestaña "UART1 IO" pones "Enable UART1 IO", en la opción de "Output" elegís "window"

Y de esa manera simula la transmisión y te aparecen en dicha ventana los datos que envía el PIC. Te adjunto la captura.

Fijate que en la ventana output aparece un dato todo en 0 (corresponde al primer PrintF, cuanlo CycleTime vale 0), y el segundo dato enviado se corresponde perfectamente con el valor de CycleTime.  También se puede observar una clarísima diferencia con el valor del StopWatch. Esto es debido a que el StopWatch también está tomando el tiempo que tarda en ejecutarse el segundo "printf" mientras que el dato enviado por el segundo "PrintF" está siendo tomado con anterioridad a la ejecución de esa instrucción.

Yo creo que es ahí donde le estabamos pifiando.

[marito]

Hice la prueba con la configuración que me pasaste en la siguiente rutina:

                CycleTime = 0;
      ContadorGlobal = 0;
      set_timer0(0);
      Printf(" %f ", CycleTime);
      delay_ms(30);
      //for (cuenta=400000; cuenta != 0; cuenta--);

      CycleTime=(float)(0.0000512*get_timer0()+0.0131072*contadorglobal);
      Printf(" %f ", CycleTime);

Lamentablemente, el valor que mido con el StopWatch (muy similar al que genera en la ventana Sim Uart) difiere del que calcula el PIC y envia al PC. En el simulador mido 71 ms y en el pic 40 ms.

Creo que habría que hacer los cálculos sobre el código en assembler, para tener el valor verdadero. Eso va a facilitar encontrar en que punto está el problema

Adjunto capturas del simulador y el terminal recibiendo los valores. Por lo que parece, tenemos un problema con los calculos que hace el Simulador o tengo un problema con el PIC.

[AngelGris]

Yo tuve que poner así la línea para que me muestre como a vos el número enviado; printf(" %1.6f ", cycleTime);  si ponía
printf(" %f ", cycleTime); -sin el 1.6- el tiempo de printF variaba... ¿Será que con el agregado del 1.6 (para darle el formato de 1 entero y 6 decimales) se fuerza a la funcioón a que siempre envie la misma cantidad de bytes y es allí donde puede habar un fallo?

[marito]

Entonces, como conclusión, el StopWatch, se puede usar para calcular tiempos siempre que no se estén usando comandos de comunicación. Sino, hay que trabajar con el Timer del PIC.
Voy a ver de hacer los cálculos en assembler, y publico si encuentro algo interesante.
Esperemos que si alguien ha experimentado igual que nosotros, también pueda sumar para dar claridad al tema.
Saludos Angel! Gracias por el aguante!!!

[AngelGris]

Cambié mi respuesta anterior, porque si el USART trabaja en modo independiente no debería influir en los tiempos....

[marito]

Repasando un poco lo que vinimos haciendo, veo que en la gráfica Programa2, mediste un tiempo de 46ms.
Lo que calcula el PIC es 40 ms.
Lo que no estaría tan alejado, pero con el mismo programa, yo mido 71ms.

Tenes el programa que usaste en esa simulación?

[AngelGris]

Este es el programa, y ahora lo simulé sobre un 16f876a y obtuve los mismos valores.

Yo estoy usando el MPLAB 8.10, y si no me equivoco el CCS 4.104

Código: [Seleccionar]

/*
Programa para evaluar las diferencias de medición entre el
StopWatch y el TMR0
*/

#include <16f876a.h>
#use delay(clock=20000000)
#use rs232(baud=2400, xmit=PIN_C6, rcv=PIN_C7)

unsigned int ContadorGlobal;

#int_timer0
void timer0interrupt()
{
ContadorGlobal++;
clear_interrupt(int_timer0);
}


void main()
{
unsigned long  cuenta;
float CycleTime = 0;
setup_timer_0(RTCC_INTERNAL|RTCC_DIV_256);
enable_interrupts(GLOBAL);
enable_interrupts(INT_TIMER0);


while (1)
{
CycleTime = 0;
ContadorGlobal = 0;
set_timer0(0);
delay_ms(30);
printf(" %f ", cycleTime);
//for (cuenta=400000; cuenta != 0; cuenta--);
CycleTime=(float)(0.0000512*get_timer0()+0.0131072*contadorglobal);
printf(" %f ", cycleTime);
}
}


[marito]

Con el programa que me pasaste, mido 63ms colocando un breakpoint en el segundo(ultimo) printf. Tengo el MPLAB v8.36 CCS 3.4.

En la PC desde el PIC recibo 38ms.

Tendria que ver el tema de la versión del CCS...

[AngelGris]

En este hilo http://www.todopic.com.ar/foros/index.php?topic=19143.0 hablan de un comm virtual así que lo voy a bajar a ver que carajo obtengo