Опрос клавиатуры на С, Как написать компактный и "красивый" код? Опции

[iliusmaster]

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

[AlexandrY]

Ну почему же? Стильно, модно, молодежно. Следующим этапом будем искать кнопки с переключающими контактам, потому что только такие есть в модели.

Да не проблема.


Просто сегодня тестирую Matlab 2018а.
А так это конечно шутка. (Но рабочая!)

[Forger]

Обычно, чтобы ничего постояно не опрашивать,

А в чем проблема периодического опроса, что его по-вашему следует избегать? Вот честно, не понимаю )

Обычно, чтобы избежать ненужной мгновенной реакции на очень медленное событие - реакция человека на различные действия, в т.ч. и действия его самого - делают как раз периодический опрос с такой частотой,
с которой среднестатистический индивидуум никак не увидит разницы.
А раз нет разницы, то зачем за это платить диким колхозом из нагромождений "временных меток", "каскадов сравнений" и подобной средневековой дикости?

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

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

Вот тут можно время отклика до микросекунд уменьшить

Почитайте название темы : "Опрос клавиатуры...", не управление ключами драйвера двигателя для соотв. формирования ШИМ, а опрос клавиатуры!
Клавиатуру нажимает человек, а не робот. Именно из этой позиции и следует подходить к решению задачи с клавиатурой.
Роботы еще не скоро займут место человека, но, если и займут, то клавиатура им точно не понадобится

Как-то в свое время ради интереса я собирал статистику: имеем задачу, которая занимается обработкой матричной клавиатуры 16х16, период - 50мс (дребезг в таких условия не грозит).
Так вот нагрузка на CPU (мерял под RTOS) составляла сотые доли процента. Речь тогда была про "бытовые" кортексы STM32F103 на 72Мгц.
Сокращая период до 25 мс, нагрузка на CPU соотв. удвоилась - но в итоге те же доли процента ...
Поскольку события возникают лишь при изменении состояния клавиатуры, то в расчете на 10 событий в секунду (таких индивидуумов еще найти нужно) нагрузка возрастала до 0.1%.
Вот и вся математика
Повторюсь - постоянный опрос клавиатуры 256 кнопок и 10 отпусканий/нажатий в секунду. Конкретный пример и конкретные цифры.
Код простейший, построенный по алгоритму, как я описал во втором посте этой темы.

[ArtemKAD]

Ну развели... Проблема дребезга полностью освещена даже в Вики: https://ru.wikipedia.org/wiki/%D0%94%D1%80%...%82%D0%BE%D0%B2

В частности программные методы борьбы:

При программном формировании очищенного от дребезга контакта сигнала наибольшее распространение получили три из них:

1.Путём установки временной задержки — программа, обнаружив замкнутое состояния контакта, игнорирует его состояние на время, заведомо большее длительности дребезга, и спустя это время снова проверяет состояние контакта. Если после этого времени состояние контакта замкнутое, то соответствующая переменная меняет значение.
2.Методом подсчёта числа совпадающих значений сигнала замкнутости — программа многократно считывает состояние контакта, и, если последовало определённое количество подтверждений замкнутости в течение заданного промежутка времени (определяется экспериментально и выбирается в пределах от 10 до 100), контакт считается устойчиво замкнутым.
3.Методом подсчёта времени устойчивого состояния — программа в течение заданного времени многократно считывает состояние контакта. Если в течение заданного времени не обнаружено ни одного изменения состояния на противоположное, то контакт считается устойчиво замкнутым. В противном случае, если было обнаружено изменение состояния в течение заданного времени, то подсчёт времени прерывается (или продолжается, но с установкой флага или подсчётом количества изменений состояния для оценки физического состояния механических контактов) и контакт считается разомкнутым или с неустойчивым состоянием (если такая информация используется в программе).

Время дребезга для контактов клавиатуры до нескольких миллисекунд (до 5). Forger по сути предложил метод №1 суть которого сравнить 2 измерения с временным промежутком времени завершения переходного процесса на контакте. Кстати, не обязательно постоянно опрашивать. Если есть необходимость глубоко дрыхнуть и просыпаться по сигналу нажатия, то никто не мешает в прерывании которое разбудило запустить таймер на те самые несколько мс в котором и принять решение чего это такого только что было...

ЗЫ. На самом деле есть еще более тупой метод борьбы с дребезгом - RC-цепочка после контакта плюс триггер Шмитта который есть на входах многих современных контроллеров...

[Forger]

Ну развели... Проблема дребезга полностью освещена даже в Вики

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

Если есть необходимость глубоко дрыхнуть и просыпаться по сигналу нажатия,

