Скажу сразу, многие начинающие осваивать МК (что греха таить, и сам таким был, а местами и до сих пор есть) не умеют правильно работать с кнопками и довольно часто в поделках (причем не только любительских) наблюдается специфическая реакция на нажатие кнопки (то кнопка сразу сработает, то с задержкой, а то, бывает, и вообще не сработает в зависимости от того, в какой момент нажата). Также новички часто забывают про дребезг. Вот я и решил собрать "коллекцию" приемов взаимодействия (и подключения кнопок), описать преимущества и недостатки того или иного метода... В общем здесь будем добиваться четких нажатий, быстрой реакции и взаимопонимания с МК.
Добавлено 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 - это ж сколько обвеса дополнительного?! решение всех проблем программно (ну или аппартно встроенными в МК средствами) - вот наш выбор!
и кроме нас с Бусей и Кексом, так считают многие другие
_________________ если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе при взгляде на многих сверху ничего не меняется...
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 41
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения