Кнопки и кнопочный интерфейс

[Ivanoff-iv]

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

Добавлено after 26 minutes 57 seconds:
для начала подключение кнопки и настройка порта:
устройство небольшое, кнопка рядом, помехи невелики, кнопка подсоединяется с Y выход порта X на "минусовую" шину:

Код:

DDRX&=~(1<<Y); //DDRX.Y=0; устанавливаем ногу на вход.
PORTX|=(1<<Y);  //PORTX.Y=1; включаем подтягивающий резистор (внутри МК).
...
//теперь PINX&(1<<Y)   //PINX.Y отражает состояние входа (и кнопки) 0-нажата, не 0 - не нажата
//(тут важно - "не 0" это не обязательно 1, конструкция PINX&(1<<Y) при отпущенной кнопке принимает значение 2^Y)


кстати тут и у меня вопрос: в чем принципиальные отличия при обращении к биту в регистре порта DDRX&=~(1<<Y); или DDRX.Y=0;?

самый простой пример антидребезга:

Код:

if ((PINX&(1<<Y))==0)
{
delay_us(100); //задержка перед повторной проверкой кнопки
if ((PINX&(1<<Y))==0) {действия при нажатой кнопке};
};

вся эта конструкция должна постоянно повторяться (выполняется в цикле или запускается в прерывании по таймеру).

Добавлено after 9 minutes 12 seconds:
если требуется величить стабильность (ослабить помехи) можно добавить внешний резистор от "ноги" к плюсу питания МК (R около 10кОм).

[pyzhman]

Ivanoff-iv писал(а):

...в чем принципиальные отличия при обращении к биту в регистре порта DDRX&=~(1<<Y); или DDRX.Y=0;?...

Попробуйте писать в AtmelStudio и в CodeVision. Посмотрите результаты компиляции в обеих программах.

самый простой пример антидребезга:

Вот так вот, с места в карьер. Неплохо бы для начала обозначить суть проблемы - что такое дребезг. Далее - методы его подавления.

я ... решил ...описать преимущества и недостатки того или иного метода...

Где оные для "самого простого примера"?

довольно часто в поделках (причем не только любительских)

Примеры в студию. Особенно того, что в скобках.

[Ivanoff-iv]

pyzhman писал(а):

Примеры в студию. Особенно того, что в скобках.

вот как привести? сфоткать устройство и подписать - у него кнопки отрабатывают хреново? счетчики вроде такие попадались, попадутся опять - сфоткаю. ПС. китайские поделки к какой группе относить?

Попробуйте писать в AtmelStudio и в CodeVision. Посмотрите результаты компиляции в обеих программах.

студии под рукой нет, КВАВР отрабатывает обе, результат одинаковый: CBI 0x12,1 , но, если написать типа PORTA&=~(1<<0|1<<1); (изменяем несколько бит) то тут обработка будет через регистр (чтение всего порта, правка регистра, запись в порт).

Вот так вот, с места в карьер...что такое дребезг?

дельное замечание...надо хоть ссылочкой подкрепить

Где оные для "самого простого примера"?

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

[ARV]

как считаете, вообще тема нужная или я это зря затеял?

зря

[Jack_A]

Как уже пришли к консенсусу в другом топике - тупо delay - зло абсолютное и должно быть игнорируемо. А антидребезг легко делается в таймерном прерывании: получили >=3 совпадений подряд (при 10мс-ном прерывании) - состояние зафиксировано, не совпадает с текущим - отрабатываем изменение состояния.
Насчет go to мнения разделились

[Пока_без_кота]

Даже с учетом того, что подход с задержками неправильный, задержки в 100 микросекунд будет недостаточно. При дребезге кнопок нужны задержки порядка единиц миллисекунд.
Попутно, кто-то может подсказать алгоритм обработки коротких/длинных нажатий кнопок. Можно кодом на АСМ/Си, можно псевдокодом, можно вообще словами описАть.

[ARV]

Насчет go to мнения разделились

ну и на счет delay() они тоже моими стараниями не так однозначны.
не вижу абсолютно ничего плохого в delay(), в том числе и при подавлении дребезга. как и в случае с goto просто есть разумные ограничения на эффективность применения, только и всего. никакого абсолютного зла, не наводите напраслину на задержку

да, кстати, о каком топике вы говорили? что-то пропустил я холиварчик ...

[pyzhman]

Ivanoff-iv писал(а):

...тема нужная или я это зря затеял?

У вас нет системного подхода, сумбур. Составьте план, обязательно отрецензируйте и только потом, если не пропадёт запал, выкладывайте в сеть.

...подход с задержками неправильный...

Я бы не был так категоричен. В ногодрыгалках (бегущие огонёчки, гирлянды, таймерочки, моторчики) вполне себе работает делэй_мс(10) в майне.

[Ivanoff-iv]

Пока_без_кота писал(а):

кто-то может подсказать алгоритм обработки коротких/длинных нажатий кнопок.

