Так нужно дребезг подавить или определить, что он был?
Если первое, то, наверное, красивше так:
case 0x02:
if (millis() - timer < 100) {
break; // крутимся в этой ветке до 100мс
}
if (!pinstat) {
Serial.println("button is pressed");
} else {
Serial.println("p3");
}
stat = 0x00;
break;
я предпочитаю реагировать на нажатие сразу и далее блокировка принятия решения на время дребезга контактов, это если не надо отслеживать длительное нажатие, только клик
И больше, чем именованные константы? Осмысленное имя понять проще, чем безликую цифру 
А без разницы. Если нужно отслеживать удержание, отсчет ведется с момента первого срабатывания, т.е. время антидребезга тоже туда включается
Чем “заблокированное” действие отличается от неначатого? Усложнением алгоритма разве что…
С учётом того, что дребезг удачно пережидается за 5-10мс, что для обычного человека незаметно, смысл в наворотах теряется.
Это если от дребезга может лишнее событие случиться, типа на индикаторе при наборе цифра 2 в 6 перескочит, то надо давить. А так и так сойдёт. Без подавления можно аварийный клапан стопорить.
Нужно подавить, то есть чтобы кнопка была нажата, к примеру, минимум 100 мс, хотя это наверно уже удержанием называется? Чтобы при однократном нажатии счётчик прибавился на единицу (так проще объяснить), а не на N число, которое получится из-за дребезга.
Ну нет, конечно же нет)
100 мс - это очень, очень раздолбанная кнопка. Для нормальной и 20 мс хватит. Ну для гарантии можно 50 мс сделать. На глаз это будет тоже незаметно, но дребезг подавит гарантированно
ВременнЫх стандартов на то, что называется кликом, что удержанием, я не видел.
Один из способов переждать дребезг - перепроверка через 100мс. Через это время, предположительно, всё должно успокоиться. Способ простой, как палка. Вы его попытались реализовать, но в конце немного неверно поступили, на мой взгляд.
Второй - проверка N раз в течении 100мс. Как только M попыток из N дают одинаковый результат - значит всё устаканилось. Если правильно помню, SergeyL является сторонником этого метода. В реализации посложнее, но, теоретически, может сэкономить капелюшку времени, если кнопка успокоится раньше.
Если посадкой на луну управлять не нужно, первого - за глаза.
Не только он, я читаю 16 раз с задержкой после чтения 1-2 мс. Если ВСЕ 16 раз кнопка нажата - значить она нажата, если хоть один раз нет, то дребезг, кнопка считается ненажатой/отпущенной.
Я просто просто за метод вертикальных счетчиков плюсую, уж больно он оптимален по продуктивности. Я искал решение, и оптимальней не нашел.
Надеюсь, в курсе, какие фокусы выкидывал компьютер (кстати, по причине родственной дребезгу) при посадке Аполлона 11?
В миссии не участвовал, так что не в курсе.
А если попадёт так, что на таймере 1000 мс кнопка в LOW, на таймере 1100 кнопка в LOW, а в 1050 кнопка была в HIGH. Делать сброс и начинать отсчёт заново?
Вот второй вариант мне больше нравится, к примеру проверяю каждые 5 мс, если после 5 проверки на счётчике цифра 5, значит всё ок, если был переход с 0 на 1, начинаю всё заново.
Чуть позже напрограмлю код, на зачёт ))))
Ты думаешь Петрович прям участвовал ?
Так может это у человека рука дрогнула, а на самом деле он держит палец на кнопке и думает, что аппарат должен сработать.
Тут вы с немного иной, но ненулевой вероятностью можете пропустить HIGH на 7,5мс, и 12,5мс к примеру. И как этот случай трактовать?
В нашей реальности нет 100% гарантированных способов отделить полезный сигнал от бесполезного. Можно только бесконечно приближаться к этой величине, усложняя алгоритм обработки сигнала.
Ну, и как критерий истины, использовать практику.
Вобщем, моё мнение таково - как “blink без delay” закрывает 80% нужд местного ардуинщика, так и простая перепроверка через 10-100мс закроет проблему дребезга в самопальных устройствах
Ну, он-то поумней меня…
а это мысль! судя по тому с какой доскональностью знает все о ейном компьютере
А то! Я в это время в первый класс пойти готовился и очень даже интересовался как там дяди по Луне шастают и почему до сих пор не свалились оттуда.
Ну, сейчас это просто глава в истории программирования, и чтобы о ней знать, не обязательно участвовать. Есть мнение, что это самая дорогостоящая ошибка в истории.
Если погуглить “Apollo 11 error 1202” , до фига чего найдётся.
Хотя, конечно, лучше всего читать официальную информацию от NASA. Там подробно расписан механизм управления памятью AGL и причины ошибки.
Кстати, вот журнал разговоров ЦУПа с экипажем. Их реакция на то, как компьютер с катушек слетел тоже интересна.