Скорость вывода пикселей на TFT 3.5" 320x480 (ili9486)?

[Donker]

Ну вот например я читаю датащит, вижу что разработчик протокола интерфейса экранчика не считает быстрейший вывод пикселя по случайным
координатам приоритетной задачей (заполнение потоком прямоугольного окна это полезный, но уже костыль) и я начинаю сомневаться в своей способности искать и читать датащиты!

[dkm]

Ну вот например я читаю датащит, вижу что разработчик протокола интерфейса экранчика не считает быстрейший вывод пикселя по случайным
координатам приоритетной задачей (заполнение потоком прямоугольного окна это полезный, но уже костыль) и я начинаю сомневаться в своей способности искать и читать датащиты!

Для начала вы определитесь с тем, что вы выводить собрались.
Если кино собрались смотреть, то без дополнительной памяти для буферизации вам не обойтись, практически для всех остальных случаев трудно представить какие могут быть проблемы с эти контроллером (кстати подавляющее большинство из них имеют схожий набор команд, включая попиксельное обращение)
0.4 с на экран - это очень сильно "постараться" надо, откуда вы берете индивидуальное значение для каждого пиксела? Похоже вы не очень представляете принципы работы с подобными дисплеями, это же вам не канву в винде заполнять, тут уровень гораздо "ниже".
Для GUI, вывода всяких диаграмм, в том числе в динамике, вполне себе красиво справляются, особенно если через FSMС работать.

[NewWriter]

Блин, по отдельным пикселям с заданием координат окна для каждого пикселя - это какое-то издевательство. Да, конечно, когда нет нужного размера ОЗУ в МК, когда ресурсы ограничены, когда нет места для нескольких вариантов функций вывода, или просто когда башка тупая и не варит - тогда да.
Но я уже объяснил, как что выводится. С первого раза разве не ясно? Хорошо, я повторю.

У этого дисплея с полным набором выводов довольно разнообразны варианты интерфейса. Все они расписаны в мануале, и там же приведен порядок действий и посылки байт. Вы используете паралленьную шину 8080-типа шириной 16 бит.
Для команд учитывается только младший байт шины. Для цвета вы можете использовать либо 16-битный цвет формата RGB565 (65k), либо 18-битный цвет формата RGB666 (262k). В первом случае (RGB565) вы используете все 16 бит шины и передаете цвет пикселя за один раз. Во втором случае (RGB666) вы используете так же 16-битную шину, но цвет одного пикселя передается за 1,5 посылки - старшие 6 бит в каждом байте. Таким образом, у вас скорость пиксельного заполнения падает в 1,5 раза.

Окей. С этим понятно.
Теперь по поводу передачи координат. Я уже объяснял. Отдельно каждый пиксель рисовать вам потребуется ТОЛЬКО для алгоритмов Брезенхема (загуглите, че это такое) при рисовании наклонных линий и окружностей, эллипсов.
Для остальных случаев - экономически не обосновано. И вполне решается методом установки размеров окна вывода. В частности, при выводе шрифта вам нужно установить размер окна вывода равный размеру выводимого символа и спокойно заполнить это окно. Как правило, обычно, шрифт выводится сверху-вниз, слева-направо, это связано с порядком битов в исходнике шрифта. Обычно это так.

Ладно, с этим понятно.
Если вам нужно выжать максимальную скорость заливки всего кадра дисплея, то просто выставляете размер окна вывода на размер дисплея (320 х 480) и заполняете полный кадр.
Размер кадра = 135600 пикс. При 16-битном цвете (65k) 1 пикс = 2 байта, а при 18-битном 1 пикс = 3 байта.
Теоретически вы вполне можете получить порядка 20-25 fps. Может, и больше даже.
Однако, как только вы начнете использовать неэкономичные методы с выводом по одному пикселю, скорость катастрофически упадет на порядок.
Но при построении линий по Брезенхему скорость получается хорошей, поскольку рисуется ровно столько точек, сколько есть в линии, а не весь дисплей.

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

[Donker]

Спасибо, видел.

[mike-y-k]

Donker, а памяти у Вас оперативной 320x480xN найдётся?
Нарисуйте все в ней и выпихните на экран одним потоком данных.
Для динамики можно за несколько циклов выводить…
На мелком МК (напрямую) калейдоскоп на похожем экране шёл с плавающей скоростью 15…1.5fps.