Чтобы зря не опрашивать её в цикле, если она нажимается редко. Плюс не будет гемора с многократным опросом кнопки за время её нажатия, поскольку прерывания происходят только по фронтам.
Не вопрос. Исходя из этой позиции, вы сидите ждете какой-то флаг. Работа МК судя по вашему производится зря, вхолостую. Временные задержки на основе счета тактов. Времянки какие угодно. От микросекунд, до секунд. И представляете, МК работает ЗРЯ! Парадокс, не правда ли?! Я к чему, забудьте об этом суждении. Какую бы вы программу не написали, работа МК - выполнять написанную вами программу. Не хотите ждать зря кнопку? Создайте условие, по которому если кнопки не нажата, идем выполнять другую работу. Так вы освоите псевдопараллельность работы модулей программы.
Вот тестовый вариант для проверки кнопок на длительный дребезг (выбраковка кнопок)… на базе тини13, тактируется от заводской установки (1,2 МГц) – фьюзы устанавливать не надо… две кнопки и два светодиода… алгоритм проверяемой кнопки выполнен как описывал выше (от внешнего прерывания)… в теле прерывания организовано так: какой первый лог уровень замечен такой светодиод и загорится… зелёный – лог. 0; красный – лог. 1… сброс свечения светодиодов осуществляется кнопкой сброс. Схема:
На чём основаны такие умозаключения? Аргументы будут?
Математика, закон Ома... кнопка - сопротивление контакта 0.1Ом, на конденсаторе в момент нажатия 5Вольт... калькулятор сами достанете? А для кнопки заявлен максимальный ток в 50мА. И усреднение тут не катит, ток разряда конденсатора будет таки потихоньку плавить конаткт и оставлять нагар. В итоге кнопка превращается в черт знает что.
Цитата:
Тут тоже желательно аргументированных утверждений, а не бла бла.
Все люди у нас очень терпеливые и обладают железной выдержкой. Попробуйте к примеру поработать с планетом у которого нажатие регистрируется 9 раз из 10. Через 15 минут начинаешь присматриваться к стенке, как бы его так кинуть чтобы обои не поцарапать.
уже присматриваешься? К кнопке ещё резистор, чтоб ток гасить..., не слишком ли много обвеса получается? проще регулярно опрашивать, и на основе 2х или 3х подряд одинаковых замеров принимать решение...
_________________ Просто не учи физику в школе, и вся твоя жизнь будет наполнена чудесами и волшебством Безграмотно вопрошающим про силовую или высоковольтную электронику я не отвечаю, а то ещё посадят за участие в (само)убиении оболтуса...
Качественное и безопасное устройство, работающее от аккумулятора, должно учитывать его физические и химические свойства, профили заряда и разряда, их изменение во времени и под влиянием различных условий, таких как температура и ток нагрузки. Мы расскажем о литий-ионных аккумуляторных батареях EVE и нескольких решениях от различных китайских компаний, рекомендуемых для разработок приложений с использованием этих АКБ. Представленные в статье китайские аналоги помогут заменить продукцию западных брендов с оптимизацией цены без потери качества.
Причем тут резистор? У кнопки по любому должен быть резистор подтяжки. Проблема в конденсаторе, который в момент нажатия находится после резистора. И опрос не нужно делать подряд. Его нужно делать ПОСТОЯННО с интервалом чуть больше дребезга.. Но если дребезг слишком велик, можно опрашивать чаще, но фильтровать полученный битный массив. Впрочем, это не ускорит срабатывание изношенной кнопки.
Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре.
Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.
Имхо, все эти игры с попыткой обработать нажатие кнопки через прерывание - это бирюльки. Потому что дребезг нормально таким способом не подавишь. И вешать конденсаторы - это не выход из ситуации.
Гораздо лучше делать периодический опрос состояния кнопок. Но не в главном цикле программы, как любят некоторые, судя по тем примерам кода, что я иногда встречаю. В этом случае, пока нажата кнопка, вся остальная программа, по сути, висит в ожидании.
Корректнее всего использовать аппаратный таймер. Как правило, либо есть свободный таймер, либо описываемый подход вполне сочетается с параллельным использованием какого-то уже задействованного таймера.
Допустим, таймер настроен на 1кГц. Каждую 1мс срабатывает прерывание, в нём мы просто смотрим на состояние кнопок. Если ничего не нажато - в этой итерации ничего не делаем. Если же по прерыванию мы видим, что одна из нескольких кнопкок нажата - записываем состояние кнопок в некотрой переменной (назовём её btnStatus), а также инкрементируем некоторый счётчик (btnCnt). При следующем прерывании - всё то же самое.
В какой-то момент кнопка будет отпущена. В прерывании мы увидим, что btnStatus изменился. Это повод для того, чтобы 1) обнулить счётчик; 2а) если счётчик насчитал достаточно (скажем, до 100 = 100мс) - мы предыдущий btnStatus сохраняем в новой глобальной переменной (скажем, btnStatusGlobal); 2б) если счётчик не насчитал достаточно - ничего не делаем (считаем это дребезгом контактов).
Ну а основной цикл просто смотрит btnStatusGlobal, и, если в ней что-то есть, выполняет соответствующий обработчик нажатия.
Из опыта - работает такой подход абсолютно надёжно.
Слишком сложно... переменные, счетчики... достаточно считать прерывания и смотреть на младшие 4 бита если они равны нулю - опрашиваем, сохраняем состояние кнопок и сравниваем с предыдущим - если есть несовпадения обновляем маску нажатия/отпускания кнопки, а обнулить маску может только основной цикл. Как правило счетчик прерываний уже есть, поэтому никакой дополнительной шелухи не надо.
Ничего сложного. Минут за 30 набросал код (правда на C), который по вышеописанному принципу делает вроде как простую задачку, но с подвохами.
Вкратце - есть две кнопки, есть два светодиода. Кратковременное нажатие каждой кнопки зажигает свой светодиод на определённое время. Кнопки работают абсолютно независимо одна от другой.
Задействован лишь один - самый простой в atmega8 - таймер. Как для опроса кнопок, так и для таймаутов свечения. Ни одной функции задержки в коде нет, основной цикл программы не блокируется нигде, поэтому никакие полезные вычисления, которые могли бы где-то выполняться, выполнялись бы себе.
Добавить аналогично ещё кнопок / светодиодов - никакой проблемы.
Размер программы меньше 400 байт (на ассемблере, вероятно, и меньше был бы), исходник, hex и проект в Proteus там же.
Математика, закон Ома... кнопка - сопротивление контакта 0.1Ом, на конденсаторе в момент нажатия 5Вольт... калькулятор сами достанете?
То есть твоя схема с конденсатором убивает кнопку!? А я тут причём… не нужно свои домыслы перекладывать на других… вот схема ничего не убивает и работает как часы устраняя дребезг… верхний по схеме резистор можно задействовать в самом МК… нижний рассчитывается в зависимости от ёмкости…
Попробуйте к примеру поработать с планетом у которого нажатие регистрируется 9 раз из 10. Через 15 минут начинаешь присматриваться к стенке, как бы его так кинуть чтобы обои не поцарапать.
И тут придумал что-то своё и пытаешься это навесить на меня… ладно всё понятно.
получается: либо антидребезг занимает место в коде по методу, например, WiseLordа, либо на плате, по схеме АСУ, а тут уж самому решать - какое место нужнее...
_________________ Просто не учи физику в школе, и вся твоя жизнь будет наполнена чудесами и волшебством Безграмотно вопрошающим про силовую или высоковольтную электронику я не отвечаю, а то ещё посадят за участие в (само)убиении оболтуса...
Keys_Init: ser r16 mov KEYS_PREV, r16 mov KEYS_CURRENT, r16 std Y+DISP_KEYS_BUF, r16 Set_State _KEYS_NONE ret
Keys_None: sbrs FSM_FLAGS, KEYS_PRESSED_FLG // Если что-то нажато, то пропуск команды. ret Read_Keys_Current Save_Keys_Prev // Сохранение текущего состояния клавиатуры. Set_Timer Par_Tim_Debounce_Delay // Установка задержки устранения дребезга. Set_State _KEYS_DOWN ret
Я борюсь с дребезгов в 90% случаях программными методами, но бывает когда по разным причинам приходится прибегать к старому методу RC цепочки которой пользовался в былые времена для рассыпухи.
Возник очередной вопрос. Подключил кнопку на PB7, разрешил прерывания PCIE и PCINT7. Т.е. любое изменение логического состояния на этой ноге будет вызывать прерывание... Как сделать так, чтобы кнопка срабатывала только один раз?
Как вариант использования PCINT для опроса кнопки с антидребезгом. Идея в накоплении состояния нажатой кнопки счетчиком за 128 тактов опроса. Если есть дребезг счетчик сбрасывается и счет начинается снова. Индикатором служит реверсирование состояния лапы PD0 при нажатии кнопки. Посмотрел на макете, правда кнопка у меня заведена на PB4 с резистором подтяжки 1,1к. Каждый раз при нажатии кнопки происходит смена состояния лапы PD0. При отпускании кнопки смены состояния нет.
Все определяется схемотехникой конкретного устройства и системой команд/особенностями ядра конкретного семейства МК. В том числе и для кнопок. Так что решений может быть весьма много (в том числе и аппаратного предподавления дребезга механических контактов).
вот схема ничего не убивает и работает как часы устраняя дребезг… верхний по схеме резистор можно задействовать в самом МК… нижний рассчитывается в зависимости от ёмкости…
Боюсь разочаровать, но схема ваша не устраняет дребезг полностью, а лишь уменьшет его вероятность. Периодически, кнопку будет таки глючить несмотря на все предпринятые решения. Чем больше величина нижнего резистора, тем хуже схема давит дребезг. А он не может быть маленьким - ибо ток через кнопку надо ограничить.
Зачем такие пляски с дополнительными деталями на каждую кнопку, если отлично справляется простой до гениальности программный способ подавления дребезга. Представьте, куда эти резисторы и конденсаторы ставить в матричную клавиатуру?
Периодически, кнопку будет таки глючить несмотря на все предпринятые решения.
Теоретические предположения – это хорошо. Только вот теория должна подтверждаться практическими фактами на железе. Если таковые факты есть (+ осциллограммы и т.п.) – с удовольствием взгляну. Если таковых нет, буду тогда тебя считать лишь теоретиком не более того.
Alexeyslav писал(а):
Представьте, куда эти резисторы и конденсаторы ставить в матричную клавиатуру?
Опять ты «о своём, о девичьем» (С) А если клавиатура на герконах!? Как в былые времена…
Alexeyslav писал(а):
Зачем такие пляски с дополнительными деталями на каждую кнопку, если отлично справляется простой до гениальности программный способ подавления дребезга.
Бывают (у меня довольно часто) ситуации, когда свободной памяти для написания кода для подавления дребезга просто нет… часто это относится к девайсам на тини13… брать из-за этого более ёмкий МК или поставить дополнительные RC цепочки – я в большинстве случаях выбираю второе, так как это дешевле на порядок, да и кнопка может быть удалена от девайса на значительном расстоянии (несколько метров). Ты же в свою очередь поступай как считаешь нужным – я свой опыт тебе не навязываю.
Заголовок сообщения: Re: Ассемблер (ASM) для AVR в вопросах и ответах
Добавлено: Вс янв 21, 2018 11:22:29
Встал на лапы
Карма: 3
Рейтинг сообщений: 7
Зарегистрирован: Чт сен 10, 2015 06:59:03 Сообщений: 106 Откуда: Гродно, BY
Рейтинг сообщения:0
Думаем о подавлении дребезга и тех несчастных, которые во вновь разрабатываемых устройствах использует больше половины памяти. Как в дальнейшем можно модифицировать данное устройство, если не делать халтуру?
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 22
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения
Вход
Регистрация
Правила
FAQ
Поиск
ладно всё понятно.
