Việc di chuyển mã vào không gian hạt nhân có cung cấp thời gian chính xác hơn không?

Question

Thông tin cơ bản:

Tôi hiện có thiết bị phần cứng kết nối với cổng USB. Thiết bị phần cứng chịu trách nhiệm gửi các thông điệp định kỳ chính xác lên các mạng khác nhau, nó lần lượt cũng kết nối. Bên trong thiết bị phần cứng, tôi có một vài MicroPip dsPIC. Có hai phương thức hoạt động.

Một trường hợp là nơi gửi "công việc" đơn giản tới dsPICs, đến lượt nó, có thể gửi các thông điệp chính xác với độ chính xác .001ms. Kiến trúc này không lý tưởng cho việc nhắn tin phức tạp hơn, nơi chúng ta cần gửi một gói định kỳ thay đổi dựa trên các sự kiện đang diễn ra trong ứng dụng PC. Vì vậy, chúng tôi có một chế độ hoạt động thứ hai, nơi ứng dụng PC của chúng tôi sẽ gửi các tin nhắn định kỳ và các dsPIC chỉ đơn giản là chuyển đổi và truyền tải đáp ứng. Tất cả điều này, bằng cách này, là minh bạch cho người dùng cuối của phần mềm của chúng tôi. Thiết bị phần cứng của chúng tôi là một công cụ kiểm tra được sử dụng trong lĩnh vực ô tô.

Hiện tại, chúng tôi sử dụng USB để nối tiếp chip từ FTDI và trình điều khiển Windows FTDI để giao tiếp phần cứng với phần mềm PC của chúng tôi.

Vấn đề ở chế độ hai nơi chúng tôi gửi tin nhắn từ máy tính, tốt nhất chúng tôi có thể đạt được là khoảng 1ms trên phạm vi phần cứng trung bình. Chúng tôi phải chịu sự chấp thuận trước của hạt nhân Windows. Tôi đã thử một số "thủ thuật" để cải thiện những thứ như:

1. Đảm bảo rằng người đọc của chúng tôi có thể sống riêng biệt khi có thể.
2. Tăng mức ưu tiên luồng của người viết trong khi giảm mức độ ưu tiên của người đọc.
3. Thông báo cho người dùng tắt trình bảo vệ màn hình và các ứng dụng khác khi sử dụng phần mềm của chúng tôi.
4. Thay thế cuộc gọi tạo cuộc gọi bằng CreateTimerQueueMọi cuộc gọi.

Tất cả phần mềm của chúng tôi được viết bằng C/C++. Tôi rất quen thuộc và thoải mái với lập trình Windows nâng cao; chẳng hạn như IO hoàn thành, Overlapped I/O, hàng đợi threadless khóa (thực sự là một chiến lược thiết kế), ổ cắm, chủ đề, semaphores, vv ...

Tuy nhiên, tôi không biết gì về phát triển trình điều khiển Windows. Tôi đã đọc qua một vài giấy tờ về KMDF so với UDMF so với WDM.

Tôi hy vọng nhà phát triển trình điều khiển chế độ hạt nhân dày dặn của Windows sẽ phản hồi tại đây ...

Vòng tiếp theo. phần cứng của chúng tôi có tùy chọn thay thế chip FTDI và sử dụng giao diện USB của dsPIC hoặc, có thể, chuyển mã nguồn mở FTDI Linux sang Windows và tiếp tục sử dụng chip FTDI trong trình điều khiển tùy chỉnh của chúng tôi. Tôi nghĩ bằng cách vào trình điều khiển chế độ hạt nhân ở phía PC, tôi có thể thiết lập trình điều khiển hạt nhân có thể gửi các tin nhắn định kỳ vào các khoảng thời gian chính xác hơn mà không cần sử dụng và/hoặc có thể tận dụng DMA.

Chúng tôi có một đối thủ cạnh tranh trong kinh doanh của chúng tôi, những người tôi nghĩ chính xác điều gì đó tương tự với công cụ của họ. Theo như tôi biết, các ứng dụng không gian người dùng không thể lên lịch một chuỗi nào tốt hơn 1ms. Chúng tôi hiện đang sử dụng timeGetTime trong một chủ đề. Tôi đã thử nghiệm với hàng đợi hẹn giờ (thông qua CreateTimerQueueTimer) mà không có cải tiến thực sự.

