Будет ли перемещение кода в пространство ядра давать более точное время?

Справочная информация:

В настоящее время у меня есть аппаратное устройство, которое подключается к USB-порту. Аппаратное устройство отвечает за отправку точных периодических сообщений в различные сети, к которым оно, в свою очередь, также подключается. Внутри аппаратного устройства у меня есть пара микросхем dsPIC. Есть два режима работы.

Один из сценариев - это отправка простых «заданий» на dsPIC, которые, в свою очередь, могут отправлять точные сообщения с точностью до 0,001 мс. Эта архитектура не идеальна для более сложного обмена сообщениями, когда нам нужно периодически отправлять пакет, который изменяется в зависимости от событий, происходящих в приложении ПК. Итак, у нас есть второй режим работы, при котором наше приложение для ПК будет отправлять периодические сообщения, а dsPIC просто конвертируют и передают в ответ.Все это, кстати, прозрачно для конечного пользователя нашего программного обеспечения. Наше аппаратное устройство - это тестовый инструмент, используемый в автомобильной сфере.

В настоящее время мы используем микросхему USB-последовательного порта от FTDI и драйверы FTDI для Windows для взаимодействия оборудования с программным обеспечением нашего ПК.

Проблема в том, что во втором режиме, когда мы отправляем сообщения с ПК, лучшее, что мы можем достичь, составляет около 1 мс в среднем диапазоне оборудования. Мы подвергаемся преимущественному праву ядра Windows. Я испробовал ряд "уловок" для улучшения вещей, таких как:

1. Обеспечение того, чтобы наши потоки чтения и записи работали с разными сходствами ЦП, когда это возможно.
2. Повышение приоритета потока писателя при одновременном уменьшении приоритета читателя.
3. Информирование пользователя об отключении хранителя экрана и других приложений при использовании нашего программного обеспечения.
4. Замена вызовов createthread вызовами CreateTimerQueueTimer.

Все наше программное обеспечение написано на C / C ++. Я хорошо знаком с продвинутым программированием для Windows; такие как завершение ввода-вывода, перекрывающийся ввод-вывод, очереди потоков без блокировки (на самом деле стратегия проектирования), сокеты, потоки, семафоры и т. д.

Однако я ничего не знаю о разработке драйверов Windows. Я прочитал несколько статей о KMDF, UDMF и WDM.

Я надеюсь, что здесь ответит опытный разработчик драйверов режима ядра Windows ...

В следующей ред. В нашем оборудовании есть возможность заменить микросхему FTDI и использовать либо USB-интерфейс dsPIC, либо, возможно, портировать Linux FTDI с открытым исходным кодом в Windows и продолжить использование микросхемы FTDI в нашем настраиваемом драйвере.Я думаю, что, перейдя к драйверу режима ядра на стороне ПК, я могу установить драйвер ядра, который может отправлять периодические сообщения с более точными интервалами без вытеснения и / или, возможно, используя DMA.

В нашем бизнесе есть конкурент, который, я думаю, делает то же самое со своими инструментами. Насколько мне известно, приложения пользовательского пространства не могут планировать поток лучше, чем 1 мс. В настоящее время мы используем timeGetTime в потоке. Я экспериментировал с очередями таймера (через CreateTimerQueueTimer) без особого улучшения.

Является ли WDM правильным подходом для достижения более точной синхронизации?

Наш конкурент каким-то образом добивается очень точной синхронизации сигналов, управляемых Windows, на свое оборудование, и они загружают драйвер ядра (.sys), и их устройство выходит из строя USB2.0, как и наш.

Если WDM - лучший вариант, могу ли я посоветовать, какие функции ядра мне следует изучить для настройки таймингов? Спасибо за чтение