Подскажите плз как можно организовать Светодиодный экран, а то со строками все просто а тут и скорости нехватает да и вообще может есть какието надорогие миркухи для обслуживания сего дела

Да какая разница экран или строка? Специализированных микросхем нет. Обычно используются ПЛМ или микроконтроллеры.

На что именно не хватает производительности и какой именно микросхемы?


На самом деле производительности МК с ядром AVR практически достаточно для прямого вывода TV сигнала. Проблема в другом - посчитайте на калькуляторе скорость передачи этой информации. Необходимо либо TV сигнал разбивать на куски предварительно либо сжимать. В первом случае требуется достаточно мощный промежуточный микропроцессор, да и задача непростая. Во втором МК не справится с декомпрессией видеосигнала. Короче проблема больше в передаче сигнала. На больших экранах с данной задачей справляется IBM с платой вместо видеокарты, построенной на ПЛМ. Либо модуль на ПЛМ который снимает сигнал со стандартной VGA платы с DVI выхода. Далее (на ПЛМ) сигнал дробится на куски. Каждый кусок подаётся на свой модуль вывода. Обычно сам модуль вывода тоже делается на ПЛМ.


Если колличество градаций яркости на цвет невелико и не требуется прямого видео, то с данной задачей вполне справится AVR либо другой МК. Так у меня 4 градации яркости на цвет. Анимированная графика с частотой перерисовки 25Гц. С этим вполне справляется AVR. Попробую в новом проекте применить ARM и реализовать 8 градаций яркости. Это не так и мало на бицветных матрицах обеспечивается 64 цвета на полноцветных - 512. Что для рекламных целей вполне достаточно.

Вопрос именно как мк связать со светодиодами? Строку я делал(так там всего 12 регистров и один дешифратор)но индикачия получилась динамическая и при движении заметен наклон, и ничего с ним сделать я не смог .
а вот как AVR связать со светодиодами для экрана я незнаю?

Принцип динамической индикации применяется например в ЖКИ мониторах. Да и обычный телевизор можно рассматривать с этой точки зрения. Вы там наклон видете?

Совершенно очевидно что у вас ошибки в программе или неверный подход.

Обычно делается две страницы видеоэкрана. Одна отображается, во второй меняется изображение. По завершению изменения картинки меняются местами, но только с начала кадра.

Я здесь тоже видел такую бегущую строку - на экране виден снег, буквы двигаются рвано, подёргиваются. Это просто банальное непонимание теории.

В дальнейшем прежде чем браться за изделие - изучите теорию. Почитайте что сделано другими. Можно прямо на этом форуме. Например эту вот ветку http://electronix.ru/forum/index.php?showtopic=22921

Это все я конечно читал, и аниматеьно слежу за постами, НО посудите сами 96 светодиодов в каждой строчки и 8 строчек, заполнили первую (последовательно) - показали на какоето время, заполнили вторую, снова показали на какоето врем и так все 8!!!если картинка стоит то все хорошо!!! но если сдвигать буквы то получается эффект "наклона" чисто визуальный эффект в глазах(если чильно прищюрится или посмотреть через маленькие щелочки этого эффекта нет). так вот и спрашиваю как смастерить железку чтобы этого (или подобного небыло).а сам я программист а не электронщик.

Значит ошибка у вас не в программе а в алгоритме и электроника здесь совершенно не при чём. Кстати у меня базовый модуль 144х16 в моно или 288х16 в бицвете. Принципиально я могу сделать в несколько раз больше и подёргиваний не будет. У меня проблемы только с размерами печатной платы. При этом в моно цвете я обхожусь без регистров.

Если вы работаете с регистрами, то с какими именно?
Честно говоря не понимаю что вы имеете ввиду под "эфектом наклона"?

Я попробую вам объяснить именно как программисту.

Для начала: Забудьте про движение и различные эффекты. Разбейте вашу программу на задачи. Воспринимайте каждую задачу как отдельное устройство.
Таким образом у вас существует (грубо) модуль приёма/передачи, модуль обработки (формирования изображения), модуль отображения. У меня последние две задачи синхронизированы. Регенерация изображения осуществляется с частотой 75Гц. Обновляется изображение (изменяется) с частотой 25Гц или каждый третий кадр и только в начале кадра. Поскольку задачи разделены, то у меня принципиально не может изменится картинка во время её отображения. Имеются две видеостраницы. Пока одна отображается (по указателю) вторая изменяется (например сдвиг текста). Потом указатели меняются местами.

Подумайте и укажите что вам непонятно?

