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

[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]

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

[yagger]

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

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

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

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