Из PWM в BAM с оглядкой на CDC+HID

[Mikhail Sannikov]

Если основное изменение в аппаратной части Лайтпака это последовательное подключение драйверов с использованием аппаратного SPI, то самое значительное из рассматриваемых нами изменений в прошивке это переход с широтно-импульстной модуляции (ШИМ, PWM) на побитно-угловую модуляцию (BAM). Сравнение двух этих вариантов для управления светодиодами обещает нам теоретическое уменьшение времени, которое затрачивает МК на генерацию аж в 32 раза. Так же, для наиболее эффективного использования ВАМ будет целесообразно поворачивать матрицу на стороне софта и уже в повёрнутом виде передавать в МК. Отсюда возникает две проблемы, которые я и хочу обсудить:

1. Увеличивается нагрузка на управляющий софт. Программа должна разворачивать матрицы с той же частотой с которой происходит захват картинки.

2. Если МК будет ждать от софта уже перевернутую матрицу, то мы теряем возможность управлять Лайтпаком через CDC, о которой говорили в прошлых письмах. Или нет? Быть может нам стоит описать алгоритм поворота так, чтобы каждый желающий смог запрограммировать его в своём скрипте? Быть может, если есть возможность сделать устройство составным, то есть и возможность разделить работу внутри прошивки таким образом, чтобы родной софт работал с Лайтпаком через HID с повёрнутой для BAM матрицей, а сторонние скрипты/плагины работали через CDC таким образом чтобы матрица для BAM поворачивалась уже в самом МК? Но этот второй вариант кажется мне каким-то совсем уж overkill'ом.

Есть мнение, что после перехода на ВАМ помимо разгрузки МК мы сможем увеличить разрядность данных для каждого цвета, что (опять же в теории) даст более качественное отображение тёмных цветов. Какие ещё плюсы, минусы и подводные камни при переходе с PWM на BAM вам известны?

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

--
С уважением, Санников Михаил
ata...@gmail.com | www.atarity.ru

[kv35]

1. Нагрузка на софт должа быть минимальна. С этой задачей без проблем
справится даже МК, что уж говорить о современном ПК, так что об этом
можно не беспокоиться.
2. Рассматривая оба варианта пришел к выводу, что поворачивать массив
лучше все-таки силами МК. Пусть софт занимается генерированием данных,
а устройство - преобразованием данных в формат, годный для вывода.
Можно будет сделать совместимость со сторонним софтом. Будет
возможность поддержки текущей ревизии платы (паралельное подключение
драйверов), протокол обмена будет аналогичным.
3. 9-10бит - надо тестировать. Скоро соберу плату для тестов, возьмусь
за прошивку. Теоретически - все должно работать.
Минусов от BAM не замечал, все работает как надо.
4. Использовал BAM в своем варианте подсветки: поворот массива
объединен с перестановкой каналов. Можно будет разводить платы как
попало: поменять местами каналы не составит труда, как и пропустить
нераспаяные выходы драйверов (на 2 драйверах останется 2 лишних, на
доп. плате - аналогично).
Попутно можно во время поворота подменять 8бит на эквивалентное 10бит.

Так же использовал BAM вместо PWM для управления 8x8 RGB матрицей:
частота обновления 100*8=800Гц (иначе видны мерцания), 192 светодиода
- с ШИМ просто не хватало ресурсов.

По сути при использовании PWM происходит тот же поворот массива,
только однобитный: или гореть, или не гореть. И вместо 8 сравнений на
BAM происходит 2^8 сравнений на PWM. Количество передаваемых данных на
драйвера (при 2 шт: 10xRGB): по BAM - 8 кадров(8*4=24 байта); PWM - по
количеству каналов(30*4=120 байт).
Выгода очевидна.

[Андрей Синюткин]

пїЅпїЅпїЅпїЅпїЅпїЅ, пїЅпїЅпїЅпїЅпїЅпїЅ. пїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅ, пїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ/пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅ - пїЅпїЅпїЅпїЅпїЅпїЅ пїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ. пїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅ, пїЅпїЅпїЅ пїЅпїЅ пїЅпїЅпїЅпїЅ пїЅпїЅпїЅ, пїЅ пїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅ. пїЅ пїЅпїЅ пїЅ пїЅпїЅпїЅпїЅпїЅ, пїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅ
пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅ 32 пїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ (пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ BAM), пїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅ пїЅ пїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅ. пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅ пїЅ пїЅпїЅпїЅпїЅпїЅ, CDC пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅ. пїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅ пїЅ пїЅпїЅпїЅпїЅпїЅ, пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ RGB пїЅпїЅпїЅпїЅ пїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅ, пїЅпїЅпїЅ пїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅ пїЅпїЅпїЅпїЅпїЅ.

