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

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

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


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