Autor Tema: Timers (Leído 6659 veces)

allisap · « **en:** Miércoles 10 de Enero de 2007, 22:28 »

saludos....
estoy haciendo una aplicacion que pide datos a un pic por el usb....
todo funciona perfecto, pero encontre que el envio y recepcion de datos los realiza mi aplicacion cada 50 ms y necesito que sea mas rapido (1 mseg seria genal

), buscando en la red encontre que es windows el que se tarda esos 50ms y dicen que una opción seria usando los timers de multimedia que tienen un mayor resolucion pero no entiendo muy bien como utilizarlos, alguien sabe como se usan o alguna idea de como bajar el tiempo de 50ms

JuanK

puedes utilizar los timers de directX, con el SDK viene la clase de DXUtil la cual incorpora la fucionalidad de timers.

allisap

en serio?, ya lo busque y no lo encuentro, tengo el sdk 9

JuanK

Bueno no es precisamente una clase que haga parte del sdk...
es una clase que utilizan en la mayoria de los ejemplos del sdk y se encuentra su fuente disponible.

Eternal Idol

Cita de: "allisap"

saludos....
estoy haciendo una aplicacion que pide datos a un pic por el usb....
todo funciona perfecto, pero encontre que el envio y recepcion de datos los realiza mi aplicacion cada 50 ms y necesito que sea mas rapido (1 mseg seria genal ), buscando en la red encontre que es windows el que se tarda esos 50ms y dicen que una opción seria usando los timers de multimedia que tienen un mayor resolucion pero no entiendo muy bien como utilizarlos, alguien sabe como se usan o alguna idea de como bajar el tiempo de 50ms

¿Se tarda 50ms en hacer que? El timer lo que va a hacer es ejecutarse cada X tiempo pero si dentro del timer tenes el mismo codigo que ejecutas ahora y ese es el que tarda 50ms ... no vas a ganar nada.

allisap

se tarda 50ms en volver a pedir un dato al usb , mi codigo no creo que se tarde 50 ms , de hecho lo unico que hace es estar pidiendole datos al usb y los ponen en pantalla ,

lo que necesito es que en cada llamada al timer pida datos al dispositvo usb ( el pic) lo mas rapido posible y el pic no creo que se tarde tanto en enviar los datos

Eternal Idol

Cita de: "allisap"

se tarda 50ms en volver a pedir un dato al usb , mi codigo no creo que se tarde 50 ms , de hecho lo unico que hace es estar pidiendole datos al usb y los ponen en pantalla ,

lo que necesito es que en cada llamada al timer pida datos al dispositvo usb ( el pic) lo mas rapido posible y el pic no creo que se tarde tanto en enviar los datos

¿Y necesitas el timer de verdad? ¿No es mas facil hacer un bucle y de necesitar esperar usar Sleep? Podes crear un hilo para que se encargue de eso ...

allisap

en realidad la primera aplicacion que hice esta en un bucle, y lo unico que hace es pide

datos al usb
imprime en pantalla

pero aun asi se tarda esos 50ms

luego hice una aplicacion que utiliza los timers normales y asi se tarda menos pero aun no es suficiente....

en cuanto a los hilos, no se muy bien como hacerlo asi, por eso buscaba los timers de multimedia que dicen tienen una mejor resolucion (creo que de 1ms o algo asi)

Eternal Idol

Cita de: "allisap"

en realidad la primera aplicacion que hice esta en un bucle, y lo unico que hace es pide

datos al usb
imprime en pantalla

pero aun asi se tarda esos 50ms

luego hice una aplicacion que utiliza los timers normales y asi se tarda menos pero aun no es suficiente....

en cuanto a los hilos, no se muy bien como hacerlo asi, por eso buscaba los timers de multimedia que dicen tienen una mejor resolucion (creo que de 1ms o algo asi)

Por lo que decis es tu codigo el que tarda, especialmente si lo hacias en un bucle, ahi no hay nada mas. Es cierto que tienen mejor resolucion pero si el problema es el tiempo que tardas en procesar esos datos tal vez tendrias que hacer un hilo con el bucle original que tenias pero dedicado solo a recibir y poner en una cola esos datos y que otros hilo (o uno solo) se dedique a procesar estos datos, asi le darias tiempo a recibir ...

Para crear un hilo usas CreateThread:
http://search.msdn.microsoft.com/search/Re...reatethread.asp

Y si queres ver lo de los timers multimedia (me parece innecesario):
http://search.msdn.microsoft.com/search/Re...edia_timers.asp

allisap

bueno este es parte de codigo

....

