При работе с графическими дисплеями многие сталкивались с проблемой подбора графичиский сопроцессоров\контроллеров лично мне приходилось использовать только не очень шутрый и простой всем наверное известный SED1335 но он медленно но верно погружаеться в историю
Вопрос в общем то прост есть дисплей разрешением скажем от 64х64 до 320х240 больше редко используеться в встраимых приложениях и глубина цвета от 1 бита скажем до 16 контроллер должен цепляться к чему то вроде lpc2294 или более современные аналоги вопрос какие вариатции есть на современном элементном попрыще поделитель народ опятом наша сила в сообществе как всегда хочеться подешевле и без BGA

Используйте серию процессоров LPC2468/2470/2478 со встроенным контроллером ЖКИ и в корпусе LQFP208.

Ну то что LPC2468/2470/2478 имеють встроенные граф контроллеры знают все только вот не всегда например это возможно например не хватаеть производительности или чего то в тех случаях и требуються другие решения со внешним граф контроллером

Если не хватает производительности, используйте LPC2468/2470/2478 только для задачи внешнего граф. контроллера

И что же вы реально считаете что он будет лудше себя вести чемм отдельный граф процессор ?? Какой минимальный корпус у этого процессора кажеться QFP208 ? И как его цеплять к другому процессору на шину ?? ставить 2-х портовое озу или делать программный захват внешней шины ??? Сигнала запроса шины у него нет я насколько понял ????

Если правильно подойти к решению задачи - наверняка лучше и проще. Вообще в первом своем посте я не имел ввиду какую то 8/16/32-бит внешнюю шину. Я имел в виду задачу визуализации ВАШЕГО процесса, которая оформляется в виде отдельного граф. процессора на LPC2468/2470/2478, и основную задачу на ДРУГОМ процессоре. Эти две задачи общаются по какому нить простенькому последовательному каналу...

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

Я кстати, тоже задумывался.
Для большинства приложений вполне достаточно обычного VGA-контроллера (640х480, 16 одновременных цветов из 256-цветной палитры), для этого достаточно мелкой плисины за 5 баксов, даже без внешней памяти. Хотя, может и действительно проще будет применить отдельный контроллер в качестве видеоконтроллера (правда, подороже выйдет)

Мы применяем S1D13A05F00A от Epson. У них есть много интересного:
Epson LCD Controllers

5 баксов - это половина LPC2478. Плюс место, программирование и проч. Тут главное не превысить объем внутренней памяти, чтобы для простых дисплеев не ставить внешнюю SDRAM.

Ну для "простой плисины" автор хотел в 150K (640*480*4/8) укладываться правда не знаю, где он FPGA с 150K набортной памяти за 5 баксов найдет .

Ну да, память скорее всего внешняя... Это я осознал...
Так ведь для того же епсона или ЛПЦ тоже снаружи память надо вешать, а цены - 10-20 уёв.
Хотя, давно цены не сверял, а они постоянно падают
А вообще, на 320х240 всего-то 38кБ надо

А я разделяю мнение Protoss-a. Классика то меняется...

Давайте возьмём стандартные PLC. Тот же сименс или митсубиши... На экране красота, а связь по последовательному порту. Передаются не команды процессора графическому ядру, а идёт чистый обмен "тегами", то есть данными используемыми в проекте. Иными словами работа обоих процов совершенно независима. Один обслуживает дисплей/клаву, второй процесс.
Обратите внимание, что основной проц вообще не загружен работой с экраном! Он не занимается вырисовыванием полигонов и картинок. Ему вообще по фене что там изображено.

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

Я - в дальнейшем буду данный подход использовать. При этом подходе, например такое преимущество. Стоит дисплей монохромный. Выпускаются изделия. Я переработал дисплей, вместе с интерфейсом - пошёл цвет + крассивая графика. Прога основного проца - не изменилась.

Хм, что, при работе с монохромным дисплеем у Вас все тэги управления цветностью формировались? Человек слаб и никогда наперед ничего не делает.
Т.е. все равно придется два проекта править.

При нормальной структуре ПО внутри программы отдельно прописаны все уровни взаимодействия. Например, на LPC2478 у меня внутри одного рабочего пространства три проекта болтаются для разных дисплеев. Да, еще и ориентация дисплея разная. Добавился новый дисплей - создали новый проект, перекомпилировали - и все.

Привязывать сюда аппаратное разделение более чем притянуто за уши.

Вы меня не поняли, так как не совсем представляете. Либо я вас не совсем понял. Попробую привести пример. Пример приведу простой, дабы много не писать.

