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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

То что Вы описали, вполне "законный" глюк такого управления светодиодами. Хотя сам я почему-то за 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. Достаточно поднапрячь фантазию и возникает масса способов. Тут главный вопрос, важно ли сохранить приемущества именно весового алгоритма, потому как с другого "краю" возможных алгоритмов стоит дельта-сигма вообще без глюков в визуальном восприятии, но требующем больших аппаратных затрат на уровне спартанов и циклонов.

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

Протестировал я глюки "весового" алгоритма на новой своей процессорной железке с градациями. При правильном управлении глюки очень-очень слабые даже когда кадровая частота 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 и ориентируюсь - как это работает. Огромное спасибо еще раз.

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

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

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

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

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

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

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

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

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

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

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

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

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

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