Что может привести к тому, что вызовы CreateFile на последовательном порту будут чрезвычайно медленными?

У меня есть приложение Qt (Qt 4.8.1), которое выполняет некоторые задачи последовательного порта Windows. Я нахожу, что иногда вызов CreateFileA, который я делаю для открытия последовательного порта, занимает до 30 секунд! Очевидно, я делаю что-то, чтобы вызвать это странное поведение, и я хочу знать, что я могу сделать, чтобы вызвать это.

m_portHand = CreateFileA( portDevice.c_str(),
                          GENERIC_READ | GENERIC_WRITE,
                          0,      //  must be opened with exclusive-access
                          NULL,   //  default security attributes
                          OPEN_EXISTING, //  must use OPEN_EXISTING
                          FILE_FLAG_OVERLAPPED,      //  overlapped I/O
                          NULL ); //  hTemplate must be NULL for comm devices

m_portHand - это РУЧКА, а portDevice - это std::string и содержит "COM5".

Этот вызов запускается нажатием кнопки в основном потоке моего приложения. В то время это приложение имеет не более одного другого потока, но эти потоки (если они есть) простаивают.

Единственное, что происходит в системе, - это виртуальная машина под управлением Linux, но система представляет собой четырехъядерный процессор, а 3 ядра находятся почти в режиме ожидания, как вы видите в окне Windows, причем только один делает что-либо с помощью VM.

Последовательные порты находятся на 8-портовом последовательном USB-порту, может ли это быть связано?

Связано ли это с перекрывающимся IO?

В ответ на комментарии:

Порт не открыт другим приложением. Порт ранее был открыт предыдущим вызовом этого приложения, которое было правильно закрыто, а порт закрыт с помощью "CloseHandle".

Я не смог определить какие-либо корреляции между ними, занимая 30 секунд, а не - иногда я запускаю приложение, нажимаю кнопку, и мы уходим на гонки, иногда это занимает до 30 секунд.

VM перехватывает некоторые другие USB-устройства в одном и том же серийном окне.

Помимо серийного окна (с полем опроса VM 4 для поиска устройств), USB-шина выгружается.

Я не видел поведения в других приложениях. Я попробую переключиться на встроенный порт (COM1 на материнской плате), чтобы убедиться, что это имеет эффект.

Мне пришла в голову мысль: может ли форма адресной адресации иметь к ней какое-либо отношение? Другие подобные приложения, над которыми я работаю, используют библиотеку qestserialport, которая открывает порты, используя ноту "\\.\COM #". Есть ли способ, которым используемая нотация может повлиять на время?

Последовательное устройство USB говорит об этом "VScom", и обычно оно сразу открывается (< 10 миллисекунд для вызова CreateFile). Это просто случайная проблема, когда вещи накапливаются, и у меня есть другие программы, которые НИКОГДА не проявляют такого поведения.

Устройство, с которым я разговариваю, является медицинским монитором, использующим протокол IEEE 11073. Во всяком случае, у меня есть соединение с устройством, работающим просто отлично, он ТОЛЬКО последовательный порт открывает эту проблему. Могло ли состояние последовательных линий управления в открытое время иметь какое-то отношение к этому? Устройство на другом конце опроса его портов ищет различные вещи, с которыми можно поговорить, поэтому я понятия не имею, как выглядят серийные строки в тот момент, когда все идет не так.

Ответ 1

ОК, проблема понятна, если не решена. Я играл с другим последовательным устройством, и проблема стала проявляться еще чаще.

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

Моя тестовая программа откроется, а затем закрывает порт 1000 раз, синхронизируя открытый вызов. Он НЕ задает параметры последовательного порта. До запуска тестовой программы я выполнял фактическую работу с устройством, использующим скорость передачи 460800.

Когда виртуальная машина находится в распоряжении 4 порта, затем открывается на оставшихся 4 портах иногда (20-30 раз из 1000 попыток) занимает 20-30 секунд для завершения. Когда виртуальная машина не работает, разворачивается быстро все 1000 попыток. При запуске виртуальной машины, но в нем нет последовательных портов USB, открытие произошло быстро на всех 1000 попытках.

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

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

Ответ 2

Возможны быть последовательные линии управления, взаимодействующие с проблемой драйвера устройства.

Правильно ли подключены сигналы управления?

Если нет, подключите RTS к CTS и подключите CD, DTR и DSR. На DB25 это означает подключение контактов 4 и 5 и соединительных штырей 6, 8 и 20. На DB9 соедините контакты 7 и 8 и соедините контакты 1, 4 и 6.

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