-----------
пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅ m.mail.ru

[Mikhail Sannikov]

Андрей, вы абсолютно правы. И я в курсе приоритетных работ. Сейчас основные для нас задачи -- производительность под Вин и захват в игрушках. Именно в таком порядке. Это знаю я и это известно Мише Шатохину. К сожалению, я в этих работах (доработка софта) полностью бесполезен и сдвинуть софт с мёртвой точки сейчас может только Миша и он над этим работает, стараясь не отвлекаться на то о чём мы тут говорим.

Среди тех задач, которые могу решить я, были определены как раз анализ перспективных доработок. Выяснение, что именно пойдёт в серию. У меня нет большого желания переделывать Лайтпак с нуля или вести его к какому-то кухонному комбайну, который умеет всё, включая Android 5.0. Вы правы, и API и BAM и даже последовательное подключение драйверов -- это не первоочередные задачи потому что всё, кроме софта УЖЕ работает. Но нам нужно двигаться дальше и для этого приходится смотреть вперёд. Например, пока Миша воюет с софтом я мог бы собрать для него прототип следующей ревизии железа, просто для того чтобы он не тратил на это время в будущем.

Не переживайте за софт, Андрей. Я уверен, что Миша его одолеет. Если вы, или кто-то из ваших знакомых, может помочь с этим, я готов раздать вам права на запись в репозиторий хоть сейчас. На главной странице объявление о нехватке программистов уже опубликовал.

--
С уважением, Санников Михаил
ata...@gmail.com | www.atarity.ru

2011/3/8 Андрей Синюткин <sin_...@mail.ru>

Привет, Михаил. Мне кажется, что сосредотачиваться на оптимизации/переделке аппаратуры лайтпака сейчас - борьба с ветряными мельницами. Вы создаете проблемы там, где их пока нет, и этим отвлекаетесь от решения действительно важной задачи. Я не в курсе, зачем вдруг
понадобилось разгружать в 32 раза микроконтроллер (применяя BAM), когда ему и так хорошо. Оставьте железо в покое, CDC добавите потом. Сейчас узкое место только в софте, микроконтроллер вполне справится с управлением RGB даже на обычном ШИМ, так как большая точность управления яркостью не нужна.

-----------
Отправлено с m.mail.ru

[Андрей Синюткин]

пїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ.

пїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅ пїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅ. пїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅ, пїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ. пїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅ пїЅ 8-пїЅпїЅпїЅпїЅпїЅпїЅ, пїЅ пїЅ 10-пїЅпїЅпїЅпїЅпїЅпїЅ, пїЅ пїЅ 16-пїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅ - пїЅпїЅпїЅ пїЅпїЅ пїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ. пїЅпїЅпїЅ пїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅ LED-пїЅ - пїЅпїЅпїЅ пїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ firmware. пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ, пїЅпїЅпїЅпїЅ пїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ/пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ, пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅ пїЅпїЅ 10 пїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅ 7 (пїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ).
-----------
пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅ m.mail.ru

[kv35]

В софте помочь не могу, потому обсуждаю железную часть.

То, что сейчас - действительно рабочее. Но не стоит на этом
останавливаться.
Как минимум - нужно увеличить кол-во светодиодов. Далее - попробовать
улучшить цветопередачу. А больше по сути ничего и не требуется:
управление яркостью нескольких светодиодов - это основная и
единственная задача устройства.

Переход на BAM - не столько из-за нехватки ресурсов МК, сколько для
оптимизации вывода данных. И именно для сохранения текущего протокола
обмена - поворот массива лучше возложить на МК.
В софте все останется как есть: 1 байт - яркость одного канала. Все
будет передаваться так же, как и сейчас. Или по CDC, как во многих
анологичных проектах.

Конвертировать яркость в 10бит - тоже задача МК.
По сути яркость остается 8-битной. Средний 8бит цвет высчитывается из
8бит значений. И отображается 256 вариантов яркости. И передавать все
логичнее байтом.
Просто эти 256 точек яркости расположены будут не на одинаковом
рассоянии, а неравномерно распределены по ширине 1024. Так половина
значений размещается в 1\10 от общего диапазона.
При текущей реализации яркость при значении 25 светит на половину
максимальной яркости. При 10 бит яркость будет почти линейной, как на
мониторе\тв.