do{
   system("cls");
   lectura=ResultadoPIC();
   printf("lectura del adc: %4d \r\n",lectura);
   }
while( !_kbhit() );

....

como ven solo limpia pantalla y pide datos al pic, (el pic solo se tarda cerca de 1ms , ya lo medi) usando la funcion ResultadoPIC() que esta aqui

int ResultadoPIC()
{
int result = 0;
BYTE receive_buf[2];
DWORD RecvLength = 2;

ReceivePacket(receive_buf, &RecvLength);
result = receive_buf[0]+receive_buf[1]*256;

return result;
}

no creo que esto se tarde esos 50ms,

alguna idea de como acelerar el proceso?

Eternal Idol

Cita de: "allisap"

alguna idea de como acelerar el proceso?

El problema es el tiempo que tardas en procesar esos datos, limpiando la pantalla, escribiendo una nueva cadena previo formateo de la misma y comprobando que no haya niguna pulsacion de letra (eso supongo que sera redundante en tiempo en MS-DOS pero lo dudo en Windows).

¿Que pasa si sacas el cls? ¿Que pasa si no haces la comprobacion de tecla ahi?

Tendrias que hacer un hilo con el bucle original que tenias pero dedicado solo a recibir y poner en una cola esos datos y que otros hilo (o uno solo) se dedique a procesar estos datos, asi le darias tiempo a recibir.

Código: Text

 
for (;;)
{
  lectura=ResultadoPIC();
  push(lectura);
}
 
 

allisap

ya revise lo de los timers y multimedia

y la verdad no le entendi

no tendran un ejempplo de como implementarlos

Eternal Idol

¿Hiciste las pruebas que te dije? No creo que sea ninguna solucion hacer eso, el problema esta en tu codigo y no en la capacidad de ejecutarlo cada X tiempo con una mayor resolucion ... por algo no te funcione ni con un bucle.

JuanK

1-Haciendo incapie en lo mencionado por eternal idol, no te servira de nada lo del timer para agilizarlo como tu quieres.

2- lo de borrar pantalla e ir imprimiendo el resultado también es un gran problema deberias quitar eso.

3- si realmente es imprescindible mirar los resultados mi recomendación es que lo hagas al final de todo y que mientras solo mandes las variables a una pila que tu mismo implementes, y al final imprimir todo en un bucle, pero despues del bucle que llama al PIC.

4- Para agilizar el trabajo en la pila desde luego ya debes tener previamente reservado el espacio que utilizaras previendo el máximo que pueda llegar a tener o algo muy parecido a eso.

5- Declarar las variables por fuera del loop, con eso solo se declaran una vez y se reducira el numero de veces que intercambiaras areas de memoria reservando y liberando.

6- Interrelacionado con lo anterior, no usuaria la función int ResultadoPIC() y haria la implementación directamente en el código para evitar los excesivos cambios de contexto que pueden llegar a ser desgastantes debido a que los llamados se hacen X veces desde el loop.

</div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td>XCODE </td></tr><tr><td id='XCODE'>int lectura = 0;
BYTE receive_buf[2];
DWORD RecvLength = 2;

do
{
  ReceivePacket(receive_buf, &RecvLength);
  lectura=receive_buf[0]+receive_buf[1]*256;
  //Lo de la pila seria asi y reemplazaria la linea anterior y la que hacia el printf.
  //Push(receive_buf[0]+receive_buf[1]*256;);
}
while( !_kbhit() ); </td></tr></table><div class='postcolor'>

7-Finalmente, dependiendo de como devuelva los datos ReceivePacket, puede que llegues a necesitar usar un ZeroMemory aunque no creo.

xx- para que haces esto?

receive_buf[1]*256

estas seguro que eso es lo que quieres?

Eternal Idol

Cita de: "JuanK"

6- Interrelacionado con lo anterior, no usuaria la función int ResultadoPIC() y haria la implementación directamente en el código para evitar los excesivos cambios de contexto que pueden llegar a ser desgastantes debido a que los llamados se hacen X veces desde el loop.

Solo a modo de aclaracion lo que se conoce comunmente como cambio de contexto sucede cuando se pasa de un proceso a otro.

Tu solucion iria bien pero me parece que el problema es diferente, no quiere obtener una lista de valores e imprimirlos sino mantener un valor actualizado (solo) en la pantalla. Al menos es lo que entendi yo, si fuera asi es mejor hacerlo con varios hilos encargados de cada tarea, siempre tendria un delay en la parte de output pero el input del PIC siempre llegaria a completarse. Si es que necesita obtener muchos valores y despues imprimirlos es mejor hacerlo como decis, obtenerlos todos en un bucle, almacenarlos y finalmente procesarlos.

