Здравствуйте. Есть прибор на базе STM32. На нем реализовано устройство которое передает на комп данные с частотой не менее 200 пакетов в сек. по протоколу HID. По сути все просто пара датчиков. Размер пакета 32 байта. Частота рассчитана на уровне железа, длина пакета 32 байта и отправка каждые 5 мс итого 200 фпс. Сбор пакета занимает максимум 1мс.
На компе есть программа которая эти данные принимает и выводит частоту получения.
Прием данных организовал через стандартные функции WinApi
public static bool ReadReport(IntPtr HidDeviceObject, byte[] InputReport, HIDP_CAPS Capabilities, ref uint NumberOfBytesRead)
{
bool result = false;
if (HidDeviceObject != IntPtr.Zero)
{
CancelIo(HidDeviceObject);
result = ReadFile(HidDeviceObject, InputReport, Capabilities.InputReportByteLength, ref NumberOfBytesRead, 0);
}
return result;
}
Но наблюдается какое то странное поведение. На стационарном компе Windows 7 программа показывает нормальную скорость в 200 фпс. Ту же самую прогу и устрйоство ставим на 10 и скорость падает до 60 фпс. Еще отмечу что это ноутбучная система.
Кто может подсказать что не так с этйо десяткой?? В плане ппроизводительности ноутбук достаточно матерый. 6 ядер. 16 гигов. План производительности выставлен максимальный.
Может у семерки еще где нибудь настройка для скорости?
А это именно фпс, то есть что-то рисуется, или просто пакеты/сек?
Если первое, то наверно стоит отвязать скорость рисования от приема пакетов — рисовать реже, новые пакеты полученные за это время.
Монитор же все равно вряд ли 200 Гц.
Под фпс понимается скорость передачи пакета. В пакете 32 байта.
на отрисовку не влияет потому что это данные акселерометра, гироскопа и тд. Но требуется именно 200 раз в секунду определять положение.
Причем проблема как я понял только с Windows 10. На младших версиях стабильно 200 выдает.
Ну так это 200 мс на сборку всех пакетов, итого 1,2 секунды на все. Может в этом все дело?
И еще, предположительно. Защитник оси может вносить задержки. Ведь устройство общается с ПК по USB. Точнее ПК опрашивает устройство, но не в этом суть.
Так ведь дескрипторами прописана жесткая работа с железом. USB ведь достаточно жесткий протокол. Шаг влево - расстрел и отказ в обслуживании. Причем поковыряли в биосе, отключили Power Control и чудом стало 200. Но основная причина так и не понятна.
код приема:
while (!StopProces)
{
Thread.Sleep(2);
if (WinApi.ReadReport(device, data, DevCapatibylity, ref readed))
{
// конвертация и вывод в поля ..
}
}
Верно, это только сборка. А еще опрос устройства каждые 5 мс, и так 200 раз = 1 с.
1 с + 0.2 с = 1.2 с. Такая вот математика.
Но это все фигня по сравнению с тем что люди написали относительно обновления, ссылка предыдущего поста.
Там один пользователь жаловался на серьезные тормоза в работе клавиатуры и мышки после установки пакета. Это видимо и есть истинная причина. С новой фичей новый баг от Microsoft.
ОС Windows не является системой реального времени. Поэтому ждать от неё адекватных задержек при работе с железом - это просто вера в лучшее и светлое Может повезти, а может - нет.
для доказательства этого раньше очень просто поступали - запускали в отдельном окошке форматирование дискеты и всё, всё подвисало - винда занималась только этим.
Может повезти, а может - нет.