Комментарии 53
AlexGyver, перелогиньтесь =)
PS. Мне действительно было интересно как это реализовано.
Все оказывается просто.
Спасибо!
PS. Мне действительно было интересно как это реализовано.
Все оказывается просто.
Спасибо!
получается когда первый светодиод получил первый пакет, он его не передает дальше, а оставляет себе? а дальше он передает уже все остальные пакеты? я почему-то всегда думал что они как сдвиговые регистры работают.
Аналогично, тоже думал что как hc595 работают, почитал даташит, оказывается нет, работают как автор описал, по очереди заполняются. Получается, светодиоды в начале ленты сменяют цвет раньше тех, что идут за ними? Или они все же передают цвет на сами диоды только после ресета, т.е. одновременно?
Опс… посмотрел свою реализацию, действительно у меня получается, что первый светодиод раньше получает информацию. А правильнее будет, как вы написали — по сбросу, чтобы одновременно.
Контроллер (находящийся в диоде) включает светодиоды когда 50 микросекунд не идут никакие пакеты, то есть пока вы пихаете данные в вашу ленту, контроллеры будут принимать информацию и передавать дальше по цепочке остальным контроллерам в диодах, но как только наступит тишина длящаяся более 50 микросекунд, контроллеры зажгут светодиоды исходя из информации которую получили.
После того как контроллеры включили диоды вы можете отключить микроконтроллер от ленты и диоды будут продолжать светиться. Но как только вы станете снова посылать данные, контроллеры в диода снова начнут их запоминать, и когда вы прекратите посылать, снова после 50 микросекунд простоя контроллеры зажгут светодиоды.
Вот собственно и весь протокол работы.
Это можно увидеть просто рассматривая устройство ленты. Видны отдельные микросхемы, припаянные к гибкому шлейфу, видны соединения: микросхемы соединены последовательно всего тремя проводами, при этом два из них это питание и землясудя по описанию, это не последовательное, а параллельное соединение (последовательное расположение и последовательное соединение — разные вещи)
Круто, давно было интересно как происходит адресация в светодиодной ленте. Все гениальное просто.
Автор, объясните, вот какой смысл изобретать какой-то отдельный пропиетарный протокол обмена данными, вместо того чтобы использовать какой-нибудь стандартный i2c?
А то потом пользователи должны голову ломать, как сеё поделье запустить на каком-нибудь stm32f100 через DMA чтобы процессорного времени не тратить на передачу.
А то потом пользователи должны голову ломать, как сеё поделье запустить на каком-нибудь stm32f100 через DMA чтобы процессорного времени не тратить на передачу.
Ну так-то это не совсем ко мне вопрос. Это вопрос к китайцам. Я просто повторяю их протокол в своем «реверс инжиниренге»…
У I2C:
1. В 2 раза больше проводов для сигналов. Для узкой ленты это критично.
2. Имеет меньшую скорость.
3. В добавок к предыдущему ещё и накладные расходы на передачу адреса устройства (при передаче по 3 байта на устройство будет как минимум 25% пропускной способности уходить на адреса).
3. Ограниченное и не очень большое количество адресов (127, 255 или 1023, причём последний вариант дополнительно повысит накладные расходы на передачу адресов). Светодиодов в ленте может быть больше.
4. Эти адреса нужно как-то конфигурировать. Каждый светодиод джамперами не обвесишь, потребуется какой-то велосипед для автоконфигурации адресов и я даже с ходу не могу его придумать. Насколько надёжным будет такой велосипед — тоже большой вопрос.
5. Сигнал мастера должен проходить всю длину светодиодной ленты, со всеми её паразитными ёмкостями и индуктивностями, что накладывает на эту самую длину ограничения и ощутимо повышает чувствительность ко всяким наводкам и помехам, либо выдвигает существенные требования и к мастеру, и к самим светодиодам.
6. От светодиодов требуется немножко более сложная логика, что потенциально может повысить их стоимость, а поскольку в лентах могут быть тысячи светодиодов это критично. Логичнее перенести это удорожание на необходимость поставить более мощный МК или даже дополнительный МК в помощь основному, преобразующий UART/SPI/I2C в этот протокол. Ведь он будет 1 на всё устройство, а не тысяча.
7. К тому же более сложная логика повышает и вероятность глюков. Я встречал I2C устройства, которые при некорректных сигналах I2C могли притянуть к земле SCL и уже больше никогда не отпустить до перезагрузки по питанию, парализовав всю шину. На многометровой шине вероятность ошибочных сигналов сильно выше из-за помех и т. д. (не забываем, что мастеру нужно управлять всей длинной шины)
Текущий же протокол не содержит явных ограничений ни на количество светодиодов (адресов нет, можно влить сколько-угодно бит), ни на длину ленты (ведь каждый светодиод по сути выступает ретранслятором). Можно хоть миллионами светодиодов так управлять, озаботится придётся только подводом питания, ну и частота обновления упадёт. В данном конкретном приложении использовании нестандартного протокола вполне обоснованно.
1. В 2 раза больше проводов для сигналов. Для узкой ленты это критично.
2. Имеет меньшую скорость.
3. В добавок к предыдущему ещё и накладные расходы на передачу адреса устройства (при передаче по 3 байта на устройство будет как минимум 25% пропускной способности уходить на адреса).
3. Ограниченное и не очень большое количество адресов (127, 255 или 1023, причём последний вариант дополнительно повысит накладные расходы на передачу адресов). Светодиодов в ленте может быть больше.
4. Эти адреса нужно как-то конфигурировать. Каждый светодиод джамперами не обвесишь, потребуется какой-то велосипед для автоконфигурации адресов и я даже с ходу не могу его придумать. Насколько надёжным будет такой велосипед — тоже большой вопрос.
5. Сигнал мастера должен проходить всю длину светодиодной ленты, со всеми её паразитными ёмкостями и индуктивностями, что накладывает на эту самую длину ограничения и ощутимо повышает чувствительность ко всяким наводкам и помехам, либо выдвигает существенные требования и к мастеру, и к самим светодиодам.
6. От светодиодов требуется немножко более сложная логика, что потенциально может повысить их стоимость, а поскольку в лентах могут быть тысячи светодиодов это критично. Логичнее перенести это удорожание на необходимость поставить более мощный МК или даже дополнительный МК в помощь основному, преобразующий UART/SPI/I2C в этот протокол. Ведь он будет 1 на всё устройство, а не тысяча.
7. К тому же более сложная логика повышает и вероятность глюков. Я встречал I2C устройства, которые при некорректных сигналах I2C могли притянуть к земле SCL и уже больше никогда не отпустить до перезагрузки по питанию, парализовав всю шину. На многометровой шине вероятность ошибочных сигналов сильно выше из-за помех и т. д. (не забываем, что мастеру нужно управлять всей длинной шины)
Текущий же протокол не содержит явных ограничений ни на количество светодиодов (адресов нет, можно влить сколько-угодно бит), ни на длину ленты (ведь каждый светодиод по сути выступает ретранслятором). Можно хоть миллионами светодиодов так управлять, озаботится придётся только подводом питания, ну и частота обновления упадёт. В данном конкретном приложении использовании нестандартного протокола вполне обоснованно.
1. В 2 раза больше проводов для сигналов. Для узкой ленты это критично.
Да ладно. В том же ws2815 две линии сигнала. И ничего, на ленту влезают, никто не жаловался.
2. Имеет меньшую скорость.
0.9 + 0.35us = 1.25us -> 800khz /bit
i2с — позволяет работать на 3.4Мгц
3. В добавок к предыдущему ещё и накладные расходы на передачу адреса устройства (при передаче по 3 байта на устройство будет как минимум 25% пропускной способности уходить на адреса).
что? не вижу проблемы передавать в bulk режиме:
|address| data_led1 | data_led2 | data_led3 |… data_led_100500|
передать один раз адрес и пачкой данные.
4. Эти адреса нужно как-то конфигурировать.
Зачем? они также будут соеденены последовательно. mcu -> led1 -> led2 -> led3… -> led100500 пусть будут на одном же адресе. Тут без разницы.
5. Сигнал мастера должен проходить всю длину светодиодной ленты,
См. предыдущий ответ про последовательное соединение.
6. От светодиодов требуется немножко более сложная логика, что потенциально может повысить их стоимость
Вот тут частично согласен, но не думаю что от доп. нескольких тысяч транзисторов существенно возрастет цена. она больше от техпроцесса зависит а не от количества pn-переходов.
Скорее тут китайцам было лень лицензию на i2c покупать у филипса.
А адрес то чего вначале? какого устройства?
Вы прикалываетесь? Это в даташите обычно пишут.
как первый после передаст второму? без адреса?
Каждый предыдущий будет master для последующего. И передавать на тот же адрес, что в даташите.
+ ещё 2 резистора в вашей схеме для i2c на каждый светодиод
Их можно прямо в светодиод встроить как pullup. Там токи не большие
можно DMA
Та реализацию, которую я видел здесь память жрет как свинья. И не факт что в какой-нибудь stm32f100 вообще этот буфер влезет.
Если у вас есть более элегантное решение, я готов его выслушать.
Есть одна неурядица: в статье описывается работа с адресными светодиодами, в заголовке с лентами. Одно строится на другом, но вроде из статьи можно понять, что объектом рассмотрения выступает не лента, а именно адресный светодиод. Управлять лентами действительно разумнее по устоявшимся протоколам, но внутри ленты описанный «кувшинный» (не знаю названия) протокол выглядит лаконичным. К тому же пары проводов нужны не везде, а вот для i2c — увы, везде. Протоколы типа 1W слишком медлительны, хоть и тоже можно всего 1 провод юзать. Там у вас с другим человеком диалог вы о ленте, а он о диодах (вы о заголовке, а он о тексте статьи, по сути). Если я верно понял ваши претензии по i2c.
При отсутствии передачи более 50 микросекунд лента переходит в исходное состояние, готова принимать пиксели начиная с первого.
Что означает «лента переходит»? У нее же нет общего «мозга», на сколько я понял. Тут имеется ввиду первый светодиод?
Еще такой вопрос: контроллер может как-то определить сколько светодиодов в ленте?
Общего мозга конечно нет. Каждый светодиод сам по себе решает. Если данные не приходят в течении какого-то времени, то каждый из них сам решает, что видимо начинается новый кадр и нужно быть готовым его принять.
Контроллер не может определить количество светодиодов. Нет для этого никаких возможностей.
Контроллер не может определить количество светодиодов. Нет для этого никаких возможностей.
Хм, получается чтоб сделать на ленте какой-то световой эффект, нужно в программу зашить количество светодиодов в ней? Такое себе решение…
Можно конечно, но это уже усложнение. А вообще странно что не предусмотрели какого-то опрашивающего сигнала для этих целей, для простоты светодиод может «отвечать» на запрос замыканием сигнального провода, например.
Зажигать по одному, измерять ток. Ток не меняется — светодиоды кончились. Заодно и контроль повреждения ленты.
Еще такой вопрос: контроллер может как-то определить сколько светодиодов в ленте?
Если только закольцевать сигнал с последнего светодиода обратно на контроллер
Прикольно, но интереснее было бы реализовать передачу по двум проводам вместо трёх (данные по линии питания).
Там с питанием и так жесть полная. Ленте нужен очень большой ток.
К примеру, я питал ленту от компьютерного блока питания и полную яркость с трудом удавалось зажечь — начинала глючить.
К примеру, я питал ленту от компьютерного блока питания и полную яркость с трудом удавалось зажечь — начинала глючить.
А сколько у вас диодов в ленте? Если не включать белый свет на максимальной яркости, то не так уж много лента потребляет. У меня на карнизе 90 диодов, питается все от полутораамперной зарядки от телефона. Как бы стрелочные часы (60 диодов, все горят одновременно) — вообще напрямую от Digitalspark.
Для длинных осветительных светодиодных лент встречал совет: подавать питание на оба конца ленты, т.к. падение напряжения вдоль ленты заметно уже на трехметровых.
Да и посередине не помешает.
Каждый светодиод в кластере кушает 12 мА. Учитываем худший вариант — белый свет при максимальной яркости, т.е. 36 мА на светодиод.
Для пятиметровой ленты 60 LED/m это 10,8 А при 5 В.
Для пятиметровой ленты 144 LED/m это уже 26 А.
Там дорожки и разъемы столько не вытянут.
Каждый светодиод в кластере кушает 12 мА. Учитываем худший вариант — белый свет при максимальной яркости, т.е. 36 мА на светодиод.
Для пятиметровой ленты 60 LED/m это 10,8 А при 5 В.
Для пятиметровой ленты 144 LED/m это уже 26 А.
Там дорожки и разъемы столько не вытянут.
стоит попробовать запитать ленту с 2х сторон, или подавать питание в середину.
Несомненно, это поможет.
По-моему, там желательно во все места подавать. Уж очень эти 5 вольт проседают. Когда делал MIDI-гирлянду на ёлку, попробовал включить все диоды белым светом, и было очень заметно, что чем дальше от питания — тем желтее, вплоть до оранжевого, причём ток был ниже, чем мог выдать БП. С лентами получше, но тоже к концу желтее (144 LED/m).
На их основе каждый может изобрести что-то свое:
Эрон дон дон:D
Можете, пожалуйста, объяснить как цвета меняются одновременно? Например, если нужно всю ленту зажечь одним цветом. Если светодиод меняет свой цвет после того, как получил свою порцию данных, то одновременное переключение не получится
Глаз — слишком инерционная штука. Вся пятиметровая лента включается менее чем за 5 мсек — это нереально заметить.
Возможно активация нового принятого цвета происходит именно по сигналу Reset (это на самом деле не сигнал, а пауза в передаче более 50 микросекунд). Тогда светодиоды будут включаться примерно в одно время. У меня в коде это не сделано, но сделать легко.
Получается что светодиоды меняют цвет последовательно, но происходит это достаточно быстро чтобы глаз не заметил.
Я раньше думал, что в лентах управление идет по какой-нибудь параллельной шине, по которой передается что-то вроде адреса светодиода и команда. Но такой способ оказался намного проще и универсальнее (в теории можно подключить любое количество светодиодов)
Я раньше думал, что в лентах управление идет по какой-нибудь параллельной шине, по которой передается что-то вроде адреса светодиода и команда. Но такой способ оказался намного проще и универсальнее (в теории можно подключить любое количество светодиодов)
после передачи цвета посылаеца команда ресэт, низкий уровень более 280мкс. по заднему фронту команды появляюца новые цвета.
очевидно что команда передаёца последовательно через все микросхемы и последний светик поменяет немного позжэ чем первый. чтобы это проверить нужна достаточно длинная лента и 2х канальный быстродействующий осцылограф.
очевидно что команда передаёца последовательно через все микросхемы и последний светик поменяет немного позжэ чем первый. чтобы это проверить нужна достаточно длинная лента и 2х канальный быстродействующий осцылограф.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как работает адресная светодиодная лента?