Почему?

по определению...

быстрые клики попавшие в паузы опроса - не будут замечены. Прерывание чем хорошо, что даже если вы запретили прерывания в момент нажатия, нажатие все равно будет замечено и флаг будет поставлен, и разрешив прерывания вы узнаете что нажатие было.

Главное не понятно откуда такая боязнь прерывания? Любой полинг грузит процессор в разы выше,

Я внимательно прочитал, только всё равно не понял зачем опрашивать дребезг??? Я почему-то всегда считал - его надо гасить...
Если у вас максимальное время дребезга кнопки 5мс, то соответственно частота сканирования кнопок не должна превышать 200Гц иначе будут ложные срабатывания. Вот и всё.

Здесь вроде обсуждается вопрос подавления дребезга, а не генерации его.

И на прерывание и опрос в цикле - обе плохие. Грамотно - делать опрос из периодического прерывания.


Обоснуйте.

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

Опрос раз в 50 мс в прерывании таймера. Клик быстрее 50 мс - это не клик, это наводка. Зато никаких ограничений на функции вывода - ему не обязательно иметь возможность генерить прерывания. Он может использоваться для дополнительных функций - например, на нем может висеть еще и индикатор. Он может вообще быть аналоговым и читаться через АЦП. Кнопки могут быть организованы в матрицу или еще каким-то хитрым способом.




У меня в ATmega8 только две ноги могут генерить прерывания. Мне отказываться от заказов, в которых более двух кнопок?

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


имеем
кнопка подключена к ножке процессора, которая умеет генерить прерывание на изменение фронта этой ножки. Вешаем на эту ножку кнопку, применяем все меры по устранению дребезга на схемотехническом уровне. Теперь вопрос, почему в данной ситуации не использовать прерывание? Чем оно хуже полинга? Зачем в этой ситуации нужен полинг? Какой выигрыш от периодического опроса?

Когда я пишу потенциально - это значит потенциально, а не всегда. пишешь приложение с главным циклом

опрос кнопок
измерение
вывод на экран

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

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

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


Проверяйте состояние входа в функции прерывания таймера.

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

про таймер написал чуть ниже, тоже прерывание, только еще и таймер заюзали.

Про то что будет работать для любого входа, аргумент, но есть ли смысл? Если есть устройство, в нем есть прерывание и кнопка, зачем писать так чтобы работало и без этого? На будущее?
Мы решаем эти вопросы во время проектирования, если прерывания выделить невозможно, решается так, если есть порты с прерываниями - сяк. Конкретный прибор - конкретная реализация, переносимость кода и его изменяемость решается на более высоком уровне, на том где уже состояние кнопок получено, а как получается состояние кнопок - это уже конкретный прибор == конкретный способ.

На то они и таймеры, чтобы их юзать...
К тому же в программе как правило нужен таймер для формирования времени и тп.

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

Есть одно НО: периодический опрос кнопок - это не хоть как-то. Попробуйте на досуге - работает замечательно.

мне кажется меня не слышат, наверное вам кажется так же.

у человека есть проц
есть ножка с прерыванием
есть кнопка
есть прерывание

спрашивает так делать хорошо или плохо? ему говорят плохо, потому что в АВР нет прерывания))... ну смешно же!
Мой ответ так делать в конкретно этом случае хорошо!

Скажу больше: и так, и так хорошо. А с учётом времени, потраченного на спор, мой аргумент о недостатке времени в данном случае не применим :-)
Но есть иные аргументы: переносимость кода, например. Хотя в данном случае он тоже может быть не применим - автору вопроса виднее. Со своей стороны замечу, что при прочих равных стараюсь выбирать переносимый вариант, причём на практике это реально приносило плоды при переходе на другой компилятор, МК и т.д.

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