давайте мало-мало определимся.
1. мы делаем устройство тренировки мастера кун-фу? только специально тренированный человек способен совершать ОСОЗНАННО нажатия на кнопку с периодом меньше 0,1 с (100 мс), у остальных это либо механическое тыканье, которое невозможно своевременно остановить или начать, либо просто случайное везение. то есть смею предположить, что нет, мы рассчитываем на обычного человека.
2. мы делаем систему управления пуском ядерных ракет или на худой конец систему дистанционного управления роботизированным хирургом-кардиологом? случайный пропуск нажатия или случайное нажатие кнопки приведет к катастрофическим последствиям? предположу, что нет и в этом случае.

итак, опрос состояния битов порта 1 раз в 50 мс обеспечит реакцию на нажатие не хуже, чем 1 раз за 100 мс (Брюс Ли ликует), и не допустит пропуска или случайного срабатывания из-за дребезга (поскольку если у вас кнопка дребезжит более 50 мс - это говно, а не кнопка).

для справки: все учебники по защите от дребезга учат, что дребезг длится около 10-15 мс у среднестатистической кнопки.

зачем вы сами себе придумываете проблемы?! чтобы героически их решать? из мазохизма? из манеризма и эстетсва?

Добавлено after 5 minutes 21 second:
дополнительно: как бы вы не боролись с дребезгом, это неизбежно приводит к тому, что должны возникать паузы между опросами. и если мой алгоритм, по-вашему, вызывает неприятные задержки в данных условиях, ваш алгоритм в тех же условиях не сможет лучше бороться с дребезгом и тоже приведет к тем же самым (а то и большим) задержкам! это ведь логика: если кнопка дребезжит 80 мс, то любой надежный алгоритм будет обязан ждать не менее 80 мс!!! и не важно, эти 80 мс будут регулярными по таймеру или адаптивными по логике анализа состояний.

Обработчик кнопок "сам по себе" не существует.
Соответственно и его содержимое будет различаться довольно существенно.
Я пока долизываю "упрощёнку" для 8/10 позиционного "кракозяброва" дисплейчика.
Курсор в виде децимальной точки знакоместе, четыре/пять кнопок "джойстика", отдельно кнопа+Светик активации клавиатуры. Интерактив с оперативной сменой назначения и функционала кнопы в зависимости от хода программы и пиктограммы в позиции курсора.
Режимы сработала по нажатии, однократная, многократная(при удержании), авто отключение сканирования кнопок при длительном отсутствии нажатии(активности).
Заложен(но пока не доделан) режим однократной сработки по отпусканию.
Собственно для малых конструкций с семисегментниками.
Функционал ессно похуже, чем у 1602 с полноценными пиктограммами и строкой подсказки, но для малых поделок вполне с годиться.

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

не надо путать уровни.

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

"Все взаимосвязанно" и зависит от конечной цели применения.
Как и задачки
исполнение по нажатию
исполнение по отпусканию

Без конкретики задачи разговор о кнопках будет бесконечен.

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

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

хотя... евть и у меня старая поделка, всё руки не дойдут разобраться (там алгоритм опроса немного другой, кнопка опрашивается по прерыванию, и хоть вход там сильно задушен многократными перепроверками - всё равно иногда ложные срабатывания пролазят... (хотя я не уверен, что через кнопку... там кроме кнопки есть вход детектора 0 и ИК приёмник... но, если честно, то мнеикажется, что глюк пролазит не через кнопку и не через ИК, т.к. они сбрасывают счётчик, а он остаётся несброшенным...

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

оффтоп: меня в своё время убила инфа про "системы, защищенные от радиации". типа ОЗУ с автоматическим контролем возникающих ошибок - дескать, прилетел нейтрон радиационный, выбил бит в ОЗУ - система аппаратно посчитала CRC и выдала сигнал контроллеру, что доверять памяти нельзя. я опускаю риторический вопрос о том, что помешало этому нейтрону повредить "аппаратный" вычислитель CRC... это такое... лучше не задумываться.

вроде все хорошо, но вопрос: и чо контроллер с этим сигналом делать должен?! особенно для случая, когда исполняемая программа так же в ОЗУ (речь шла о компьютерах)?! если доверять нельзя, то и обработать сигнал нельзя, ведь неизвестно, что там программа из недостоверного ОЗУ исполнит... в итоге этот сигнал, по сути, сводится к выключению процессора и всё. хороша защита от радиации, которая вырубает систему в случае "несанкционированных" сбоев...

Сейчас в простейших STM32 за 40 центов есть хардварный контроль четности SRAM, а в более продвинутых - ECC(Error code correction). Нарушается целостность SRAM, генерится прерывание и да, сбросить мк чтобы он перезапустился и дальше работал правильно вполне разумное решение когда альтернативой является его потенциальная продолжительная неправильная работа.

А если пьезоэлектрические кнопки сделать,наступил на неё,выдала одиночный импульс.
Будет у них дребезг ? От перенапряжения можно снабер поставить. Правда ж я умная ?

правда.. но этого вслух никто не скажет..
иначе свою несостоятельность придётся признать

"простой" алгоритм при периоде таймера ~= периоду дребезга не гарантирует что дребезг "пройден" потому что не синхронизирован с фактом нажатия.


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


обычно у меня общий подход к обработке сигналов, гдето дребезг кнопки, или рэлюхи какогото удаленного на 500m датчика, гдето просто дребезг квантования медленного сигнала. часто подобные сигналы сгруппированы в 1 порт и обрабатываются обшим алгоритмом (по 1 его прогону на каждые обрабатываемые 8 сигналов).
можно назвать эстетством а можно системным подходом

поскольку дребезг возникает не сам по себе, а при изменении состояния кнопки, то даже если в момент опроса он "еще не пройден", все равно факт изменения состояния будет зафиксирован либо сразу в момент опроса, либо при следующем опросе (т.е. спустя злосчастные 100 мс или даже менее). и это так же универсальный подход для любых дребезжащих сигналов.

в этой теме КРАМ неоднократно рекомендовал нарисовать временную диаграмму опроса дребезжащего сигнала... похоже, никто не воспользовался советом, отсюда и продолжающиеся дискуссии о том, что якобы "таймер ничего не гарантирует".

если время_обработки_события + время_следующего_опроса > времени_дребезга, то смысла нет обрабатывать дребезг..

если ожидается наводка на линии, то гарантии, что она не обойдёт программный алгоритм нет абсолютно никакой

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

Добавлено after 2 minutes 18 seconds:
при значительных наводках на линии беспокоиться надо совсем о другом, да... например о том, чтобы устройство вообще осталось целым.

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

ну да, как железный купол израиля, до первой атаки..
или как крестик, типа от всего уберегает, но в случае чего - то к врачу или в полицию..))

Дребезга не будет только если резонансная частота их будет порядка десятка Гц или меньше. Но боюсь себе представить размер таких пьезокристаллов. И какой слон потребуется для наступания.

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

и ещё момент)) у всего должны быть свойства. и у защит тоже.
иначе разговор о "защите" просто беспредметный.

Допустим программный алгоритм предохраняет от наводки..
Тут же вопрос: от какой наводки? её кто-то в глаза видел, или программист сам её нафантазировал?))
Считает и сравнивает 7 сэмплов.. А если прилетит ещё, а 8-й сэмпл не сравнивается?

У дребезга допустим есть свойство, выражаемое в наносекундах.
А у наводок какие свойства? амплитуда? частота? повторяемость?
С чем борьба то?