[GetSmart 0]

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

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

 

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

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

[picman 0]

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

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

[GetSmart 0]

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

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

[picman 0]

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

 

http://www.d-sign.com/viewtopic.php?t=626&...asc&start=0

Добавлено: Пн Фев 18, 2008 2:49 pm

"хотя правды я тоже не скажу, это ноу-хау."

[GetSmart 0]

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

[picman 0]

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

 

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

 

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

 

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

Кстати, не подскАжите? если для переноса потока видео взять Ethernet, то как там аппартаный или тоже программный :07: надо воротить?

[GetSmart 0]

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

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

 

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

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

[picman 0]

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

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

З.Ы. Спасибо за ответы, :beer: очень помогают. А по поводу "дальше не принимать DVI", я как то застопорился :05: думал все как это сделать так чтобы ни одного кадра не пропустить, а с вашим ответом понимаю что в действительности то все равно кадров "поймаю" больше чем реально в видеороликах отображается (25-30). Честно говоря я впервые залез на форум и действительно получил неоценимую информацию, сам я точно в елках да березах блуждал бы еще дооолго! :)

[Mikhail1954 0]

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

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

 

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

 

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

[adc 0]

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

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

[GetSmart 0]

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

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

 

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

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

 

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

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

 

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

[picman 0]

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

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

[GetSmart 0]

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

[Mikhail1954 0]

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

Не знаю, что в точности значит "симметричный", хочу пояснить суть проблемы.

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

 

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

 

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

 

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

[picman 0]

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

 

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

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

 

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