Điều gì có thể gây ra các cuộc gọi CreateFile trên một cổng nối tiếp cực kỳ chậm?

Question

Tôi có một ứng dụng Qt (Qt 4.8.1) đang thực hiện một số tác vụ cổng nối tiếp Windows. Tôi thấy rằng thỉnh thoảng cuộc gọi CreateFileA mà tôi làm để mở cổng nối tiếp mất tới 30 giây để hoàn tất! Rõ ràng tôi đang làm một cái gì đó để kích hoạt hành vi kỳ lạ này, và tôi muốn biết tôi có thể làm gì để gây ra điều này.

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 là HANDLE và portDevice là chuỗi std :: và chứa "COM5".

Cuộc gọi này được kích hoạt bằng cách nhấn nút trong chuỗi chính của ứng dụng của tôi. Vào thời điểm nó xảy ra ứng dụng có nhiều nhất một chủ đề khác, nhưng những chủ đề (nếu có) là nhàn rỗi.

Điều quan trọng duy nhất xảy ra trong hệ thống là máy ảo chạy Linux, nhưng hệ thống là lõi tứ và 3 lõi gần như không hoạt động như bạn thấy trên hộp Windows, chỉ có một thao tác với VM.

Các cổng nối tiếp nằm trên hộp nối tiếp USB 8 cổng, điều đó có liên quan không?

Điều này có liên quan đến IO bị chồng chéo theo một cách nào đó không?

Đáp lại nhận xét:

Cảng không mở cửa bởi ứng dụng khác. Cổng trước đó đã được mở bằng một lời gọi trước đó của ứng dụng này, đã được đóng lại đúng cách và cổng đóng với 'CloseHandle'.

Tôi không thể xác định bất kỳ mối tương quan nào giữa việc mất 30 giây và không - đôi khi tôi khởi động ứng dụng, nhấp vào nút và chúng tôi đang đi đến các cuộc đua, đôi khi mất đến 30 giây.

Máy ảo đang chặn một số thiết bị USB khác trên cùng một hộp nối tiếp.

Khác với hộp nối tiếp (với máy ảo bỏ phiếu 4 cổng tìm thiết bị), xe buýt USB đã được tải xuống.

Tôi chưa thấy hành vi trong các ứng dụng khác. Tôi sẽ cố gắng chuyển sang một cổng tích hợp (COM1 trên bo mạch chủ) để xem có hiệu ứng nào không.

Một ý nghĩ chỉ xảy ra với tôi: liệu hình thức cổng địa chỉ có liên quan gì đến nó không? Các ứng dụng tương tự khác tôi làm việc trên sử dụng thư viện qestserialport, mở các cổng bằng cách sử dụng ký hiệu '\\. \ COM #'. Có cách nào mà ký hiệu được sử dụng có thể ảnh hưởng đến thời gian không?

Thiết bị nối tiếp USB nói 'VScom' trên thiết bị và bình thường nó mở ra ngay lập tức (< 10 mili giây cho cuộc gọi CreateFile). Nó chỉ là một vấn đề thường xuyên, nơi mọi thứ được nhồi lên, và tôi đã có các chương trình khác mà KHÔNG BAO GIỜ dường như thể hiện hành vi này.

Thiết bị tôi đang nói đến là một màn hình y tế sử dụng giao thức IEEE 11073. Dù sao, tôi có kết nối với các thiết bị làm việc tốt, nó chỉ mở cổng nối tiếp đó là vấn đề. Trạng thái của các dòng điều khiển nối tiếp vào thời gian mở có liên quan gì với điều này không? Thiết bị ở đầu bên kia đang bỏ phiếu là các cổng tìm kiếm những thứ khác nhau để nói chuyện, vì vậy tôi không biết các dòng nối tiếp trông như thế nào vào đúng thời điểm mọi thứ xảy ra sai.

Answer 1

OK, vấn đề được hiểu, nếu không được giải quyết. Tôi đang chơi với một thiết bị nối tiếp khác và vấn đề bắt đầu biểu hiện thường xuyên hơn.

Vấn đề có vẻ là khi VM điều khiển một số cổng nối tiếp, trình điều khiển trở nên không liên tục chậm để mở các cổng khả dụng.

Chương trình thử nghiệm của tôi mở sau đó đóng cổng 1000 lần, định thời gian cuộc gọi mở. Nó KHÔNG thiết lập các tham số cổng nối tiếp theo bất kỳ cách nào. Trước khi chạy chương trình thử nghiệm, tôi đã thực hiện công việc thực tế với thiết bị sử dụng tốc độ truyền 460800.

Khi máy ảo sở hữu 4 cổng, sau đó mở 4 cổng còn lại đôi khi (20- 30 lần trong số 1000 lần thử) mất 20-30 giây để hoàn thành. Khi máy ảo không chạy, mở sẽ diễn ra nhanh chóng trong tất cả 1000 lần thử. Với máy ảo đang chạy, nhưng không có cổng nối tiếp USB trong đó là sở hữu, mở ra xảy ra nhanh chóng trên tất cả 1000 lần thử.

Vì VM là một công cụ phát triển, không phải là một phần của kịch bản triển khai dự định của chúng tôi, tôi có thể sống với vấn đề này.

Điều thú vị là hiệu ứng này dường như phụ thuộc vào tốc độ truyền của cổng được sử dụng lần cuối vào lúc nào. Trước các yêu cầu ban đầu của tôi, tôi đã hoạt động ở mức 9600 baud trở xuống và không nhớ là đã từng gặp vấn đề. Khi tôi lần đầu tiên đặt câu hỏi, tôi đã làm việc với một thiết bị ở mức 115000 baud, và có vấn đề không liên tục. Với thiết bị mới nhất ở tốc độ 460800 baud, tôi gặp vấn đề thường xuyên đủ để có thể tìm kiếm sự cố. Không có ý tưởng tại sao, nhưng có nó.

Answer 2

Các dòng điều khiển nối tiếp tương tác với sự cố trình điều khiển thiết bị là nguyên nhân có thể xảy ra.

Bạn có tín hiệu điều khiển được kết nối chính xác không?

Nếu không, hãy kết nối RTS với CTS và kết nối CD, DTR và DSR. Trên một DB25, điều này có nghĩa là kết nối các chân 4 và 5 và nối các chân 6, 8 và 20. Trên một DB9, nối các chân 7 và 8 và nối các chân 1, 4 và 6.

Nếu điều này khắc phục được sự cố, bạn nên tìm kiếm các cài đặt trình điều khiển để bỏ qua các tín hiệu điều khiển khi mở.