Она и подтверждается. В чем я давно убедился и мне никакие подтверждения уже не нужны.

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


У герконов дребезг есть, но ситуация на порядки лучше чем у обычных кнопок. Если кнопкам нужен защитный интервал в 10-20мс, то для герконов достаточно 1мс.

То есть предъявленных фактов не будет? Вопрос риторический… оно впрочем было сразу понятно.



«Когда кажется, тогда крестятся». (С)

Предполагать ты можешь что угодно – это не возбраняется!

Апломба то сколько!

PCBWay - всего $5 за 10 печатных плат, первый заказ для новых клиентов БЕСПЛАТЕН

Сборка печатных плат от $30 + БЕСПЛАТНАЯ доставка по всему миру + трафарет

Онлайн просмотровщик Gerber-файлов от PCBWay + Услуги 3D печати

Практика - мерило истины. Это я к тому, что спорить бесполезно. Если кто-то желает наступать в будущем на грабли, это его дело. И не надо ему в этом мешать. Самое страшное наказание - оставить наказуемого в покое. Он сам въедет в пень.
Так что заканчивайте бесполезный спор.

Выбираем схему BMS для заряда литий-железофосфатных (LiFePO4) аккумуляторов

Обязательным условием долгой и стабильной работы Li-FePO4-аккумуляторов, в том числе и производства EVE Energy, является применение специализированных BMS-микросхем. Литий-железофосфатные АКБ отличаются такими характеристиками, как высокая многократность циклов заряда-разряда, безопасность, возможность быстрой зарядки, устойчивость к буферному режиму работы и приемлемая стоимость. Но для этих АКБ очень важен контроль процесса заряда и разряда для избегания воздействия внешнего зарядного напряжения после достижения 100% заряда. Инженеры КОМПЭЛ подготовили список таких решений от разных производителей.

Подробнее>>

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

Конечно, учитывая, что ветка форума посвящена ассемблеру, а я на C код писал, видео не совсем в тему будет. Плюс видеоролик не только про антидребезг (это где-то с середины), но и вообще о том, как попытаться избавиться от использования задержек в коде.

Но саму идею можно перенести и на другой язык без проблем. Так что ссылочку я тут всё-таки оставлю https://www.youtube.com/watch?v=c7rE9JCF6Wg

Новый аккумулятор EVE серии PLM для GSM-трекеров, работающих в жёстких условиях (до -40°С)

Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре. Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.

Подробнее>>

время в ролике 28:00 но на самом деле ролик просто ужасен, смысл происходящего просто ускользает куда-то. Его можно понять разве что изначально уже в теме.
Показывать код... в онлайн-трансляции... нет, увольте. Код лучше изучать в виде текста, а если пояснять какие-то алгоритмы в онлайне - то лучше использовать графики, блок-схемы и т.д. А код приложить рядом, чтобы можно было его изучать.
Не выдержал до конца ролика, так и не понял какую идею пытались донести.

Да, соглашусь, что ясно идею в ролике я не высказал.

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

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

События могут наступать не только от кнопок. В проекте анализатора спектра у меня, например, события генерируются не только механикой - кнопками и энкодером. Есть также код, обрабатывающий сигнал с пульта ДУ, и код, обрабатывающий "текстовые" команды, приходящие по UART. Все эти источники событий работают независимо и не блокируя основной цикл программы, в котором в это время идёт, например FFT-анализ, вывод спектра на экран, и т.д.

Как я понял из дизассемблера студии реакция идет на отпускание кнопки(ок). По мне, таким функционалом может обладать только одна кнопка - "RESET". Реакции на кратковременное нажатие кнопки нет.

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

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

Извините, но вы написали чушь.

опередили...

Почему же? Как можно по первому моменту, когда на кнопке лог. 1 сменяется нулём, понять, что это короткое нажатие кнопки, а не помеха/дребезг/или пользователь планирует удерживать кнопку более, например, секунды?

"Короткое " - я понимаю, микросекунды... Пальцем..

Обычное короткое нажатие кнопки пальцем - это несколько десятков миллисекунд, реально больше сотни.

Ну ёмаё, так и фиксируем нажатие по истечении сего времени

Если нужны только короткие нажатия - так и делаем. Если нужны ещё и длинные или сочетания кнопок - тогда уже отпускание кнопки играет роль.
Просто тут считают, что, умея каким-то волшебным образом только по факту нажатия кнопки понимать, что это не помеха, а именно короткое нажатие.

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

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

WiseLord Спокойнее. Никакого волшебства и шаманства нет. Киньте взгляд на клаву - она обрабатывает всякие нажатия и короткие и длинные и комбинации.

Это да, но компьютерная клавиатура при длинном нажатии кнопки генерирует и короткое, и длинное нажатия.

Если у меня на короткое нажатие повешен, например, Channel_Up, а на длинное - Volume_+, я не хочу, чтобы каналы переключались при попытке регулировки громкости.

Судя по надписям на вашей картинке - решаемо.