Arduino.ru

 А просто конденстор 2-4 мкФ параллельно каждой кнопке прицепить не вариант?

Это разве не подходит под описание второго варианта?

Один конденстор на кнопку - это перегруженность схемы? В чем проблема, не понимаю )

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

Я же так понимаю вам важно ловить кто первый нажал? Ну вот от кого первым импульсом словили нажатие, тот и выиграл. А то что после первого импульса последует еще парочка быстрых "нажатий/отжатий" (пока кнопка не займет четко нажатое положение) - так просто плевать на них и все. Поймали импульс - миллисекунд 100, больше не смотрим на этот пин. В любом случае "кто первый нажал кнопку", тот и "дребезжать первым начнет". 

www.edaboard.com/thread36051.html

Здесь говорят, что подобная схема (конденсатор последовательно кнопке плюс pull-up сопротивление) является, дословно "perfect example of an unreliable RC debouncer" (сообщения 9-10). Где правда?

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

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

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

C ведущим - ну так тем более. Вам опять-таки важно как можно раньше поймать "когда он начал нажимать кнопку". А кондер вам это время "затянет". Что делает кондер? Увеличивает время между нажатием кнопки и приходом сигнала. Он как-бы делает "ход кнопки" более медленным. И игнорирует импульсы меньше определенной длины. Все тоже самое вы можете сделать программно, только подстраивать импульсы меньше какой длины игнорировать - легче.

"Полу выжим кнопки" - даже философии не вижу. Предположим есть кнопка с полным ходом 5mm. Мы можем объявить что "нажатием считается вжатие кнопки на 5mm", а можешь сказать "нажатой считается вжатая на 3mm" кнопка. То есть она будет работать как "четкая кнопка" с ходом в 3mm, которую, после нажатия, можно "еще продавить", но на это уже ни на что не влияет. Граница-то "нажатия" находится только у вас в голове. Как решите - так и будет.

Можно еще взять кнопки у которых сопротивление нажатию не линейно, которые "щелкают" (клавиатуры многие такие кнопки имеют). У них сопротивление нажатию растет до определенного порога (и сработки в этот момент еще нет), а потом "резко пошла без усилий". И вот после этого порога остановить палец уже практически не возможно. С другой стороны этот "порог" хорошо чувствуется пальцем. Есть хорошая тактильная обратная связь. Если почувтсвовал щелк - значит кнопку точно нажал.

 И вообще программист должен быть существом ленивым. Решать проблему только 100% убедившись что не решать ее - нельзя :)

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

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

Я не программист, я математик-теоретик. Я привык предвидеть все возможные проблемы и варианты заранее)

Как привезут плату - попробую, потестирую, может, и вправду я зря заранее голову грею. Спасибо за советы!

"Математик выливает воду из чайника и заявляет что задача сведена к предыдущей" ;)

Ну тогда, наверное такой ход мысли будет более близким:

а. Прикидываем разницу в стоимости решение проблемы если она "продумана заранее" и "пришлось переделывать".

б. Прикидываем стоимость "продумывания заранее" и вероятность что "проблема будет". Делим первое, на второе.

--------

Если (а) выше - думаем заранее, если (б) - откладываем.

P.S. Вам, тогда, как математику, навероное, ближе будут фунциональные языки программирования, а не императивные. Но не слышал про функциональные на микрокотроллерах. Разве что ПЛИС-ы, чем-то напоминают. Но у них цены "ой", хотя начали дешеветь.

Да, математик ещё и огонь должен потушить. =)

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

Пойду прикидывать стоимости и вероятности=)