И это планирую, есть обкатанный алгоритм: понадобятся 1) регулярный запуск подпрограммы опроса кнопок и переменная - накопитель.
//отступление: считаем запаркованный счетчик == 0, сброшенный ==1.
в подпрограмме проверили кнопку: нажата
{счетчик не запаркован? //>0
{прирастили счетчик, сверили его с уставкой длинного нажатия: дошла
{паркуем счетчик; действие длинного нажатия;};};}
иначе (не нажата){
проверяем счетчик: ((больше минимума) и (незапаркован)) {действие короткого нажатия;};
/*запаркованный счетчик итак меньше минимума => это условие можно не проверять.*/
сброс счетчика;};
----------

Последний раз редактировалось Ivanoff-iv Чт янв 11, 2018 06:09:53, всего редактировалось 2 раз(а).

[Jack_A]

да, кстати, о каком топике вы говорили? что-то пропустил я холиварчик ...

Дык это наша с вами дискуссия и была, viewtopic.php?f=57&t=150874&p=3261138#p3261138
А мне показалось, что консексус

[philosoraptor]

_delay_ms() в обработке кнопок, если речь не идет о примитивном радиобрелке с одной функцией, это, наверно, самый четкий признак профнепригодности. В адекватном же коде опрос вызывается по переполнению таймера каждые ~200 ms из основного цикла. Если отслеживаем длинные нажатия, то первый раз поднимаем флажок, тогда второе срабатывание будет означать долгое нажатие, если же пин вернулся в начальное состояние, то нажатие было короткое.
Это, собственно, одна из простейших реализаций т.н. State Machine.

[Flasher]

Самый четкий признак профнепригодности- категоричный бред.
Для начала смотрим на дребезг
http://radio-hobby.org/modules/news/art ... toryid=797
Потом вспоминаем про возможные помехи.
Затем вспоминаем про постепенное окисление дешевых тактовых кнопок.
Пытаемся все эти вещи учесть в обработчике.

[Аlex]

вообще тема нужная или я это зря затеял?

Вообще, такая тема уже существует. Причём она прикрепленная. viewtopic.php?f=61&t=79801

[Ivanoff-iv]

philosoraptor писал(а):

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

Вот против этого я и хотел выступить - 1) ты сделал 2 коротких нажатия, а получил одно длинное, т.к. второе нажатие совпало с вторым опросом, 2) даже если надо одно короткое, но выверенное по времени, то это будет сложно сделать т.к. система будет ожидать 2го замера, чтобы убедиться, что нажатие было коротким, и вообще система будет казаться тормознутой (по той же причине).

Добавлено after 24 minutes 39 seconds:

Аlex писал(а):

Вообще, такая тема уже существует.

Вот я лоханулся, там эта тема, наверно, действительно уместней...
П.С.: я просматриваю 5 тем на форуме, на большее интернета не хватает (открывает > 40сек страницу...) вот и проглядел. Пошел туда почитаю, может там, всё что я хотел обсудить уже есть...

Добавлено after 1 hour 30 minutes 25 seconds:
Для pyzhmana:

Спойлер

pyzhman писал(а):

довольно часто в поделках (причем не только любительских)

Примеры в студию. Особенно того, что в скобках.

Вот: не я один это вижу

Аlex писал(а):

Щелчёк - это ~ 0.2...0.3 сек.
А ждать 0.5 сек нажатой кнопку, для одного клика - мазохизм.
Встречался я с пром-приборами, ПО для которых писались такими горе-программистами. Одно только лазанье по меню вызывает раздражение, переходящее в нервоз. Не говоря уж о том, когда увеличиваешь/уменьшаешь цифровые значения параметров

[pyzhman]

Ivanoff-iv писал(а):

...
Для pyzhmana...

Не оправдывайтесь, ни к чему. Все пацаны и так в курсе.

[ARV]

Дык это наша с вами дискуссия и была,

ну так консенсус же был достигнут на фразе

Даже в этом ответе - сомневаюсь

, а тут снова категоричность в заявлении

тупо delay - зло абсолютное и должно быть игнорируемо

Самый четкий признак профнепригодности- категоричный бред.

люто плюсую!

В адекватном же коде опрос вызывается по переполнению таймера каждые ~200 ms из основного цикла.

[pyzhman]

philosoraptor писал(а):

...каждые ~200 ms...

[Jack_A]

В общем, сколько людей - столько и мнений. В спорах не рождается истина, в спорах ее могут только придушить
Старая добрая RC решает проблему, а если нужны фронты, есть место и не жмет потребление - триггер Шмиткина нам в помочь. И тогда об delay спор утихнет, и проблема автоповтор=длинное нажатие решится безболезненно, бо по прерыванию по фронту-срезу. Мы с Мурзиком такого мнения.

Вложения

RC.JPG

(2.53 KiB) Скачиваний: 1227

[ARV]

Старая добрая RC решает проблему

ну вы даёте! это же mauvais ton! а если кнопок 10 - это ж сколько обвеса дополнительного?! решение всех проблем программно (ну или аппартно встроенными в МК средствами) - вот наш выбор!

и кроме нас с Бусей и Кексом, так считают многие другие

[ozonn]

не вижу ничего плохого в применении _delay где бы то ни было и уж тем более для подавления дребезга