При работе с графическими дисплеями многие сталкивались с проблемой подбора графичиский сопроцессоров\контроллеров лично мне приходилось использовать только не очень шутрый и простой всем наверное известный 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 от основного проца.

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