- Автор темы Greyhom
- Дата начала
Parallel Output
The FastLED library for colored LED animation on Arduino. Please direct questions/requests for help to the FastLED Reddit community: http://fastled.io/r We'd like to use github "issues&...
github.com
Большую матрицу не проще ли делать матрицей?(тавтология). RGB светодиоды, 5 регистров сдвига с защёлкой и 5 транзисторов.
Адресные не очень для динамики. Порядка 1.5 мкс,если не ошибаюсь,на 1 бит,умножаем на 24=36мкс/1 светодиод и умножаем на 1600=57мс. Итого 20 кадров/сек. Но! Это тупо вывод на экран,без возможности любых прерываний.(на АВР). Тут только DMA поможет. На esp32 он есть вообще?
А параллельный вывод разве одновременный? Мне кажется там по очереди они выводят.
Адресные не очень для динамики. Порядка 1.5 мкс,если не ошибаюсь,на 1 бит,умножаем на 24=36мкс/1 светодиод и умножаем на 1600=57мс. Итого 20 кадров/сек. Но! Это тупо вывод на экран,без возможности любых прерываний.(на АВР). Тут только DMA поможет. На esp32 он есть вообще?
А параллельный вывод разве одновременный? Мне кажется там по очереди они выводят.
@te238s,Не имели опыт. Если не адресные, то что? Паять из 1600 светодидов? Или речь идет о готовых матрицах? Мы школа, нам чем дешевле, тем дешевле. Поэтому и работаем с адресными лентами.
Ну 20 кадров в сек. мне кажется это несмертельно. Для не самых динамичных игр. Подождут игроки. Или я не прав? Подскажите как лучше сделать и контроллер-то какой выбрать?
Ну 20 кадров в сек. мне кажется это несмертельно. Для не самых динамичных игр. Подождут игроки. Или я не прав? Подскажите как лучше сделать и контроллер-то какой выбрать?
@Alexs-vplicei, у гайвера где-то видео было, он большой экран делал на 7-ми сегментных экранах, возможно будет полезным.
Возможно и такое, но нужно будет разобраться с логикой подачи сигнала, минус управляемой ленты - это её линейность, а в матрице уже есть координаты
@te238s, мне кажется, есть натяжка в расчётах. Для RGB матрица представляет собой, по факту, три независимые матрицы (для каждого цвета). Итого - 16*3*2=96 контролируемых линий, а это, как минимум шесть 16-разрядных сдвиговых регистра. Даже если использовать построчную развёртку для 20Гц кадровой частоты потребуется переключать строки в 16 раз чаще (320Гц, при этом 100% яркости добиться не получится), а заполнение строчного регистра нужно будет делать с частотой как минимум ещё в 48 раз чаще (15360Гц).
Но основная проблема состоит в том, чтобы контролировать яркость светодиодов. Все вышеописанные манипуляции - для однобитового отображения. Чтобы обеспечить, например, 256 уровней яркости нужно обновлять строчный регистр ещё в 256 раз чаще (ШИМ нужно делать за счёт duty конкретного пикселя), а это уже почти 4МГц.
@Boroda22,
Для этого и делают несколько каналов управления лентой.
Но основная проблема состоит в том, чтобы контролировать яркость светодиодов. Все вышеописанные манипуляции - для однобитового отображения. Чтобы обеспечить, например, 256 уровней яркости нужно обновлять строчный регистр ещё в 256 раз чаще (ШИМ нужно делать за счёт duty конкретного пикселя), а это уже почти 4МГц.
@Boroda22,
Для этого и делают несколько каналов управления лентой.
@Alexs-vplicei,паять 1600 светодиодов это как налепить 10 кг пельменей,сначала жуть,но через часок-другой уже половина готова
Вопрос цены не решающий, адресные или RGB с кучей регистров стоят копейки. Вопрос лишь в трудоёмкости. Адресная лента вне конкуренции по простоте. А к ней прикрутить либо stm32,либо esp. С Esp я не знаком,а stm32 очень подходит,но опять же,нет радиосвязи,а это опять трудозатраты.
Надо гуглить аналогичные решения,наверняка они есть,а то очередной велик изобретаем))
@poty,как представляю я:
Динамическая индикация,т.е имеем 40 бит(5 байт,5 регистров) и 40 строк.
Итого для 20 Гцх40л=800раз переключать строки. И 800х5=4000 раз отправить байт в регистр.
3 цвета без градаций... 12000. Это 83мкс на один отправленный в регистр байт. Хрень получается какая-то.
Так,всё! Не слушайте меня! Сам знаю,лох)
Вообще проще считать,исходя из информационного объема одного кадра. В нашем случае это 1600×3цвета×8бит=14.4 кб.
Вопрос в том,в каком форматы проще и чаще можно выводить из МК.
Учитывая что необходимо не только выводить картинку,но и много считать и обрабатывать,смею предложить отдельно stm32 для вывода и Esp для прочих расчетов и радиосвязи. Короче разделение труда,ибо,как сказал @Boroda22, надобно ещё и в удобоваримые координаты переводить
Вопрос цены не решающий, адресные или RGB с кучей регистров стоят копейки. Вопрос лишь в трудоёмкости. Адресная лента вне конкуренции по простоте. А к ней прикрутить либо stm32,либо esp. С Esp я не знаком,а stm32 очень подходит,но опять же,нет радиосвязи,а это опять трудозатраты.
Надо гуглить аналогичные решения,наверняка они есть,а то очередной велик изобретаем))
@poty,как представляю я:
Динамическая индикация,т.е имеем 40 бит(5 байт,5 регистров) и 40 строк.
Итого для 20 Гцх40л=800раз переключать строки. И 800х5=4000 раз отправить байт в регистр.
3 цвета без градаций... 12000. Это 83мкс на один отправленный в регистр байт. Хрень получается какая-то.
Так,всё! Не слушайте меня! Сам знаю,лох)
Вообще проще считать,исходя из информационного объема одного кадра. В нашем случае это 1600×3цвета×8бит=14.4 кб.
Вопрос в том,в каком форматы проще и чаще можно выводить из МК.
Учитывая что необходимо не только выводить картинку,но и много считать и обрабатывать,смею предложить отдельно stm32 для вывода и Esp для прочих расчетов и радиосвязи. Короче разделение труда,ибо,как сказал @Boroda22, надобно ещё и в удобоваримые координаты переводить
Изменено:
Проекты делают школьники и вопрос трудоемкости - это еще вопрос возможности. Они ленту-то перепаивают 10 раз, еще и жгут ее. Чем меньше паячных работ, тем лучше. Проект матрицы с 7-сегментными индикаторами я видел, но мне кажется это Алекс по приколу делал. Мы делали как у него панель-бегущую строку, но там всего 400 светодиодов и Wemos это тащил и тащит прекрасно. А вот как работать с 1600 мы пока не понимаем.
А что касается скорости обновления, то своим программистским умом думаю, что необязательно обновлять всю матрицу ежесекундно, можно менять свечение только тех светодиодов, которые нужно заменить в текущий момент или метод .show() отправляет сигнал всем светодиодам ленты?
Ну это ладно. Разберемся.
Контроллер таки посоветует хоть кто-то для подобного проекта? В том числе из того, что я себе вижу?
А что касается скорости обновления, то своим программистским умом думаю, что необязательно обновлять всю матрицу ежесекундно, можно менять свечение только тех светодиодов, которые нужно заменить в текущий момент или метод .show() отправляет сигнал всем светодиодам ленты?
Ну это ладно. Разберемся.
Контроллер таки посоветует хоть кто-то для подобного проекта? В том числе из того, что я себе вижу?
Принцип работы адресной ленты: вы отправляете на ленту команду {номер: 100, цвет: RGB}
Контроллер первого светодиода смотрит: номер не ноль. Отнимает единицу, на выход отправляет {номер: 99, цвет: RGB}. И так далее.
Сотый смотрит "опа, ноль". Ставит себе цвет, дальше не отправляет.
Поскольку контроллеры не гигагерцовые - накапливается задержка.
нет, логика работы адрессной ленты такова, что даже при обновлении одного пикселя из тысячи надо обновлять все 1000
Зависит от контроллера. Дуе, Тенси, СТМ32(может еще кто) могут выводить одновременно на несколько выводов, на остальных контроллерах вывод на несколько пинов делается последовательно.
Изменено:
а не в 16 ? Вы же написали, что по сути у нас три независимых матрицы - R G B. Соответвенно и обновляются они независимо и на 3 умножать не надо.
Не, обновить достаточно всего 8 раз - 256 уровней яркости это 8 бит. Но выдерживать каждый бит придется разное время - пропорционально весу бита.
На первый взгляд кажется, что это тоже самое - однако с практичнской точки зрения обновлять 8 раз и выдерживать интервалы все-таки проще, чем 256 раз закачивать в регистры новые данные... Это называется BCM кодирование
@bort707, не очень понял: у нас (16*3) = 48 строк и 48 колонок. Допустим строки разных цветов можно объединить, получится 16 - я так и написал, что по строкам управление идёт в 16 раз медленнее. Каждый элемент строки (даже разных цветов) управляется своим битом регистра, то есть меньше 48 никак не получится. Да, можно их подключить к разным пинам, но таким способом мы лишь перетащим "сдвиг" в код МП: для того, чтобы сформировать 3 раздельных сигнала для пина без DMA нужно сформировать эти биты в байт (часть байта). С DMA мы можем формировать три отдельных потока, да!
8 раз для организации ШИМ обновить не получится никак. Если в строке будет 48 разных яркостей, то обновлять регистры придётся как минимум 48 раз. При условии DMA и распараллеливания - 16 раз по трём линиям, но никак не 8. И логика будет кошмарной.
8 раз для организации ШИМ обновить не получится никак. Если в строке будет 48 разных яркостей, то обновлять регистры придётся как минимум 48 раз. При условии DMA и распараллеливания - 16 раз по трём линиям, но никак не 8. И логика будет кошмарной.
я нифига не понял, честно 
Поэтому отвечу только на это:
Конечно, выводимую картинку в микроконтроллере нужно заранее разложить на битовые слои. Но это отработанная технология.
Поэтому отвечу только на это:
Почему? Уровень яркости каждого светодиода - это один байт. То есть 8 бит. При первом обновлении НА ВСЕ СВЕТОДИОДЫ выводим их младшие биты. Это одно обновление. При следующем - второй по значимости бит... и так далее. Всего 8 обновлений и никак не больше, как регистры не соединяйте.
Конечно, выводимую картинку в микроконтроллере нужно заранее разложить на битовые слои. Но это отработанная технология.
@bort707, биты не равноценны. Младший бит имеет "вес" = 1 (т.е., светиться светодиод должен, допустим, 1мкс), следующий бит имеет вес = 2, (2мкс), дальше = 4, 8, 16. 32, 64, 128. Если все эти интервалы сложить, то получится 256. Да, изменять мы должны будем всего 8 раз, но самый короткий импульс будет 1/256 от времени, выделенного на строку.
Впрочем, в любом случае интервалы будут неравноценными, поэтому да, этот метод уменьшит количество обновлений.
Впрочем, в любом случае интервалы будут неравноценными, поэтому да, этот метод уменьшит количество обновлений.
Изменено:
Все еще раз просчитали, сделали картонный прототип панели и решили остановиться на ленте ws2815 (чтобы в случае выгорания одного светодиода не перепаивать всю ленту, просто будет битый пиксел + 12 вольт меньше ампеража, теплозатрат и прочего), количество светодиодов 30 на метр, панель будет 30*30, дина и ширина панели под метр (30*3,2 см). Беру контроллер wemos, но с esp32 чтобы соединиться по блютуз со смартфоном для управления. 900 светодиодов думаю он потянет и без параллельного вывода. Проект запускаем. Получится, напишу как-нибудь. Желаю себе удачи.
Всем спасибо кто пытался помочь, но в целом сколько пользуюсь этим форумом - вывод следующий: много математической демагогии, практических дельных советов получить сложно. Либо мало практиков, которые реально что-то делали и имеют практический опыт, либо активны снобы, которые никого кроме себя не слышат. Никого не хотел обидеть, но это мнение новичка со стороны. Как-то так.
Всем спасибо кто пытался помочь, но в целом сколько пользуюсь этим форумом - вывод следующий: много математической демагогии, практических дельных советов получить сложно. Либо мало практиков, которые реально что-то делали и имеют практический опыт, либо активны снобы, которые никого кроме себя не слышат. Никого не хотел обидеть, но это мнение новичка со стороны. Как-то так.
Дело не в этом. Это для вас ваша задача - это свершение, а для большинства здесь абсолютно очевидно, что 30х30 пикселей потянет практически любая ардуино -плата, за исключением самый древних уно-нано. Так что в вашей теме и обсуждать-то нечего - бери и делай.