Arduino.ru

Не понял, ещё одна защита? А то я уже две вижу :)

int X=0;
boolean SB1;
void setup(){}
void loop(){
if (digitalRead(4)==(HIGH)) {if (X<=2000){X++;}}
else {X=0;}
if (X>=20){SB1=(HIGH);} else {SB1=(LOW);}
}

2000 циклов(конкретно этого скетча) дают приблизительно 22мс.
Ограничил размер переменной, иначе она достигает максимума и падает в ноль.

а, теперь добавь в код печать в индикатор lcd.print(число циклов); и обрадуй нас временем исполнения 2000 циклов. О_О

Картинку не знаю как вставить, а так дал бы сигнал с осциллографа

опиши в тексте - у меня богатая фонтазия.

дальше(ниже) кода защиты от дребезга код можно писать или это только для кнопочки ? )))

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

О_О

ок. в пень глумёж - сначала:

А ты не видишь разницы, между проверкой и вычислением в каждом цикле чисел unsigned long() и int() ?

нет, не аналогичны. Метод ТС зависит от продолжительности цикла ЛУП, а значит при любом изменении кода  задержки антидребезга будут требовать корректировки. Классический метод через миилис значительно удобнее.

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

O!!! Супер! Побежал вставлять в свои проекты седьмую строчку. Правильно ли я понимаю, что после двадцатого круга лупа при нажатой кнопке каждый цикл будет выдавать TRUE ?  Подскажите как можно это использовать?

только при покупке лицензии. Купить можно у меня, ежегодное продление со скидкой 20%.

пока я вижу непредсказуемость времени отклика кнопки.

ок. тогда, поделись профитом невычисления в каждом цикле чисел unsigned long - где и что ты выигрываешь?

Кстати int() тут даже избыточен, достаточно short().
Память и процессорное время беречь надо.

как что? - несколько тиков процессора на каждом обороте. Они позволят более эффективно крутить цикл ФОР 2000 раз, пока ждем кнопку :)

это уже технические мелочи - мы напишем функцию производную количества циклов от времени исполнения кода и всё будем пучком. :D

будем калибровать длительность ЛУП прямо в коде? - блестящая идея

для кого беречь?

ты процессорное время и память по наследству потомкам передашь? О_О

чтобы сохранить память в пожилом возрасте, ее не беречь надо, а тренировать :)

будем измерять время луп и считать оптимальное количество циклов.

а, кто обещал, что будет легко?

ТС, если без глума - фигню предлагаете. Такие "костыли" вместо задержек обычно новички придымывают от неспособности понять работу миллис()

Ничего там калибровать не надо.
В том то и разница , что точные вычисления нам тут совсем не нужны. Я думаю и 5 и 10 циклов, уже будет являться защитой. Но задал с запасом. Уменьшенное с 2000 до 100, и работоспособность не изменится. Код спокойно обрабатывает дребезг, проверено осцилографом , подключались два щупа и сравнивались результаты.
Да куда как проще взять готовую библиотеку и использовать ее. Но во первых она занимает больше памяти и замедляет быстродействие.

И это походу из за таких как Клапуций у меня страница в хроме 200мб весит.

Шикарно 

зря ты на ТС наезжаешь - вот здесь https://hackaday.com/2015/12/10/embed-with-elliot-debounce-your-noisy-bu... вумные люди с академическим образованием считают, что сей метод - лучший. там они битами рулят, но не суть. 

я знал, что всё зло от библиотек и Клапауциев. О_О

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

Интересно. Но смысл-то там совсем не в счетчике циклов - счетчик там в тексте вообще не обсуждают - а в хранении историй считывания кнопки в сдвигаемом битовом поле.  Это очень интересный подход. А интервалы можно и нужно отсчитывать с помощью миллис - в том числе и в том коде, что по ссылке.

никто же и не спорит, что твой метод рабочий.

проблема в том, что твой метод требует ручной оптимизации под время исполнения кода.