Допустим я управляю конвеером. Допустим мне надо менять скорость работы конвеера, видеть текущую скорость, включать выключать конвеер, видеть включен или выключен конвеер.
Для всего этого мне нужны следующие теги (переменные):
От дисплея к CPU: Заданная скорость (2 байта). Включение привода (1 бит). Выключение привода (1 бит).
От CPU к дисплею: Реальная скорость (2 байта). Состоян. конвеера (1 бит)
Итого, с учётом округления, мне надо передавать 3 байта в одну сторону и 3 в другую.

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

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

Так что никаких тегов управления цветом - просто нет.


В данном случае это не сложнее чем править один. Они совершенно независимы.



Если притянуто за уши, тогда не нужно. Но если от этого выигрывает функциональность и ускоряется разработка? Стоимость контроллеров непрерывно падает. А потребности в оформлении с одной стороны, и в обработке процесса с другой - непрерывно растут.

Плюс при таком подходе дисплей запросто выносится на метр или 10 от основного проца.

Я же не предлагаю везде это городить. Но в некоторых случаях - просто замечательно удобно.

Да похоже туго все в этой области и все сводиться к LPC2478 и epson Я вот в свое время видел сопроцессоры от митсубиси которые кстати очень сильно превосходили эпсона. А ценник на такие вещи получаеться что ~30$ обычное дело. Где же наши друзья китайцы и куда смотрять другие производители ?? куда делись те чипы которые раньше применялись в видео картах никто не в курсе ??

Есть ещё некий Solomon Systech:
Solomon Systech
Это не совсем китайцы, это Гонк Конг. Только где купить это чудо - непонятно.

Э нет, вы не путайте. Вам ТФТ-панель нужна или аналоговый VGA? Раньше всё просто было - содержимое страницы памяти просто выгонялось на рамдак 50 (60) раз в секунду. А сейчас - столбцы, строки, мультиплекс хитрый...

На такие разрешения полно дисплеев со встроенными контроллерами. Зачем городить дополнительно внешний?

Ну чтото полноты мне как раз почти не видиться как то ! Вот знаю что в применениях типа стовых телефонов там на шлейфе разварины кристалы филипса но чтото про них на сайте ничего не нашлось А насчет соломона тож вариант ефинд выдает контакты тока нет даже приблизительной стоимости Кто знает что NXP у них есть какието чипы на эту темы ??

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

Так ведь каждый о своём. О больном.

Я вот тоже ищу что-то подобное. Только мнебы хотелось получить аппаратно законченный дисплейчик. Так сказать для визуализации данных. Ну и хотелось бы чтобы там граф библиотека была зашита (к примеру) либо что-то подобное. Применять что-то типа http://www.schemov.com/tftcomp/#Программное обеспечение - не подходит. Мне к нему ещё один контроллер придётся ставить.

Может кто подскажет подходящее решение.

Аппаратно надо чтобы контроллер + выход на дисплей по типу sharp и rs485/232. Програмно по типу Linux либо любая другая ОС с GUI.

Полная формулировка вопроса - половина ответа.
Я пока не понял, чего вы хотите. Индикатор со встроенным контроллером для регенерации изображения есть на практически любое из разрешений указанного вами диапазона. Подключайте к вашему АРМу и используйте на здоровье. Зачем самому ставить у себя не плате дополнительный контроллер?

На АРМ конференции NXP будет представлено решение для управления TFT с помощью PWM и SPI на базе высокопроизводительного МК LPC176x. Подробности будут доступны на конференции. На сегодня, по моим данным, это максимально дешевое решения для управления TFT дисплеем.

Кстати, как уважаемые думают, насколько целесообразно придерживаться нарисованной в http://www.schemov.com/tftcomp/tftcomp1_3.pdf системы команд? Если встанет задача создания подобного чуда... 

to Al Volovich
Вы не в курсе что такое граф процессор похоже на матрице находятся контроллеры для регенерации воть именно но не как не граф процессор он выполняет другие функции он как раз дает команды на регенерацию и обеспечивает доступ к своему внутреннему видео озу а дальше идут навароты типа аппаратного рисования элементарных фигур сдвигов изображений и других фич до обработки трехмерных поверхностей Безе !!!! И этот чип распологается редко на плате матрицы его приходиться ставить отдельно !
to shahr
Интересно будет посмотреть если потом у филипса появиться апликейшан по этому поводу !!!! Ведь наверно такой фокус возможен не только на LPC17
Поиски продолжаються ......

Зачем так раздражаться? Тут нет никакого противоречия. Посмотрите, например, на HX8309-A: это драйвер LCD со встроенной видеопамятью, напрямую сопрягающийся с процессорной шиной. Есть довольно много дисплеев с таким чипом внутри. Очевидно, о таких вещах речь и шла.

