Думаю, не в USB-канале мыши дело. СОМ-портовая вызовет то же самое, просто тягать окна -- занятие затратное, 100% мощи небось занимает, а запросы хост-контроллера в очень вероятном режиме Bulk не шибко приоритетны, причём одноразовые, Дельфи не достаётся управление, он не запрашивает данные у драйвера, тот не пинает контроллер, тот не лезет к девайсу...
Период опроса просто получается увеличенным, и если USB-девайс не готов к такому развитию событий, что-то может поехать. Особенно, если он не тупо считает -- ждёт -- отвечает, считает -- ждёт -- отвечает... Хотя в первом посте вроде всё просто.
Точки типа Interrupt опрашиваются регулярнее и с большим приоритетом, где-то я читал, что мыши через них работают и через HID-репорты, но опять же, если Дельфи тормозит, то не факт, что получит все данные, вдруг эти Interrupts затирают более старых собратьев.
Как запрет прерываний USB в МК может что-то испортить, я не знаю -- лично бы их и не запрещал, просто имел ячейку (глобальный массив) с текущим последним насчитанным значением (считать непрерывно, не глядя на прерывания, и скидывать в ту самую ячейку), по прерыванию высовывал бы из неё в шину пакет -- так подозрения с МК снимутся полностью. Только запрет нужен ненадолго -- на перепись насчитанного из локального буфера в глобальную ячейку "для прерывания", чтобы в хост не ушло наполовину обновлённое очень изредка и не организовало трудноуловимые глюки.
Сейчас можно пытаться снифферить обмены по USB (софт для этого в недалёкой ветке
Интерфейсы вполне достаточен, в отличие от моих запросов) и глядеть на времена запросов из хоста и ответов от МК. Если прерывания запрещены, то какое-то прерывание или пару МК может прозевать, но его контроллер должен сам ответить NACK, если его выдающий буфер пуст или прерывания запрещены. Боюсь, что по прерыванию пихать что-то в буфер уже поздно (хотя надо читать доки), и запихнутое пойдёт в хост на следующем цикле опроса, хотя может быть и "умный" ответ NACK-ом -- если выходное ФИФО не трогается 1000 тактов от начала прерывания, то выдаётся NACK, иначе уж придётся терпеть до наполнения нужного уровня и пинка на передачу. USB-контроллер не должен долго ждать ответов, у него очередь на опросы по 10 девайсов каждую миллисекунду! А если мы ещё в отладчике остановимся, да будем глядеть на процесс ответа ?..
Также можно возвращать из МК для Дельфи в том же самом пакете значение внутреннего таймера, считанное в момент прерывания. Если прерывания не запрещены, мы в хосте получим все моменты, когда его контроллер что-то хотел от нашего девайса, для анализов. И если сниффер включен, то и с его данными ещё совместить времянки...
Хостовый рецепт -- использовать комп с несколькими ядрами и Дельфи пускать на последнем (функция примерно SetAffinity()), приоритет потока ему задрать посеръёзнее -- 0-му ядру это не помешает, где обычно сидят все драйверы и обработка прерываний, а наше приложение получит воздуха побольше. Но только б не загнать проблему вглубь и не спрятать, в совсем редкие глюки ! Я обычно советую наоборот -- вытягивать её на свет Божий и анализировать, можно и комп похуже ради этого найти, под Safe Mode загрузиться без оптимизированных драйверов, кэш выключить в БИОС, чтоб и на этом всё обострилось, а все предпринимаемые шаги тоже лечили.
Как активность ПК влияет на работу МК STM32F207 ?, влияние по USB
Sep 10 2014, 10:39
