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

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

Ну, и приготовьтесь к некоторым тормозам.
abcdefg
Цитата(hwdev @ Jun 4 2008, 11:19) *
К процу at91sam9263 надо подключить две TFT панели. Обе 7" 800x480, т.е. одинаковые.


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


Цитата
В принципе проц должен отрисовать требуемое разрешение, только хочется понять как это можно сделать чисто технически.
Какие будут идеи?


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


p.s. для lvds интерфейса - что все сигналы передаются парой? или имеется ввиду serdes?
aaarrr
Цитата(abcdefg @ Jun 5 2008, 14:09) *
обратите внимание не на максимальное разрешение, а на частоту (dotclk) с которой надо будет отрисовывать 60Гц.

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

Про LVDS: будут стоять либо пара LVDS либо, пара 18бит.
aaarrr
Цитата(hwdev @ Jun 5 2008, 22:25) *
На двух экранах будут разные картинки. Можно и ПЛИС поставить. Только как работа этой ПЛИС будет согласована с фрейм-буфером? В смысле фрейм буфер то линейный. Он будет 1600х480, как бы одна большая картинка. А дальше что?

Очень просто: организуем в ПЛИС два буфера на строку, в один пишем, из другого в это время выдаем одновременно на два выхода.
Al Volovich
Цитата(hwdev @ Jun 4 2008, 13:19) *
К процу at91sam9263 надо подключить две TFT панели. Обе 7" 800x480, т.е. одинаковые. Есть 2 вида: LVDS и 18-бит. В принципе проц должен отрисовать требуемое разрешение, только хочется понять как это можно сделать чисто технически. Может быть надо ставить внешний графический контроллер (или 2 таких). Или можно обойтись внутренним?

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

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

Если цена не имеет решающего значения, и хочется простых путей, то можно взять два ТФТ-Компаньона и повешать их на любой МК с ИФ SPI. Если, конечно, видео гнать не надо.
hwdev
Цитата(Al Volovich @ Jun 7 2008, 07:36) *
А почему не поставить заместо одного 9263 два 9261? Выйдет дешевле, чем ставить граф контроллер, или 9263+ПЛИС. И по скорости вывода будет выигрыш.

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

Цитата(Al Volovich @ Jun 7 2008, 07:36) *
Если цена не имеет решающего значения, и хочется простых путей, то можно взять два ТФТ-Компаньона и повешать их на любой МК с ИФ SPI. Если, конечно, видео гнать не надо.


Видео гнать не надо. Но надо будет рисовать всякие стрелочные приборы и прочее. Потому хотелось воспользоваться библиотекой Qt или gtk. А с этим компаньеном придется еще и драйвер под Линукс писать соответсвующий. Не вижу где тут экономия. Сэкономили на железке, зато оплатили труд программисту? Или я не прав?
Al Volovich
Цитата(hwdev @ Jun 8 2008, 04:09) *
Есть живой модуль с процессором 9263 (sbc-9263), потому будет в любом случае дешевле, чем разводить многослойки для БГА.
Видео гнать не надо. Но надо будет рисовать всякие стрелочные приборы и прочее. Потому хотелось воспользоваться библиотекой Qt или gtk. А с этим компаньеном придется еще и драйвер под Линукс писать соответсвующий. Не вижу где тут экономия. Сэкономили на железке, зато оплатили труд программисту? Или я не прав?

Если изделие единичное - тогда конечно не имеет смысла заморачиваться. Только 9263 под линуксом может недостаточно шустро ворочать экраном разрешением 1600х480, даже если разрулить проблему с регенерацией на два экрана. Но тут все зависит от того, сколько данных ему нужно обрабатывать и в каком темпе выводить.
aaarrr
1600x480 это даже меньше, чем 1024x768. Если использовать отдельную шину памяти для экрана и <=16bpp, то все может не так уж и плохо.
hwdev
Цитата(Al Volovich @ Jun 8 2008, 19:11) *
Если изделие единичное - тогда конечно не имеет смысла заморачиваться. Только 9263 под линуксом может недостаточно шустро ворочать экраном разрешением 1600х480, даже если разрулить проблему с регенерацией на два экрана. Но тут все зависит от того, сколько данных ему нужно обрабатывать и в каком темпе выводить.


Изделие не единичное. Минимум 100 штук будет выпущено. Правда, если всё заведется как надо.
cioma
Посчитайте пропускные способности шин на всем пути передачи данных кадра. Может оказаться, что узкое место будет, например, в SDRAM или во внутреннем DMA.
AlexN
Цитата(aaarrr @ Jun 8 2008, 22:20) *
1600x480 это даже меньше, чем 1024x768. Если использовать отдельную шину памяти для экрана и <=16bpp, то все может не так уж и плохо.


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

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

а как это улучшает usability (торможение прорисовки новой картинки) на экране 800*480*16bpp
aaarrr
Цитата(AlexN @ Jun 3 2009, 09:00) *
а как это улучшает usability (торможение прорисовки новой картинки) на экране 800*480*16bpp

Ну, очевидно должно улучшать. На сколько в %% можно определить только экспериментально для какой-то конкретной системы, но 800x480x16 - не такая уж большая нагрузка.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.