Еще раз про дребезг при нажатия кнопки

Сергей К, ну каюсь, чуть ошибся с 10 мс........а вдруг бы у кого-то получилось...

SAK: Вот для этого вывод MCLR нельзя оставлять висящим в воздухе, иначе он сбрасывается даже если руку поднести не прикасаясь.

А как быть, если этот вывод задействован не как MCLR, а как внешний вход?

Zandy: Все так и делают!
Жаль, что в Микрочип об этом не знают AN557 (00557C.PDF)
Zandy: Зачем еще изобретать велосипед?
Да вот и я о том же, зачем решать несуществующую проблему, которую, к тому же, невозможно решить при дискретной проверке. Можно ли утверждать, что уровень сигнала не менялся между проверками если несколько последовательных проверок дали одинаковые результаты? Только с некоторой вероятностью. И вероятность ошибиться в данном случае значительно больше, чем вероятность гипотетической помехи, тогда что дают эти дополнительные проверки?

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

Zandy: А как быть, если этот вывод задействован не как MCLR, а как внешний вход?
Ну насколько я понимаю "висящий в воздухе" означает "ни к чему не подключенный" или я ошибаюсь?

SAK: Жаль, что в Микрочип об этом не знают AN557 (00557C.PDF)

http://ww1.microchip.com/downloads/en/AppNotes/00557d.pdf

Once the key hit is sensed, a 40 ms
debounce period elapses before key sampling is
resumed. No more key hits are sensed until the present
key is released. This prevents erroneous key inputs.

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

Crot2: дребезг заметить никак не удалось
Существенно - дребезг какого контакта?
Если взять два проводка - это одно, герконовую клавиатуру - совсем другое.
Понимаю, тут пытаются программно решить проблему. Но она ИМХО решается комплексно.
Программа должна быть привязана к железке.

SAK: Жаль, что в Микрочип об этом не знают

SAK: зачем решать несуществующую проблему, которую, к тому же, невозможно решить при дискретной проверке.

Crot2: я проверял нажатие по двум подряд нулям через 20 мс, а после ждал отпускание - две единицы подряд через 20 мс

петр1: Понимаю, тут пытаются программно решить проблему. Но она ИМХО решается комплексно.

Ну и т. д.
Друзья, я предвидел нечто подобное, поэтому, чтобы тема не переросла в полемику, в начале поста два раза сказал, что интересуют конкретные времена, а не способы программной или аппаратной обработки. Понятно, что их существует несколько вариантов. Со всеми известными можно ознакомиться и выбрать "по вкусу". А вы все-таки спровоцировали меня высказаться за тот, который применяю я. Я ведь тоже не с потолка его взял. И тоже могу ссылку привести. Очень солидная фирма. Выпускает специализированные микросхемы, в которых аппаратно решается именно эта задача (предотвращение помех и дребезга контактов). http://www.rtcs.ru/supplier_article_detail.asp?supplier=9&id=87 Легко реализуется софтовым путем.

Подвожу резюме по высказываниям.
SAK: 50 мс оптимальное время опроса
picmaniac: На антидребезг, ИМХО, достаточно 50-200 мс
Crot2: Реально в своей программе я проверял нажатие по двум подряд нулям через 20 мс, а после ждал отпускание - две единицы подряд через 20 мс

SAK: Zandy: А как быть, если этот вывод задействован не как MCLR, а как внешний вход?
Ну насколько я понимаю "висящий в воздухе" означает "ни к чему не подключенный" или я ошибаюсь?

Так все-таки, если вывод является входом, могу ли я его "бросить в воздухе"? Такое иногда встречается. Например, разобрав свой "покупной" сенсорный выключатель, обнаружил, что ко входу микроконтроллера подсоединена металлическая пластинка (и больше ничего) при поднесении руки к которой, выключатель срабатывает. О корректности такого решения говорить не будем. Вопрос именно про вероятность сброса МК.
А потом ситуация гипотетическая. Зачем мне специально конфигурировать вывод, как MCLR, чтобы потом бросить его в воздухе? А если я конфигурирую вывод как вход, разве MCLR внутри МК не подвязывается к питанию?