WDM là phương pháp đúng để đạt được thời gian chính xác hơn?

Đối thủ cạnh tranh của chúng tôi một số cách đạt được thời gian rất chính xác từ các tín hiệu điều khiển Windows đến phần cứng của chúng và chúng tải trình điều khiển hạt nhân (.sys) và thiết bị của họ chạy trên USB2.0 cũng như của chúng tôi.

Nếu WDM là con đường để đi, tôi có thể nhận được một số lời khuyên về những chức năng hạt nhân nào tôi nên nghiên cứu để thiết lập thời gian không? Cảm ơn bạn đã đọc

Answer 1

Trong chế độ hạt nhân, bạn có sự sang trọng để nhận DPC được kích hoạt theo bội số của khoảng thời gian 100 nano giây mà không phải xử lý gián đoạn. Một DPC không thể được preempted (aka bị gián đoạn bởi thread scheduler) vì thread scheduler cũng là một DPC. Một gián đoạn vẫn có thể ngăn chặn một DPC mặc dù. Vì vậy, một giá trị khoảng 10 nên làm các trick cho bạn để có một cuộc gọi lại với độ chính xác tối đa.

Tuy nhiên bạn không có quyền truy cập vào nhiều tính năng như bộ nhớ phân trang hoặc không gian bộ nhớ của một chủ đề cụ thể ở cấp DPC vì chúng chạy trong ngữ cảnh tùy ý. Có thể hữu ích để trì hoãn việc xử lý ngữ cảnh của quá trình chế độ người dùng của riêng bạn bằng cách sử dụng APC có quyền truy cập vào nhiều tính năng hơn.

Chuỗi hạt nhân không được xử lý đặc biệt về mặt ưu tiên. Chúng giống với chủ đề người dùng từ phối cảnh của lịch biểu. Có vài mức độ ưu tiên cao hơn các luồng hạt nhân có thể nhận được nhưng thường không có luồng hạt nhân nào sử dụng bất kỳ chuỗi nào trong số chúng. Tôi không nghĩ rằng nút cổ chai của bạn là ưu tiên luồng. Không quan trọng số lượng ưu tiên của bạn là bao nhiêu, chỉ có một người ở trên mọi người khác là đủ để bạn trở thành "chủ đề thần" được ưu tiên hàng đầu. Có ưu tiên cao nhất không có nghĩa là bạn sẽ nhận được sự chú ý liên tục. Hệ điều hành vẫn sẽ tạm dừng luồng của bạn để chạy các luồng khác, vì vậy sự đói khát lượng tử không xảy ra.

Một lưu ý khác về hành vi mua trước của Windows: Trình quản lý tập hợp cân bằng tạm thời tăng ưu tiên của chuỗi khi chuỗi được báo hiệu bởi sự kiện không đồng bộ (GUI, kích hoạt hẹn giờ, hoàn thành I/O) để cho phép hoàn thành mã hoàn thành. tiền thưởng. Việc sử dụng trình xử lý bộ đếm thời gian async sẽ cung cấp đủ sự thúc đẩy để ngăn chặn việc sử dụng ít nhất cho một lượng tử. Tôi tự hỏi tại sao mã của bạn không rơi vào cửa sổ đó. Tuy nhiên có vẻ như bạn không phải là người duy nhất gặp sự cố với độ chính xác của hẹn giờ: http://www.virtualdub.org/blog/pivot/entry.php?id=272

Tôi đồng ý với Paul về sự phát triển trình điều khiển phức tạp, nhưng miễn là bạn có lý giải chính xác thì đó không phải là khoa học tên lửa.

Answer 2

Đây là một trong những khía cạnh thiết kế cơ bản của hạt nhân Windows - mã đang chạy ở mức thụ động (=> tất cả mã chế độ người dùng) chịu sự điều chỉnh của DPC và ngắt thời gian, và nếu bạn muốn 1us chính xác, có thể bạn sẽ không nhận được nó với một trình điều khiển UMDF hoặc chế độ người dùng.

