Скажу сразу, многие начинающие осваивать МК (что греха таить, и сам таким был, а местами и до сих пор есть) не умеют правильно работать с кнопками и довольно часто в поделках (причем не только любительских) наблюдается специфическая реакция на нажатие кнопки (то кнопка сразу сработает, то с задержкой, а то, бывает, и вообще не сработает в зависимости от того, в какой момент нажата). Также новички часто забывают про дребезг. Вот я и решил собрать "коллекцию" приемов взаимодействия (и подключения кнопок), описать преимущества и недостатки того или иного метода... В общем здесь будем добиваться четких нажатий, быстрой реакции и взаимопонимания с МК.
Добавлено 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 писал(а):
Попробуйте писать в AtmelStudio и в CodeVision. Посмотрите результаты компиляции в обеих программах.
студии под рукой нет, КВАВР отрабатывает обе, результат одинаковый: CBI 0x12,1 , но, если написать типа PORTA&=~(1<<0|1<<1); (изменяем несколько бит) то тут обработка будет через регистр (чтение всего порта, правка регистра, запись в порт).
pyzhman писал(а):
Вот так вот, с места в карьер...что такое дребезг?
самый большой недостаток - применение программной задержки Delay_us(); - "благодаря" ей приостанавливается выполнение вычислений, ещё из недостатков - слежение за кнопкой происходит программно, и если контроллер занят чем-то другим (возможно отрабатывает чью-то задержку ) нажатие кнопки может быть пропущено... pyzhman спасибо за правки, а как считаете, вообще тема нужная или я это зря затеял?
_________________ Просто не учи физику в школе, и вся твоя жизнь будет наполнена чудесами и волшебством Безграмотно вопрошающим про силовую или высоковольтную электронику я не отвечаю, а то ещё посадят за участие в (само)убиении оболтуса...
Обязательным условием долгой и стабильной работы Li-FePO4-аккумуляторов, в том числе и производства EVE Energy, является применение специализированных BMS-микросхем. Литий-железофосфатные АКБ отличаются такими характеристиками, как высокая многократность циклов заряда-разряда, безопасность, возможность быстрой зарядки, устойчивость к буферному режиму работы и приемлемая стоимость. Но для этих АКБ очень важен контроль процесса заряда и разряда для избегания воздействия внешнего зарядного напряжения после достижения 100% заряда. Инженеры КОМПЭЛ подготовили список таких решений от разных производителей.
Как уже пришли к консенсусу в другом топике - тупо delay - зло абсолютное и должно быть игнорируемо. А антидребезг легко делается в таймерном прерывании: получили >=3 совпадений подряд (при 10мс-ном прерывании) - состояние зафиксировано, не совпадает с текущим - отрабатываем изменение состояния. Насчет go to мнения разделились
Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре.
Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.
Даже с учетом того, что подход с задержками неправильный, задержки в 100 микросекунд будет недостаточно. При дребезге кнопок нужны задержки порядка единиц миллисекунд. Попутно, кто-то может подсказать алгоритм обработки коротких/длинных нажатий кнопок. Можно кодом на АСМ/Си, можно псевдокодом, можно вообще словами описАть.
ну и на счет delay() они тоже моими стараниями не так однозначны. не вижу абсолютно ничего плохого в delay(), в том числе и при подавлении дребезга. как и в случае с goto просто есть разумные ограничения на эффективность применения, только и всего. никакого абсолютного зла, не наводите напраслину на задержку
да, кстати, о каком топике вы говорили? что-то пропустил я холиварчик ...
_________________ если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе при взгляде на многих сверху ничего не меняется...
кто-то может подсказать алгоритм обработки коротких/длинных нажатий кнопок.
И это планирую, есть обкатанный алгоритм: понадобятся 1) регулярный запуск подпрограммы опроса кнопок и переменная - накопитель. //отступление: считаем запаркованный счетчик == 0, сброшенный ==1. в подпрограмме проверили кнопку: нажата {счетчик не запаркован? //>0 {прирастили счетчик, сверили его с уставкой длинного нажатия: дошла {паркуем счетчик; действие длинного нажатия;};};} иначе (не нажата){ проверяем счетчик: ((больше минимума) и (незапаркован)) {действие короткого нажатия;}; /*запаркованный счетчик итак меньше минимума => это условие можно не проверять.*/ сброс счетчика;}; ----------
_________________ Просто не учи физику в школе, и вся твоя жизнь будет наполнена чудесами и волшебством Безграмотно вопрошающим про силовую или высоковольтную электронику я не отвечаю, а то ещё посадят за участие в (само)убиении оболтуса...
Последний раз редактировалось Ivanoff-iv Чт янв 11, 2018 06:09:53, всего редактировалось 2 раз(а).
_delay_ms() в обработке кнопок, если речь не идет о примитивном радиобрелке с одной функцией, это, наверно, самый четкий признак профнепригодности. В адекватном же коде опрос вызывается по переполнению таймера каждые ~200 ms из основного цикла. Если отслеживаем длинные нажатия, то первый раз поднимаем флажок, тогда второе срабатывание будет означать долгое нажатие, если же пин вернулся в начальное состояние, то нажатие было короткое. Это, собственно, одна из простейших реализаций т.н. State Machine.
Самый четкий признак профнепригодности- категоричный бред. Для начала смотрим на дребезг http://radio-hobby.org/modules/news/art ... toryid=797 Потом вспоминаем про возможные помехи. Затем вспоминаем про постепенное окисление дешевых тактовых кнопок. Пытаемся все эти вещи учесть в обработчике.
Если отслеживаем длинные нажатия, то первый раз поднимаем флажок, тогда второе срабатывание будет означать долгое нажатие, если же пин вернулся в начальное состояние, то нажатие было короткое. Это, собственно, одна из простейших реализаций т.н. State Machine.
Вот против этого я и хотел выступить - 1) ты сделал 2 коротких нажатия, а получил одно длинное, т.к. второе нажатие совпало с вторым опросом, 2) даже если надо одно короткое, но выверенное по времени, то это будет сложно сделать т.к. система будет ожидать 2го замера, чтобы убедиться, что нажатие было коротким, и вообще система будет казаться тормознутой (по той же причине).
Вот я лоханулся, там эта тема, наверно, действительно уместней... П.С.: я просматриваю 5 тем на форуме, на большее интернета не хватает (открывает > 40сек страницу...) вот и проглядел. Пошел туда почитаю, может там, всё что я хотел обсудить уже есть...
Добавлено after 1 hour 30 minutes 25 seconds: Для pyzhmana: Спойлер
Щелчёк - это ~ 0.2...0.3 сек. А ждать 0.5 сек нажатой кнопку, для одного клика - мазохизм. Встречался я с пром-приборами, ПО для которых писались такими горе-программистами. Одно только лазанье по меню вызывает раздражение, переходящее в нервоз. Не говоря уж о том, когда увеличиваешь/уменьшаешь цифровые значения параметров
_________________ Просто не учи физику в школе, и вся твоя жизнь будет наполнена чудесами и волшебством Безграмотно вопрошающим про силовую или высоковольтную электронику я не отвечаю, а то ещё посадят за участие в (само)убиении оболтуса...
В общем, сколько людей - столько и мнений. В спорах не рождается истина, в спорах ее могут только придушить Старая добрая RC решает проблему, а если нужны фронты, есть место и не жмет потребление - триггер Шмиткина нам в помочь. И тогда об delay спор утихнет, и проблема автоповтор=длинное нажатие решится безболезненно, бо по прерыванию по фронту-срезу. Мы с Мурзиком такого мнения.
ну вы даёте! это же mauvais ton! а если кнопок 10 - это ж сколько обвеса дополнительного?! решение всех проблем программно (ну или аппартно встроенными в МК средствами) - вот наш выбор!
и кроме нас с Бусей и Кексом, так считают многие другие
_________________ если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе при взгляде на многих сверху ничего не меняется...
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 27
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения
Вход
Регистрация
Правила
FAQ
Поиск
в зависимости от того, в какой момент нажата). Также новички часто забывают про дребезг.
это же mauvais ton! а если кнопок 10 - это ж сколько обвеса дополнительного?! решение всех проблем программно (ну или аппартно встроенными в МК средствами) - вот наш выбор!
