Библиотека для вождения светодиодов с STM32F103

Октавио
Вторник 12 сентября 2017 г. 14:46
https: // github.com/octavio4/parallel-output-stm32
Эта библиотека не блокирует, она использует DMA и IRQ для отправки данных, в то время как основная программа может выполнять другие задачи, и очень гибкая на используемых выводах.
Он поддерживает протоколы WS2812, APA102 и DMX.

Rogerclark
Вторник 12 сентября 2017 г. 20:56
Спасибо, что поделились.

Можете ли вы объяснить, для чего это используется.

Протокол WS28 для адресуемых светодиодов, известных как Neopixels? Если это так, вы сравнили производительность с лишним ударом или менее сложными методами ?

И Рик Кимбалл, и я также попытались написать библиотеки для использования DMA (и в моем случае SPI DMA) для отправки данных в адресабельные пиксели, но время настройки, необходимое для настройки закодированных буферов данных, только быстрее, чем било.

victor_pv
Вторник 12 сентября 2017 г. 22:22
Глядя на библиотеку, я видел, как она поддерживает до 4 струн, параллельно. Интересно, сколько светодиодов на строку и сколько обновлений в секунду, но это может быть с хорошей скоростью, которая впечатляет.

Октавио
Вторник 12 сентября 2017 г. 22:58
>Протокол WS28 для адресуемых светодиодов, известных как Neopixels?
Да, а также APA102 (SPI) и DMX (сериал 250 кбит / с).Вы не пробовали свою библиотеку, но по сравнению с Fastled:
Двигайте 4 полоски параллельно, быстро справляется с 8 полосками с Teensy, но для STM32F103 поддерживается только одна полоса за раз, так что моя либерация в 4 раза быстрее.
Моя библиотека позволяет применению продолжать работать, пока данные отправляются и используют (выдвинутые) менее 30% процессора, в то время как ваш код должен подождать, пока перевод не будет завершен, чтобы выполнить другие задачи.В качестве ссылки у меня есть программа, которая считывает данные с SD -карты, выполняет некоторую обработку изображений (смешивание образцов, изменения цвета и т. Д..) при 60 кадров в секунду с 4*512 пикселей WS2812 и немного быстрее со светодиодами APA102.

Октавио
Вторник 12 сентября 2017 г. 11:11
> Интересно, сколько светодиодов на строку.
Нет ограничения, в примере есть функция, которая считывает данные из памяти, но вы можете написать подпрограмму (см. Get_bits), которая не использует Bufer памяти и генерирует данные пикселей по требованию или просто ставит все пиксели с одним и тем же цветом. Обратите внимание, что вселенная DMX ограничена определением до 512/3 пикселей (и FPS также ограничен), но сама библиотека не имеет пределов, и настройки часов могут быть изменены, чтобы поддержать новые типы светодиодов.

Rogerclark
Ср 13 сентября 2017 г. 1:58
Не могли бы вы кратко объяснить, как вы создаете и отправляете данные для протокола WS28 ?

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

Длина высокого импульса определяет, составляет ли бит 1 или 0.

Длинный высокий и короткий низкий = 1
Короткий высокий и длинный минимум = 0

Вы кодируете буфер с 3 битами на бит пикселя ?

эн.глин.

110 = данные "1" бит
100 = данные "0" бит

???

Или ваш код выглядит использованием прерывания, называемого 3 раза на бит данных пикселя ?

Или какой -то другой метод ?

Октавио
Ср 13 сентября 2017 г. 12:06
Для WS2812 IRQ называется один раз для Pixel (24 бита на полосу), затем обработчик заполняет буфер DMA 24*3 словами, первое слово устанавливает вывод на 1, второе слово - это данные, а последнее устанавливает штифт до 0, слова 1 и 3 написаны только на 2 первом и 2 последних IRQ.

Октавио
Ср 13 сентября 2017 г. 12:11
110 = данные "1" бит
100 = данные "0" бит
Существует также возможность кодировать как это:
npk = 4
1100 = данные "1" бит
1000 = данные "0" бит
npk = 5
11000 = данные "1" бит
10000 = данные "0" бит
Чтобы уменьшить скорость передачи, если это необходимо.

Rogerclark
Ср 13 сентября 2017 г., 21:49
Спасибо за объяснение

@racemaniac также написал систему для WS28, которая использует 32 бита на пиксель.

Я использовал 24 бит, потому что он использует меньше оперативной памяти, и я строю весь буфер перед отправкой через DMA SPI
(Но мой код может сделать только одну строку)