Извините, что вмешиваюсь, но мне кажется рассуждать с таким опломбом позволительно лишь специалисту. SasaVitebsk, рекомендую потусоваться на форумах светодиодников и хотя бы для себя выяснить, как устроены строки/экраны и что означают базовые понятия типа "эффект наклона букв" или "неровные края линий при чересстрочной развёртке" или "почему нельзя сделать всё просто и без проблем". А то теоретически давать советы, не зная о существующих проблемах, имхо, неуместно. Простой пример: увеличьте размер вашего модуля раз в ...дцать (до размера обычных светодиодных экранов 320*240 пикселов * 3 цвета * 8 бит на цвет) и прикиньте, что изменится и можно ли будет всё так же лихо сделать. А явление "наклона букв" больше полезное, чем вредное, только в вашем случае (при тройном отображении каждой картинки) вместо эффекта наклона будет эффект размытия, что, конечно же, есть исключительно вредное явление, т.к. утолщает символы и ухудшает читабельность. А количество видеостраниц - это софтовые мелочи, которые решаются в последнюю очередь.

Люди не переходите на личности,самое паршивое дело,форум для разговоров и передачи информации от одного к дургому. сорри за оффтопик.

Кстати вот на счёт эффекта наклона, если вы были в Минске посмотрите вечерком на батькину библиотеку. Ну так вот, когда выводится строка по кругу, действительно есть эффект заваливания букв. Я так понимаю он означает , что вывод того или иного изображения происходит слева на права и снизу вверх (по крайней мере на библиотеке вроде так) отсюда выходит,что нижнии "пикселы" перерисовываются быстрее чем верхние. Ну и как результат смотришь и видишь, будто пол у букв бежит влево,а буквы валятся вправо. Чем быстрее двигаемся тем критичнее время вывода строки.

dkostik попробуйте сделать так: забейте прерывание от таймера раз эдак 100 в секунду. Во время прерывания будете выводить из своего буфера на ноги контроллера. Ну и два буфера,один из них активный,тоесть тот который будет отображаться в перывании. Во второй вы будете писать что пришло через uart к примеру, ну и сдвигать,если бежим куда-то. Как отработали в основном цикле второй буфер,сделали его активным -> он выводится в следующем перывании,работаете с первым.Зачем лишняя волокита с третьим кадром,что советует SasaVitebsk, я не пойму. Поставил флаг о смене изображения -> перирисовал,нет флага валишь старые.

SasaVitebsk вопрос к вам. Вы делали бицветную матрицу на 4 градации. Вот в общем-то чтоб развить это ещё больше я так понимаю всё дело стоит в ЦАП. Очень интересно как вы поступили для управления светодиодами. Ну вот у меня что-то ничего умнее например четырёх ног регистров и каждый регистр добавляет по резачку на делитель. Больше резаков больше току.... 4 резака - 16 градаций. Ну это ладно,а как пашут панельки RGB на улицах? Еслиб подвешивать резаки линейно поднимая ток было бы всё просто,да вот незадача,нелинейны характеристики светодиодов. А это надо очень чётко отработать прогой, иначе цвета поменяются. Хотелось бы узнать,мож есть простой и эффективный способ для решения нелинейности: сила тока->сила света,кроме програмного. И ещё такой вопрос,какой блок питания вы используете. Вот видел проблемку когда сканировании картинки начинаются приколы типа изменения яркости. Блок питания не успевает чётко отработать ввиду инэрционности и напряжение начинает скакать. Ну может на небольшом экране эт не так чувствуется.хотя 288х16 это есть 4608 светодиодов,прикинуть по 10мА на каждый ну если по максимум то колебания тока могут составить в моно режиме(по 2 светодиода за пиксель) 288*0.01=2.88 Ампера. 75 герц регенирации,частота строк 1200 герц. Выходит от строки до строки ток может прыгать от нуля до 3 А за время меньше 1 мс. Ну до какого-то размера панели увеличение ёмкости выходных фильтров дадут толк,но так и до фарадов можно дойти

Эффект наклона - это следствие построчной однократной развёртки. Особенная прелесть в том, что при торможении бегущей надписи буквы выпрямляются, как будто ба натолкнулись на препятствие и по инерции проехали ещё чёть-чуть, и этот эффект достаётся абсолютно бесплатно (без софтовых изощрений) - лишь благодаря свойству глаза и мозга строить целую картину по мгновенным "снимкам".

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