Я знаю, что такое графический сопроцессор (или акселератор, как угодно), мне только непонятно, зачем он нужен при использовании разрешений до 320х240. Особенно непонятно, зачем он нужен при использовании монохромных индикаторов.

А разве ктото раздражался ? Очевидно ускоритель как вы его еще назвали нужен чтобы ускорять Потому как если мы измуднимся и будем процессором проводить постоянный редрафт это будет занимать боле процессорного времени хоть и мы будем иметь дело с мизирным разрешением и мизирной глубиной цвета ! Да и складывать графические ресуночки для меню не сильно хорошо когда этих рисуночков становиться много невольно задумываешься а как же сделать все почесному по математике взять некий аналог векторного рисунка и рисовать все как раз то средствами видео контроллера тоесть из линий прямоугольников и кружков !!! да и зря вы думаете что на разряшении 128Х64 нельзя чтото изобразить действительное красивое вы видили что вытворяють на авто магнитолах на экранах там и 3д объекты плавающие и эфекты капли и что угодно ! Понятно если писать на экране слово "Вася сюда не ходи" то можно и программно сделать но это далеко не придел ! Вообще то идеей данного поста было собрать информацию для всех тут присутствующих о возможных решениях по созданию видео подсистемы ! Пока два здравых ответа которые наверное знають все это огромный LPC2478 и контроллеры от epson далеко не дешовые и не очень быстрые Что нет и правдо более вариантов ??

Осмелюсь предположить, что эти 3D объекты на экране магнитолы - не что иное, как заранее записанные ролики. Как это реализуется - понятно. К тому же рынок автомагнитол - массовый, и там можно себе позволить сделать специализированную микросхему CPU+GPU+VRAM с нужными функциями ускорения.


"Видео-подсистема" - это слишком расплывчато. Надо сужать поиск, конкретизируя требования.

Мы в свое время присматривались к Fujitsu. Правда назвать их "недорогими" можно с большой натяжкой. И корпуса в большинстве своем BGA.

Я уже рекламировал свое решение здесь на форуме, как мог, но повторюсь LPC2478. Разработка платы под 7 дюймовый дисплей завершена, сейчас будет переделываться под маленький. Как земляки, можем договориться
Но послушате автора Проводника Al Volovich'a - связываться отдельно с дисплеем и контроллером при малых партиях - геморрой, производители дисплеев постоянно что-то меняют.
Мы это проверили на себе.

Фокус возможен на всём, что даёт высокие частоты ШИМа. Правда разрешение до 320х200. Пока. По поводу аппликейшена - посмотрим, что можно сделать.

Немного не в тему, но чтобы не плодить новую... но никто не подскажет контроллер с встроенным LCD-контроллером, который позволяет работать с разрешением 1024x768, до 24bpp; тактовая частота контроллера чтобы с запасом была, мегагерц на 400-500. Ну и желательно, чтобы Linux/WinCE можно было бы запустить без излишних прыжков и танцев с бубнами =) Пока углядел S3C2450 от самсунга, OMAP3530... ну или как вариант PXA3xx. Какие еще могут быть варианты?

Для такого разрешения и WinCE лучше использовать готовый процессорный модуль на PXA от Toradex, например.

Freescale iMX37 и т.д.

1. EP9315 (ARM926, 200MHz), http://www.cirrus.com/en/products/pro/techs/T7.html
2. AU1100, AU12xx, AU13xx, (MIPS32, 300MHz...600MHz) http://www.rmicorp.com/products/alchemy.htm
3. http://www.alchemydevices.ru/Terminal%20MIPS-board.htm

недавно разработан новыи стандард для мелких дисплеи MIPI, можно ожидать что это имеет влияние как на дисплеи так и мк, т.к. вместо 18...24 проводов останется всего 4.

Видимо вы об этом. Просто хотят прикрутить LVDS к мелким дисплеям, и стандартизировать регистры и команду управления. По стандарту все равно предполагается регенерация экрана пользовательской системой.
Стандартизация в интерфейсах TFT уже давно назрела.

Интересный чип попался мне недавно в руки - PVX-522 - на его базе китайцы делают конвекторы различных видеостандартов ....
__tp://advance-tech.com.tw/product/powerView/PVX522.htm
вот только "доставаемость" просто НИКАКАЯ

PVX-522. Что-то подсказывает, что можно поинтерисоваться в КТЦ-МК... Могу ошибаться.

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

Нет его там.


Тут нужно не на тактовую частоту первым делом смотреть, а на полосу памяти: 1024x768x24 @ 60Hz займет около 250МБайт/с, что может быть фатально для производительности остальной части системы.