В предложенном мной решении, для этого таймер периодического опроса клавиатуры можно временно перенастроить на период, скажем, в 1 сек.
Этот таймер будет периодически будить проц. Для полного пробуждения достаточно удерживать "правильную" кнопку соотв. более 1 сек.
Если же и это не годится, то кнопку пробуждения следует делать вообще отдельной от остальной части клавиатуры и заводить на соотв. пин проца.

[Сергей Борщ]

Forger по сути предложил метод №1 суть которого сравнить 2 измерения с временным промежутком времени завершения переходного процесса на контакте.

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

ЗЫ. На самом деле есть еще более тупой метод борьбы с дребезгом - RC-цепочка после контакта плюс триггер Шмитта который есть на входах многих современных контроллеров...

С натяжкой подходит для одиночных кнопок и не годится для матричных клавиатур.

[Forger]

...

Вы прям "разжевали все до молекул"
Честно говоря, мне лень было расписывать такие, казалось бы, очевидные вещи. Но очевидность, видать, тоже - понятие субъективное ...

[ArtemKAD]

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

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

[Forger]

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

В автомобилях подтяжки ставят достаточно низкоомные.
В одном из проектов для опроса такой кнопки мне пришлось ставить реально низкоомные резисторы, через которые при нажатии кнопки шел довольно немалый ток.
Чтобы не спалить эти резисторы, питание на них подавалось кратковременно (около 1мс) и непосредственно перед опросом кнопок. Опрос - периодический (50мс).

С "классической" постоянной подтяжкой (около 1мА) эти кнопки, которые находятся снаружи кабины камаза, через какое-то время эксплуатации переставали работать - постепенно окислялись контакты.
Но относительно большой ток подтяжки (около 0,15 А), видать, "выжигал" тонкий слой окисла и кнопки работали как ни в чем не бывало.

Глянул конкретные значения: 150 Ом (24В). А резисторы всего лишь в корпусе 1206.
Но, если бы оставил постоянную подтяжку, то пришлось бы ставить 5..10 Вт резисторы.

Один "минус" такой схемы - нужен доп. транзистор для программного управления подтяжкой.

[ArtemKAD]

Импульсную подтяжку еще и на кнопку - знаете вы толк в извращениях...

[Forger]

Импульсную подтяжку еще и на кнопку - знаете вы толк в извращениях...

Извращение как раз в противоположном - ставить 5 Вт резистор подтяжки для подобных кнопок. А если кнопок много, то ...
К вашему сведению, я не придумал ничего нового - в данном случае также "традиционно" позаимствовал идею, обернув ее в свою обертку.
Прочитайте мою подпись внизу каждого поста ...

[k155la3]

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

Постоянный опрос не есть "явное зло". Если он происходит раз в 10-20-50-100 мс (можно и больше) то это скорее благо.
По предложенной Вами схеме на каждом дребезге контакта (если это обычный "сухой контакт" а не или матмодель или "через-триггер") на каждом нажатии-отжатии
в течение интервала дребезга будет дергаться вектор прерывания (если, конечно, не прописать соотв-ие EI DI разрешения прерывания).
Вопрос, так ли необходимо микросекундное "время отклика" системы при нажатии кнопки оператором ?
Экономить на опросе нет смысла, тк он (для матрицы) сводится к двум коротким операциям - записи в порт маски опроса (столбцов) и чтения из него (рядов).
чтения из него (рядов) и записи в порт маски опроса (столбцов).
Это делается в векторе имеющегося таймера RTC или "тиков" RTOS. Если этот таймер очень "быстрый" - делается условный вход по софт-делителю
с интервалом нескольких десятков мс. Дальнейшая обработка (по выставленному флагу интервала опроса клавиатуры и считанному скан-коду) выполняется вне вектора прерывания, с минимальным приоритетом.
---
ps
ООП имеет смысл применить для работы с очередью скан-кодов, полученных из драйвера клавиатуры.

[iliusmaster]

У музыкантов нужно точно отслеживать длительность нажатия, с разрешением не хуже 10 мс.

Сообщение отредактировал iliusmaster - Jun 24 2018, 09:34

[Forger]

а если клавиатура музыкального инструмента?

Решили повторить копеечный китайский детский синтезатор, которые раздают на сдачу в супермаркетах? Ведь именно такой вы и описали

В нормальных музыкальных электронных инструментах клавиатура - это не просто нажатие/отпускание, а еще как минимум контроль скорости нажатия.
А в проф. инструментах еще и полная имитация "физики" клавиш настоящего механического рояля/пианины.
Такие клавиатуры составляют основную стоимость самого инструмента.
В эту область не пускают "простых смертных", коими мы практически все тут и являемся

[Herz]

Импульсную подтяжку еще и на кнопку - знаете вы толк в извращениях...

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