Прошу (как обычно при таких вопросах говорят на форумах) сильно не пинать...
Поправьте меня пожалуйста если я где то ошибся: имеем панель 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 а поменьше???

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


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

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

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

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

Для справки, на 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, то можно слать сжатый поток и декодировать его в рилтайме.

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



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