ATMega32: защита от дребезга контактов (прерывания)

[ellioh]

-

[saschai]

http://radiokot.ru/forum/viewtopic.php? ... start=1220
Посмотри, сам мучался, очень изящный ход,
Понятно, что применительно к своему варианту

Код: Выделить всё

Button:

Waitms Debouncetime           ' антидребезг
Toggle Led

While Pind.2 = 0                   ' если кнопка удерживается
Waitms Debouncetime
Wend                                  ' крутимся здесь

Eifr = 64                             ' сбрасываем флаг

Return

[Rimsky]

Я бы сделал так:
1. Инициализировал прерывания по спаду фронта INT0
2. В обработчике инициализировал таймер защиты от дребезга и запретил прерывание от INT0
3. Далее в цикле после sleep отсчитал временной интервал (обычно около 200 мСек)и пощупал пин на нажатие.
4. Если кнопка нажата, то запускаемся, если нет возращаемся к процедуре инициализации и засыпаем.

[Amator]

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

Самый простой способ - это аппаратный (повесить на ногу int конденсатор).

[IgorKu]

Самый простой способ - это аппаратный (повесить на ногу int конденсатор).

Подтверждаю. Более того, по-моему чисто программно как не пиши - путевого не получится. Сам изощрялся с енкодером, чего только не выписывал - пока не повесил конденсаторы на контакты по 0.1, нормально не заработало.

[Engineer_Keen]

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

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

[ellioh]

-

[ChipKiller]

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

... думаю прерывание по INT0 не нужно, как и всякие конденсаторы на контактах . В конструкциях типа АОН и Spectrum и т.д. опрос по таймеру прекрасно со всем справлялся. Причем несложно учесть одновременное нажатие нескольких клавиш, ввести функцию "автоповтор" при удержании и многое другое. Все что нужно - завести несколько переменных и правильно обрабатывать их состояние.

[ellioh]

-

[ARV]

ощущение такое, что никто не в курсе, как борятся с дребезгом по-настоящему... конденсаторы... ё-моё! традиционная борьба с дребезгом, причем ВЕСЬМА эффективная, заключается в проверке через 10-15 миллисекунд уроня на кнопке и сравнения его с тем, кторый породил само событие. то есть, если у вас прерывание настроено на срабатывание по спаду (хотя, если мне память не изменяет, для просыпа лучше использовать срабатывание по низкому уровню), то в обработчике прерывания этого вам надо подождать 10-15 миллисекунд и проверить уровень на пине - если он НИЗКИЙ, то делать свои черные дела, если ВЫСОКИЙ - спать дальше. да, перед тем, как выйти из прерывания, надо сбросить флаг запроса прерывания, так как из-за дребезга он мог установиться повторно.

и всех делов. и никаких кондеров!

[Murav]

то в обработчике прерывания этого вам надо подождать 10-15 миллисекунд

Делать огромную задержку в прерывании?

Хотя идея правильная, только задержку стоит делать на таймере(не важно, аппаратном или программном на основе общего аппаратного) и по его прерыванию уже проверять состояние на входе.
И временную границу дребезга обычно берут не 10-15мс, а 50-100мс.

и всех делов. и никаких кондеров!

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

[ARV]

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

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

[ellioh]

-

[ARV]

уважаемый, я думаю, что ваши опасения на счет задержек в прерывании и нарушения стиля "по событиям" НАПРАСНЫ. с точки зрения основной программы, которая СПИТ, задержка при пробуждении не играет никакой роли совершенно! из режима "глубокого сна", т.е. при максимальной экономии энергии, МК не в состоянии проснуться даже за 15 мс, поэтому реальное время выхода из прерывания СОВЕРШЕННО БЕЗРАЗЛИЧНО. мне так кажется.

а в вашем подходе есть существенный изъян: вы регистрируете КУЧУ прерываний и анализируете их. а мой вариант - ТОЛЬКО ОДНО ПРЕРЫВАНИЕ и анализ уровня. это намного проще, и, пожалуй, правильнее.

[Rimsky]

В принципе можно использовать пустое прерывание по int (без обработчика) чтобы проснуться, а кнопку опрашивать по таймеру.

[ellioh]

-

[ARV]

я ж говорил, что имею ввиду режим максимальной экономии, т.е. Power Down... а из Standby пробуждается быстрее, факт.

в общем, мое дело - уведомить о способе, а будете вы им пользоваться или нет - дело ваше.

[ellioh]

-

[lsdy]

Обратите внимание еще на один аппаратный подход

[ARV]

Обратите внимание еще на один аппаратный подход

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