Внешние недорогие граф контроллер для ARM, Давайте выстроим возможные варианты Опции

[asen]

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

[asen]

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

[SasaVitebsk]

Вариант конечно вариант не как то не совсем правельный с стороны классики ....

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

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

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

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

[Dog Pawlowa]

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

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

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

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

[SasaVitebsk]

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

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

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

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

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

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

Человек слаб и никогда наперед ничего не делает.
Т.е. все равно придется два проекта править.

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

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

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

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

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

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

[Dog Pawlowa]

Вы меня не поняли, так как не совсем представляете. Либо я вас не совсем понял.

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