JuanK

Cita de: "Eternal Idol"

Tu solucion iria bien pero me parece que el problema es diferente, no quiere obtener una lista de valores e imprimirlos sino mantener un valor actualizado (solo) en la pantalla. Al menos es lo que entendi yo, si fuera asi es mejor hacerlo con varios hilos encargados de cada tarea, siempre tendria un delay en la parte de output pero el input del PIC siempre llegaria a completarse. Si es que necesita obtener muchos valores y despues imprimirlos es mejor hacerlo como decis, obtenerlos todos en un bucle, almacenarlos y finalmente procesarlos.

Claro, todo depende de que es lo que necesite, hacer algo como lo que le sugeriste a una persona la otra vez puede ser muy util.

carmamezo

Hola a todos!
Pues creo que la mejor solución al problema es el siguiente:
Como bien dice Eternal idol parece más un problema de threads que de temporizadores, se puede controlar el tiempo de nuestro programa (más o menos) pero no podemos controlar el tiempo que tardan en ejecutarse las rutinas de escritura en pantalla...
Parece que es un problema de ejecución en tiempo real, bueno, pues para solucionar este tipo de problemas se utiliza la ejecución en paralelo como decía el compañero antes citado pero además se debe agregar un sistema de prioridades.
Por partes, lo primero es separar el código que se encarga de realizar la lectura de datos del puerto del que se dedica a escribirlos en pantalla. Para ello deberíamos realizar dos hilos, uno principal, que se encarga de mostrar los datos en pantalla y otro que se encarga de la lectura de datos del puerto. Este último hilo debe tener la prioridad más alta del sistema operativo (en el caso de windows, la prioridad 32), este hilo ejecutará un bucle hasta que desde el hilo principal se le envie una orden de fin.
Se debe realizar un Sleep() al final del bucle para liberar la CPU y dejar que otros procesos puedan pugnar por acceder a sus recursos. Para realizar un control óptimo se debe medir el tiempo que tarda el bucle en ejecutarse mediante uso de temporizadores multimedia y luego restar este tiempo a los 50ms que se desean esperar para realizar una espera del tiempo exacto, o simplemente disparar el hilo mediante temporizadores, las funciones para manejo de temporizadores multimedia son las siguientes:
timeGetDevCaps()
timeBeginPeriod()
timeSetEvent()
timeKillEvent()
timeEndPeriod()
Si lo que queremos es medir cuánto tiempo tarda en ejecutarse nuestro código (tiempo real) podemos usar los contadores de alta resolución de windows:
QueryPerformanceCounter()
QueryPerformanceFrequency()
Estos contadores tienen una resolución de micro segundos y utilizan una resolución de 64bits.

Para la modificación de la prioridad de los hilos se usan las siguientes funciones:
SetThreadPriority()
SetThreadPriorityBoost()
SetThreadPriority() debe recibir como parámetro THREAD_PRIORITY_TIME_CRITICAL previa modificación de la prioridad del proceso padre que lo crea mediante la función SetPriorityClass() pasándole a esta última función este parámetro: REALTIME_PRIORITY_CLASS.

Mucho ojo con jugar con las prioridades de hilos y procesos, dos hilos con prioridad máxima en el SO ejecutando ambos dos bucles infinitos dejan al sistema operativo totalmente bloqueado.

El proceso sería el siguiente:
- Iniciar el programa principal, llamar a la función SetPriorityClass() y pasarle el valor REALTIME_PRIORITY_CLASS. (nuestro proceso se ejecutará con prioridad 24).
- Llamar al hilo que se encarga de leer datos del puerto USB mediante un temporizador multimedia, timeSetEvent(), o bien crear el hilo.
- Llamar a la función SetThreadPriority() y pasarle el valor THREAD_PRIORITY_TIME_CRITICAL para que nuestro hilo se ejecute con prioridad 32.
- Si se opta por crear el hilo, ejecutar un bucle infinito en su interior con un Sleep() al final (NO OLVIDAR REALIZAR UNA ESPERA ACTIVA PARA NO BLOQUEAR EL SISTEMA OPERATIVO), calculando el tiempo a esperar como 50ms menos el tiempo que ha estado ejecutándose el hilo (medido mediante los contadores de alta resolución antes citados).
- Utilizar un array de tipo FIFO circular para la comunicación con el hilo principal y posibilitar al hilo principal escribir los datos en pantalla.

Lo bueno de los hilos con alta prioridad es que acaparan la CPU en cuanto esta se libera, apenas hay retraso desde que se realiza una petición para usar la CPU y se consigue la misma.

