Странности со светодиодом
- Войдите на сайт для отправки комментариев
Сб, 26/10/2019 - 11:06
Я только начал знакомится с Arduino и с электроникой в целом, но сумел написать прогу для плавного включения и выключения светодиода с задаваемой скоростью мерцания по потенциометру
word counter;
word last_speed;
void setup() {
pinMode(3,OUTPUT);
Serial.begin(9600);
counter = 0;
last_speed = map(analogRead(0),0,1023,1,10);
}
void loop() {
int speed_ = map(analogRead(0),0,1023,1,10);
Serial.println(counter);
smoothToggle(3,1);
Serial.println("Counter "+(String)counter);
Serial.println("Speed "+(String)speed_);
}
void smoothToggle(int port,int speed_){
//constrain(counter,0,255*speed_);
analogWrite(port,map(counter,0,255*speed_,0,255));
timer(speed_);
}
boolean off = true;
void timer(int speed_){
if(counter==255*speed_){
off=false;
} else if(counter==0){
off = true;
}
if(off == true){
counter++;
} else if(off==false){
counter--;
}
}
Крутилка крутится и светодиод плавно включается и выключается, но только когда там есть вот это
Serial.println("Counter "+(String)counter);
или вот это
Serial.println("Speed "+(String)speed_);
Когда этих строк нет, диод начинает хаотично мерцать и я не могу ничего понять, почему? Я писал обычный Serial.println(); Но проблема была та же, только чуть меньше. Проблема не критичная, но надписи были для дебага, а без них ничего не работает, помогите пожалуйста!
pinMode(A0, INPUT_PULLUP);
Зачем? Или троллишь просто?
Дак а что еще делать? Схемы то нет.
Ваша функция smoothToggle вызывается с частотой вызова loop. Если нет никаких задержек (типа Ваших долгоиграющих принтов с преобразованиями строк), то это значительно чаще, чем мигает ШИМ. В результате Вы этот бедный порт только настраиваете, ему и мигать-то некогда.
Поставьте задержку хоть небольшую и будет Вас счастье. А ещё лучше не дёргать настройки постоянно, а перенастраивать только когда действительно что-то поменялось (только шум АЦП учитывайте).
сумел написать прогу
Потому и не работает ни хрена - это общее свойство всех прог. Впредь пишите программы.
А ещё лучше не дёргать настройки постоянно, а перенастраивать только когда действительно что-то поменялось (только шум АЦП учитывайте).
Можно на этом поподробнее?
Ну, а чё там подробнее. Значения с АЦП пропускать через программный фильтр НЧ (гугл), сравнивать с предыдущим значением и изменять настройки только тогда, когда значение поменялось - чего его перенастраивать, когда оно не поменялось?
Но можно и без этого, просто задержку поставить там 10-20мс. На глаз незаметно, а ШИМ успеет помигать. Собственно Ваши принты и играют роль такой задержки.
Значения с АЦП пропускать через программный фильтр НЧ (гугл), сравнивать с предыдущим значением и изменять настройки только тогда, когда значение поменялось - чего его перенастраивать, когда оно не поменялось?
Так он у меня постоянно меняется!
Это для Вас он постоянно меняется, а для процессора как тот быстрый финский парень, практически стоит на месте.
Что это вы понаобъявляли на каждом углу кучу переменных speed_? Вы в них не путаетесь?
Нет! Наоборот!
Что это вы понаобъявляли на каждом углу кучу переменных speed_? Вы в них не путаетесь?
Тогда объясните ее сакральный смысл в loop-е (ну, кроме вывода на печать)?
Че прицепились по мелочам, он токо начинающий. Дай бог чтоб каждый начинающий так начинал.
По делу.
Тебе там вобщем верно сказали, луп сильно быстро крутится, на глаз скажу что без принтов он тысячи раз в секунду проходит, перезапускает ШИМ у которого частота 500Гц, потому и блымает безпорядочно. Он просто не успевает отработать очередной перезапуск. А с принтами - десятки раз в секунду луп пройдет. Откуда знаю? На скорость смотри, при 9600 порт грубо говоря байт в миллисекунду отправит. При полном буфере этот вызов будет блокирующий. За один луп отправится несколько десятков байт, т.е. несколько десятков миллисекунд уйдет, а значить за секунду луп несколько десятков раз пройдет. Что делать - простейшее deley на те самые десятки миллисекунд. Но плохо, т.к. все равно перезапуски ШИМ будут, хотя и реже. Лучше сравнивать значения с АЦП (или после мапа), предыдущее с текущим и если не совпало - тогда выводи. Там как бы намек есть - last_speed для этого. Но несовпадать будет слишком часто из за шумов analogRead. Тоже не гуд. А вот после мара только 10 шагов изменения яркости, значить здесь лучше такой подход. Ну а совсем гуд - заведи счетчик, при last_speed==_speed в счетчик пиши допустим 10, а если last_speed!=_speed то делай счетчику -1. Когда счетчик доминусуется до нуля - перезапуск ШИМа, last_speed=_speed в счетчик 10. Это от шума спасет. Дальше. Как быстро ты хочешь увидеть результат кручения крутилки? я думаю задержку 0,1сек ты не заметиш. Вот и проверяй значить крутилку не чаще. Только учти еще счетчик, который замедлит процесс. Как проверять не на каждом проходе лупа - читай блинкбезделея. Это полюбому надо если с ардуиной возишся.
... при 9600 порт грубо говоря байт в секунду отправит.
Logik, с Вашего разрешения, я исправлю на "миллисекунду".
Так он у меня постоянно меняется!
С какой частотой? Если действительно с частотой большей, чем частота ШИМ, то либо бросьте это дело, либо увеличивайте частоту ШИМ.
А может проще энкодер или кнопочки? И печатать, только когда значения меняются. Мы ж как - никак в цифре работаем. Аналог в любом случае шуметь будет.
Согласен, если ничего не мешает - замените переменный резистор энкодером и будет все «петь и плясать».
Гуру, а в данной задаче использовать таймер с прерыванием каждые 500мс к примеру уместно? Или это бред?
В функции прерывания смотрим - если значение считанное analogRead() изменилось - действуем. Нет - выходим из функции.
Хотя такое и в лупе должно сработать?
Гуру, а в данной задаче использовать таймер с прерыванием каждые 500мс к примеру уместно? Или это бред?
В функции прерывания смотрим - если значение считанное analogRead() изменилось - действуем. Нет - выходим из функции.
Хотя такое и в лупе должно сработать?
Да тут вообще не нужны прерывания. Каждые 1/25 секунды проверяем состояние реостата. Чаще не надо - и так глаз не заметит. И все. Господа - работайте в реальном времени, а не во времени процессора. Вы его все равно не поймете и не увидите.
... при 9600 порт грубо говоря байт в секунду отправит.
Logik, с Вашего разрешения, я исправлю на "миллисекунду".
Ай, спасибо!
Согласен, если ничего не мешает - замените переменный резистор энкодером и будет все «петь и плясать».
там свои грабли. переменный помнит положение при ребуте, енкодер нет, переменный можно выставить на требуемый уровень при выключеном - энкодер нет. Оно конечно EEPROM есть, но то тоже усложнит.
Гуру, а в данной задаче использовать таймер с прерыванием каждые 500мс к примеру уместно? Или это бред?
В функции прерывания смотрим - если значение считанное analogRead() изменилось - действуем. Нет - выходим из функции.
Хотя такое и в лупе должно сработать?
Да тут вообще не нужны прерывания. Каждые 1/25 секунды проверяем состояние реостата. Чаще не надо - и так глаз не заметит. И все. Господа - работайте в реальном времени, а не во времени процессора. Вы его все равно не поймете и не увидите.
так это получится 25-й кадр, будем нейропрограммировать )))
так это получится 25-й кадр, будем нейропрограммировать )))
Чисто физиология - человек не видит более 24 кадров в секунду. 1/25 интереснее в десятеричном измерении. 25-й кадр - общемировой обман, никак не связанный с нейролингвистическим программированием, которое в части лингво, задействует слова
да не факт, что у ТС это надо человеку видеть - мы ж конечной задачи не знаем. Все кругом штирлицы
да не факт, что у ТС это надо человеку видеть - мы ж конечной задачи не знаем. Все кругом штирлицы
Киборги - они заполоояют чего-то там. А конечная задача любого разумного - мировое господство
Вообще говоря - «Киборги... они заполонили.. Киборги....» камедиклаб если не ошибаюсь.
Надо ждать ТС, чтобы открыл занавес тайны что он в итоге хочет получить.
Чисто физиология - человек не видит более 24 кадров в секунду. 1/25 интереснее в десятеричном измерении. 25-й кадр - общемировой обман, никак не связанный с нейролингвистическим программированием, которое в части лингво, задействует слова
Кто Вам сказал эту глупость?
Любой геймер легко отличит 24 fps от 60 fps.
А по звуку отличит направление кристаллов меди в проводе, его прогретость и срок использования ;)
Заметь, речь не о киноманах, они не отличат. А о геймерах. Кадр 24fps обновляется каждые 42мсек, а 60fps - каждые 17мсек. 42-17=25мсек. При скорости реакции 100мс получить визуальную информацию на 25мсек быстрей - очень некислая фора в игре будет.
Но и 24 - не догма для визуальной информации, например белые светодиоды даже при ШИМ 50Гц заметно моргают, но заметно не всем и не всегда и не при любом заполнении. При 90% я не вижу моргания, а при 30% вижу. А на фиолетовых я такое не замечаю, не моргают полюбому. Наверно от цвета тоже зависит.
ПС. Не нагружайте ссылками на ютуб по теме 24vs60 в одном ролике не бывает разных fps, а конвертация из 60 в 24 сама по себе тема отдельного разговора.
Logik, тут просто 23 сообщении из известного факта (используемая частота кадров в кино) делается совершенно неверное обобщение (насчет физиологии человека).
Вообще говоря, зрительный анализатор (глаз) обладает определенной инерционностью. В глазу имеется два типа (один из них в свою очередь подразделяется на 3 разновидности) светочувствительных клеток. У них различные постоянные времени между собой и у каждой из них различные постоянные времени на увеличение и уменьшение яркости. В частности, на увеличение яркости глаз реагирует намного быстрее, чем на уменьшение.
В среднем можно считать, что человек не замечает паузы (гашения) около 15 мс (для колбочек - больше, для палочек - меньше). В случае с кино при обычном коэффициенте обтюрации 2/3 на паузу приходится 1/3 длительности кадра, что при 24 кадрах в секунду составляет 1000/24/3 ~ 14 мс. При этом мерцания изображения почти не заметно. Именно из соображения незаметности мерцания и была выбрана такая частота кадров в кино. К скорости восприятия эта величина никакого отношения не имеет.
В случае же ЭЛТ (кинескопа) каждый элемент изображения засвечивается практически мгновенно и длительность паузы практически равна длительности кадра, что при 60 кадрах в секунду будет уже 1000/60~17 мс. Т.е. частота кадров, вроде, в 2.5 раза выше, а мерцание изображения, тем не менее, более заметно.
Скорость же, с какой человек "видит" определяется прежде всего двумя параметрами: постоянной времени на увеличение яркости (которая в несколько раз меньше) и величиной потока информации, который способен обработать мозг. Т.е. человек способен "видеть" гораздо больше 24 кадров в секунду, правда, при этом он воспринимает не кадр целиком, а, как правило, лишь изменения нового кадра по сравнению со старым.