Промежуточный драйвер GPS Замедление данных из драйвера виртуального последовательного порта - PullRequest
1 голос
/ 22 ноября 2010

Follow from - Проблемы с промежуточным драйвером GPS

Выше не удалось ответить, и я чувствую, что у меня есть новая информация по этому вопросу, чтобы перейти к новому вопросу.

Проблема, с которой я сталкиваюсь, заключается в скорости передачи данных промежуточным драйвером GPS.

Я успешно использовал Pocket Putty для чтения последовательных портов и просмотра точной информации.

COM 1 - промежуточный драйвер GPS

COM 6 - Последовательный порт для ПК (ввод данных вручную)

COM 8 - виртуальный последовательный порт для оборудования GPS.

При чтении COM 8 я вижу, что примерно 18 строк NMEA появляются каждые ~ 3 секунды, это так же быстро, как мы можем протолкнуть его через ограниченное USB-соединение. И это быстро появляется на дисплее. При чтении COM 6 (отправка данных с ПК вручную) оно отображается одинаково быстро. Таким образом, нет проблем с доступными данными.

Введите в промежуточный драйвер GPS. Когда промежуточный драйвер GPS установлен на COM1 (программное обеспечение) и COM6 (аппаратное обеспечение). Данные, введенные на COM6, отображаются на COM1 так же быстро, как и без промежуточного драйвера GPS. Данные не изменяются, поэтому, если я отправлю «JON» на COM6, он появится на COM1, даже если это недействительные данные NMEA, что нормально.

Проблема с COM8. Когда промежуточный драйвер GPS установлен на COM1 (программное обеспечение) и COM8 (аппаратное обеспечение). Данные, отображаемые в PocketPutty на COM1, очень медленные. Вывод на экран составляет около 5 символов в секунду, данные действительны, но они доставляются очень медленно. Для меня это указывает на проблему в реализации виртуального последовательного порта, как будто промежуточный драйвер GPS не читает все данные только по одному символу за раз, учитывая, что я изолировал проблему с моим виртуальным последовательным портом.

Может ли кто-нибудь предоставить наглядный пример реализации виртуального последовательного порта, поскольку я не уверен, что я мог бы изменить, чтобы улучшить это, учитывая, что COM8 напрямую работает с программным обеспечением GPS и приложением PocketPutty, которое указывает, что данные доступны, будучи прочитанными, и правильно.

1 Ответ

0 голосов
/ 10 января 2011

После получения поддержки от производителя устройства, выполняющего отладочную сборку, причиной проблемы было то, что клиентские приложения выполняли много вызовов чтения. Последовательный порт может обрабатывать их самостоятельно, но через промежуточный драйвер GPS количество вызовов было слишком велико, а служебные данные наносили ущерб связи, это было связано с блокировками Mutex и общими проблемами с многопоточностью.

Клиентские приложения должны считывать 960 байт данных за чтение в промежуточный драйвер GPS, чтобы они работали нормально. Это не идеальное решение, поэтому было найдено другое исправление.

Было решено добавить в метод чтения метод WaitForSingleObject (IsThereEnoughGPSDATAEvent, COMTotalTimeout), чтобы все операции чтения получали данные только при наличии достаточного количества данных. Первоначально я просил 960 быть доступным в буфере, но я установил его на 10 байтов, и он все еще работает.

Пример кода

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