saludos....¿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.
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 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 ,¿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 ...
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
en realidad la primera aplicacion que hice esta en un bucle, y lo unico que hace es pidePor 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 ...
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)
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).
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.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.
xx- para que haces esto?
receive_buf[1]*256
estas seguro que eso es lo que quieres?
Si es un problema de ejecucion en tiempo real entonces hay que usar un S.O. que lo permita y no WindowsSupongo que cuando dices "Windows" te refieres a Windows 95/98/Millenium/NT/2000/XP/vista... Windows CE es un sistema operativo en tiempo real, :whistling: .
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, :whistling: .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 ...
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....
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)
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. :P.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.