а, когда ты захочешь плюшек настройки времени отклика кнопки, прочих производных состояния кнопки по времени - тебе придётся оперировать числами unsigned long.

На соревнованиях вместо секундомера тоже можно просто считать "Раз, два, три...". Немного потренироваться и отсчеты будут получаться вполне равномерынми и точными.  А судьи зачем-то пользуются сложными приборами, где можно обойтись своим разумом и здравым смыслом :)

в том то и дело, когда начнёшь отсчитывать интервалы с помощью миллис, все преимущества хранения состояний кнопки в счётчике или битовом поле теряют смысл - их съедают накладные расходы операций с миллис.

а если программа в зависимости от события в любое произвольное время преходит в фунция и шлет что-нибуть в сериал(на дисплей, делает замер чего-нибудь)

то как быть?

Ну значит на проверку дребезга будет в эти моменты уходить не 20-30 мсек а 30-60. Критично ?

а кто сказал, что все это затеяно ради ускорения работы? там в тексте, вообще-то, совсем другие "преимущества" обсудаются -

Wow, that’s simple — the entire routine just checks to see if button_historyis. Detecting a release is then a test for 0b10000000and the up and down states are 0b00000000and 0b11111111respectively. The memory overhead is small, all of the functions are essentially one-liners, and the update and test functions are separable. There’s no need to keep track of what state the button is in, or so it seems, because 0b01111111already contains the notion of a state change between unpressed and pressed. And it works surprisingly well.

Пролистал статью по ссылке.
Пендосы вполне себе обошлись одним байтом.
Мне есть куда расти :-).

к чему тогда рассуждения о экономии процессорного времени, если, как выясняется. даже полсекунды не критично ? :)))))))))

вы просто не поняли, о чем они пишут.... Сходство с вашей "идеей" лишь внешнее, и оно обманчиво :)

Не критичны полсекунды, которые ты на кнопку давишь. И это так, утрировал. Но согласись, что когда ты нажимаешь на кнопку, не важно 20 или 50мсек проверяется дребезг , ты разницы не почувствуешь.

та, да - не корысти ради, а токмо во исполнение воли пославшей мя жены. О_О

кроме эмоций о внезапно открывшемся методе хранения информации в битах - никаких преимуществ не увидел.

а, недостатков - вагон и маленькая тележка.

зря ты так, некая новизна присутсвует.

А какие недостатки?

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

дело за малым - воткнуть результат 2000 опросов в один байт. О_О

дабы ТС ещё чего не переизобрёл - программная эмуляция конденсатора на пине кнопки.

http://www.kennethkuhn.com/electronics/debounce.c

Позвольте узнать, сколько "памяти и процессорного времени" сбережётся, если все, какие бывают в скетчах int'ы заменить на short'ы? Ну вот на одну замену сколько сэкономиться? Или на десять замен?

долой полумеры! - заменяем все переменные на биты.

Точно. А еще можно биты в полубиты. Один бит в LOW, а другой в HIGH.

Ну, уж нет! Это милитаризм какой-то! Одни вон такие неделимый атом разщепили, Хиросиме с Припятью до сих пор аукается. Так что ращеплять неделимые биты мы всяким тут безответсвенным экспериментаторам позволить не могём!

Ну боды расщепили. Почему бит нельзя разщипить. А то что Терминаторы всякие заведутся, ну такова судьба человечества.Пожили и хватит.

А зачем это оперировать большими числами?! Интервал на миллисе отлично делается на шорте или  байте. Дето так например по 20мсек интервальчик.

void loop(void)
{
  static byte OldTime;
  byte Time;  
  
  Time=millis();

  if(byte(Time-OldTime)>20)
  {
.....

На байте до 256мсек. Вполне достаточно для вашего извращения - борьбы с ветряными мельницами.  Начнете писать взрослый код - поймете почему дребезг это надуманая проблема.