Доброго времени суток.
У меня возник вопрос. В некоторых топиках проскакивали различные мнения, поэтому хотелось бы проконсультироваться у знающих.

Итак имеется LPC2478 + SDRAM + TFT. SDRAM подключено ч/з шину 16 бит. Читал мнение, что в таком случае нет смысла подключать TFT по 8-8-8, так как шина 16 бит. Возникает и другой вопрос. Целесообразно ли обрабатывать одновременно 2 точки в варианте 5-6-5? Вроде как всё равно операция будет выполнена не одновременно. Но с другой стороны, я читаю в даташите, что есть буферизация на запись/ чтение. С учётом параллельной работы TFT, всё это сложно оценить теоретически. А аппаратно можно, но нехочется заморачиваться, наверняка кто-то это уже проделывал и может быть подскажет?

Заранее спасибо.

Что есть обрабатывать? и Что есть одновременно?

Странное мнение. Если хватает пропускной способности шины, то всё можно.
Калькулятор загрузки шины

При работе в режиме 5-6-5 точка занимает 2 байта. Я могу записывать 4 байта одной операцией. То есть сразу 2 точки.
Например при выводе изображения, при заливке, при выводе линии и т.п.
В целом, в GUI придётся переписать некоторые примитивы графические.
Вопрос какой выигрыш это даст?

При работе с графикой во внутренней памяти на другом контроллере с аналогичным ядром (без контроллера TFT), это даёт существенный выигрыш.



Спасибо большое. Весьма наглядно.

Пробовал и 16 и 24 битный цвет.
Разница по скорости на ТЕСТАХ - ожидаемая.

А вот в реальном приложении доля графики очень низкая. Скажем, 24 битный цвет - 5%, 16 битный - 2.5% (Очень грубо). Как бы не стоит борьбы такой выигрыш. А вот картинки все кругом 24 битные. И градиент намного лучше 24 битный.

Разумеется, если мультики крутить - то да. А так - я бы оставил 24 бита.

Память у меня тоже 16 разрядов.

----

ЗЫ. Графика такого рода. 4 штуки индикатора типа бар на 256 градаций, цифровые часы, аналоговые часы с секундной стрелкой, число на экране, которое постоянно меняется - 8 разрядов шрифта 40 на 35 точек со сглаживанием.

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

Подтверждаю,ваш сжиматель очень даже работает на ура, делал в двух проектах ,хамелеон и термометр с песиком. Даже запускал картинку на lpc 2478, когда подключал ее к ТВ. Но вот на армах нужно разрешение картинки от 320*240, а мне уже и стыдно у вас просить.

Качайте с предыдущего топика последний релиз ,будет Вам 320*240

Для такой графики как вас палитрового цвета хватило бы с запасом. У меня аналогичная система, плюс еще несколько статических картинок. Для шрифтов со сглаживанием достаточно 5-6 уровней, а если 8 сделать, то дальнейшее увеличение никакого улучшения не дает.

Размер в пикселях, простите упустил. 480х272. Дисплей 4.3".

В первом варианте использовался стартеркитовксий комплект. Там стояла 8-бит SRAM. Я не додумался, что можно реализовать 5-6-5, так как дисплей физически был подключён 8-8-8. Я его и ввалил как 8-8-8. Согласно расчётов на предложенном калькуляторе загрузка шины при этом превышает 100%. ))
В графике у меня пару самопальных (требование) слайдеров, тексты меняющиеся и 3 ряда картинок 48х48. Это на основном экране. На следующем - полноценная гуёвина со всеми атрибутами, только без TS.
Часть пиктограм расположена на фиксированном месте экрана - часть как бы с вставлением (то есть, кпримеру, при удалении картинки перерисовываются все последующие). Есть картинки, которые могут "моргать", по принципу светодиода, с частотой 1Гц.

Была реализована первая часть. Вот это моргание и выглядит х@..., короче плохо. Пока первое изделие катается на новом навороченном автобусе МАЗ, я приобрёл второй комплект стартеркит и делаю на нём гуёвину. Там уже стоит SDRAM 16 бит. Дисплей подключил 5-6-5. При такой конфигурации загрузка шины составляет ~30%. Гуёвина работает отлично. Пока лишь мелкие претензии. Я её очень сильно перелопатил. Нашёл и устранил некоторые ошибки. Написана в лоб. Я думаю что смогу оптимизировать вывод картинок ~ на 30%, текста более чем на 50% и примитивов ~ 15-20%. Времени на работу мало. Первая часть написана за 2 месяца, при том, что графика там совсем не основное. Вот я и оцениваю насколько нужна такая работа. И насколько она нужна сейчас. ))

8-8-8 более удобно. Ибо там пиксель 32 разрядный на самом деле.
В 16 разрядном надо будет тратить время на упаковку распаковку. Небольшое, мизерное, но придется.

Чтоб не моргало (в моем случае секундная стрелка часов), вставил перед обновлением ожидание обратного хода луча.
У меня тоже 480 на 272.

Я тоже сначала опасался. Но потом даже в шрифты вставил реалтайм эффект (типа, выпуклости вогнутости). Т.е. оборзел. И ничего.
Самое главное, на самом деле, организовать все так, чтобы все процедуры, когда им нечего делать - отдавали управление следущему. Тогда времени хватает...

У меня данные не поступают извне. Таким образом никаких упаковок/ распаковок делать не придётся. Картинки хранятся в виде монохромных. При выводе я оцвечиваю. Также и с гуёвиной, что в общем стандартно. То есть упаковка цвета осуществляется на этапе компиляции и при исполнении не влечёт доп расходов. При формировании картинки я могу одной операцией выводить 2 точки.

Можно пример ожидания, пожалуйста.