Обновить
0
Alexander Belousov@belav

Пользователь

5
Подписчики
Отправить сообщение

Есть классы для uart, spi, can. К примеру, для urat сделан modbus rtu, wake.

Одно дело пользоваться этими структурами в пользовательский части кода, другое дело, когда они спрятаны внутри классов.

Ок. Буду готовить следующую.
Спасибо, это только начало.
да, реализовывал тройную, когда работал с tms320dm643. делал для камеры и для дисплея.
Я хочу сказать, что главное преимущество тройной буферизации — это повышение FPS.

нет. это упрощение синхронизации.
не относится к оптимизации FPS.

да, не относится к оптимизации, а относится к невнимательности или непониманию принципов формирования кадров.
Разве тройная буферизация всегда исключает необходимость проверки вертикального бланка? Если у вас ЦПУ отрисовывает кадр всегда быстрее, чем контроллер дисплея грузит кадр в экран, то тройная буферизация теряет смысл перед двойной буферизацией. Ну и, собственно, когда контроллер дисплея всегда быстрее грузит кадр нежели система его отрисовывает та же история. При этом, я понимаю как это может помочь «в среднем». Вы же читали обсуждения про тройную буферизацию выше (случаи когда кто-то из ЦПУ или LTDC быстрей)? Было бы интересно вас выслушать.

1. один буфер используется, когда поцессор успевает отрисовать кадр во время бланка (вертикального) или перерисовывается малая часть кадра, не заметная для глаза
2. два буфера используется, когда процессор не успевает отрисовать кадр во время бланка. при этом отрисовка нового кадра начинается, когда освободился буфер. т.е. программа (поток) отрисовки должна ожидать.
3. тройная буферизация используется когда идет непрерывный поток формирования кадров (например, камера или Ваш случай, где пытаетесь достичь много fps)
да, я читал выше про тройную буферизацию. там за бланками следить не надо, только контролеру видео сообщить, с какого адреса начинать следующий кадр.
почитайте как делается тройная буферизация, там не сложно. главное, не запутаться какой буфер на вывод, какой в очереди, а какой свободный.

Можете пояснить? Казалось бы, ни один их этих способов не должен зависеть от соотношения скоростей формирования кадра/отображения кадра. При любом соотношении, оба способа должны давать адекватную картинку (без дрожания), ведь переключение буферов в обоих методах происходит исключительно внутри VBLANK.

я код не видел, из контекста понял, что Вы формируете кадры не синхронно с выводом и переключением буферов (см. выше п.2)
У нас в этом примере только графическое приложение исполнялось. Помимо этого разве что системный таймер. Поэтому полученные 85 FPS это когда система только графикой и занимается. Если экран 60 Гц, то можно прикинуть какая часть свободного времени остается.

ну, тут у каждого свое мнение.
Ну, если изучали, тогда бы не было:
Обсудив ситуацию, мы решили отложить унификацию до более глубокой проработки графического стека.

Попробуйте сделать тройной буфер, как рекомендовали выше. Это классика. Тогда не будет проблем с маленькими или большими разрешениями. И не надо ловить «обратный ход луча» или как принято сейчас называть — «вертикальный бланк».
Ваш первый способ (с переключением слоев) работает только, когда скорость формирования кадра выше скорости вывода, второй (переключение буферов) — наоборот.
Возможно, это мое мнение, но fps замерять не очень корректно, более правдиво — время, затраченное на формирование кадра. Тогда можно оценить свободное процессорное время для других задач.

Может, надо сначала внимательно почитать документацию и теорию, а потом экспериментировать? Что Вы в итоге измеряли: пропускную способность памяти? Скорость DMA?

12 ...
13

Информация

В рейтинге
Не участвует
Откуда
Санкт-Петербург, Санкт-Петербург и область, Россия
Дата рождения
Зарегистрирован
Активность