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

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

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

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

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

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

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

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

Спасибо.

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

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


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

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

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


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


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

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