Запрет прерываний при эффектах адресных лент.

Добрый день. Использую библиотеку neopixel для адресных ленточек. Все норм, но эффекты, которые нашел, все используют циклы for и задержку delay(wait). Никаких других команд не пропихнуть, пока цикл не закончен, ну это логично. Вопрос: эта или другая подобная библиотека для ws2812 может работать совместно с прерываниями? Или как-то можно переписать эффекты на возможность работы с millis к примеру? Заранее благодарен за любую инфу.

 

В процессе передачи данных прерывания отключаются, иначе на 800 КГц ровно не пропихнуть. Только между кадрами. Решить можно только дополнительным отдельным МК со связью с другим, благо это не дорого.

 

Вы немного не о том. Речь не о передаче данных.. Все проще. Если посмотреть примеры т.н. "эффектов" - в них широко используются циклы For и задержки в сотни и тысячи мс.Вопрос ТС, как я его понял - можно ли переписать эти циклы с использованием миллис.
Ответ - можно.

 

Пока уходит пакет данных на всю цепочку адресников прерывания отключаются, потому что малейшая задержка и пакет уйдет кривой. Соответственно останавливается все остальное, включая отсчет millis. Можно ли что то делать пока уходит пакет? Ответ -- нет, только между кадрами. А если кадры прут постоянно...

 

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

 

Одно непонятно, чего вы тут забыли? Зайти на форум тазоводов и хвастать мерседесом не самое правильное занятие.

 

Спасибо за ответы. Более подробно о проблеме: Ардуинка управляет лентой, оборотами кулера и считывает датчик температуры. При этом общается с ПО на ПК в двухстороннем порядке. Пока крутится цикл датчик не опрашивается, данные не принимаются и не передаются, вентилятор не регулируется. Все это понятно. Как бы все терпимо кроме как ожидание выполнения команд полученных с ПК и ответа... Немного криво выглядит ждать цикл светодиодов)

Стандартный эффект круговой радуги.

Код (C++):

void rainbowCycle(uint8_t wait) {
  uint16_t i, j;
  for(j=0; j<256; j++) { // *5  for 5 cycles of all colors on wheel
    for(i=0; i< strip_fan.numPixels(); i++) {
      strip_fan.setPixelColor(i, Wheel(((i * 256 / strip_fan.numPixels()) + j) & 255));
    }
    strip_fan.show();
   
    delay(wait);
  }
}

Ну и порядок смены цветов

Код (C++):

uint32_t Wheel(byte WheelPos) {
  if(WheelPos < 85) {
   return strip_fan.Color(WheelPos * 3, 255 - WheelPos * 3, 0);
  }
  else if(WheelPos < 170) {
   WheelPos -= 85;
   return strip_fan.Color(255 - WheelPos * 3, 0, WheelPos * 3);
  }
  else {
   WheelPos -= 170;
   return strip_fan.Color(0, WheelPos * 3, 255 - WheelPos * 3);
  }
}

Пакет в данном случае это один раз сдвинуть спектр, по сути если переписать void rainbowCycle(uint8_t wait) на millis, то возможно увеличиться задержка между пакетами, но сами пакеты будут целыми. Или я не прав?

 

И delay() и millis() используют один и тот же таймер, поэтому пакеты не пострадают.
Другой вопрос, что просто поменять в цикле делей на миллис не поможет - логику цикла нужно будет переписать полностью.

 

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

 

Я тоже думаю - как же затолкать в код общение с МК AVR, который непрерывно обслуживает хвост из 1024 светодиодов?

 

Между пакетами, как обычно.

 

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

Это понятно, что от цикла for в принципе нужно отказаться. Я просто нулевой программист, по образованию железячник. Ардуинку изучая как хобби. Как приблизительно должен выглядить рабочий цикл через millis, куда можно между пакетами по таймеру назначать иные команды?

И щас вообще бредово: если в сам цикл for вставить код приема/передачи данных по serial, т.е. после каждого пакета на ленту будет проверяться наличие данных на COM, если есть обрабатывать их, затем следующий пакет. Скажется ли это на быстродействии? Или скажем внутри цикла чтобы не после каждого пакета, а раз в секунду по таймеру проводилась проверка наличия на serial данных?

 

это вполне возможно.

 

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

 

Я так и не понял, вы хотите внутри передачи пакета чтото принимать? Это не получится. А если между пакетами, то причем тут библиотека?

 

Ну вот давайте расставим точки на i: берем анимацию, которую привел в 7м посте, это полный видимый спектр в пределах одной ленты. Цикл rgb начинается с того, что в первом пакете первый пиксель будет иметь 255, 0, 0, последний в ленте 255, 0, 3 идеально при достаточном количестве пикселей и расширяющей способности библиотеки, не суть. Цикл закончиться, когда придет на ленту пакет при котором последний пиксель станет чисто красным, т.е. 255, 0, 0. Так вот я предложил "в бреду" проверять наличие данных между пакетами к примеру по таймеру или вообще по значению переменной "j", которая используется в том же цикле.
Еще раз моё понимание, поправьте, если туплю:
сейчас работает скрипт связанный с serial'ом после каждого цикла, т.е. цвета первого пикселя от 255,0,0 - 255,0,3.
предполагаю возможность запуска скрипта чаще, например после пакетов с первым пикселем 255,0,0; 255,120,0; 255,255,0; 130,255,0; 0,255,0 и т.д.
Реально?

 

Для начала: сколько пикселей в ленте?

 

максимум 30

 

0,6 мс на один пакет. Если делать 10 кадров в сек, то за секунду будет использовано 6 мс. Остальные 994 мс в вашем распоряжении. Чего не хватает?

 

На 30 штук 0.9 мс пакет, по уточненным данным. Даже в этом случае процессор простаивает 99% времени.