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

[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 а поменьше???

[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) алгоритм дельта-сигма.

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

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