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

[Stas633]

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

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

[MrYuran]

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

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

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

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

[scifi]

Как уже сказано, вариант "б" совсем уж нехороший. Вариант "а", насколько я понял, - это общепринятый подход. Однако, как уже сказано, это излишне сложное решение для такой простой задачи. Гораздо проще просто периодически опрашивать клавиатуру.

[Stas633]

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

Спасибо.

[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, вероятность пропуска нажатия кнопки еще меньше.
....

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

[scifi]

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

Конечно проще. Возможно, MrYuran описывал случай без ОС (без процессов/потоков): тогда в прерывании таймера можно устанавливать флаг, а в главном цикле по этому флагу делать опрос.

И если "останавливаться" на Sleep(n), то не проще ли опрашивать через время достаточное для устранения дребезга...

Конечно проще. Тут всё зависит от конкретного применения. Чем сильнее мы фильтруем дребезг, тем больше рискуем пропустить законные нажатия на кнопку. Где-то это не важно (кому надо, подержат кнопку подольше), а где-то - очень важно. Опять же, в разных применениях требуются разные события от клавиатуры: где-то только нажатие кнопки, где-то - нажатие и отпускание, а где-то - нажатие, автоповтор с задержкой и отпускание. Исходя из требований и выбирается алгоритм.

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

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

[MrYuran]

Что теряем? - Увеличивается время реакции на нажатие с 3мс до 50мс. Но при скорости печатания 150 знаков/мин (это очень хороший результат, обычно 100...120) время между нажатиями 60/150 = 400мс.
Быть может такое мнение ошибочно?

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