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

[Stas633]

... опрос клавиатуры по прерыванию, устранение дребезга контактов....
Подскажите как, с точки зрения RTOS, поступать правильнее :
а) в прерывании от кнопок "сигналить" процессу, а уже в нем вводить паузу через Sleep(..), счивать скан-код, разрешать прерывания.
б) паузу вводить в прерывании, там же получать скан, разрешать прерывания и, как писал в форуме dxp, отправлять процессу сообщение (а не флаг).
...
Если "б)", то чем реализовывать паузу?

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

[MrYuran]

Как угодно, только не б)

И вообще, зачем прерывания от кнопок заводить?
По-моему, намного проще опрашивать порт по таймеру. То есть, системный таймер выставляет флаг раз в 2-5 мс, по этому флагу отдельный поток считывает порт и анализирует вволю.

Я обычно (даже без РТОС) делаю так:

Если что-то нажато и совпадает N раз подряд, то выставляю флаг KeyPressed и байт KeyCode.
Если нажато долго (допустим, 1с), выставляю дополнительный флаг KeyLocked.
Далее заинтересованные приложения могут делать с этими данными что им нужно.
При первом несовпадении сбрасываю всё в исходное состояние.

[Stas633]

И еще мнение, "..в догонку.."

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

.... намного проще опрашивать порт по таймеру. То есть, системный таймер выставляет флаг раз в 2-5 мс, по этому флагу отдельный поток считывает порт ....

, разве не проще через Sleep(n) в самом процессе? /нет необходимости ни флаг создавать, ни конструкцию "сочинять" для установки флага с периодом, отличным от периода сис.тика (напр., флаг нужен через 3мс, а тик равен 1мс. А для Sleep(n) -> n=3 и "..все..")/.
...
И если "останавливаться" на Sleep(n), то не проще ли опрашивать через время достаточное для устранения дребезга...

Общепринятым считается:
- опрос состоятия через ~2..10мк;
- при получении изменения "задержка" опроса на ~50мс /тут два варианта или "пауза", или подсчет числа обращений (3мс х 17 раз = 51 мс). Для RTOS приемлем последний вариант, посностью согласен с MrYuran/ ;
- повторный опрос;
- принятие решения.

А что если производить опрос через 50мс?
Получается:
- опрос /обнаружено изменение/;
- задержка 50мс;
- повторный опрос;
- принятие решения.
Дествия те же, но вот для RTOS от 17 (в нашем примере) циклов переключения процессов, со всеми вытекающими..., удается избавиться.
...
Что теряем? - Увеличивается время реакции на нажатие с 3мс до 50мс. Но при скорости печатания 150 знаков/мин (это очень хороший результат, обычно 100...120) время между нажатиями 60/150 = 400мс. А предполижить, что кнопками прибора бутут пользоваться с такой скоростью затруднительно.. То есть, применительно к EmbeddedDevice, вероятность пропуска нажатия кнопки еще меньше.
....

Быть может такое мнение ошибочно?