Есть некий контроллер дисплея. Есть проц который пишет картинку в память контроллера. Контроллер отображает с какой то своей частотой.

Собственно есть несколько вариантов
1. Проц пишет со своей скорость, контроллер отображает со своей.
2. Проц знает частоту обновления и обновляет данные синхронно с отрисовкой

Собственно подскажите есть ли какие то типовые паттерны для обоих случаев которые стоит писать в память чтобы наглядно убедиться в наличии заданных FPS. А в идеале чтобы можно было их измерить например +/-5 FPS пойдёт.

Примерно как умудряются отображать гамму дисплея рисуя чёрно белые полосочки.
Вот может уже всё придумано до нас?

Вам надо померить FPS без дополнительных датчиков (фотодиодов)?
Например так:
Допустим - известно, что видеопамять выводится построчно (т.е. - сперва 1-я, строка, потом - 2-я и т.д.).
Изначально экран пустой - заполнен 0-ми. МК с фиксированной скоростью (прерывания и прочие процессы все выключены, есть только один процесс рисования) в первом проходе цикла выводит столбец байтов 0xFF, затем сразу же этот же столбец во 2-м проходе заполняет нулями.
Скорость вывода столбца должна быть больше скорости экранной развёртки (за время одной развёртки МК должен успеть заполнить 0xFF, а затем заполнить 0-и этот столбец).
Данный процесс повторять периодически с интервалом примерно в 2-3 экранных развёртки.
На экране будет наблюдаться мерцающий вертикальный столбец, перемещающийся по вертикали (из-за разности начальных фаз отрисовки контроллером экрана и CPU).
Меряем линейкой высоту столбца на экране и из неё, зная скорость отрисовки CPU, получаем частоту развёртки.
Если знать начало развёртки видеоконтроллером (по какому либо сигналу), то привязав отрисовку CPU к этому сигналу, можно получить статичный, а не плывущий по экрану столбец.
Даже если не знать начало развёртки кадра, то можно, варьируя задержку между циклами отрисовки (на небольшую величину), добиться малой скорости смещения столбца, так чтобы померить его было удобно.
Также можно линейку нарисовать в соседнем столбце (пикселами).
Примерно так.

PS: Да - и при чём тут "Аналоговая техника"??? Вроде есть спец. ветка по устройствам отображения.

Ага именно так. И желательно без пересчёта тоже ))
Т.е. по сути мы включаем столбец на некоторое время и смотрим сколько строк успел отрисовать экран за кадр? Хитро...
Упс... не нашёл подходящий раздел . Модераторы перенесите тему плииз в нужный раздел.

Да. Основная идея: измерение разницы частот кадровой развёртки и рисования CPU. Поэтому скорость рисования CPU должна быть фиксированной. Далее время рисования измеряем таймером и вычисляем частоту развёртки. Можно придумать разные вариации этого метода.

А в качестве таймера используйте песочные часы. Меняя количество песка в них можно синхронизировать частоту кадров/развертки с часами. Остается только создать механизм переворачивания песочных часов по кадровому импульсу.
Ну и решение из прошлого века - почему нельзя просто измерить частоту кадровых/строчных импульсов?

С какой частотой выдает картинку контроллер, знает осциллограф по сигналам развертки.
С какой частотой процессор загружает, это можно тоже на контрольную ножку сигнал вывести.

Исходя из условия. А Вы знаете какой там контроллер? А если это капля компаунда на стекле?


Зачем?

А если устройство зарыто на Луне?

Пусть ТС доложит. Думается, все же нет.

Проверить в реальной работе.

Вот именно. И в реальных условиях.

Несколько причин.
1. В дисплее не выведена сия ножка. Т.е. есть только интерфейс от проца к памяти. Между памятью и дисплеем влезть осциллографом низя
2. Заказчику хотелось бы показать нечто наглядное.
3. Хотелось бы показать не только то что дисплей может выводить статическую картинку с нужной частотой но и то что данные меняются с той же частотой.

