Потеря данных виртуального COM-порта , Потеря данных виртуального COM-порта

Добрый(ое, ая) вечер / ночь / утро / день.

Есть некое устройство, которое работает через USB (2.0).
Firmware устройства реализует класс CDC, соответственно на хосте видно как виртуальный COM-порт.
Принцип работы прост: устройство получает от хоста команду (16 байт) и отправляет обратно ответ (тоже 16 байт).
Тестовое приложение после открытия COM-порта в цикле производит запись команды и чтение ответа.

Пока устройство работает в режиме Full-speed (до 12 Мб/с) - всё нормально.

В режиме High-speed (до 480 Мб/с) на Windows (7 x64) (на некоторых компьютерах) начинаются проблемы: некоторое количество итераций работает нормально, потом зависает на чтении из порта. Количество итераций всегда разное (от нескольких десятков до нескольких сотен (иногда тысяч)).

При этом согласно анализаторам USB (как аппаратному, так и программному) ответ от устройства проходит по шине USB и попадает в систему. А вот снифер COM-порта ответ не видит.

На том же самом компьютере под Linux'ом в режиме High-speed всё работает без ошибок.

В чём может быть причина ошибок на Windows?
(Если я правильно понимаю, за создание виртуального COM-порта отвечает usbser.sys. Его версия определяемая в диспетчере устройств: 6.1.7601.18247 (win7sp1_gdr.130828-1532).)

У сетевых драйверов есть функция "контроля прерываний", появилось оно с ядра ОС семейства Vista. Смысл его заключается в том, чтобы не дергать прерывания на каждое событие (или пакет). Прерывание вызывается при накоплении определенного объема в буфере либо истечении таймаута.

Так вот, не исключено наличие такого подхода и у драйвера виртуального порта.
Попробуйте на XP ради интереса (позволит проверить ваш код и выявить ошибку в компонентах ОС).

И позвольте поинтересоваться, а зачем извращаться с виртуальным COM-портом на такой скорости?
Чем USB плох? Он аппаратно заполняет выделенный вами буфер (скажем 512 байт за мах) и дергает прерывание.

Спасибо за ответ.
Но всё равно остаётся непонятным почему происходит зависание на ReadFile. Данные то в порт со стороны устройства приходят.

Компьютера с Windows XP, к сожалению, под рукой нет.
Но даже под Windows 7 x64 проявляется не на всех компьютерах. Под Linux (на проблемном компьютере) ошибок с этим устройством не обнаружено.

Цитата

И позвольте поинтересоваться, а зачем извращаться с виртуальным COM-портом на такой скорости?

Виртуальный COM-порт хорош тем, что под него не нужно переписывать пользовательское приложение.

Цитата

Чем USB плох? Он аппаратно заполняет выделенный вами буфер (скажем 512 байт за мах) и дергает прерывание.

Не совсем понял, под USB вы здесь имеете в виду lib-usb?
Если проблема с usbser.sys не решится, то придётся использовать её.

Цитата WWX @ 04.08.17, 09:44

Компьютера с Windows XP, к сожалению, под рукой нет.

1. Можно попытаться поставить XP в виртуальную машину. Будет интересный эксперимент.
2. Возможно проблема в программе. Написать простенький тест и попробовать его.
Не знаю, какие у вас запросы/ответы. Если текстовые, тогда можно пробовать
какую-нибудь программу-терминал.

1. Интересная идея. Будет время - попробую.
(В пн меня не было на работе, а сейчас приходится заниматься более приоритетными делами, но рано или поздно вернуться придётся.)

2. Запросы / ответы не текстовые, но основная проблема применения терминалов не в этом - ошибка плавающая. Может проявиться и на тысячной итерации.

Временно проблема решается добавлением миллисекундной задержки перед вызовом ReadFile.
В режиме Full-speed данные не теряются даже без задержки (проверено многократно в течении длительных промежутков времени).

Цитата WWX @ 08.08.17, 11:52

Временно проблема решается добавлением миллисекундной задержки перед вызовом ReadFile.

Тогда это явно что-то с программой.
Такая штука - генерация двоичных или текстовых сообщений для отладки с некоторым периодом - у меня есть.
Самописная. Если надо, могу дать.
Но и самостоятельно смастерить такой тест не очень сложная задача.

Цитата ЫукпШ @ 08.08.17, 12:07

Тогда это явно что-то с программой.

Ну, это и так понятно - данные то в систему через USB попадают.
А то в начале грешил на USB контроллер на устройстве (точнее на то, как он окучен на плате) - прецеденты были - плата перепаивалась.

Цитата ЫукпШ @ 08.08.17, 12:07

генерация двоичных или текстовых сообщений для отладки с некоторым периодом

У меня примерно так и происходит. Только от периода мало что зависит.
Характерно то, что наличие отладочного принта между вызовами WriteFile и ReadFile значительно уменьшает воспроизводимость ошибки.
Возможно, данные теряются когда вызывается ReadFile и в этот же момент (практически одновременно) приходит ответ от устройства. Только как это проверить?

Цитата WWX @ 10.08.17, 20:09

Только как это проверить?

1-й способ я уже предложил - другое приложение. Если оно надёжно работает, значит
искать и исследовать разницу между исходниками.
2. Судя по этому утверждению:

Цитата

...Возможно, данные теряются когда вызывается ReadFile и в этот же момент (практически одновременно) приходит ответ от устройств..

речь идёт о синхронной работе с портом ?
Я не знаю всей структуры твоей программы. Попробуй работать по событиям.
Тогда ReadFile просто не сможет мешать приёму.
---
Качай ситуацию. Странное поведение программы может быть вызвано не обязательно неправильной
работой с COM-портом. Может где-то/что-то портится, а эффект проявляется так.
Просто напиши другую программу-тест, пусть даже и с той же структурой, что и сейчас.
---
У меня такого эффекта не было, хотя я не могу точно утверждать, в каком режиме работает виртуальный COM-порт.

Сообщение отредактировано: ЫукпШ - 11.08.17, 11:59

1. Буду пробовать другой тест (как только появится возможность - у меня сейчас временно отсутствует доступ к компьютеру, на котором проявляется ошибка (на моём компьютере ошибка не проявляется)).
2. Да, с COM-портом я работаю в синхронном режиме. Попробую асинхронный.

Асинхронный режим здесь ещё может быть применён как временное костыльное решение. Т. к. плата после потери хостом ответа остаётся в работоспособном состоянии и готова к принятию следующей команды (с её точки зрения вообще никаких ошибок не произошло).

Цитата WWX @ 03.08.17, 21:22

Есть некое устройство, которое работает через USB (2.0).

Простая идея: а USB-кабель снабжён фильтром ?
Если нет - поставить фильтр и снова попробовать.

Нет, причина не в этом.
Пробовались практически все доступные шнуры и с ферритовыми фильтрами и без них и разной длины.
При этом согласно анализатору на USB шине полный порядок.
Данные теряются где-то в недрах Windows...

Похоже, что проблема именно в драйвере usbser.sys т. к. если для эмуляции COM-порта использовать аналогичный сторонний драйвер (из комплекта ПО для какого-то совершенно другого устройства) то всё работает без ошибок (гоняется сутками).

Всем, кто отвечал - спасибо (особенно ЫукпШ).

Вопрос решён.