Tuy nhiên, viết một trình điều khiển hạt nhân không phải là một ánh sáng hoặc cam kết giá rẻ, nó là rất khó khăn, cả hai thậm chí viết, và để đảm bảo rằng nó hoạt động trên máy của khách hàng (rất nhiều của thử nghiệm là cần thiết). Bắt nó đúng sẽ chi phí bạn tài nguyên kỹ thuật quan trọng.

Là điểm dừng, tôi sẽ xem xét MMCSS cho> = Vista (http://msdn.microsoft.com/en-us/library/windows/desktop/ms684247(v=vs.85).aspx) , nó có thể cung cấp cho bạn đủ ưu tiên mà bạn có thể hài lòng.

Nếu bạn thực sự muốn đi xuống hố thỏ, KMDF là những gì bạn nên sử dụng. KMDF là một khuôn khổ trên đầu trang của WDM đại diện cho rất nhiều thực hành tốt nhất được mã hóa cho trình điều khiển. Trừ khi bạn hoàn toàn bị buộc phải, KMDF là luôn luôn cách tốt nhất để lái xe. Và thành thật mà nói, bạn gần như chắc chắn sẽ muốn hoặc là hợp đồng với OSR (http://www.osr.com) hoặc thuê một người nào đó (một số người?) Có kinh nghiệm trong việc viết các trình điều khiển Windows.

Answer 3

Việc bạn tập trung vào các trình điều khiển và hiệu suất hạt nhân bỏ lỡ rừng cho cây cối.Con voi trong phòng là thực tế là các khung xe buýt USB 2 tốc độ đầy đủ xảy ra với khoảng thời gian 1ms. Tốc độ cao USB 2 micro-frame xảy ra mỗi 1/8ms.

Khi bạn gửi dữ liệu qua đầy đủ tốc độ USB (như đối với hầu hết các chip FTDI), là tốt nhất ứng dụng của bạn có thể hy vọng là dữ liệu sẽ đến được với các thiết bị đôi khi trong khung hôm sau. Với một chiếc xe buýt USB không tải, quá trình chuyển sẽ diễn ra rất gần với khung hình bắt đầu. Bạn sẽ quan sát nó dưới dạng độ chi tiết 1ms với độ lệch ngẫu nhiên nhỏ. Đây chính xác là những gì bạn đang thấy và không tệ. Ví dụ, vì tất cả các thiết bị USB được gắn vào cùng một máy chủ sẽ thấy các khung hình cùng một lúc, đó là một cách đơn giản để đồng bộ hóa nhiều đồng hồ thiết bị với độ chính xác cao hơn micro giây. Ứng dụng của bạn có thể làm gì đơn giản là gửi một thông điệp không chỉ có dữ liệu mà còn một thời gian nữa trong tương lai gần khi nó được gửi đi. Một vấn đề khác với USB là không có sự đảm bảo nào về thời điểm yêu cầu truyền dữ liệu của bạn sẽ được bảo trì. Bạn đang chia sẻ một chiếc xe buýt với các thiết bị khác, sau khi tất cả.

Tôi nghĩ bạn cần xem xét lại hệ thống của mình và không phụ thuộc vào bất kỳ loại thời gian nào từ đầu PC. Ứng dụng chạy trên máy tính nên được giả định là, thời gian khôn ngoan, giới hạn đối với hiệu suất của con người tương tác với nó. Bất kỳ thứ gì yêu cầu hiệu suất thời gian thực được đảm bảo đều phải có trên thiết bị dsPIC của bạn. Ngay cả các xe buýt USB không cắt nó như bạn không có bảo đảm ở tất cả như thế nào sẽ yêu cầu của bạn sẽ được lên kế hoạch sớm trên xe buýt. Về cơ bản, nếu bạn muốn đảm bảo hiệu suất thời gian thực trên Windows, thì phải có chế độ người dùng liên quan - phải tất cả chạy ở chế độ hạt nhân và bạn phải sử dụng các kênh liên lạc để sử dụng độc quyền (hoặc bạn làm cho chúng hoạt động theo cách đó, ví dụ như bằng cách lọc ngay trên đầu máy chủ lưu trữ USB).