Схемотехника и алгоритм работы видеоэкрана, Схемотехника и алгоритм работы видеоэкрана Опции

[yagger]

Прошу (как обычно при таких вопросах говорят на форумах) сильно не пинать...
Поправьте меня пожалуйста если я где то ошибся: имеем панель 24х32 пиксела, 3 цвета > итого у нас есть 24*32*3=2304 физических точки. Идем далее => необходимо развернуть картинку из озу 100 раз (100 Гц), но при этом!!!! требуется создать еще и градации серого ШИМом для каждой точки (8 битный шим, т.е. 256 градаций), отсюда вытекает мне необходимо разворачивать картинку 1 сек/100 Гц=10 мСек => 10 мСек/256 (1 такт ШИМа)=39 мкСек , т.е. на разворот 2304 бита мне надо это время. Далее: пусть у меня стоит ПЛИС опрашивает озу (в озу зашиты данные о шим каждого пиксела) сравнивает с счетчиком и выставляет соответствующие данные на шине данных для регистров (если регистры 16-разрядные их требуется всего 2304/16=144 шт) стробит и в конце цикла защелкивает. Значит для того чтобы считать данные о шим для каждой точки требуется 39 мкСек/2304 бита=16-17 нСек. Справится ли современная электроника с этим бредом? или все же ЭТИ дела делают таким же способом но не 24х32 а поменьше???

[Dog Pawlowa]

Справится ли современная электроника с этим бредом? или все же ЭТИ дела делают таким же способом но не 24х32 а поменьше???

ЭТИ дела делаются на драйверах светодиодов с возможностью управления током каждого выхода.
ШИМ - это решение для табло в пионерском кружке

[yagger]

ммммм.... Т.е. китайцы до сих пор пионеры и строят по такой технологии тоже?
Просто я сколько видел на выставках на таких драйверах как DM163 совсем нет экранов, а вот на простых mbi почти все!!!! и при чем статическая индикация. Так как они ими управляют?

И кстати мне почему то кажется, что именно на этом принципе строит (или строил) уважаемый ledmaster. Как я посмотрел на форумах он вроде как хорошо отзывался о драйверах TI, а они почти аналоги MBI5026 к примеру. (и при этом он упоминал о тысячах используемых этих драйверов в его разработках).

[Dog Pawlowa]

Просто я сколько видел на выставках на таких драйверах как DM163 совсем нет экранов, а вот на простых mbi почти все!!!! и при чем статическая индикация. Так как они ими управляют?

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

[yagger]

Т.е. ГРУБО говоря у них обновление как ШИМ так и КАДРОВ идет к примеру с частотой 100 Гц????

[GetSmart]

Большинство табло так не работают, они равномерно изменяют яркость всего табло.

Не верьте ему! Он фальшивый
yagger
У вас расчёт верный. Только умные люди перезагружают эти регистры по параллельной шине, а не через одну линию. Например через 24 линии и по каждой будет передано 32 бита для перезагрузки всех регистров табло. Таким образом длительность одного бита вырастет в 24 раза и будет 400 нс. Все подобные вещи уже давно можно было делать на уже состарившейся элементной базе. Сейчас база озволяет делать всё в десятки раз круче.

Ошибся. По каждой из 24 линий будет передано 32*3 бит. То есть 6 регистров MBI5026 (16-разрядных) в цепочке.

[Dog Pawlowa]

Не верьте ему! Он фальшивый

А тут все фальшивые, настоящие только (оглянувшись) модераторы.

Я говорил, с чего бы я начал такой проект. Но я его никогда не буду делать - нет шансов сделать сложное табло дешевле, чем в Китае. Простое - запросто
По Дискавери недавно показывали, "Как это делается", но тонкости электроники конечно не затрагивали.
Посмотрю в понедельник, может фотки найду.

[yagger]

GetSmart дело в том что я пока в расчете и не затрагивал "загон" в регистры меня на самом деле интересует время считывания из озу... Даже если взять озу с временем доступа 5-10 нс (а я расчитывал на 12-20) то за 16-17 мс необходимо сделать все остальное (записать с другой строны байты(я имею ввиду со стороны приемника потока 25-30 кадров), далее загнать в регистр текущий бит, но перед этим сравнить в счетчике шима и т.д. не говоря уже о том что я наверное еще что то упускаю)
Я кстати на параллельную шину сразу и расчитывал, ввиду многих причин...
Но что то я не понял как это время вырастет до 400 нс???? мне то разницы на самом деле нет выставлять бит на параллельную шину или на последовательную (если бы БАЙТ это другое дело)...

Да и еще, Dog Pawlowa, в одном форуме видел хорошее замечание " Титаник делали профессионалы, а ковчег - любитель!" и если придерживаться позиции что китайцы всех победят, то можно завтра закрывать почти все фирмы и производства и у нас и у вас в стране...(хотя на самом деле я не знаю откуда вы). Просто есть такая вещь как маркетинг или например личные договоренности в особых кругах сбыта, где ни какие китайцы не пробьются.

[vetal]

Что-то вы не то насчитали. У вас 24*32*3*8*100 бит/с для приведенных вами условий, иными словами - 542,5 нс/бит.

[GetSmart]