Я вижу с вашим кодом, который обрабатывает несколько строк, что потребуется слишком много оперативной памяти, чтобы создать буфер для нескольких строк, поэтому вам нужно построить каждый пиксель в ISR

Я использовал LUTS, чтобы кодировать данные Pixel на 24 бита, но я не уверен, что это ускорит ваш код.

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

Вы проанализировали, какой процент времени ваш код, потраченный внутри ISR?

Вы проанализировали, сколько времени потребовалось ваш код, чтобы отправить 1 строку, против того, сколько времени это заняло через битовые? я.эн. Какова была задержка между каждым пикселем во время кодирования ? Или ваш ISR заполняет буфер DMA так быстро, как его отправляют ?


КСТАТИ. Я хотел сделать свою библиотеку совместимой с библиотекой Neopixel Adafruit, но у меня возникла проблемы с асинхронно, и мне пришлось удвоить буферизацию кодированных данных, чтобы они не были перезаписаны новыми данными, пока старые данные все еще отправлялись

Октавио
Ср 13 сентября 2017 г., 23:27
ISR заполняет буфер DMA быстрее, чем его отправляется, поэтому скорость ограничена 800 Кбит / с (может работать также при 1 Мбит / с), используемой WS2812, написав 4 полосы за время, скорость x4 x4.
Если вы хотите узнать, сколько CLK CLK требуют для обработки пикселя, вы можете посмотреть на вывод и счет сборки (я не могу сделать это с помощью сборки ARM).
Другой способ - использовать светодиоды APA102, увеличивая скорость, пока что -то не сработает.Код для APA102 и WS2812 очень похож и имеет то же самое
производительность. «SETUP_APA (48);» означает, что немного отправляется каждые 48 часов процессора, поэтому в этом случае часы - 1.5 МГц, постарайтесь уменьшить это значение, пока что -то не потерпит неудачу, тогда вы точно узнаете производительность всего кода ISR (dma_apa () + get_rgb44 () + transpose ()).В моей программе (не опубликовано) я делаю больше вещей на ISR, поэтому я знаю, что скорость может быть увеличена, если будет выполнена меньшая обработка.
>Я использовал LUTS, чтобы кодировать данные Pixel на 24 бита, но я не уверен, что это ускорит ваш код.
Нет, это работает по -другому.Каждая передача DMA равна 1 -битному выходу, DMA записывает 32BITS в GPIOA->регс->BSRR, верхние 16 бит, соответствующие штифту, а 0, в то время как более низкие 16 бит устанавливают штифт на 1, значение 0 не изменяет штифт.«Output_table []» используется для перевода 4 бита данных в слово 32BITS, которое устанавливает выбранные выводы. Код может быть изменен для работы с большим количеством светодиодных полос, и это было бы быстрее, но для моего проекта мне нужно только 4.

Rogerclark
Чт 14 сентября 2017 г. 12:05 утра
Спасибо...

Звучит как хорошая система.

Кодирование на лету означает, что вам не нужно хранить большой «закодированный» буфер, который очень важен, если вам нужно двойное буферизацию цельной строки «пиксель» RGB.

Для нескольких струн задержка ISR - это то, что стоит смириться с.... Было несколько интересных потоков о внешнем задержке ISR -триггера, что варьируется в зависимости от того, используется ли вектор ISR по нескольким контактам или нет.
Я подозреваю, что в вашем случае вектор ISR не будет обмен, иначе код будет менее эффективным.
На самом деле, я не уверен в задержке ISR, когда вызвано таймером, и является ли это таким же медленным, как внешнее запуск GPIO, или сколько вызов накладных расходов.

Мы кратко исследовали, пытаясь оптимизировать общую задержку ISR, но можем сэкономить только 10 % скидки на скорость. (но это не будет применяться к вашему использованию)

Октавио
Чт 14 сентября 2017 г. 13:49
Чтобы избежать проблем с задержкой, приоритет IRQ установлен выше, чем по умолчанию nvic_irq_set_priority(NVIC_DMA_CH1,14);

Hackstage
Вторник 05 февраля 2019 г., 16:08
Я пытался изменить библиотеку, чтобы запустить 8 параллельных выходов для светодиодов RGBW уже пару недель - но до сих пор мало удачи. Можете ли вы дать несколько советов о том, как это можно сделать? Предыдущие комментарии на этом форуме были очень полезными!