Arduino.ru

к чему подключаете-то?

4 шт 32x64 - это 8К точек, не всякая плата потянет

К меге. Ну да это не суть, в понедельник буду пробовать единичными сигналами по контактам что-нибудь получить. По идее вся матрица это набор сдвиговых регистров, последовательно и параллельно соединённых. Контакты R1 G1 B1 и R2 G2 B2 полюбому на регистры эти ведут, а вот что на контактах А В С D, и как с этим работать - хз. Самое интересное, что А В С D сидят на аналоговых контактах, на амперке нашёл статью со схожей панелью, там эти контакты за выбор адреса строки отвечают, но по какому принципу? Вот ссылка на статью http://wiki.amperka.ru/%D0%BF%D1%80%D0%BE%D0%B4%D1%83%D0%BA%D1%82%D1%8B:rgb-led-matrix-64x32

Адрес строки (вернее двух строк, т.к. вывод идёт сразу в две строки). адрес - просто 4-битное число от 0 до 15.

Ну, там же у Амперки есть нечто вроде даташита, там всё нормально прописано.

Мега никак не потянет.  4 матрицы, как уже сказал - это 8К пикселей, причем пикселей RGB - то есть по минимуму 2 байта на пиксель. Простая математика показывает. что только для буфера вывода на панели нужно 16К оперативки, а у Меги всего 8.  Да и по скорости обновления Мега даже близко не подходит.

Я работаю с такими панелями на СТМ32 (своя библиотека на основе RGBmatrixPanel). Однако даже для СТМ 4 таких матрицы - это предел по скорости обновления, если нужен хотя бы 4битный цвет.  Если у вас какая-то реальная задача - возможно будет интересно пообщаться. Если просто для самообразования - советую для начала почитать вот эти статьи:

https://www.sparkfun.com/news/2650

https://learn.sparkfun.com/tutorials/rgb-panel-hookup-guide/all

Ну и вообще в инете много информации

Совершенно непонятно, нафига методом тыка "единичными сигналами по контактам" что-то пытаться получить, если есть документация, а самое главное - есть исходный код готовой библиотеки RGBMatrixPanel, из кода которой совсем несложно выяснить все принципиы управления матрицей.

Чтобы подключить к RGBMatrixPanel больше 64 пикселей в ширину - надо просто убрать из кода явно забитые там константы размеров матрицы и все заработает (при условии, конечно, что памяти хватит)

ЕвгенийП, а 4-битное число отправляем кодировано на все 4 контакта? т.е. на А допустим 0 B 1 C 1 D 0 ? так?

И как понять вывод сразу в две строки? У нас есть матрица 32х64 как этот адрес к ней применим?

Т.е. можно пример?

Там у амперки маловато инфы, и всё завязано на библиотеку, а с неё прикурить несколько таких матриц не получилось.

Вы бы для начала изучили принцип работы этих панелей ...

b707, спасибо, прочитаю. 

Есть и реальная задача и для самообразования.

В библиотеке пока разбираюсь.

upd. 

Komandir, уже занимаюсь.

Если хотите использовать 4 таких матрицы - берите сразу СТМ, Есп или Дуе. На меге это в принципе не заработает, не тратьте время.

Если "реальная задача" действительно реальная :) - обращайтесь. Я этой темой плотно занимаюсь два года.

На Меге вполне заработает.
Скорее всего даже на Уно.
Без буфера, трансляция с внешней флеш памяти массивов на матрицу

Кактус, ты точно понимаешь, а чем говоришь? :)

вывод на такие матрицы - сродни динамической индикации, меняется картинка на матрице или нет - все одно нужно шарашить 16 сканов на каждый бит цвета не менее 200 раз в секунду

СТМ32 загружен выводом на 4 матрицы близко к 100%. Уверен, что Уно потянет?

Я про динамику и скорость отрисовки ничего не говорил.

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

ну если на матрице в каждый момент времени засвечивается только 2 строки из 32х - как ты без динамики обойдешься?

ну да в пределы дуни вы уже уперлись :)

Смотрите исходник, библиотека RGBMatrixPanel сразу создает буфер под все матрицы:

int buffsize = width * nRows * 3

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

Чтобы организовать работу с внешнего носителя, как говорит Кактус - надо полностью переписывать библиотеку.

int buffsize = width * nRows * 3

Вот была такая мысль, но отгоняю пока. Всё-таки усилий порядком приложить придётся.

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

у вас стоит задача использовать именно дуни? МК стоит подбирать под задачу. а не тратить кучу усилий, запихивая невпихуемое

Не пойму. что Вам мешает взять. например. ЕСП32 - плата не дороже меги и тоже программируется в Ардуино ИДЕ.

А при подключении по дуне на матрицу вы поимеете новую проблему - как обеспечить их синхронную работу со скоростью обновления матриц

Ну, тут более отношение имеет чтобы мк на макетке стоял, потом уже наличие библиотек, потом среды разработки и отладчики, а дальше я ещё не придумал =)

Крч решающий фактор это сборка беспаечным методом. 

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

Макетка для этого не нужна, вот так вот можно подключится к любой плате - к меге, ЕСП, СТМ...

b707, так и сделано =) только проводов больше, ну да это осталось в офисе, а пока - приятных выходных!

