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

ЭТИ дела делаются на драйверах светодиодов с возможностью управления током каждого выхода.
ШИМ - это решение для табло в пионерском кружке

ммммм.... Т.е. китайцы до сих пор пионеры и строят по такой технологии тоже?
Просто я сколько видел на выставках на таких драйверах как DM163 совсем нет экранов, а вот на простых mbi почти все!!!! и при чем статическая индикация. Так как они ими управляют?

И кстати мне почему то кажется, что именно на этом принципе строит (или строил) уважаемый ledmaster. Как я посмотрел на форумах он вроде как хорошо отзывался о драйверах TI, а они почти аналоги MBI5026 к примеру. (и при этом он упоминал о тысячах используемых этих драйверов в его разработках).

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

Т.е. ГРУБО говоря у них обновление как ШИМ так и КАДРОВ идет к примеру с частотой 100 Гц????

Не верьте ему! Он фальшивый
yagger
У вас расчёт верный. Только умные люди перезагружают эти регистры по параллельной шине, а не через одну линию. Например через 24 линии и по каждой будет передано 32 бита для перезагрузки всех регистров табло. Таким образом длительность одного бита вырастет в 24 раза и будет 400 нс. Все подобные вещи уже давно можно было делать на уже состарившейся элементной базе. Сейчас база озволяет делать всё в десятки раз круче.

Ошибся. По каждой из 24 линий будет передано 32*3 бит. То есть 6 регистров MBI5026 (16-разрядных) в цепочке.

А тут все фальшивые, настоящие только (оглянувшись) модераторы.

Я говорил, с чего бы я начал такой проект. Но я его никогда не буду делать - нет шансов сделать сложное табло дешевле, чем в Китае. Простое - запросто
По Дискавери недавно показывали, "Как это делается", но тонкости электроники конечно не затрагивали.
Посмотрю в понедельник, может фотки найду.

GetSmart дело в том что я пока в расчете и не затрагивал "загон" в регистры меня на самом деле интересует время считывания из озу... Даже если взять озу с временем доступа 5-10 нс (а я расчитывал на 12-20) то за 16-17 мс необходимо сделать все остальное (записать с другой строны байты(я имею ввиду со стороны приемника потока 25-30 кадров), далее загнать в регистр текущий бит, но перед этим сравнить в счетчике шима и т.д. не говоря уже о том что я наверное еще что то упускаю)
Я кстати на параллельную шину сразу и расчитывал, ввиду многих причин...
Но что то я не понял как это время вырастет до 400 нс???? мне то разницы на самом деле нет выставлять бит на параллельную шину или на последовательную (если бы БАЙТ это другое дело)...

Да и еще, Dog Pawlowa, в одном форуме видел хорошее замечание " Титаник делали профессионалы, а ковчег - любитель!" и если придерживаться позиции что китайцы всех победят, то можно завтра закрывать почти все фирмы и производства и у нас и у вас в стране...(хотя на самом деле я не знаю откуда вы). Просто есть такая вещь как маркетинг или например личные договоренности в особых кругах сбыта, где ни какие китайцы не пробьются.

Что-то вы не то насчитали. У вас 24*32*3*8*100 бит/с для приведенных вами условий, иными словами - 542,5 нс/бит.

Начните уже сразу мыслить широко. У вас что однобитное ОЗУ ? Тогда вам труба! Профи всё это делают внутри FPGA. Там и ОЗУ бывают по 10 КБ и логики выше крыши. Да и скорости еденицы нансек. Я конечно разжёвывать всё до мелочей в схемотехнике и алгоритмах не буду, так, пару советов могу дать.

Хм, это не форум сантехников? Всякий уважающий себя инженер должен пахать широко


Угу.
"Зато мы делаем ракеты..." (с) Ю.Визбор
Тогда договориться можно и с президентом.

??? что то мне подсказывает что у вас не то что то...
хотя я все же могу ошибаться.
24*32*3=2304 физических точки.
теперь следую алгоритму: берем из озу 1 байт(8 бит) сравниваем его со счетчиком (к примеру в ПЛИС) и по результату сравнения выставляем 0 или 1 на шине данных, стробим, читаем след байт(8 бит) и так 2304 шт, после этого подаем строб LE. На этом этапе первый такт ШИМа загружен в регистры. И таких разворотов нам надо 256 (так как шим 8 битный). И вот эта последовательность и есть картинка за 10 мСек так как 1 сек/100 Гц=10 мСек. а Если так, то 10 мСек/256=39 мкСек на 2304 байта, а соответственно 39 мкСек/2304~17 нСек на выборку 1 байта (который сравнивается с счетчиком) и установку 1 бита на шине данных. Где ошибка???

Так делают любители, вроде ledmaster. Ковчег наверно тоже он делал. Зачем по 256 раз сравнивать один и тот же байт (яркость)? Берёте младший бит, отображаете его 1 такт. Берёте второй, отображаете 2 такта. ... Берёте 4-ый бит, отображаете его 16 тактов. ... Берёте старший 7-ой бит, отображаете его 128 тактов. Никаких сравнений не надо. Сразу после начала отображения 7-ого бита оперативка освобождается для перезагрузки новыми данными. То есть 1/2 времени она гарантированно не используется (реально 97%). Что бы не париться и не читать из ОЗУ байт ради одного бита, делается так:
Заранее в ОЗУ записываются не байты яркости пикселей друг за другом, а уже разрезанные на 8 плоскостей данные. Таким образом если память байтовая, то чтение одного байта извлечёт данные для 8-ми пикселей и должно длиться 17*8 ==> 136 нс. Однако, уже подчёркивал, что делать это на рассыпухе - школьное подельничество. FPGA или ARM-проц. Они же могут раскрутить в 10 раз большее табло.

GetSmart, огромное спасибо за достаточно подробное описание алгоритма, я прошу прощения, возможно бестактно с моей стороны будет спросить, Вы строили данные девайсы? Конечно можете не отвечать, просто я сколько читаю форумы там чуть ли не 90 процентов теоретики и философы. А по поводу ledmaster я просто видел его высказывания в форуме ledforum.ru и у меня сложилось о нем некоторое мнение.(я его не считаю любителем). Любитель это я точно... Правда стараюсь выбраться повыше. Как говорится "Завтра начну жить с нуля. Только до него еще добраться надо."

Да, строил. Знаю там каждую крупинку. Поверьте мне, никаких побочных эффектов на неподвижном табло не наблюдается. Даже на не сильно подвижном тоже.