Хочу сделать простой контроллер, по сути, видеобуфер, который будет формировать изображение в формате NTSC или PAL. А дальше, уже с помощью внешнего микроконтроллера, рисовать разноцветные буковки, простенькие графики и прочее.
Хочу получить 320 на 240 точек, пара бит на цвет. Короче, все не сложно. Но и проект должен быть бюджетным.
Вопросы:
1. Нет ли где готового проекта, посидеть - поковырять, сделать на его основе что нужно мне.
2. Если нет, подскажите пожалуйста, как прикинуть минимальную ПЛИС, которая потянет задачу. Склоняюсь в сторону Альтеры. Хочется чтобы была Альтера за 3-5 долларов + статическое ОЗУ за пару долларов.
Спасибо!

Поищите в Альтеровской университетской программе. Должны быть такме проекты.
А у Ксайлинкса - тоже есть на сайте, где стартовый набор на Спартан 3Е...

1. http://opencores.org/projects.cgi/web/fbas_encoder/overview
2. Автор пишет что проект поместился в XC9536 (~5$)

этот проект я видел. Это энкодер просто. Есть готовые микросхемы для выполнения данной функции, к примеру, CXA1645 - совсем дешевая, есть производства Аналоговых Девиц, подороже и по качественнее. Но мне нужно сделать фрейм буфер. Логика, которая будет работать с ОЗУ, выплевывая из нее в соответствующие моменты времени RGB пикселя, и одновременно, следящая за синхронизацией - строковой и кадровой. Другими словами, формирующая эти самые кадры. Ну а содержимое ОЗУ я буду заполнять внешним микроконтроллером.



Спасибо за наводку! Посмотрю обязательно.

Пару недель назад задавался такими же вопросами. Мне нужно разрешение 480х232, 2 бита на цвет, двойная буферизация.
Перебрал много вариантов от третьего циклона до LPC. В итоге сделал на EPM3032A (заняло 20 ячеек ) и 2 памяти N256S08 (из одной выводим на телевизор, в другую рисует контролер). В железе пока не проверял, так как все микросхемы привезут только в понедельник.

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

Интересно.... сообщите пожалуйста, как получится в железе. Я как раз про эту Аьтеру и думаю, тоже на ней хочу.
Единственное, я немного вас не понял - синхронизацию вы делаете на контроллере. Что имеется в виду? вы говорите о внешнем управляющем микроконтроллере? На мой взгляд, это-то как раз и неудобно, и джиттер будет. Или вы о внешнем энкодере говорите, которому достаточно из ПЛИСа подавать совсем простенькие синхросигналы, сформировать которые очень не сложно?
В чем смысл применения 2-х корпусов памяти? По-моему вполне можно все успевать и с одной памятью, с нашими-то несложными требованиями по разрешению и по глубине цвета....

Нда.. судя по вопросам не худо бы сначала почитать теорию..
В свое время я поинтересовался такой задачей и путями ее решения.
В первом варианте задача была решена на Lattice 1032 + 3x64КБ SRAM - разрешение 320х240х8бит
Во втором варианте цеплял контроллер к TFT Sharp 640x480x16бит (макетка с CycII + 512КБ SRAM)
К первому варианту легко довешивается кодер (PAL, NTSC) - мне было без надобности

Теперь по существу вопросов:
1. сходи сюда и почитай (это была для меня отправной точкой):
http://elm-chan.org/works/crtc/report.html
2. "прикинуть" объем несложно - тащишь пакет для проектирования в том кристалле, который выбрал, устанавливаешь, пишешь или рисуешь прошивку, в логах смотришь ответ в ЛЭ, типа такого:
Number of Macrocells is 116
Number of GLBs is 30
Number of product terms is 288
Maximum number of GLB levels is 4
Average number of inputs per GLB is 8.8
Average number of outputs per GLB is 3.9
Average number of product terms per GLB is 9.6
далее делаешь правильные выводы и подбираешь подходящий кристалл..

Теорию..... думаю, таким образом можно отвечать на 80% всех сообщений на этом форуме. Теорию читал и буду читать. Но надо пробовать и практику.

1. Я там уже все вылизал что можно. И прошил ПЛИСину (кстати только 1 версия Абелевского исходника проходит фитинг на ISE, другие - нет и вообще проекты, похоже не рабочие, но это для меня не важно. Как пример интересно). По этому проекту вопросов нет.

2. Это понятно. Это везде так. Только методологически, это - научный тык, а не прикидывание. Типа все написал, откомпилировал, не влезло (или влезло с большим запасом), пошел ножки переписывать для другой микросхемы. Вопрос задан с целью услышать +/- семейство Альтеры, которое "вроде бы" подойдет. Далее, в пределах семейства, я уж соображу что к чему. Сам думаю про микросхему EPM3032. Но это просто ощущение, может и промахиваюсь.

В общем, всем большое спасибо. На данном этапе вроде все более - менее ясно. Отправные точки имеются.

Вопрос в догонку:
когда источник картинки (streaming video) 320x240 или другое меньше чем натуральная резолюция ТВ - интерполриуем ?
Стандатные PAL/NTSC енкодеры ожидают на входе сигнал стандартной TV резолюции PAL или NTSC соответственно и его кодируют в composite.
Так вот если источник имеед дающий менее чем стандартный ТВ сигнал по резолюции, значит перед подачей на енкодер его нужно подогнать под PAL/NTSC ?

Если например кадровая частота источника зачительно больше нужной конечной (25 или 30 fps), например: 50, то в приципе можно попробовать запускать каждый входной кадр как одно поле выходного (т.е. из 2х кадров по 240 строк на входе получаем один кадр на выходе 480 строк). Но по ширине все равно по идее нужно интерполировать до PAL/NTSC стандарта ?

ну там 704 или 720 точек - из 320 повторить дважды + небольшие поля с боков - имхо, проще

а вопрос, кроме CXA1645 какие-то аналоги есть более современные : 3В, жруть поменьше, корпус поменьше?

Есть у Аналоговых Девиц, типа AD725 и подобные. AD723 - с питанием 3 V

Вот это то как раз и вопрос...
повторять каждый второй пиксель то оно наиболее просто, но как сказывается на качестве на ТВ относительно более "умных" алгоритмов ? (тут в схожих ветках предлагались несколько подходов пиксельной интерполяции). Интересно именно на основании опыта: сильно ли сказывается простая дупликация пикселей на статическом и динамическом изображении ?

если информации 320х240 точек, то сильно умный алгоритм нужен, чтобы качество улучшить
а при динамическом с учетом "векторов движения" совсем какие-то эвристические алгоритмы нужны - имхо, не та тема
то есть железо несопоставимо сложнее чем выдача изображения ХхУ


мне получается дешевле AD7171 использовать, который (вроде бы) Вам рекомендовал на телесиськах

казалось, что такие микрухи вообще забезплатно должны раздавать

Да, на телесиськах я был, но AD7171 не помню, кажется не было. Учту, погляжу. Спасибо.
Да, цены при данном функционале - не очень. Но я слышал отзывы людей, которым довелось ставить и CXA и AD. Ответ однозначный, AD много выигрывает по качеству картинки. Заметно даже на простых задачках, типа той, что мне нужно сделать. Про сравнение с AD7171 ничего не слышал.

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