[picman 0]

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

[GetSmart 0]

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

[picman 0]

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

[GetSmart 0]

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

Изменено 21 января, 2009 пользователем GetSmart

[picman 0]

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

 

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

[GetSmart 0]

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

 

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

[picman 0]

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

 

:)

[picman 0]

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

 

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

Изменено 22 января, 2009 пользователем yagger

[GetSmart 0]

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

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

 

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

[add 0]

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

 

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

Где-то я такой алгоритм у нас на форуме уже видел

http://electronix.ru/forum/index.php?showt...37510&st=75

[picman 0]

Уважаемый GetSmart, тут еще пара вопросов возникла... :rolleyes:

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

 

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

Изменено 23 января, 2009 пользователем yagger

[GetSmart 0]

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

[picman 0]

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

 

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

[GetSmart 0]

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

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

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

[rezident 0]

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

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