Может, надо сначала внимательно почитать документацию и теорию, а потом экспериментировать?
В процессе разработки все это, конечно же, изучал. Если есть какие-то замечания по делу — высказывайте. Если нет — не тратьте мое время, пожалуйста.
Измерялось FPS (frame rate). Эта характеристика зависит не только от аппаратных, но и от программных факторов. Скорость DMA и пропускная способность памятей это вещи сугубо аппаратные, все есть в документации, нечего измерять. Они конечно влияют на итоговый FPS.
Да-да, мне тоже кажется что должно быть именно в «среднем». То есть если ЦПУ будет отрисовывать кадр то быстрей, то медленней чем LTDC грузит кадр в дисплей, то они гипотетически могут шаг в шаг идти. Может быть даже буфера может быть не три, а в зависимости от FPS как-то в динамике вычисляться.
И ещё вопрос. А в контроллере есть режим с 8-битной палитрой? Могло бы уменьшить требования к памяти, если не нужна фотореалистичная графика.
Да, палитра есть. Это и правда размер видео памяти раза в 4 уменьшит. Но есть нюанс — плагин rawfb в Nuklear, который мы используем, рисует только в RGBA8888. Соответственно, поэтому настроили и LTDC на этот формат. Но вы правы, если выбрать палитру, и научиться сразу рисовать в нее, а не в RGBA8888, то экономия памяти возрастет. Да и скорость стала бы выше — можно этот буфер уже в быструю память поместить (SRAM).
обычно сама отрисовка бывает искуственно ограничена макс. количеством кадров в секунду, так как сам дисплей не сможет показывать например 200+ FPS.
Это да. Можно как программно, по идее, ограничить — по таймеру, к примеру, рисовать в отдельном потоке, так и аппаратно — через проверку статуса VSYNC или прерывание. Но тут похоже тоже надо думать, а будет ли тогда выигрыш от дополнительного буфера. Потому как если LTDC в общем случае заканчивает работу с буфером раньше ЦПУ (мы же ЦПУ искусственно ограничили), то тогда у ЦПУ всегда будет по крайней мере один свободный буфер. Короче говоря, вопрос любопытный, надо экспериментировать.
Тоесть как вы писали выше, нам надо ждать, пока LTDC дойдет до последней строчки и сменит адрес на буффер…
Так вот третий буфер позволит вам избавиться от такой задержки… И только.
Не совсем. Если я правильно вас понял, вы предлагаете после отрисовки во второй буфер, не ждать когда LTDC закончит с первым, а сразу же переходить к третьему. Это хорошо, но в таком режиме, процессор в скором времени «догонит» LTDC (т.е. окажется на том же самом буфере) и рисовать станет некуда, и все опять сведется к ожиданию как и в случае с двумя буферами.
То что всегда нужно за одно расплачиваться другим это да. Тут другое — не понятен смысл третьего буфера, который еще и накладные расходы по памяти увеличивает. Синхронизация то все равно должна быть.
Еще как рариант, сднлайте 2 небольших буффера для отрисовки в sram, и их через DMA пересылайте в будующий видимый буффер (их тоже будет 2)
Ну это уже дополнительные оптимизации :) Там еще вопрос насколько оно вообще получится в эти небольшие буферы элементы отрисовывать (к примеру, если буфер небольшой, а графический элемент «большой», то отрисовывать в него как-то кусками нужно).
А, да, там есть режим, в котором обновление shadow регистров LTDC (того же адреса, например) происходит во время VBLANK периода. То есть вы правы, это еще один способ. Но тогда нужно за VSYNC битом сделать. Не уверен, что будет выигрыш в сравнении с прерыванием. Но можно проверить.
Я думаю может получиться. Если взять какую-нибудь full-speed USB мышь (смотрю сейчас на свою), у нее есть interrupt эндпоинт с интервалом опроса 10 мс. То есть 100 прерываний в секунду, грубо говоря, что не очень-то и много. У нас на той же stm32f7 работает pjsip, а там нагрузка от прерываний по сети и прерываний аудио и DMA точно больше. То есть плавный drag'n'drop мышкой кажется вполне реальным. Но это все в теории, точно ответить можно, конечно, только после экспериментов.
:)
Тут еще от размера видеопамяти (и, собственно, экрана) зависит. Когда перешли на 800x480 получили 25 FPS. Но в целом да, тоже удивились когда на микроконтроллере хорошего FPS около 60-70 достигли.
Для Калмана, кажется, брались данные с гироскопа и акселерометра, потом в дополнение и e-compass прикручивал (он есть на stm32f3-discovery ). Составлялась система, для оценки коодинат x и z. При помощи фильтра Калмана как раз боролись с помехами в значениях координат, чтобы поточней угол наклона определить.
Здравствуйте! Под ESP32 пока не планировали. Но если найдем время, то обязательно попробуем, такие мысли были (но пока сильно ограничены во временных ресурсах).
Кажется из dts этот адрес уарта было не достать так просто, он выражался через адрес gpio (надо бы проверить), плюс там ещё есть и другой уарт (который mini) и важно не перепутать, а тут сразу получаешь финальный адрес. Но в целом Вы правы, и я согласен, мы тоже часто смотрим в дтс :)
Пока решили упростить qpa плагин, дабы не тащить ничего лишнего. Но вероятно попробуем linuxfb как только начнём добавлять поддержку прерываний от touchscreen'а для примеров с виджетами. Пока не смотрели как там прерывания пробрасываются в qt по-хорошему (какой-то плагин с мышью и клавиатурой у нас есть, но весьма костыльный).
В процессе разработки все это, конечно же, изучал. Если есть какие-то замечания по делу — высказывайте. Если нет — не тратьте мое время, пожалуйста.
Измерялось FPS (frame rate). Эта характеристика зависит не только от аппаратных, но и от программных факторов. Скорость DMA и пропускная способность памятей это вещи сугубо аппаратные, все есть в документации, нечего измерять. Они конечно влияют на итоговый FPS.
Да, палитра есть. Это и правда размер видео памяти раза в 4 уменьшит. Но есть нюанс — плагин rawfb в Nuklear, который мы используем, рисует только в RGBA8888. Соответственно, поэтому настроили и LTDC на этот формат. Но вы правы, если выбрать палитру, и научиться сразу рисовать в нее, а не в RGBA8888, то экономия памяти возрастет. Да и скорость стала бы выше — можно этот буфер уже в быструю память поместить (SRAM).
Это да. Можно как программно, по идее, ограничить — по таймеру, к примеру, рисовать в отдельном потоке, так и аппаратно — через проверку статуса VSYNC или прерывание. Но тут похоже тоже надо думать, а будет ли тогда выигрыш от дополнительного буфера. Потому как если LTDC в общем случае заканчивает работу с буфером раньше ЦПУ (мы же ЦПУ искусственно ограничили), то тогда у ЦПУ всегда будет по крайней мере один свободный буфер. Короче говоря, вопрос любопытный, надо экспериментировать.
Не совсем. Если я правильно вас понял, вы предлагаете после отрисовки во второй буфер, не ждать когда LTDC закончит с первым, а сразу же переходить к третьему. Это хорошо, но в таком режиме, процессор в скором времени «догонит» LTDC (т.е. окажется на том же самом буфере) и рисовать станет некуда, и все опять сведется к ожиданию как и в случае с двумя буферами.
Ну это уже дополнительные оптимизации :) Там еще вопрос насколько оно вообще получится в эти небольшие буферы элементы отрисовывать (к примеру, если буфер небольшой, а графический элемент «большой», то отрисовывать в него как-то кусками нужно).
Я знаю только про line interrupt. Его можно запрограммировать, к примеру, на последнюю строку, это да. Вы не про него?
Два буфера и используется. Один для отрисовки сцены приложением, второй для LTDC. А заранее это когда?
Было 60 FPS, увеличили размер видео памяти в 3 раза и получили 25 FPS. Или вы про что-то другое?
Тут еще от размера видеопамяти (и, собственно, экрана) зависит. Когда перешли на 800x480 получили 25 FPS. Но в целом да, тоже удивились когда на микроконтроллере хорошего FPS около 60-70 достигли.
Для Калмана, кажется, брались данные с гироскопа и акселерометра, потом в дополнение и e-compass прикручивал (он есть на stm32f3-discovery ). Составлялась система, для оценки коодинат x и z. При помощи фильтра Калмана как раз боролись с помехами в значениях координат, чтобы поточней угол наклона определить.
Кажется из dts этот адрес уарта было не достать так просто, он выражался через адрес gpio (надо бы проверить), плюс там ещё есть и другой уарт (который mini) и важно не перепутать, а тут сразу получаешь финальный адрес. Но в целом Вы правы, и я согласен, мы тоже часто смотрим в дтс :)
Пока решили упростить qpa плагин, дабы не тащить ничего лишнего. Но вероятно попробуем linuxfb как только начнём добавлять поддержку прерываний от touchscreen'а для примеров с виджетами. Пока не смотрели как там прерывания пробрасываются в qt по-хорошему (какой-то плагин с мышью и клавиатурой у нас есть, но весьма костыльный).