Даже если взять озу с временем доступа 5-10 нс (а я расчитывал на 12-20) то за 16-17 мс необходимо сделать все остальное (записать с другой строны байты(я имею ввиду со стороны приемника потока 25-30 кадров),

Начните уже сразу мыслить широко. У вас что однобитное ОЗУ ? Тогда вам труба! Профи всё это делают внутри FPGA. Там и ОЗУ бывают по 10 КБ и логики выше крыши. Да и скорости еденицы нансек. Я конечно разжёвывать всё до мелочей в схемотехнике и алгоритмах не буду, так, пару советов могу дать.

[Dog Pawlowa]

Да и еще, Dog Pawlowa, в одном форуме видел хорошее замечание " Титаник делали профессионалы, а ковчег - любитель!"

Хм, это не форум сантехников? Всякий уважающий себя инженер должен пахать широко

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

Угу.
"Зато мы делаем ракеты..." (с) Ю.Визбор
Тогда договориться можно и с президентом.

[yagger]

Что-то вы не то насчитали. У вас 24*32*3*8*100 бит/с для приведенных вами условий, иными словами - 542,5 нс/бит.

??? что то мне подсказывает что у вас не то что то...
хотя я все же могу ошибаться.
24*32*3=2304 физических точки.
теперь следую алгоритму: берем из озу 1 байт(8 бит) сравниваем его со счетчиком (к примеру в ПЛИС) и по результату сравнения выставляем 0 или 1 на шине данных, стробим, читаем след байт(8 бит) и так 2304 шт, после этого подаем строб LE. На этом этапе первый такт ШИМа загружен в регистры. И таких разворотов нам надо 256 (так как шим 8 битный). И вот эта последовательность и есть картинка за 10 мСек так как 1 сек/100 Гц=10 мСек. а Если так, то 10 мСек/256=39 мкСек на 2304 байта, а соответственно 39 мкСек/2304~17 нСек на выборку 1 байта (который сравнивается с счетчиком) и установку 1 бита на шине данных. Где ошибка???

[GetSmart]

Так делают любители, вроде ledmaster. Ковчег наверно тоже он делал. Зачем по 256 раз сравнивать один и тот же байт (яркость)? Берёте младший бит, отображаете его 1 такт. Берёте второй, отображаете 2 такта. ... Берёте 4-ый бит, отображаете его 16 тактов. ... Берёте старший 7-ой бит, отображаете его 128 тактов. Никаких сравнений не надо. Сразу после начала отображения 7-ого бита оперативка освобождается для перезагрузки новыми данными. То есть 1/2 времени она гарантированно не используется (реально 97%). Что бы не париться и не читать из ОЗУ байт ради одного бита, делается так:
Заранее в ОЗУ записываются не байты яркости пикселей друг за другом, а уже разрезанные на 8 плоскостей данные. Таким образом если память байтовая, то чтение одного байта извлечёт данные для 8-ми пикселей и должно длиться 17*8 ==> 136 нс. Однако, уже подчёркивал, что делать это на рассыпухе - школьное подельничество. FPGA или ARM-проц. Они же могут раскрутить в 10 раз большее табло.

[yagger]

GetSmart, огромное спасибо за достаточно подробное описание алгоритма, я прошу прощения, возможно бестактно с моей стороны будет спросить, Вы строили данные девайсы? Конечно можете не отвечать, просто я сколько читаю форумы там чуть ли не 90 процентов теоретики и философы. А по поводу ledmaster я просто видел его высказывания в форуме ledforum.ru и у меня сложилось о нем некоторое мнение.(я его не считаю любителем). Любитель это я точно... Правда стараюсь выбраться повыше. Как говорится "Завтра начну жить с нуля. Только до него еще добраться надо."

[GetSmart]

Да, строил. Знаю там каждую крупинку. Поверьте мне, никаких побочных эффектов на неподвижном табло не наблюдается. Даже на не сильно подвижном тоже.

[yagger]

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

[GetSmart]

Далековато от меня. В Минске я ещё не разу не был.

Скажем так, количество знаний в какой-то области не всегда пропорционально оплачиваются. Вобщем по разным причинам сейчас занимаюсь другими делами, но тоже связанными с электроникой. Я уже давно не интересовался драйверами, спросите у ledmasterа. А FPGA выбирайте сами между Altera и Xilinx. Соответственно Cyclone или Spartan. Я бы выбрал самую дешёвую из них, подходящую по размеру ОЗУ. Хотя лично я скорее всего сделал всё на ARMе, но это долго объяснять что и как.

[yagger]

GetSmart,Спасибо еще раз... А в Минск милости просим. У нас тут весьма неплохо. А по поводу знаний... У меня с детства сложилось такое отношение ко всем делам (наверное глупое) сначала сделать, а потом теорию изучать. Т.е. я по натуре чистейший практик. Но вот в последнее время начинаю понемногу и думать перед тем как сделать. По поводу ваших объяснений как шим получается в экране... Ведь именно с этим у меня пока туговато, так ноги а контроллерах доргаю (там часы всякие табло спортивные и строки бегущие) а вот с математикой двоичной как то не получается пока дружить. Скажем так нет учителя по этим вопросам, а самому разбираться с 0 как то страшновато долго получится... Можно я буду задавать глупые вопросы? С надеждой на толковые ответы? В ранг учителя вас возведу...

[_LD]

Может поделитесь с какими подводными камнями могу столкнуться?

Главное - изначально продумать иерархичную наращиваемую систему. Все остальное приложится

например нужна ли синхронизация всех модулей, минимальная частота кадров без потери качества видео, может драйверы посоветуете и ПЛИС...

Синхронизация модулей не нужна, правда, у меня она всегда получалась автоматически. Минимальная частота кадров - порядка 75 герц, но нелишним будет задрать ее до нескольких сотен герц. У китайских товарищей в основном 200-300 герц.
Лично я использую драйверы MBI5026 и ПЛИС Альтера (Циклон1/2), которая тянет модули размерностью порядка 64 на 32 полноцветные точки. Обычно хватает внутренней памяти, но иногда приходится ставить внешнюю.

Да, глубина цвета (разрядность ШИМ), что выбрана Вами (8 бит - 256 значений), абсолютно неприемлема (проблемы с воспроизведением "темных" полутонов). Минимум - 10 бит; опять-таки, у китайцев от 12 до 14 бит. Я делал не менее 12 бит для статической индикации.

Будут вопросы - милости просим.

[yagger]

Обычно хватает внутренней памяти, но иногда приходится ставить внешнюю.

Спасибо за советы. Очень помогает, на душе легче становится. А что означает обычно? Вы все время применяете для своих девайсов разную схемотехнику?

Да, глубина цвета (разрядность ШИМ), что выбрана Вами (8 бит - 256 значений), абсолютно неприемлема (проблемы с воспроизведением "темных" полутонов). Минимум - 10 бит; опять-таки, у китайцев от 12 до 14 бит. Я делал не менее 12 бит для статической индикации.

А как данные о 10-12 разрядном шиме грамотно в памяти располагать? 2 байта на пиксель занимать приходится?

[Ledmaster]

Так делают любители, вроде ledmaster. Ковчег наверно тоже он делал. Зачем по 256 раз сравнивать один и тот же байт (яркость)? Берёте младший бит, отображаете его 1 такт. Берёте второй, отображаете 2 такта. ... Берёте 4-ый бит, отображаете его 16 тактов. ... Берёте старший 7-ой бит, отображаете его 128 тактов. Никаких сравнений не надо. Сразу после начала отображения 7-ого бита оперативка освобождается для перезагрузки новыми данными. То есть 1/2 времени она гарантированно не используется (реально 97%).

Уважаемый GetSmart, что-то не припомню, когда я Вам рассказывал, что и как я делаю
Я не отношу себя к числу людей, которые всегда и во всем считают себя суперпрофессионалами, но некоторые приемы построения экранов и мне доступны
Хотите подробностей, их есть у меня!

[GetSmart]

Уважаемый GetSmart, что-то не припомню, когда я Вам рассказывал, что и как я делаю

Уже на раз слышал упоминание о Вас в контексте алгоритма с постоянным сравнением яркости точек на больших экранах.

А как данные о 10-12 разрядном шиме грамотно в памяти располагать? 2 байта на пиксель занимать приходится?

Ни в коем случае. Тем самым сразу увеличите поток данных от компьютера или чего-то ещё в экран. Внутри FPGA вообще проблем нет. Сразу можно поделить на 8..10 плоскостей. Хотя это не принципиально. Главное не передавать и не хранить лишние пустые ~6 бит. Только если памяти некуда девать.

ЗЫ. Для уличного экрана 8 бит на точку вполне приемлемо. Особенно если это сказывается на экономии чего-нибудь. Желательно конечно 10.

[Tehnoon]

Господа, извините что вмешиваюсь... Но мне совершенно не понятно, в чем прелесть постройки экрана, с такой разверткой и шимом ? Почему все же, не DM163 и ей подробные ? Грубо говоря, весь экран, это три длинных сдвиговых, с програмным управлением каждой точкой. Или я чего-то кардинально не понимаю ?

[yagger]

Господа, извините что вмешиваюсь... Но мне совершенно не понятно, в чем прелесть постройки экрана, с такой разверткой и шимом ? Почему все же, не DM163 и ей подробные ? Грубо говоря, весь экран, это три длинных сдвиговых, с програмным управлением каждой точкой. Или я чего-то кардинально не понимаю ?

Где то в форуме я видел нелестные высказывания о работе данного драйвера. :-(
А я тоже начал было с ним работать. Более того, я вроде как посчитал, при одинаковых размерах и возможностях модуля, на классических драйверах значительно дешевле получается.

Ни в коем случае. Тем самым сразу увеличите поток данных от компьютера или чего-то ещё в экран. Внутри FPGA вообще проблем нет. Сразу можно поделить на 8..10 плоскостей. Хотя это не принципиально. Главное не передавать и не хранить лишние пустые ~6 бит. Только если памяти некуда девать.

Уважаемый GetSmart, а где я могу почитать или может даже посмотреть в картинках , как это в адресном пространстве делается. Я понимаю для 8 бит, 8х8 переворачиваю на 90 градусов вот у меня готовые байты на выдачу. а 10-12 бит???

ЗЫ. Для уличного экрана 8 бит на точку вполне приемлемо. Особенно если это сказывается на экономии чего-нибудь. Желательно конечно 10.

На сколько я понимаю приемлемо из-за того что общая освещенность бОльшая и "ньюансов" видно не будет?

[_LD]

Вы все время применяете для своих девайсов разную схемотехнику?

Да. Все зависит от размерности управляемого объекта. Если два полных кадра лезут в память ПЛИС - нафига внешняя память?
А вот если не лезут, то приходится ее ставить.

А как данные о 10-12 разрядном шиме грамотно в памяти располагать? 2 байта на пиксель занимать приходится?

Память ПЛИС может быть организована не байтами. Можно хоть 13 бит без потерь сделать 12 бит в Альтере - три блока памяти разрядностью 4 бита.

А если память внешняя, то ее обычно дофига, и не проблема потерять четверть 16-ти битного слова.

[yagger]

Если два полных кадра лезут в память ПЛИС - нафига внешняя память?
А вот если не лезут, то приходится ее ставить.
Память ПЛИС может быть организована не байтами. Можно хоть 13 бит без потерь сделать 12 бит в Альтере - три блока памяти разрядностью 4 бита.

А если память внешняя, то ее обычно дофига, и не проблема потерять четверть 16-ти битного слова.

Уважаемый _LD, может Вы поделитесь? чем (интерфейс, протокол) вы доставляете к блокам видеопоток (не сжимать же его, а то аппаратное сжатие стоит огогого, а програмное мне не потянуть с моими знаниями это точно в ближайшее время ). Спасибо за разъяснения по поводу памяти альтеры, я как раз это изучил. Я думал про 2 байта ПОЛНЫХ с лишними битами в видеопотоке, как их там не передавать? (грамотно).
Вопрос к Вам (ибо вижу вы не просто любитель, а вроде как знающий человек ), Вы тоже применяете способ ШИМа взвешиванием (тактированием) весовых коэффициентов разрядов или же у Вас иной способ? (и вообще какие еще бывают способы создания ШИМа без потери времени на прием данных и обслуживание ОЗУ без применения драйверов с шимом)?
З.Ы. Какую внешнюю память Вы применяете (если такая все же необходима)?

[yagger]

Да, глубина цвета (разрядность ШИМ), что выбрана Вами (8 бит - 256 значений), абсолютно неприемлема (проблемы с воспроизведением "темных" полутонов). Минимум - 10 бит; опять-таки, у китайцев от 12 до 14 бит. Я делал не менее 12 бит для статической индикации.

Будут вопросы - милости просим.

Вот еще перечитывал возник вопросик, Вы тут имели ввиду 12-14 бит на 1 ЦВЕТ?! Раз так то откуда их снимать? Ведь по тому же DVI прет по 8 бит на цвет, откуда лишние биты берутся? Неужели их приходится добавлять самому при преобразовании(так называемой гамма коррекции)?
Еще вопрос. я наверное слишком много их задаю... в ПЛИСке у Вас организована память 2-х портовая? (если так то, тогда понятно как она успевает независимо и шим вывести и принять DVI, или что там еще...)

[_LD]

Уважаемый _LD, может Вы поделитесь? чем (интерфейс, протокол) вы доставляете к блокам видеопоток

Китайские товарищи вовсю используют гигабитный ethernet, а я не захотел
В небольших поделках - манчестер 8 мбит по витой паре, в больших - 100 мбит ethernet.

Вопрос к Вам (ибо вижу вы не просто любитель, а вроде как знающий человек )

Уже сменил род деятельности. Задолбало лампочками управлять
Но несколько лет просидел на этом.

Вы тоже применяете способ ШИМа взвешиванием (тактированием) весовых коэффициентов разрядов или же у Вас иной способ?

Если быстродействие памяти и требуемые параметры позволяют - делаю "в лоб", вычитывая каждый раз значение яркости. Если поджимает - делаю смешанный вариант (младшие разряды стробом, остальные вычитыванием).

З.Ы. Какую внешнюю память Вы применяете (если такая все же необходима)?

Асинхронную статику Samsung.

Вот еще перечитывал возник вопросик, Вы тут имели ввиду 12-14 бит на 1 ЦВЕТ?! Раз так то откуда их снимать? Ведь по тому же DVI прет по 8 бит на цвет, откуда лишние биты берутся? Неужели их приходится добавлять самому при преобразовании(так называемой гамма коррекции)?

Именно так.

Еще вопрос. я наверное слишком много их задаю... в ПЛИСке у Вас организована память 2-х портовая? (если так то, тогда понятно как она успевает независимо и шим вывести и принять DVI, или что там еще...)

Конеюно, двухпортовая. Если два полных кадра в ПЛИС не лезут, идет прием во внешнюю память с перебросом ее во внутреннюю при смене кадров.

[GetSmart]

Если быстродействие памяти и требуемые параметры позволяют - делаю "в лоб", вычитывая каждый раз значение яркости. Если поджимает - делаю смешанный вариант (младшие разряды стробом, остальные вычитыванием).

А в чём приемущества такого "гибрида"?

[GetSmart]

На сколько я понимаю приемлемо из-за того что общая освещенность бОльшая и "ньюансов" видно не будет?

Именно из-за этого. При низком освещении уже будут видны "ступеньки" на малых яркостях. Кстати, если для уличного экрана не применяется изменение гаммы в зависимости от времени суток (день/ночь), то 10 и более битный экран всего-лишь "пыль в глаза". Другими словами - рекламный трюк.

[Галстук]

Господа, извините что вмешиваюсь... Но мне совершенно не понятно, в чем прелесть постройки экрана, с такой разверткой и шимом ? Почему все же, не DM163 и ей подробные ? Грубо говоря, весь экран, это три длинных сдвиговых, с програмным управлением каждой точкой. Или я чего-то кардинально не понимаю ?

Был бы благодарен за информацию о том, чем плохи DM163.

У нас сделали 2 экрана на этих драйверах - один с SMD светодиодами, шаг 10мм, другой с колбочками, шаг 28мм. Так вот, плата с SMD диодами - это один длинный сдвиговый регистр на 96 последовательно включенных DM163. Никаких сбоев не наблюдается, что меня сильно порадовало, даже на это и не рассчитывал, думал, придется распараллеливать. Правда, плата вышла 4-хслойная.

Поскольку тупую работу ШИМ выполняют сами драйверы, снижена нагрузка на ПЛИС, один Cyclone управляет 4-мя такими платами, снимая данные с LVDS линии.

Вот, хотелось бы узнать, чем действительно плохи DM, может, я рано обрадовался?

[at90]

а какого разрешения модули и экран?

[yagger]

а какого разрешения модули и экран?

ну если я правильно понимаю, то исходя из соображений что DM163 24 канала(8 пикселей RGB) то в итоге получается 96 микросхем это 32х24 это если статика конечно... (кстати я как раз где то читал , что именно при динамике у этих микросхем всякие пошлости... только вот не помню где читал )

GetSmart, может Вы можете поделиться секретом: какие еще бывают способы создания ШИМа без потери времени на прием данных и обслуживание ОЗУ без применения драйверов с шимом.(я как буратино - хочу все знать.

[Галстук]

ну если я правильно понимаю, то исходя из соображений что DM163 24 канала(8 пикселей RGB) то в итоге получается 96 микросхем это 32х24 это если статика конечно... (кстати я как раз где то читал , что именно при динамике у этих микросхем всякие пошлости... только вот не помню где читал )

Абсолютно правильно подсчитали - плата именно 32х24 и именно статика. Из 4-х плат собран блок, управляемый контроллером. А размерность экрана - по количеству блоков.

Что касается динамики, ее даже и не рассматривали, хотя теоретически можно прилично сэкономить на числе драйверов. Если исходить из среднего тока диода 20мА и макс токе 60мА на выход, можно одним выходом без потери в яркости управлять тремя диодами, т.е. использовать в 3 раза меньше драйверов. Если же речь идет о ярких диодах и табло используется в помещении, достаточная яркость может быть получена при меньшем токе и число драйверов можно еще уменьшить. Однако это чревато мерцанием экрана, пока это не обдумывали.

Сообщение отредактировал Галстук - Feb 21 2008, 19:38

[yagger]

У нас сделали 2 экрана на этих драйверах - один с SMD светодиодами, шаг 10мм, другой с колбочками, шаг 28мм. Так вот, плата с SMD диодами - это один длинный сдвиговый регистр на 96 последовательно включенных DM163. Никаких сбоев не наблюдается, что меня сильно порадовало, даже на это и не рассчитывал, думал, придется распараллеливать. Правда, плата вышла 4-хслойная.

Поскольку тупую работу ШИМ выполняют сами драйверы, снижена нагрузка на ПЛИС, один Cyclone управляет 4-мя такими платами, снимая данные с LVDS линии.

А ШИМ чем создаете? Я имею ввиду на PWC вход что подаете на каждой плате свой отдельный генератор? и какова частота его у Вас? LVDS - это вы прямо DVI в блок пихаете или свое что то? Да кстати, на смд диодах экран не греется? как охлаждение сделали?

[yagger]

Ребята, А может расскажите принцип масштабирования? или у Вас в программе на компе есть область куда и сгружается все видео, и эта область по масштабу (по пикселам) соответствует экрану. В DVI по-моему минимально 60 Гц кадры бегут, какой принцип получения 25 кадров? ну я так понимаю 30 кадров можно через кадр забирать из потока, а вот 25? неужели через 1, а иногда через 2?

Сообщение отредактировал yagger - Feb 23 2008, 08:31

[GetSmart]

Масштабирование мы не применяли. У нас делалось так. На мониторе проигрыватель видео жёстко привязан к координатам экрана. А из потока DVI просто "вырезается" это окно и загоняется в ОЗУ FPGA. С кадровой частотой всё проще. Две страницы видеопамяти переключаются друг за другом. После полного заполнения пассивной, она становится активной и отображается, но обязательно синхронно со сменой кадров экрана. В другом варианте, когда видеопоток идёт не с DVI там можно по запросу заполнять единственную страницу ОЗУ. (если используется тот алгоритм с "взвешиванием" разрядов)

Сообщение отредактировал GetSmart - Feb 23 2008, 16:34

[Галстук]

А ШИМ чем создаете? Я имею ввиду на PWC вход что подаете на каждой плате свой отдельный генератор? и какова частота его у Вас? LVDS - это вы прямо DVI в блок пихаете или свое что то? Да кстати, на смд диодах экран не греется? как охлаждение сделали?

На каждой плате контроллера, управляющего до 8ми светодидных плат, свой генератор GCK 1.25 МГц, на более низких частотах заметно мерцание.
LVDS получается из DVI соответствующим преобразователем от TI.
А вот с охлаждением вопрос непростой. В модулях стоят блоки питания с вентиляторами, они обеспечивают какой-то принудительный обдув, на платы все равно заметно теплые. Спасает, что в помещении не надо выводить максимальную яркость, а на улице придется ставить дополнительные вентиляторы.

[yagger]

Масштабирование мы не применяли. У нас делалось так. На мониторе проигрыватель видео жёстко привязан к координатам экрана. А из потока DVI просто "вырезается" это окно и загоняется в ОЗУ FPGA.

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

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

Я очередной раз прошу прощения если я правильно понимаю, в этом варианте используется 2 страницы памяти озу с разным адресным пространством??? ну то есть дабы иметь одновременный НЕЗАВИСИМЫЙ доступ к своей памяти (активной/пассивной) как со стороны драйверов, так и со стороны потока видео? и в момент заполнения памяти пассивной со стороны потока, выжидаем пока не "отстреляет" до последнего бита активная часть и переключаем памяти??? я правильно рассуждаю? Если так, то как я и писал получается все равно из 60 кадров входных, я исскуственно должен забирать только 25-30 кадров пропуская некоторые из них?

В другом варианте, когда видеопоток идёт не с DVI там можно по запросу заполнять единственную страницу ОЗУ. (если используется тот алгоритм с "взвешиванием" разрядов)

В таком варианте я понимаю тоже можно, в принципе, использовать не 2х портовое а 1портовое озу???
А по поводу алгоритмов без "взвешивания" разрядов. Я действительно осознаю что в варианте с взвешиванием >95% времени свободно. В других алгоритмах так же дела с свободным временем обстоят, и сколько вообще можно насчитать таких алгоритмов?

[Галстук]

как я и писал получается все равно из 60 кадров входных, я исскуственно должен забирать только 25-30 кадров пропуская некоторые из них?

а кто вам мешает работать с родной частотой 60 Гц, зачем ее искусственно снижать?

[yagger]

а кто вам мешает работать с родной частотой 60 Гц, зачем ее искусственно снижать?

хм. сам дурак. действительно зачем. Но почему тогда все производители пишут типа 25-30 кадров? зачем они тогда снижают? или все же есть затык в чем то? 'Галстук' а у Вас какова частота кадров?

[Галстук]

хм. сам дурак. действительно зачем. Но почему тогда все производители пишут типа 25-30 кадров? зачем они тогда снижают? или все же есть затык в чем то? 'Галстук' а у Вас какова частота кадров?

Ну 60Гц. У нас экран работает от компа, 60 Гц. Будет источник 25 Гц - можно и 25 Гц.

[GetSmart]

если я правильно понимаю, в этом варианте используется 2 страницы памяти озу с разным адресным пространством??? ну то есть дабы иметь одновременный НЕЗАВИСИМЫЙ доступ к своей памяти (активной/пассивной) как со стороны драйверов, так и со стороны потока видео?

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

А по поводу кадровой частоты, так в начале темы вообще был расчёт на 100 Гц. Какие проблемы? У мониторов тоже частота не 25, а 60 и выше герц. Они прекрасно показывают 25 Гц фильмы. При желании можно вообще сделать автосинхронизацию экрана с идущей от DVI потока.

[yagger]

http://www.leds.ru/forum/viewtopic.php?t=26
тут давненько немного обсуждали тему?
что означает фраза (для меня пока слегка загадочная) "Сейчас буду пробывать MEGA128 с внешним сумматором (для вычисления уровня ШИМ) в адресном пространстве. Думаю смогу из нее 256 градаций на модуль 16х16 RGB вытянуть. у мастера дениса?"

[yagger]

В другом варианте, когда видеопоток идёт не с DVI там можно по запросу заполнять единственную страницу ОЗУ. (если используется тот алгоритм с "взвешиванием" разрядов)

'GetSmart' этот ДРУГОЙ алгоритм секрет?

[GetSmart]

что означает фраза (для меня пока слегка загадочная)

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

'GetSmart' этот ДРУГОЙ алгоритм секрет?

Это алгоритм с "взвешиванием" разрядов. Я же уточнил в конце фразы. Когда выведен старший бит, то происходит перезагрузка видеостраницы. То есть строго синхронно с кадровой частотой экрана.

[yagger]

В другом варианте, когда видеопоток идёт не с DVI там можно по запросу заполнять единственную страницу ОЗУ. (если используется тот алгоритм с "взвешиванием" разрядов)

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

[GetSmart]

Но ледмастер писал в ледфоруме, что все же у него есть ноу-хау.

Ссылку можно? Попробую силой мысли угадать что он от всех "скрывает"

[yagger]

Ссылку можно? Попробую силой мысли угадать что он от всех "скрывает"

http://www.d-sign.com/viewtopic.php?t=626&...asc&start=0
Добавлено: Пн Фев 18, 2008 2:49 pm
"хотя правды я тоже не скажу, это ноу-хау."

[GetSmart]

Алгоритм весов разрядов, который он описал, вещь хорошая, только выигрыша во времени не дает, те же 256 тактов. Просто для справки, у меня один контроллер на базе Altera EPM3256 обеспечивает время цикла порядка 4мс, управляя матрицей 64*48 полноцветных пикселей (256 градаций по каждому цвету).

Для справки, на 200-рублёвом АРМе без какой-либо внешней обвязки (простые буфера не в счёт) можно сделать "мозг" RGB модуля 96*96 кластеров с кадровой 60 Гц. Или 85*64 100 Гц. Или вообще любое разрешение. Только такие большие платы (на весь модуль) вроде как нереально изготовить.

Выигрыш по времени... Конечно же не 256 тактов, а только 8. Хотя цена минимального такта действительно 1/256-ая. Я в этом не вижу никакой проблемы, ведь 100 Гц * 256 = 26 КГц. Разве это много? Вся хитрость только в том, как за этот период обновить все сдвиговые регистры новыми данными. Как уже говорилось - мысли "шире" - грузи как можно больше параллельных данных.

Есть ещё теоретически другой вариант, когда яркость регулируется не только временным интервалом, но и регулировкой тока. Это в теории легко, а на практике почти нереально. Во всяком случае на дешёвых драйверах MBI5026. Вобщем байт яркости делится на два полубайта. Оба полубайта выводятся вобщем одинаково друг за другом. Либо просто сравнением, либо 4-мя плоскостями со взвешиванием. Только электрическая схема позволяет при выводе младшего полубайта уменьшить ток через светодиоды ровно в 16 раз. Если она уменьшит не в 16, а в 15 или 17, то на экране будут наблюдаться "глюки". Таким образом кол-во так называемых (ledmaster-ом) тактов уменьшается до 16+16 = 32 тактов.

У меня ещё есть оч. красивый вариант полу-динамической RGB-индикации. Он позволяет в 3 раза уменьшить количество драйверов MBI5026 или любых других. Дело в том, что каждый выход драйвера цепляется сразу к трём катодам светодиодов R,G и B. А вот аноды через мощные ключи (R, G и B канала) подключаются к питанию по очереди. Плюсы - экономия большого кол-ва регистров, места на плате и большая надёжность из-за меньшей длины цепочек регистров их емкостей и токов потребления. Однако драйвер MBI5026 должен будет выдавать на каждый свой выход утроенный ток, но он легко это делает, т.к. расчитан до 90 мА. Скорость перезагрузки регистров остаётся та же, т.к. кол-во регистров в цепочках уменьшилось втрое. Минус мне видется только в том, чтобы качественно сделать последовательное переключение питания R-G-B цветов. Чем реже переключаются эти ключи тем лучше. Если частота кадров 100 Гц, то 1/300 сек выводится цвет R, потом столько же G и B. Общий период будет как раз 1/100 сек. При желании можно переключение RGB увеличить в 2,4,8 раз.

Теперь что касалось вопроса "а что же делать 90% времени если нечё делать?". Ну с DVI-ем действительно нечего делать. А вот если канал передачи видео не DVI, то можно слать сжатый поток и декодировать его в рилтайме.

[yagger]

Для справки, на 200-рублёвом АРМе без какой-либо внешней обвязки (простые буфера не в счёт) можно сделать "мозг" RGB модуля 96*96 кластеров с кадровой 60 Гц. Или 85*64 100 Гц. Или вообще любое разрешение. Только такие большие платы (на весь модуль) вроде как нереально изготовить.

Я просто все на пиках да на пиках, а вот в последнее время чего то кошусь на плисы. А по вашему мнению что полезнее изучить плис или арм? (думаю ответ очевиден ) Просто в плисах почти все процессы идут "параллельно", а в арме чем достигается производительность, скоростью работы и командным аппаратом? или у него не конвейерная обработка команд?

У меня ещё есть оч. красивый вариант полу-динамической RGB-индикации.

я еще до написания своего первого вопроса по экранам именно так и хотел строить...но смотрю как бы мне вообще с простой статикой разобраться. Пока еще кстати не все понятно. В частности: изучать надо DVI - там куча вопросов, как синхронизировать смену активной и пассивной страницы (т.е. когда ее менять то надо, когда очередной кадровый импульс пришел? но тогда может быть не завершен процесс выдачи шима! или это по барабану?)ну и другие моменты.
Кстати, не подскАжите? если для переноса потока видео взять Ethernet, то как там аппартаный или тоже программный надо воротить?

[GetSmart]

А по вашему мнению что полезнее изучить плис или арм? (думаю ответ очевиден )

Но не Вам Ответ - оба. Ни один из них не сможет всё, что может другой. Так что под конкретную задачу будет и ответ.

изучать надо DVI - там куча вопросов, как синхронизировать смену активной и пассивной страницы (т.е. когда ее менять то надо, когда очередной кадровый импульс пришел? но тогда может быть не завершен процесс выдачи шима! или это по барабану?)

Заполняете пассивную страницу одним кадром из DVI и устанавливаете флаг готовности. Больше из DVI данные не брать, до переключения страниц. Как тока кадр светодиодного экрана закончится, страницы поменяются. И далее по кругу.

[yagger]

Так что под конкретную задачу будет и ответ.

так на данный момент задача стоит конкретная! принять видео выдать шим... просто почитав ветку http://www.microchip.su/showthread.php?t=661 я как то растерян после "разгона" Alex B. (а он, как я понимаю, почитав его посты, есть спец.)!!! может мне действительно подучить пики постарше и плис выучить, тогда и задачи разнообразней можно решать? А по поводу езернета что нить напИшете?
З.Ы. Спасибо за ответы, очень помогают. А по поводу "дальше не принимать DVI", я как то застопорился думал все как это сделать так чтобы ни одного кадра не пропустить, а с вашим ответом понимаю что в действительности то все равно кадров "поймаю" больше чем реально в видеороликах отображается (25-30). Честно говоря я впервые залез на форум и действительно получил неоценимую информацию, сам я точно в елках да березах блуждал бы еще дооолго!

[Галстук]

понимаю что в действительности то все равно кадров "поймаю" больше чем реально в видеороликах отображается (25-30).

Вы вот периодически упоминаете эти 25-30 кадров в секунду, те самые 25 fps из телевизора. Только вы учтите, что если ваш ШИМ работает по простому принципу - открыть на часть времени кадра ключ - на оставшееся время закрыть - то у вас светодиоды будут мерцать с частотой смены кадров. И чтобы глаз не замечал мерцания, эта частота должна составлять не меньше 60Гц, лучше 85Гц. На малых яркостях, когда время открытого состояния значительно меньше времени закрытого, даже и 60 Гц заметно.

Физиология зрения, знаете ли...

Поэтому вы либо забудьте про 25fps, либо делайте более изощренный ШИМ.

[adc]

У меня ещё есть оч. красивый вариант полу-динамической RGB-индикации. Он позволяет в 3 раза уменьшить количество драйверов MBI5026 или любых других.

Вот кстати ссылочка, эта тема как раз обсуждалось на обсуждаемую тему динамики на три.. http://electronix.ru/forum/index.php?showt...mp;#entry347961

[GetSmart]

Вот кстати ссылочка, эта тема как раз обсуждалось на обсуждаемую тему динамики на три.. http://electronix.ru/forum/index.php?showt...mp;#entry347961

Оказывается не только у меня рождаются идеи. Хотя в той теме я признАюсь ниразу не был. Честно, сам догадался

так на данный момент задача стоит конкретная! принять видео выдать шим...

Тут надо решить, с чем легче разобраться. Рисовать схемы (для FPGA) и писать программу (для проца) разные вещи. Желательно уметь и то и другое.

просто почитав ветку http://www.microchip.su/showthread.php?t=661 я как то растерян после "разгона" Alex B. (а он, как я понимаю, почитав его посты, есть спец.)!!! может мне действительно подучить пики постарше и плис выучить, тогда и задачи разнообразней можно решать? А по поводу езернета что нить напИшете?

Он такооой спец, что я молчу. Тут ещё один такой же есть - почитал эррату и выдал что АРМы (или только LPC) самые глючные. А вообще, я на стороне автора той темы. Могу только сказать что с dsPIC я не знаком и сравнить его с АРМом не могу. Я процы оцениваю не только по "мощности", но и по цене. Выше 300 руб я пока не применял процы и не вижу в этом необходимости. Что я писал по 200-рублёвый АРМ мне вполне достаточно.

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

[yagger]

либо делайте более изощренный ШИМ.

это типа симметричный?

[GetSmart]

Бывает ещё дельта-сигма ШИМ. Его несложно реализовать на FPGA, а вот на проце сложно.

[Галстук]

это типа симметричный?

Не знаю, что в точности значит "симметричный", хочу пояснить суть проблемы.
Допустим, вы хотите передавать 25 кадров в секунду. В кино получается все гладко, потому что статические картинки меняются "мгновенно". Если же яркость меняется с помощью ШИМ типа 1 раз за кадр включил - 1 раз выключил, мерцания делают картинку несмотрибельной, извините за выражение.

Теперь напрашивается просто взять, и прокрутить ту же форму сигнала ШИМ, допустим, 4 раза за кадр - частота повысится до 100Гц, мерцания должны стать незаметными. Очень хорошо.

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

Посмотрите даташит DM163, там описано их ноу-хау - некий ШИМ со специальным непоследовательным счетчиком, который обеспечивает псевдослучайное заполнение интервала кадра коротенькими импульсами. Осциллоскопом смотреть по-началу даже страшно, что делается. Что, вроде бы, решает эту проблему. Во всяком случае, никаких грубых артефактов при движении не наблюдаем.

[yagger]

Теперь напрашивается просто взять, и прокрутить ту же форму сигнала ШИМ, допустим, 4 раза за кадр - частота повысится до 100Гц, мерцания должны стать незаметными. Очень хорошо.

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

Т.е. в экранах, которые сейчас расставлены по нашим странам в основном частота кадров более 100 Гц? соответственно шим для них получается 100*256=25,6 кГц? а где я могу почитать про ЭТИ явления? 'Галстук', а Вы делали экраны на "классических" драйверах? или только на DM163?

З.Ы. Странно, но делают же люди 100 Гц(и даже меньше) и 8 разрядный шим. и ни кто об этих проблемах ни разу не написал. Может это тайна?

[yagger]

При эксперементах наткнулся на проблемку. Даже если рассматривать 1 канал то получается при 8 битном шиме (рассматриваемым алгоритмом) я поочередно, как писали, выставляю биты в порт и тактирую их нужным кол-вом тактов.(0ой бит 1 такт, 1ый бит 2 такта и так до 7го) а 7ой как только выставил, запускаю 128 тактов ожидания и сам делаю что мне требуется (к примеру изменение переменной шима в программе)... но вот что заметил, при некоторых переходах, а особенно это заметно при переходе 127-128 или 128-127 получается всплеск 255 тактов или провал 255 тактов, на светодиоде это заметно отражается... В частности я сделал программку плавно изменяющую яркость посредством ТАКОГО шима и вот ЭТО вылезло такими эффектами неравномерности. НатолкнЁте на мысль какими способами победить сие? Есть идеи поднять скорость, т.е. уменьшить время 1го такта и этот эффект станет почти незаметен, или все же есть какие то варианты решения такой проблемы? Как это сделано в экранах, если в ролике вдруг применяется плавное затухание?

Эскизы прикрепленных изображений

 

[GetSmart]

То что Вы описали, вполне "законный" глюк такого управления светодиодами. Хотя сам я почему-то за 3 года разработки экранов его не заметил :-( Возможно потому что частота экранов была 100 Гц, а частота видеороликов не превышала 25. Кроме того, большие или маленькие "глюки" будут в любом алгоритме формирования яркости, кроме дельта-сигма. Дельта-сигма сложный с аппаратной точки зрения и требует большую пропускную способность канала вместе с высоким (динамическим) потреблением цифрового канала передачи. Но зато самый помехоустойчивый. Не знаю на какой элементной базе (проц, FPGA) сделана Ваша схема, но если на FPGA, то я бы переделал её на дельта-сигму. Алгоритм с весовыми коэффициентами битов оптимально подходит для процессора, да и то для некоторых относительно шустрых типа LPC. Он имеет свои небольшие глюки, но и большие достоинства.

Теперь как избавиться от глюков. Можно например переставлять очерёдность вывода бит. Выводить 0,1,2,3,4,5,7,6. Или разбить старший бит пополам и выводить 7-0,0,1,2,3,4,5,6,7-1. Или 0,1,2,3,4,5,7-0,6,7-1. Достаточно поднапрячь фантазию и возникает масса способов. Тут главный вопрос, важно ли сохранить приемущества именно весового алгоритма, потому как с другого "краю" возможных алгоритмов стоит дельта-сигма вообще без глюков в визуальном восприятии, но требующем больших аппаратных затрат на уровне спартанов и циклонов.

[yagger]

Самое интересное я сейчас пересмотрел даташит на DM634 (одна из последних микрух макроблока) там как бы они не мешали свои биты выводимые, как я понял тоже по весовым разрядам, а все равно 0-ой бит и 15-ый бит выводятся "скраев", т.е. я так понимаю у них ЭТОТ баг тоже присутствует но как Вы уже написали выше он не виден скорее всего из-за разности частот вывода картинки и ее изменения... А может быть и из-за того, что предполагал я - частота то их шима (PWM free-running capability (refresh rate ~275 Hz with internal oscillator ~18 MHz)).

[GetSmart]

Протестировал я глюки "весового" алгоритма на новой своей процессорной железке с градациями. При правильном управлении глюки очень-очень слабые даже когда кадровая частота 50 Гц. Ниже уже сильно заметно мерцание светодиодов. Заметить их нереально если не знать когда и где их ожидать. Если у Вас они сильно заметны, то дело возможно в неправильном алгоритме.

Ну и заодно бонусом опишу здесь простейший (для FPGA) алгоритм дельта-сигма. Есть байт - яркость пикселя. Есть кадровая частота. Кадр делится на 255 (или 256) тактов (порций). Старший бит яркости (7-ой от нуля) отображается каждый второй такт, то есть в 1,3,5,7...253,255 тактах. 6-ой бит яркости отображается каждый 4-ый такт, то есть в 2,6,10..250,254 тактах. 5-ый бит яркости отображается каждый 8-ой такт, то есть в 4,12..,244,252 тактах. Ну там так далее. 0-ой бит отображается только 1 такт ровно в середине кадра на 128-ом такте. Проще говоря, яркостные биты распределяются равномерно по кадру. Младший - в центре. Чуть более старший (1-ый) по бокам от него на 64 и 192 тактах. Никаких счётчиков, сумматоров и прочих сложностей персонально каждому пикселю не требуется. Чистая логика и один общий для всех счётчик. Никаких глюков при таком отображении не будет заметно, даже на кадровой частоте 25 Гц и ниже. Будет очень похоже на статический алгоритм развёртки. Хотя не совсем. На малых яркостях (буквально от 1 до 5) будет заметно мерцание если кадровая частота ниже 50 Гц. Но когда картинка более яркая уже ничего заметно почти не будет.

Сообщение отредактировал GetSmart - Jan 21 2009, 16:24

[yagger]

Ну и заодно бонусом опишу здесь простейший (для FPGA) алгоритм дельта-сигма.

Спасибо. Действительно интересный алгоритм. Для меня это просто неоценимая информация. (думаю не только для меня). Я вообще по инету ничего по этой теме вообще не нашел, вот только по вашим ответам уважаемый GetSmart и ориентируюсь - как это работает. Огромное спасибо еще раз.

[GetSmart]

Всегда пожалуйста.

Да, и сдаётся мне, что при таком алгоритме можно прямо на лету обновлять видеопамять (даже медленно) без глюков на экране. Процентов на 90 уверен в этом. Но руку на отсечение не дам

[yagger]

Но руку на отсечение не дам

[yagger]

Ну и заодно бонусом опишу здесь простейший (для FPGA) алгоритм дельта-сигма.

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

Сообщение отредактировал yagger - Jan 22 2009, 16:23

[GetSmart]

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

Да. Но скорость перезагрузки не выше чем была у младшего бита в весовом алгоритме. В алгоритме со счётчиками на каждый пиксель тоже приходится перезагружать все регистры каждый такт. Для FPGA это не проблема, а вот для проца этот алгоритм не подходит. Хотя можно и проц нагрузить процентов на 90. А остальные 10% он будет делать что-то ещё. Зависит от кол-ва регистров и пикселей на экране. Если их не очень много, то и 50% проц может отдыхать.

В FPGA логика не сложная. Есть счётчик 8 бит. Делит кадр на 256. По коду на нём выбирается код 0..7 в мультиплексоре 8-1, стоящем на выходе ОЗУ и выбирающем текущий бит из байта яркости. Ещё есть счётчик адреса в ОЗУ, который должен пробежать всю видеопамять за 1 такт первого счётчика. Пока он будет перебирать адреса с выхода мультиплексора будут идти биты на выход FPGA, а далее на сдвиговые регистры/драйвера к примеру MBI5026. Таких мультиплексоров и однобитовых выходом можно сделать много для разных плат со светодиодами.

[add]

Всегда пожалуйста.

Да, и сдаётся мне, что при таком алгоритме можно прямо на лету обновлять видеопамять (даже медленно) без глюков на экране. Процентов на 90 уверен в этом. Но руку на отсечение не дам

Где-то я такой алгоритм у нас на форуме уже видел
http://electronix.ru/forum/index.php?showt...37510&st=75

[yagger]

Уважаемый GetSmart, тут еще пара вопросов возникла...
(дело в том, что я как раньше писал с ПЛИС пока на ВЫ, да наверное это еще и круто сказано, думаю если уж и учиться, то на толковом проекте )

Если использовать плис без собственной внутренней ОЗУ и учитывая, что ОЗУ требуется в принципе незначительно (32х32 пикселя 3 цвета = 3072 байта всего) такое кол-во байт адресуется 12 битами, можно ли (в качестве эксперимента, а может и так тоже делают?) использовать 2 независимые микросхемы памяти? как на картинке внизу.[attachment=29030:______RGB.jpg]

Сообщение отредактировал yagger - Jan 23 2009, 19:17

Эскизы прикрепленных изображений

 

[GetSmart]

Зачем две? Ram Buffer и Video Ram ? Лишние 22 минимум сигнала/ноги от FPGA ко кторой раме. Узкое место - копирование из одной рамы во вторую. Проще уж сделать две видеостраницы в одной раме. Неактивная будет буфером для принимаемых по кабелю данных. А вообще, с внешней микросхемой байтовой памяти получается неудачно. При кадровой 50 Гц поток данных только на чтение видеопамяти будет 40 МБ/сек. Если 16 битная рама, то 20 МБ/сек. Но тоже очень много, хотя уже более реально для дешёвых микросхем. Но это без учёта приёма в них новых данных по линии связи. Не самый плохой вариант - сразу поступаемые видеоданные разделить на битовые плоскости по 384 байта и так передавать в экран. Тогда нагрузка на внешнюю раму будет в 8 раз меньше, то есть 5 МБ/с на отображение и ещё сколько-то на перезагрузку данных. Часто на перезагрузку делают столько же, то есть ещё 5.

[yagger]

Проще уж сделать две видеостраницы в одной раме. Неактивная будет буфером для принимаемых по кабелю данных.

Брр. А как тогда во времени в таком случае делается адресация? доступ то к памяти должен быть фактически независимый! одна сторона в память (например с 0 по 100 адрес) пишет, а вторая сторона в то же время (с адреса 101-по 201) читает и выдает данные в регистры. Или я что то опять не так понимаю?

[GetSmart]

Брр. А как тогда во времени в таком случае делается адресация? доступ то к памяти должен быть фактически независимый! одна сторона в память (например с 0 по 100 адрес) пишет, а вторая сторона в то же время (с адреса 101-по 201) читает и выдает данные в регистры. Или я что то опять не так понимаю?

Самое простое - по очереди с мультиплицированием адреса. Ещё есть интересные варианты, но надо знать предельную скорость поступления данных из вне.
Например так. За 1 такт (яркостный, которых 256) требуется перезагрузить 3Кбит регистров. На самом деле скорость обращения к раме выбирается 4К. Когда по каналу связи данных нет, то из рамы считываются данные и идут на сдвиговые регистры. Когда поступает байт по связи, то сдвиг регистров приостанавливается на 1 такт, а в это время происходит запись в раму принятого байта. Ну а перезагрузка (Load, ~LE) сдвиговых регистров должна происходить строго синхронно, то есть после 4К тактов.

[rezident]

Брр. А как тогда во времени в таком случае делается адресация? доступ то к памяти должен быть фактически независимый!

Поскольку независимый доступ во втором случае не выходит делают временнОе разделение доступа. Циклы доступа к памяти чередуются.

[yagger]

Самое простое - по очереди с мультиплицированием адреса. Ещё есть интересные варианты, но надо знать предельную скорость поступления данных из вне.
Например так. За 1 такт (яркостный, которых 256) требуется перезагрузить 3Кбит регистров. На самом деле скорость обращения к раме выбирается 4К. Когда по каналу связи данных нет, то из рамы считываются данные и идут на сдвиговые регистры. Когда поступает байт по связи, то сдвиг регистров приостанавливается на 1 такт, а в это время происходит запись в раму принятого байта. Ну а перезагрузка (Load, ~LE) сдвиговых регистров должна происходить строго синхронно, то есть после 4К тактов.

Вай... Нееее, мне видится все же проще будет использовать внутреннюю память для обеих страниц... и просто переключаться между ними. А то с этим разделением адресов я чувствую зависну и не начав.

А жертвой, я так понимаю, будет просто напросто максимально возможное разрешение блока управляемого 1ой плиской?
Кстати, а в алгоритме дельта-сигма не требуется перетасовка байт побитно! Это радует.