В статусе контроллера дисплея есть флаги, я так думаю. Vertical non-Display period status.
Вообще-то, программист сам задает частоту работы контроллера жки. Зачем ее проверять? Раз влезть, есть очень надо, удостовериться, и шабаш.

Увы нет такого флага. Частота обновления вычисляется как по некой формуле от штук 5 переменных которые пишутся в разные регистры. (чем то похоже на PLL). И что там получилось на выходе можно только гадать. То ли не ту циферку записал то ли ещё где ошибся.

Но готового числа обратно он не отдаёт.

Так в этом и вопрос. Как проверить то что программист напрограммил? Как показать это заказчику?

Так просто - если изображение есть и не мерцает, значит герц 50 - 60 имеется. А больше и не надо. Я попробовал камерой мобильника глянуть, может, биения частот будут видны. Но нет, у меня не видно.
P.S. А мерцание хорошо боковым зрением наблюдать.

Длительность операций CPU намного удобнее (и точнее) измерять по таймеру.


И не будет видно даже если там не 50-60Гц. Если конечно у ТС не ЭЛТ-экран


Мой способ испытали?

Будет. Я видел (мерцание).

Нет ещё. Пока картинки нету ещё. Это я заранее собираю информацию чтобы понимать что делать. Что можно, а что не получиться.

Это ничего, кто-то и летающие тарелки видит

В данном вопросе эксперимент может сделать каждый, кто программировал контроллер TFT ЖКИ. Увеличиваете задержки в тех самых управляющих регистрах, наблюдаете мерцание. А если включить логику и подумать, зачем нужно регулярно обновлять изображение на ЖКИ, то и без эксперимента понятно.

мультиплексором. он и будет задавать развертку.
а если увидеть в мониторе, то даже в DVI сигнале есть интервалы "гашения".... но хз. как эти интервалы выглядят на осциллографе, потому что цветопиксельные данные кодируются средневзвешенным кодом.

Что касается программирования, в некоторых ОС, при некоторых драйверах возможен синхронный блит, или перключение фреймбуфера. Виндовз-ДХ это теоретически позволяет, фича есть в играх и видеоплеерах. Но на практике не всегда работает так как ожидается.

Т.е. по сути мы включаем столбец на некоторое время и смотрим сколько строк успел отрисовать экран за кадр?
не выйдет. афаик, буферы дисплеев как правило односторонние. да и на обычной PC борде в асинхронной ОС это невозможно. Но можно посчитать количество переключений буфера и поделить.

А тупой, но надёжный способ съёмки видеокамерой 1000 fps предлагался?

Почему?


Каким образом посчитать? И с чего Вы вообще взяли что в контроллере автора есть какие-то "переключения буфера"?

)))))))))))) ха ха ха )) Отличный вариант )




Буфер там один. Но судя по описанию двухпортовый. Один порт процу для записи. Второй порт контроллеру для обновления экрана.

Некоторые мобильнички и фотики Sony умеют снимать 960 кадров в секунду. Недолго, но вам хватило бы с лихвой.

Не знал. Спасибо

https://www.youtube.com/watch?v=k3MbV3SQrY4

рекурсия. см. пред. объяснение.

Где?? От вас не было ни одного объяснения, ни пред. ни посл.

вам все вынь да в рот положи
не выйдет. афаик, буферы дисплеев как правило односторонние.
вы не сможете узнать тот момент когда дисплей нарисовал кончик линии, которую вы туда отправили.
но зная устройство любого устройства, будь то адаптер, или контроллер матрицы, вы можете попробовать выловить технологические сигналы. но поскольку это непродуктивно - правильно самому задавать необходимую развертку.
если вас терзает вопрос, а как у nVidia, то ответ простой - они достают развертку из собственной схемы кодера фреймбуфера, считая что монитор не слишком тупит на отрисовку. Возможно что-то они корректируют, общаясь с монитором по DDC... хотя сомневаюсь. правильные мониторы сертифицируют соотв. наклейкой.