Я вот тут такую арифметику прикинул. Если делать полноцветный экран на RGB-светодиодах, то чтоб получить телевизионную четкость необходимо 625 х (625/3*4) = 520833 светодиодов. Если умножить на цену 1 светодиода, то даже при самой небольшой общая сумма получается очень и очень. Конечно экраны дорогие, но разьве настолько? Что я понимаю не так и как оно на самом деле?

8 килобаксов за кв.метр - минимальная цена

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


Если честно вы меня не совсем поняли или я вас не совсем понял. Какая разница третий или второй кадр? Этим просто определяется соотношение скорости перемещения изображения к частоте развёртки. У меня с точки зрения отображения картинки - она полностью статическая. Если я вывожу прямо по ходу развёртки, то наблюдается эффект ломки букв или изображения или подёргивания.

Ааааа понял. Перечитайте мой пост ещё раз. Буфера у меня два. Один отображается один меняется также как вы и советуете.



Градации яркости получаются ШИМом. То есть при отображении строки у меня три прерывания. При 8 градациях их будет 7. Да есть нелинейность. Я её выставил один раз. У меня процентное отношение получилось такое 15+25+60 в процентах. При общей регулировке яркости придётся соотношение менять.



Ну и последнее. CD_Eater перечитайте свой пост ещё раз. Посмотрите сколько вы полезной информации дали по данному вопросу. Если я в чём-то не разбираюсь, то я с большим интересом выслушаю вас и, возможно внесу улучшающие изменения в свой проект. А посты типа "ты дурак" а чтобы убедится в этом "полазь по интернету убедись сам" вызывают просто раздражение. Короче если есть что сказать - скажи или кинь ссылку на конкретную информацию.

Человек разработавший и железо и софт к сабжу и есть специалист по сабжу. Советы такого специалиста в любой форме могут быть в разы полезней чем советы "теориков", которые знают про эффекты, прочитали много книг и статей, но сами нифига не сделали.. (но это к вам, конечно же не относится).


на 4-8ms матрицах уже этого эффекта не наблюдается..

Вот это как раз то что и есть.
Так скажите плз. это из за железки так получается?
И как зделать железку чтобы его небыло ну хотябы блок 16*16?

Приведу конкретный пример: строка высотой 8 пикселов, обновление 50 Гц, сканирование по горизонтальным линиям снизу вверх, каждая линия отображается 2.5мс, 8 линий(кадр) - 20мс.
Условное расположение светодиодов(правый край строки):
... 24 16 08
... 23 15 07
... 22 14 06
... 21 13 05
... 20 12 04
... 19 11 03
... 18 10 02
... 17 09 01
Если включать на 2.5мс по одному каждый светодиод по порядку 01,02,03,04... т.е. реализовать одиночный "бегущий огонь", то визуально получится перемещающийся вертикальный столбик, наклоненый вправо вверх. Опять же визуально, соседние пикселы в этом столбике сдвинуты на 1/8 горизонтального шага, а полный наклон снизу доверху - один пиксел.

Иными словами, если я правильно понял, то мне необходимо сдвигать текст со скоростью 75 пикселей в секунду, при развёртке 75Гц чтобы добится данного эффекта? А что делать если двигать надо медленнее?

Да скажите как от него избавится???

Если честно, то я столкнулся пока лишь с пару неприятными моментами, которые меня раздражают.

1) Связан, по видимому, с минимальной величиной угла обзора. Таким образом есть оптимальная величина удаления наблюдателя от экрана. И определяется она расстоянием м/у светодиодами, то бишь величиной матрицы. При просмотре с расстояния более близкого - глаза устают. Я это проверял на любых светодиодных экранах при любой реализации. Кстати этот эффект наблюдается и на эмуляторе. При превышении данного расстояния я не вижу никого дискомфорта. При использовании фонтов типа 14х16 очевидно можно увеличить расстояние наблюдения, что учитывая единичный сдвиг в процентном отношении к размеру буквы, - увеличивает плавность сдвига.
2) Блики при ярком освещении. Пытаюсь подобрать различные покрытия. Конечно было бы оптимально использовать антибликовое покрытие и тонирование для увеличения контрастности. Пока никто не делится секретами. Изучаю. Пробую. Пока до идеала в данном вопросе очень далеко. Но на солнце и светофоры гаснут! Так что выше головы не прыгнешь. Если требуется реализация на солнце надо как минимум отказаться от динамической индикации.




У вас это проявляется на любых фонтах? Толстых и тонких?

Да

Отказаться от построчной развёртки

Другими словами, отображать в статике.

Конечно, есть ещё метод постолбцовой развёртки, но выглядит это ужасно.

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

