Видеопоток средствами Cortex M3

dmitry.shagin · 02.11.2011, 16:09

Приветствую.
Вылезла задача по генерации композитного сигнала. Вкратце об условиях:
вход: поток цифр по UART (TTL 3.3V); поток небольшой, 2400 в прыжке (несколько раз в секунду меняются до 10 1-2-х байтовых цифр типа скорость, ускорение, высота и т.д.)
выход: композит (или компонент - на выбор) на SD экран.
ограничения: минимум занимаемого пространства, минимум энергопотребления, максимум гибкости.

Пока кручусь вокруг такой мысли: взять любой STM32 с сотней ног (дабы был получить общение с памятью на уровне DMA), SDRAM-а банку для фреймбуфера (ну, пусть 16 мегабайт с большим запасом) и на выход повесить какой-нить видеоэнкодер вроде этого:
http://www.analog.com/en/audiovideo-...s/product.html

Вот собственно тут у меня проблемы возникают: во-первых никогда не сталкивался с DMA на контроллерах (преимущественно AVR мучаю, которого явно недостаточно для этой задачи, да и жрет он из расчёта на МГц много), поэтому любопытствую: можно ли настроить DMA в STM32 таким образом, чтобы он данные из памяти гнал напрямую в adv7390 минуя ядро. Ядро желательно по максимуму освободить для рендеринга шрифтов и всяких интерфейсных красявостей - поэтому вариант с какой-то обработкой данных из RAM-а ядром кажется очень непривлекательным.

Еще раздумываю над таким вариантом: ARM (или даже AVR) на низкой частоте неспешно занимается рендерингом, а какая-нить FPGA выдёргивает данные из рама и отдает из ЦАПу. Но я с FPGA никогда не работал, поэтому слабо представляю себе возможности...

tanq · 02.11.2011, 17:03

Надо пробовать. Проц лучше брать с частотой более 100 МГц. У старших версий есть встроенный контроллер TFT, который позволяет делать "это", то есть брать из памяти данные и толкать их по цифре на выход. Решение на FGPA совершенно не по теме. Вместо него уж лучше более мощный арм поставить со встроенной памятью.

dmitry.shagin · 02.11.2011, 17:29

Встроенной памяти, очевидно, не хватит даже на самых топовых STM-ах (можно запихнуть только в случае жесткого ЧБ, ну, максимум, 4 цвета). А реально ли нужны 100Мгц? Для SD сигнала данные надо отдавать на 27Мгц. Если это делать не через DMA, а процом - то 100 не хватит (по 4 такта на команду - никак), а если напрямую то вроде синхронно с частотой должно быть, не?

dmitry.shagin · 02.11.2011, 17:39

Может кто-то разбирал дешевые китайские фотоаппараты и прочую мишуру - ведь видеовыход есть везде абсолютно, и реализован компактно, и частот там явно нет сумасшедших, и питание везде батарейное (то есть кушает адекватно оно). Не ставить же 11-й АРМ на 0.5ГГц для решения такой банальной задачи...
Кстати, для примера: на всех экранах с SPI управлением контроллеры постоянно опрашивают внутреннюю память и выплёвывают данные на экран. При этом частоты их работы равны width*height*framerate - то есть очевидно, что данные из памяти они забирают и обновляют за один такт. Умеет ли так встроенный контроллер LCD на STM32 (а если нет, то кто умеет?)

General_Dead · 02.11.2011, 18:50

Сообщение от dmitry.shagin

Умеет ли так встроенный контроллер LCD на STM32 (а если нет, то кто умеет?)

STM32 не имеют встроенного LCD контроллера.

dmitry.shagin · 02.11.2011, 19:02

Сообщение от General_Dead

STM32 не имеют встроенного LCD контроллера.

Вообще имеют.. И есть аппноуты для них. Через FSMC. Но я с ними не сталкивался, поэтому не знаю, можно ли этот FSMC сконфигурировать так, чтобы вместо LCD подцепить ЦАП и выдавить из него 640х480 (в аппноутах сплошные 320х240 панельки).

dmitry.shagin · 02.11.2011, 19:05

Объясни, кстати, почему я в принципе смотрю параллельно в сторону FPGA: к этому меня подталкивает вот этот проект: http://excamera.com/sphinx/gameduino/
Логика подсказывает, что FPGA за ту же работу должна потреблять меньше Cortex-а