понятно что больше, там почти все пины плоского кабеля должны быть задействованы :)

вам того же, будут вопросы - приходите

У меня на каждой матрице сидит ATMega32A, тогда как раз хватает пинов на всё - на матрицу и на управление из общего командного центра. Она же и занимается динамической индикацией своей матрицы и её буфер хранит.

любопытствую почему именно оперативки не хватит? шрифт можно во флеше хранить к примеру, картинки тоже, вконце концов можно флешку на SPI повесить и грузить с нее. 

ответ выше в теме.

Приветствую

а откуда у нас по 2 байта на пиксель получается? На сколько я разобрался в отрисовке, сперва на экран сливается строка, в моём случае в 256 бит (6 строк таких всего), потом дёргается контакт Latch и контакт OE и строка "запекается", а перед этим происходит выбор самой строки контактами  A B C D, отсюда считаю (256*6*16)/8 = 3072 байта, это один кадр, так? Или я что-то где-то забыл, ну, т.е. тут не учитывается ещё clk и ресурсы на ядро, а что ещё?

забыли умножить на глубину цвета.

Так, а глубина цвета как у нас реализуется на платах этих? Я что-то из статьи не сильно понял.

Т.е. как мне сейчас представляется, глубина цвета достигается определённой частотой мерцания светодиода, а в случае такой матрицы - мерцать будет вся строка, нет?

Евгений, а можно подробнее про "управление из общего центра" - из центра посылаете только команды или картинку тоже? На каком протоколе связь организована?

лучше чем в статье - я не обьясню.

Изучайте вот тут https://www.sparkfun.com/news/2650

Начмная с заголовка "A Rainbow of Planes"

Из той статьи я понял, что глубина цвета достигается мерцанием, т.е. частотой смены кадра, чем выше частота, тем более глубокий оттенок можем получить. Наш видимый кадр состоит из нескольких промежуточных кадров, где, допустим, при 25 кадрах/сек светодиод загорится скажем 13 раз, что даст ему суммарную яркость чуть больше половины от максимальной, как если-бы он все 25 кадров был зажжён, и эти 13 раз мы равномерно распределяем по всем 25 кадрам.

Т.е. проблема скорее в вычислении самого полутона и расходовании мощностей на это, потому как один кадр нужно просчитать как 25 разных. В таком случае отдать отрисовку отдельным контроллерам - хорошая идея, вот только по какому каналу связи сливать им эти кадры?

Можно, допустим, по rs485 сливать слейвам кадры, после посылать мультикастом команду на отрисовку, чтобы одновременно начали. 

мы с вами говорили не о затратах на вычисление, а о необходимой памяти. С этой точки зрения все просто - вычисленный вами выше размер буфера 3072 байта - это при условии кодирования каждого цвета одним битом. Несложная математика показывает, что для трех каналов RGB такое кодирование даст только 8 цветов. то есть о любых оттенках можно забыть.

Чтобы получить более-менее полноцветное изображение, библиотека RGBMatrixPanel использует 4хбитный цвет, соответственно необходимый буфер придется увеличить в 4 раза - то есть потребуется уже 12К только на матрицы.

Получается, что, допустим, нано не вытянет даже одну панель 32х64 в полноцветном режиме. Ок пошёл выбирать новый контроллер.

Спасибо, вы очень помогли разобраться в теме. Возможно ещё появятся вопросы, рассчитываю на вас в будущем.

С текущей библиотекой - нано не потянет.

Будете выбирать контроллер - учитывайте, что для вывода динамичных картинок желательно использовать двойную буферизацию (см в библиотеке) - то есть памяти нужно еще в 2 раза больше

Может просто в мегу докинуть оперативки? Хм...

Вроде нашёл, https://datasheet.su/news/3819:2016-02-01 такое действительно возможно.

по мне так куда проще (и в разы дешевле) взять готовую плату с памятью побольше

например СТМ32 за 130 рублей

У нас в РБ цена чуть меньше, рублей 80 =) по курсу 1 к 30.32 =( 
Хотя есть и слегка дешевле, но всё равно. В запасе лежат только дуни, а из Китая стмку ждать довольно долго.

А, ну и нашёл вот такое https://www.chipdip.by/product/23lc1024-i-sn-microchip , попробую, посмотрю.

не вариант, эта память медленная лучше брать обычную параллельную SRAM (я пользую UM61256CR-20 32кб сняты с материнских плат то-ли 386 то-ли 486) и регистр типа 74HC573D (лучше 74F573) и на них сваять расширение памяти для атмеги 128 (256) эта память будет именно расширением ОЗУ атмеги т.е. в ней можно будет организовать буфера для вывода и обращатся к ним напрямую как встроенному ОЗУ а не через процедуры ввода-вывода последовательных данных 

Если что, вот здесь про них с примерами кода. Со второго поста именно про эти, но первый читать надо, т.к. код один и тот же.

Благодарю.

Полезная информация, спасибо.

в чипе-дипе - https://www.chipdip.by/product/ut62256cpc-70ll

Связь на SPI, посылаются команды типа "цвет для пиксела по адресу",  "цвета для пачки пискелов с адреса", "скролл" и т.п., но давайте попозже, пока всё в работе и на живую нитку - меню каждый день.

ок, буду ждать