К тому же, статика перед динамикой имеет ещё одно преимущество: она позволяет значительно повысить яркость, т.к. светодиоды будут работать в естественном режиме, а не импульсном (со скважностью 1/8 и превышением рекомендуемого тока).


А куда вы торопитесь? Зачем вам 75 Гц? Поставьте 50, чтобы соответствовать нужной скорости. Хотя 75 - это нормально, обычно меньше не требуется (исходя из количества пикселей по горизонтали и удобной скорости чтения). В московском метро в вагонах используется именно 75 Гц, при этом буква пробегает ширину строки за пару секунд (если правильно помню, там строка из 17 индикаторов 8*8)

А оптический поликарбонат с поверхностью "муар" не пробовали? Это матовая такая... Может имеет смсл поверхность сделать в виде сот из пирамидок чтоб отражали падающий свет в сторону, где точно не может быть зрителей?

Вот одно из ваших заблуждений

Ну нат и все же как сделать экран?
хоть в статике

http://itp.nyu.edu/~lpm248/advMicro/LED/
Видеопанель

Прикольно!!! мне понравилось!!!!
1. я понял я один раз дал кадр этой микрухи и она сама обновляет матрицу?
2. ненужно никаких резисторов?
3. может она еще и яркостью умеет управлят.
НО У НЕЁ есть ОДИН большой минус!!!!!! - 12$ за штучку!!!!!!!!!!

Можно сделать на мс макроблок (типа mbi5026 и т.д.) они представляют из себя сдвиговый регистр с защелкой и управлением состоянием выхода ..Специально для таких целей. так же токовый выход для непосредственного (без токоогр.резюков) подключения светодиодов.
Заполняем все строки(регистры всех строк), а потом всем сразу команда "отобразить". и все пучком. Наклона небудет.
Удачи!

Начать с гугления "LED drivers"

уже начинал.
но хотелось бы узнать у людей про реальные схемы, да и заодно про проблемы по распрашивать.

интересно, а как решается вопрос соответствия светотдачи светодиода насыщености цветом в сигнале. Проще говоря. Нет цвета - светодиод выключен. Максимум - включен с максимальной яркостью. А по какому алгоритму определяется длительность свечения при промежуточных значениях? Зависимость линейная? Думаю, что нет.

Делали... Проблемы обозначены в соседней теме. Ничем не отличается принцип от 595. То же самое...
Только ток на выходе поболее, да и сам драйвер удобнее. (удивляюсь как МС в корпусе с шагом 0,635 "тянула" 800мА сумарный ток при полной засветке двух 8x8).
Пойду сегодня поближе гляну панели на улице. Проблемы скорей всего связаны с тем что светодиоды безинерционные источники света в отличие от кинескопов и ЖК-панелей. Статика - выход... но всё же матрицы удобнее.

Линейная.

Тут энерционность или ее отсутствие непричем.. Предложив MBI5026 я неподумал о цене.. т.е. без динамического отображения конечно их использовать будет оч. дорого. так что пордон мерси наверное нподойдет..
А на счет сдвига и энерционности дык это оч просто(как уже говорили..)
При динамике на 8 (8 строк)Обновление идет с начиная с первой строки к примеру. Обновили мы первую (данные сдвинули и отобразили) а остальные строки еще содержат предыдущее состояние. И вот пока обновление дойдет до последней строки глаз успевает засечь состояние строк обновленных и необновленных. осюда наклон текста при движении.

В шиме диодная хар-ка не учавствует т.к. Мы его то включаем то выключаем..:-) (ну разве что чють чуть на фронтах..) Тут большую роль играет особенности зрения.

Дя я понимаю. Я имею ввиду рассчет длительности включения в зависимости от присутствия цвета в сигнале и требуемой яркости "на экране".

Если сделать линейно дискреты(к примеру 0 до 255 с шагом 1) то на глаз будет зажигаться с крутой харкой. на глаз будет нелинейность.. Если сделать пологой (0-255 с переменным длительностью шага) то тада оч. даже неплохо.. только в минимальном значении будут наблюдатся ступеньки..если скорость наарстания будет медленной . Пользую такую таблицу. Конечно не идеал.. но вообщем работает приемлемо.

я вот думаю, может на досуге изваять люкс-метр и составить такую для светодиодов, что использоваться будут. По каждому цвету отдельно. Кстати, а если другие, то можно будет уже и по люксметру прикидывать яркость...

