К процу at91sam9263 надо подключить две TFT панели. Обе 7" 800x480, т.е. одинаковые. Есть 2 вида: LVDS и 18-бит. В принципе проц должен отрисовать требуемое разрешение, только хочется понять как это можно сделать чисто технически. Может быть надо ставить внешний графический контроллер (или 2 таких). Или можно обойтись внутренним?

Какие будут идеи?

Если не хотите ставить еще один графический контроллер, то можно прикрутить снаружи ПЛИС для преобразования 1600x480 в два по 800x480. Только чтобы делать правильно и красиво потребуется память на две строки.

Ну, и приготовьтесь к некоторым тормозам.

Не понял в каком режиме будут работать эти панели? - в clone или span?




обратите внимание не на максимальное разрешение, а на частоту (dotclk) с которой надо будет отрисовывать 60Гц.


p.s. для lvds интерфейса - что все сигналы передаются парой? или имеется ввиду serdes?

Частота для 1600x480@60 получается не страшная - 59,64MHz всего. А вот разрешение такое держать умеют далеко не все.

На двух экранах будут разные картинки. Можно и ПЛИС поставить. Только как работа этой ПЛИС будет согласована с фрейм-буфером? В смысле фрейм буфер то линейный. Он будет 1600х480, как бы одна большая картинка. А дальше что?

Про LVDS: будут стоять либо пара LVDS либо, пара 18бит.

Очень просто: организуем в ПЛИС два буфера на строку, в один пишем, из другого в это время выдаем одновременно на два выхода.

А почему не поставить заместо одного 9263 два 9261? Выйдет дешевле, чем ставить граф контроллер, или 9263+ПЛИС. И по скорости вывода будет выигрыш.

Если цена не имеет решающего значения, и хочется простых путей, то можно взять два ТФТ-Компаньона и повешать их на любой МК с ИФ SPI. Если, конечно, видео гнать не надо.

Есть живой модуль с процессором 9263 (sbc-9263), потому будет в любом случае дешевле, чем разводить многослойки для БГА.



Видео гнать не надо. Но надо будет рисовать всякие стрелочные приборы и прочее. Потому хотелось воспользоваться библиотекой Qt или gtk. А с этим компаньеном придется еще и драйвер под Линукс писать соответсвующий. Не вижу где тут экономия. Сэкономили на железке, зато оплатили труд программисту? Или я не прав?

Если изделие единичное - тогда конечно не имеет смысла заморачиваться. Только 9263 под линуксом может недостаточно шустро ворочать экраном разрешением 1600х480, даже если разрулить проблему с регенерацией на два экрана. Но тут все зависит от того, сколько данных ему нужно обрабатывать и в каком темпе выводить.

1600x480 это даже меньше, чем 1024x768. Если использовать отдельную шину памяти для экрана и <=16bpp, то все может не так уж и плохо.

Изделие не единичное. Минимум 100 штук будет выпущено. Правда, если всё заведется как надо.

Посчитайте пропускные способности шин на всем пути передачи данных кадра. Может оказаться, что узкое место будет, например, в SDRAM или во внутреннем DMA.

а "насколько лучше/легче" станет ядру, если для frame buffer навешать отдельную PSRAM на EBI1 как в атмеловской отладочной плате?

в смысле мипсов то он добавляет
"and can increase available CPU MIPS by 20% to 40%"

а как это улучшает usability (торможение прорисовки новой картинки) на экране 800*480*16bpp

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