Сделал некое устройство на STM32F207, которое обрабатывает сигнал и передаёт в ПК по USB (по виртуальному COM порту).
Фирмвара написана на базе примера для отладочной платы от STM - STM322хG-EVAL, для работы ( обмена данными ПК-МК) написана программа на делфи, драйвер - стоандартный от STM, операционка винда ХР .
Алгоритм (упрощённо) следующий:
1. Команда запроса данных- запуска измерительного цикла
2. Запрет прерывания от USB
3. Старт накопления сигнала
4. Задержка на накопление
5. Преобразование накопленного сигнала, создание массива
6. Разрешение прерывания USB
7. Передача данных в ПК и повторение цикла с п.2

Проблема в том, что пока в компьютере нет активности - всё работает нормально; стоит только на компе проявить активность (например, мышкой потаскать окно любой другой программы, не той, которая работает для обмена данными) - сразу же увеличивается время накопления сигнала (как будто МК тормозить начинает) - соответственно, имеем не реальные данные, а непонятно что.

Как активность в работе ПК может сказываться на работе фирмвары?

Мышка-то небось USB-ическая?

А запрещать прерывания USB можно? Получается, MCU не отвечает. Может, PC совсем отключает устройство от USB, а когда ответы появляются, по-новой переподключает?

Думаю, не в USB-канале мыши дело. СОМ-портовая вызовет то же самое, просто тягать окна -- занятие затратное, 100% мощи небось занимает, а запросы хост-контроллера в очень вероятном режиме Bulk не шибко приоритетны, причём одноразовые, Дельфи не достаётся управление, он не запрашивает данные у драйвера, тот не пинает контроллер, тот не лезет к девайсу...
Период опроса просто получается увеличенным, и если USB-девайс не готов к такому развитию событий, что-то может поехать. Особенно, если он не тупо считает -- ждёт -- отвечает, считает -- ждёт -- отвечает... Хотя в первом посте вроде всё просто.
Точки типа Interrupt опрашиваются регулярнее и с большим приоритетом, где-то я читал, что мыши через них работают и через HID-репорты, но опять же, если Дельфи тормозит, то не факт, что получит все данные, вдруг эти Interrupts затирают более старых собратьев.

Как запрет прерываний USB в МК может что-то испортить, я не знаю -- лично бы их и не запрещал, просто имел ячейку (глобальный массив) с текущим последним насчитанным значением (считать непрерывно, не глядя на прерывания, и скидывать в ту самую ячейку), по прерыванию высовывал бы из неё в шину пакет -- так подозрения с МК снимутся полностью. Только запрет нужен ненадолго -- на перепись насчитанного из локального буфера в глобальную ячейку "для прерывания", чтобы в хост не ушло наполовину обновлённое очень изредка и не организовало трудноуловимые глюки.

Сейчас можно пытаться снифферить обмены по USB (софт для этого в недалёкой ветке Интерфейсы вполне достаточен, в отличие от моих запросов) и глядеть на времена запросов из хоста и ответов от МК. Если прерывания запрещены, то какое-то прерывание или пару МК может прозевать, но его контроллер должен сам ответить NACK, если его выдающий буфер пуст или прерывания запрещены. Боюсь, что по прерыванию пихать что-то в буфер уже поздно (хотя надо читать доки), и запихнутое пойдёт в хост на следующем цикле опроса, хотя может быть и "умный" ответ NACK-ом -- если выходное ФИФО не трогается 1000 тактов от начала прерывания, то выдаётся NACK, иначе уж придётся терпеть до наполнения нужного уровня и пинка на передачу. USB-контроллер не должен долго ждать ответов, у него очередь на опросы по 10 девайсов каждую миллисекунду! А если мы ещё в отладчике остановимся, да будем глядеть на процесс ответа ?..

Также можно возвращать из МК для Дельфи в том же самом пакете значение внутреннего таймера, считанное в момент прерывания. Если прерывания не запрещены, мы в хосте получим все моменты, когда его контроллер что-то хотел от нашего девайса, для анализов. И если сниффер включен, то и с его данными ещё совместить времянки...

Хостовый рецепт -- использовать комп с несколькими ядрами и Дельфи пускать на последнем (функция примерно SetAffinity()), приоритет потока ему задрать посеръёзнее -- 0-му ядру это не помешает, где обычно сидят все драйверы и обработка прерываний, а наше приложение получит воздуха побольше. Но только б не загнать проблему вглубь и не спрятать, в совсем редкие глюки ! Я обычно советую наоборот -- вытягивать её на свет Божий и анализировать, можно и комп похуже ради этого найти, под Safe Mode загрузиться без оптимизированных драйверов, кэш выключить в БИОС, чтоб и на этом всё обострилось, а все предпринимаемые шаги тоже лечили.