и еще. я тут прикинул - использовать три светодиода (R, G, выходит дешевле чем один RGB.

Глаз имеет логарифмическую характеристку чувствительности Y=lg(X).
Для того, чтобы ее точно компенсировать, таблица должна быть экспоненциальной X=Exp(Z)
Тогда Y=lg(exp(z)) = z

Z - освещенность объекта съемки или величина сигнала яркости (насыщенности цветом)?

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

Калибровать по телику. Формируем 256 градаций яркости цвета линейно. В темной комнате с всегда одинакого расстояния оцифровываем и записываем полученное значение (главное чтоб динамического диапазона хватило). Интересует характер зависимости. И так три раза. После чего формируем управление яркостью светодиода так, чтоб повторялась зависимость.

Да, в этом случае спектр прибора влиять не будет. Но! Что дальше?
Вы получите практически идеальную прямую (при больших токах начнется сложное влияние температуры, кстати, в том числе и на спектр излучения светодиода).
Поэтому прочитайте еще раз мой опус про логарифмическую характеристику глаза. Как в Вашем эксперименте Вы учитываете ее? Электроды в мозг?
Еще раз ...
Глаз имеет логарифмическую характеристику чувствительности Y=lg(X).
Y - "визуальная" освещенность X-реальная освещенность
Для того, чтобы ее точно компенсировать, таблица должна быть экспоненциальной X=Exp(Z)
X - ток светодиода (проценты ШИМ), z - реальная освещенность.
Тогда Y=lg(exp(z)) = z
т.е. Y=z

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

Но возникает вопрос линейности светоотдачи светодиода. Хотя... будем считать его безынерционным.

P.S. В предложенном мною способе для чистоты эксперимента прийдется уравнивать площади экрана телика и светодиодной панели. Дабы не наколоться на световом потоке.

[

Возможно, но полной уверенности нет. А в телике линейная зависимость светоотдачи от тока луча? Елки, никогда раньше не интересовался этим...



Предполагаю что изготовитеи телика и видеопродукта учли все до меня. Моя задача сводится повторить соответствие светового потока сигналу цвета.

Угу... Excel помогает в этом.


Он безынерционный и есть. Другое дело, что есть время переключения ключей и в матричном табло оно может влиять.

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

Народ, при чём здесь логарифмическая и экспоненциальная кривые, вы о чём?
На экране отображается уже подготовленный видеоролик, в том же самом виде, в каком он отображается на мониторе, например. Поэтому чтобы ролик перенести на светодиодный экран без перекодирования цветов, нужно сделать кривую яркости такой же, как и на мониторе. То есть, все логарифмические эффекты уже учтены в видеокамерах, снимающих изображение, и графических программах, генерирующих эффекты, а отображать уже готовый к показу видеоряд нужно пропорционально величинам цветов пикселов.
А рассуждения о логарифмической чувствительности глаза нужны лишь для создания эффекта равномерно по времени разгорающегося цвета. Эффект красивый, но к светодиодному экрану отношения не имеет.

Ваши же выводы.
1) Таким образом данный сдвиг зависит от частоты кадров. То есть от частоты регенерации изображения. При каком-то значении инерционность зрения не увидит этого сдвига.
2) Чем выше частота регенерации тем лучше. Но при большой частоте регенерации требуется высокая скорость сдвига изображения. Поэтому можно перейти на кратный вывод. Например один сдвиг на два/три кадра.
3) Не должно быть чёткой грани в проявлении данного эффекта.

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

Если в телике линейная, а как писалось выше, линейная не годится... путаница выходит. Надо что-то решать.

Будет размывание и утолщение. Как правило, на бегущих строках можно выбирать шрифт и режимы скорости. Побаловавшись с ними, всё равно останавливаешься на самом быстром без кратных кадров - остальные визуально много хуже.
А чтобы была нормальная скорость сдвига, нужно уменьшать расстояние между пикселями. Если 75 Гц ненормально, то это скорее всего значит, что вы рассматриваете крупную строку сблизи. В параметрах строк обычно приводится минимальное и максимальное расстояние комфортного обзора.


Годится, и только так и делают и никак иначе.

Давайте лучше поговорим всё же об избавлении или минимизации искажений изображения при динамическом способе индикации движущихся изображений. - Как это сделать? Я всё же считаю наклонные буквы не "красотой" а недостатком.

Мое мнение. Время регенерации должно быть намного меньше времени отображения и во всяком случае не выше 1/24 с на весь экран. Не видно же как в кино кадр меняют? Не видно. Значит и регенерацию не будет видно.

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


а вот и схемка просто забыл
Нажмите для просмотра прикрепленного файла

Программу переписать прийдется. А сколько столбцов всего?