En fin, siento el rollo, SUERTE!!!!!

un saludo.

carmamezo

Se me olvidaba..... el temporizador de máxima resolución del PC es el RDTSC que es un contador que se ejecuta dentro de la propia CPU de Intel, tiene una resolución de 64 bits y utliza los registros EDX:EAX para dejar el resultado del conteo. La instrucción ensamblador de este contador es 0F 31 en hexadecimal:

Código: Text

 
__int64 tiempo_init = 0,tiempo_fin=0;
 
__asm{
_emit 0x0F;
_emit 0x31;
MOV DWORD PTR tiempo_init, EAX;
MOV DWORD PTR tiempo_init+4, EDX;
}
 
Sleep (100);
 
__asm{
_emit 0x0F;
_emit 0x31;
MOV DWORD PTR tiempo_fin, EAX;
MOV DWORD PTR tiempo_fin+4, EDX;
}
 
//ciclos = tiempo
//microsegundos = tiempo / frecuencia CPU (en MHZ)
printf(&#34;Tiempo supuesto: 100ms&#34;);
printf(&#34;&#092;nTiempo real: %016I64ms&#34;, (tiempo_fin-tiempo_init)/1800000);
 
//SUPONIENDO QUE LA CPU TRABAJE A 1800MHZ
 
 
 

Un saludo.

Eternal Idol

Si es un problema de ejecucion en tiempo real entonces hay que usar un S.O. que lo permita y no Windows.

Eternal Idol

En cuanto al RDTSC creo que la Wikipedia explica bien las razones para no usarlo:
http://en.wikipedia.org/wiki/RDTSC

allisap

Citar

xx- para que haces esto?

receive_buf[1]*256

estas seguro que eso es lo que quieres?

esto lo hago porque en receive_buf[0] y receive_buf[1] estas los resultados de la conversion analogica digital lols cuales son de 10 bits, los 8 menos significativos estan en receive_buf[0] y los 2 mas significativos estan en receive_buf[1] (lo del 256 es para darle un desplazamiento de 8 bits)

seguire investigando lo de los hilos y vere que pasa

carmamezo

Citar

Si es un problema de ejecucion en tiempo real entonces hay que usar un S.O. que lo permita y no Windows

Supongo que cuando dices "Windows" te refieres a Windows 95/98/Millenium/NT/2000/XP/vista... Windows CE es un sistema operativo en tiempo real,

.
Pero es cierto, tienes razón, aunque no cabe duda que Windows (no CE) proporciona una serie de funciones que permiten cierto control en tiempo real de los programas, tiene una API bastante potente en ese aspecto....

Un saludo.

Eternal Idol

Cita de: "carmamezo"

Supongo que cuando dices "Windows" te refieres a Windows 95/98/Millenium/NT/2000/XP/vista... Windows CE es un sistema operativo en tiempo real, .

Pero es cierto, tienes razón, aunque no cabe duda que Windows (no CE) proporciona una serie de funciones que permiten cierto control en tiempo real de los programas, tiene una API bastante potente en ese aspecto....

No, yo hablaba de Windows 3.11 ... control superficial e incompleto ya que no se pueden manejar las prioridades de las interrupciones y por lo tanto es imposible asegurar que un codigo sera ejecutado o no en el tiempo requerido ...

JuanK

2 cosas.

1-

Citar

esto lo hago porque en receive_buf[0] y receive_buf[1] estas los resultados de la conversion analogica digital lols cuales son de 10 bits, los 8 menos significativos estan en receive_buf[0] y los 2 mas significativos estan en receive_buf[1] (lo del 256 es para darle un desplazamiento de 8 bits)

Exacto...

si vas a hacer un desplazamiento de 8 bits para que multipliar por 256? mejor ( otra optimizacion) es usar los operadores de desplazamiento de bits:

<<
>>

ejemplo de desplazamiento 8 bits a la izquierda

Código: Text

resultado = numero &#60;&#60; 8;
 

Ya que retoman lo de QueryPerformanceCounter and QueryPerformanceFrequency, las clases que usa DirectX en DXUtil estan implementadas haciendo uso de estas dos funciones de la API de windows.

.

Saludos.

Eternal Idol

Cita de: "JuanK"

Ya que retoman lo de QueryPerformanceCounter and QueryPerformanceFrequency, las clases que usa DirectX en DXUtil estan implementadas haciendo uso de estas dos funciones de la API de windows. .

Si, siempre que estan disponibles, son las funciones ideales ... no hay que olvidarse de ligarlas a un procesador en particular si estamos en una maquina con mas de uno.