Driver intermediário GPS diminuindo os dados de um driver de porta serial virtual

Question

Siga de - Problemas de driver intermediário GPS

O exposto acima não foi respondido com sucesso e sinto que tenho novas informações sobre o problema para fazer uma nova pergunta.

O problema que estou enfrentando é a velocidade de quais dados estão sendo entregues pelo driver intermediário GPS.

Eu usei com sucesso a massa de bolso para ler as portas seriais e ver as informações exatas foram expostas.

Com 1 - Driver intermediário GPS

Com 6 - Porta serial para PC (dados de entrada manualmente)

Com 8 - Porta serial virtual para hardware GPS.

Ao ler com 8, posso ver cerca de 18 cordas NMEA aparecem a cada ~ 3 segundos, isso é o mais rápido possível sobre a conexão USB limitada. E aparece rapidamente na tela. Ao ler com 6 (envie dados do PC manualmente), ele é exibido igualmente rápido. Portanto, não há nenhum problema com os dados disponíveis.

Digite o driver intermediário GPS. Quando o driver intermediário GPS está definido como com1 (software) e com6 (hardware). Os dados inseridos no COM6 são exibidos no COM1 tão rapidamente quanto sem o driver intermediário GPS. Os dados são inalterados; portanto, se eu enviar "Jon" no COM6, eles aparecerão no COM1, mesmo que não sejam dados válidos da NMEA, o que é bom.

O problema está no COM8. Quando o driver intermediário GPS está definido como com1 (software) e com8 (hardware). Os dados exibidos no PocketPutty no COM1 são realmente lentos. A saída na tela é de cerca de 5 caracteres por segundo, os dados são válidos, mas foram entregues muito lentamente. Isso para mim aponta um problema na implementação da porta serial virtual, como se o driver intermediário do GPS não estivesse lendo todos os dados apenas um caractere de cada vez, dado que eu isolei o problema da minha porta serial virtual.

Alguém pode fornecer um exemplo claro de uma implementação de porta serial virtual, pois não tenho certeza do que eu poderia mudar para melhorar isso, dado que o COM8 funciona diretamente com o software GPS e o aplicativo Pocketputty, que indica que os dados estão disponíveis, sendo lidos e está correto .

Answer 1

Depois de obter suporte do fabricante do dispositivo executando uma construção de depuração, a causa do problema foi que os aplicativos do cliente estavam fazendo para muitas chamadas de leitura. A porta serial poderia lidar com eles por conta própria, mas através do motorista intermediário do GPS o número de chamadas era muito alto e a sobrecarga estava prejudicando a comunicação, isso se desviou a bloqueios mutex e problemas gerais de rosqueamento.

Os aplicativos do cliente precisam ler 960 bytes de dados por leitura para o driver intermediário do GPS para que funcionem bem. Esta não é uma solução ideal, então outra correção foi encontrada.

A resolução foi adicionar um WaitformingleObject (isthereenoughgpsdataEvent, ComtotalTimeout) no método de leitura, para que todas as leituras obtivessem apenas dados se houvesse uma quantidade suficiente de dados disponíveis. Originalmente, solicitei que o 960 estivesse disponível no buffer, mas eu o defini para apenas 10 bytes e ele ainda funciona.

Código de amostra

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;
}