Co może powodować, że wywołania CreateFile na porcie szeregowym będą wyjątkowo powolne?

Question

Mam aplikację Qt (Qt 4.8.1), która wykonuje niektóre zadania portu szeregowego Windows. Odkrywam, że czasami wywołanie CreateFileA, które wykonuję, aby otworzyć port szeregowy, trwa do 30 sekund! Oczywiście robię coś, by wywołać to dziwne zachowanie, i chcę wiedzieć, co to jest, co może zrobić, by to spowodować.

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 jest UCHWYTEM, a portDevice jest std :: string i zawiera "COM5".

To połączenie jest wywoływane przez naciśnięcie przycisku w głównym wątku mojej aplikacji. W tym czasie aplikacja ma najwyżej jeden inny wątek, ale te wątki (jeśli są) są bezczynne.

Jedyną ważną rzeczą, która dzieje się w systemie, jest maszyna wirtualna z systemem Linux, ale system jest czterordzeniowy, a 3 z rdzeni są prawie bezczynne, jak widać na pudełku z systemem Windows, a tylko jeden robi cokolwiek z maszyną wirtualną.

Porty szeregowe znajdują się na 8-portowym porcie szeregowym USB, czy może to być powiązane?

Czy jest to związane z nakładającymi się zamówieniami internetowymi w jakiś sposób?

W odpowiedzi na komentarze:

port nie jest otwarty przez inną aplikację. Port był poprzednio otwarty przez poprzednią inwokację tej aplikacji, która została poprawnie zamknięta, a port zamknięty z "CloseHandle".

Nie udało mi się ustalić żadnych korelacji pomiędzy 30 sekundami, a nie - czasami uruchamiam aplikację, klikam przycisk i ruszamy na wyścigi, czasami zajmuje to do 30 sekund.

Maszyna wirtualna przechwytuje inne urządzenia USB w tym samym pudełku szeregowym.

Oprócz portu szeregowego (z 4 portami pollingu VM w poszukiwaniu urządzeń), magistrala USB jest rozładowywana.

Nie widziałem zachowania w innych aplikacjach. Spróbuję przełączyć się na wbudowany port (COM1 na płycie głównej), aby sprawdzić, czy to ma jakiś wpływ.

Przyszła mi do głowy pewna myśl: czy forma adresowania portu może mieć z tym coś wspólnego? Inne podobne aplikacje, nad którymi pracuję, korzystają z biblioteki qestserialport, która otwiera porty przy użyciu notacji "\\. \ COM #". Czy istnieje sposób, w jaki zastosowana notacja może wpłynąć na czas?

Urządzenie szeregowe USB mówi "VScom" na nim i zwykle otwiera się natychmiast (< 10 milisekund dla wywołania CreateFile). To tylko sporadyczny problem, w którym rzeczy się pakują, i mam inne programy, które NIGDY nie wydają się wykazywać tego zachowania.

Urządzenie, z którym rozmawiam, to monitor medyczny wykorzystujący protokół IEEE 11073. W każdym razie, mam połączenie z urządzeniem działającym dobrze, to TYLKO otwarty port szeregowy jest problematyczny. Czy stan linii sterowania szeregowego w czasie otwartym może mieć coś wspólnego z tym? Urządzenie na drugim końcu jest odpytywaniem portów, szukając różnych rzeczy do rozmowy, więc nie mam pojęcia, jak wyglądają linie szeregowe w momencie, gdy coś pójdzie nie tak.

Answer 1

OK, problem jest zrozumiany, jeśli nie został rozwiązany. Grałem z innym urządzeniem szeregowym, a problem zaczął się jeszcze bardziej manifestować.

Problem polega na tym, że gdy VM kontroluje niektóre porty szeregowe, sterowniki stają się z przerwami wolne, aby otworzyć dostępne porty.

Mój program testowy otwiera się, a następnie zamyka port 1000 razy, ustawiając czas otwarcia połączenia. NIE ustawia w żaden sposób parametrów portu szeregowego. Przed uruchomieniem programu testowego wykonywałem rzeczywistą pracę z urządzeniem wykorzystującym prędkość transmisji 460800.

Gdy maszyna wirtualna posiada 4 porty, wówczas otwiera się na pozostałych 4 portach (20- 30 razy na 1000 prób) ukończenie 20-30 sekund. Gdy maszyna wirtualna nie działa, otwiera się szybko wszystkie 1000 prób. Przy uruchomionej maszynie wirtualnej, ale bez portów szeregowych USB w jej posiadaniu, otwory następowały szybko po wszystkich 1000 próbach.

Ponieważ VM jest narzędziem programistycznym, nie jest częścią naszego zamierzonego scenariusza wdrażania, mogę żyć z tym problemem.

Co ciekawe, efekt ten wydaje się zależeć od szybkości transmisji ostatnio używanego portu. Przed początkowymi pytaniami działałem z prędkością 9600 bodów i poniżej i nie przypominam sobie, by kiedykolwiek widziałem problem. Kiedy po raz pierwszy zadałem to pytanie, pracowałem z urządzeniem o szybkości 115 000 bodów i miałem problem z przerwami. Dzięki najnowszemu urządzeniu z szybkością 460 800 bodów, pojawia się problem na tyle często, że mogę uporać się z problemem. Nie mam pojęcia dlaczego, ale jest.

Answer 2

Szeregowe linie kontrolne współdziałające z problemem sterownika urządzenia to prawdopodobna przyczyna.

Czy masz poprawnie podłączone sygnały sterujące?

Jeśli nie, podłącz RTS do CTS i podłącz CD, DTR i DSR. W przypadku DB25 oznacza to podłączenie pinów 4 i 5 oraz pinów łączących 6, 8 i 20. Na DB9, podłącz piny 7 i 8 i podłącz piny 1, 4 i 6.

Jeśli to rozwiąże problem, powinieneś poszukaj ustawień sterownika, aby zignorować sygnały sterujące przy otwartym.