Pregunta

Siga desde - problemas de controladores GPS intermedios

Lo anterior no fue respondida con éxito y siento que tengo nueva información sobre el tema para ir a una nueva pregunta.

El problema que estoy enfrentando es la velocidad de la que los datos están siendo entregados por el controlador GPS Intermedio.

He utilizado con éxito bolsillo masilla para leer los puertos serie y ver la información exacta sido expuesto.

COM 1 - Intermedio controlador GPS

COM 6 - Puerto serie para PC (datos de entrada manual)

COM 8 -. Puerto serie virtual para el hardware GPS

Al leer COM 8, puedo ver alrededor de 18 cadenas NMEA aparecen cada ~ 3 segundos, esto es lo más rápido que podemos empujarlo través de la conexión USB limitado. Y aparece rápidamente en la pantalla. Al leer COM 6 (datos de envío de PC de forma manual), se muestra igual de rápido. Así que no hay problema con los datos estado disponible.

Introduzca en el controlador GPS Intermedio. Cuando el conductor del GPS Intermedio se establece en COM1 (software) y COM6 (hardware). Los datos introducidos en COM6 se muestra en COM1 tan rápido como lo fue sin que el conductor GPS Intermedio. Los datos no se altera, por lo que si envío "JON" en COM6, aparecerá en COM1, a pesar de que sus datos NMEA no válidos, lo cual está bien.

El problema es con COM8. Cuando el controlador GPS Intermedio se establece en COM1 (software) y COM8 (hardware). Los datos que muestran en PocketPutty en COM1 es muy lento. La salida en la pantalla es de 5 caracteres por segundo, los datos son válidos pero acaba de ser entregado muy lentamente. Esto me señala un problema en la aplicación del analizador de ventana, como si el controlador GPS Intermedio no está leyendo todos los datos sólo un carácter a la vez, dado que he aislado el problema a mi puerto serie virtual.

Puede cualquier persona proporcionar un claro ejemplo de una aplicación de puerto serie virtual, ya que no estoy seguro de lo que podría cambiar para mejorar esto, dada COM8 trabaja directamente con el software de GPS y la aplicación PocketPutty, lo que indica que está disponible, se leen los datos, y es correcta.

¿Fue útil?

Solución

Después de conseguir el apoyo de los fabricantes dispositivo que ejecuta una versión de depuración, la causa del problema era aplicaciones cliente estaban haciendo a muchas llamadas de lectura. El puerto serie puede manejar por sí solo, sino a través del controlador GPS Intermedio el número de llamadas eran demasiado altos y los gastos generales se paralizando la comunicación, esto era por bloqueos mutex y problemas de threads en general.

Las aplicaciones cliente necesita leer 960 bytes de datos por lectura al controlador GPS Intermedio para ellos bien el trabajo. Esto no es una solución ideal por lo que se encontró otra solución.

La resolución fue agregar en un WaitForSingleObject (IsThereEnoughGPSDATAEvent, COMTotalTimeout) en el método de lectura, por lo que todas las lecturas sólo se conseguiría datos si había una cantidad suficiente de datos disponibles. Originalmente solicité 960 que esté disponible en el buffer, pero lo he instalado a sólo 10 bytes y todavía funciona.

Ejemplo de código

DWORD COM_Read( DWORD hOpenContext, LPVOID pBuffer, DWORD Count )
{
    if(gpsThreadEvents[GPS_THREAD_EVENT_DATA_AVAILABLE] != NULL)
    {
        if(WaitForSingleObject(gpsThreadEvents[GPS_THREAD_EVENT_DATA_AVAILABLE], GPSTimeouts.ReadTotalTimeoutConstant) != WAIT_OBJECT_0)
        {
            return 0;
        }
    }

    //read code goes in here

    return dataOut;
}
Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top