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

Question

У меня есть приложение 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 является HANDLE, и portDevice является станд :: строка и содержит "COM5".

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

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

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

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

В ответ на замечания:

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

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

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

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

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

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

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

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

Answer 1

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

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

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

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

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

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

Answer 2

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

У вас есть правильные сигналы управления?

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

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