Оцените алгоритм опроса матричной клавы

[H4LF]

supercelt, и я из этого:

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

ничего не понял, если честно... какое прерывание, как обнаружили нажатие... ни первый ни второй вариант явно не то, что я имею ввиду.
Я имел ввиду: заводится софт таймер (типа такого) и в главном цикле проверяем, прошло заданное время (20мс например) или нет. Когда прошло - опрашиваем кнопки, передаём их состояние в конечный автомат, который осуществляет дальнейшую обработку, и снова заводим этот таймер (timer_restart в той реализации от Mihail, что по ссылке). Прерывания не нужны для этого, совсем не нужны (ну если только нужно выходить из сна или реагировать немедленно, но это обычно можно и отдельно настроить через прерывания). Не понимаю - почему тут многие хотят делать обычную клавиатуру именно на прерываниях (таймера, EXTI или всё вместе)...

[DanilinSA]

Все верно. Нужно по максимуму выносить все из основного цикла. В идеале он должен быть совсем пустой. А вся работа выполняться в прерываниях.
Но это естественно в идеале ...

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

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

Период основного цикла в общем случае не постоянен. И зависит от того, какая обработка идет в осн. цикле. Если там много чего - период осн. цикла может очень сильно изменяться.

[supercelt]

supercelt
Я имел ввиду: заводится софт таймер (типа такого) и в главном цикле проверяем, прошло заданное время (20мс например) или нет. Когда прошло - опрашиваем кнопки, передаём их состояние в конечный автомат, который осуществляет дальнейшую обработку, и снова заводим этот таймер (timer_restart в той реализации от Mihail, что по ссылке).

20мс это между прогоном клавы всей? А как же задержка между установкой и чтением?

[supercelt]

Все верно. Нужно по максимуму выносить все из основного цикла. В идеале он должен быть совсем пустой. А вся работа выполняться в прерываниях.
Но это естественно в идеале ...

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

[H4LF]

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

вот поэтому и важно, как написано всё остальное. Например в кооперативной RTOS или "цикл + прерывания" не должно быть в принципе такого, чтобы процессор был занят неопределённо долго какой-то одной задачей. Если он занят расчётом числа пи до миллионного знака после запятой (или просто кручением _delay_ms(10000))То нет никакого смысла считывать состояние кнопок в прерываниях - всё равно процессор ничего не будет делать пока не закончит с данной задачей. Ну если только прямо в прерываниях что-то делать, но во первых - всё там делать вряд-ли получится, а во вторых - чем больше взаимодействия прерываний с основной программой и с другими прерываниями, тем больше вероятность напороться на трудноуловимый гейзенбаг - ибо не так всё просто при таком взаимодействии, как может показаться сначала. С вытесняющей RTOS тоже не всё просто, а может даже и сложнее.

[supercelt]

H4LF, и ваше мнение? таймер - прерывание - флаг - разбор в майне?

[H4LF]

Нужно по максимуму выносить все из основного цикла. В идеале он должен быть совсем пустой. А вся работа выполняться в прерываниях.

Ага, а ещё в большем идеале сделать всё на ПЛИС...

Период основного цикла в общем случае не постоянен. И зависит от того, какая обработка идет в осн. цикле. Если там много чего - период осн. цикла может очень сильно изменяться.

ну и хрен с ним, с этим периодом, пусть изменяется, главное чтобы он не был слишком большим, а по его периоду время отмерять не стоит(но можно измерять сам период, хоть для диагностики). Для того, чтобы отмерять относительно большие (например больше 1 мс) и не сильно критичные к точности интервалы времени - есть софт таймеры. Та же задача сканирования клавиатуры не будет выполняться в главном цикле постоянно, а только когда дотикает её таймер. А проверка таймера(дотикал или ещё нет) выполняется за считанные такты. По мне так наоборот - время прерываний крайне ценный ресурс, особенно если нет приоритетов.
Но согласен, что тупо пихать всё в главный цикл (например сканирование клавы в каждом проходе цикла, да ещё не дай бог с _delay) - плохая идея.

[H4LF]

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

20мс это между прогоном клавы всей? А как же задержка между установкой и чтением?

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

[6ap6oc]

Я правильно понял, что тогда, при универсальном варианте будет правильней постоянно запустить таймер и каждые, к примеру 5мс по прерыванию устанавливать ряды и сканить строки?

Алгоритм такой:
запускаем таймер каждые 20 мс (ну примерно)
Сработало 1 прерывание. Читаем состояние колонок, Устанавливаем 1 ряд, уходим - ТУТ НИЧЕГО НЕ СЧИТАЛОСЬ НО ЭТО НЕ БЕДА
Сработало 2 прерывание. Читаем состояние колонок, если есть что-то записываем, ставит ряд 2, уходим
Сработало 3 прерывание. Читаем состояние колонок, если есть что-то записываем, ставит ряд 3 , уходим

Тема себя изжила, я пасс.

[МВА]

Все верно. Нужно по максимуму выносить все из основного цикла. В идеале он должен быть совсем пустой. А вся работа выполняться в прерываниях.
Но это естественно в идеале ...

Вот с этим я не могу согласиться. Как-то на медне miwutka ваял тахометр, так он по началу все напихал в прерывания и чуть-чуть в основной цикл. А потом писал, что создается впечатление, что основной цикл совсем не работает. А как он будет работать, если пока программа выйдет из прерывания - то уже опять ждет флаг? Я прогонял кусок его программы пошагово в студии - так и есть, программа из прерывания возвращается опять в прерывание, и это было только одно прерывание по захвату в котором miwutka хотел все успеть. Наверное не зря во всех рекомендациях советуют прерывания делать как можно короче.

PS.

Основной цикл - крайне ценный ресурс. Он один на всех.

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