Ассемблер (ASM) для AVR в вопросах и ответах

[dgrett]

Удалил

[BOB51]

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

[Alexeyslav]

вот схема ничего не убивает и работает как часы устраняя дребезг… верхний по схеме резистор можно задействовать в самом МК… нижний рассчитывается в зависимости от ёмкости…

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

Зачем такие пляски с дополнительными деталями на каждую кнопку, если отлично справляется простой до гениальности программный способ подавления дребезга. Представьте, куда эти резисторы и конденсаторы ставить в матричную клавиатуру?

[АСУ]

[uquote="Alexeyslav",url="/forum/viewtopic.php?p=3288551#p3288551"]Периодически, кнопку будет таки глючить несмотря на все предпринятые решения.[/uquote]
Теоретические предположения – это хорошо. Только вот теория должна подтверждаться практическими фактами на железе. Если таковые факты есть (+ осциллограммы и т.п.) – с удовольствием взгляну. Если таковых нет, буду тогда тебя считать лишь теоретиком не более того.

Представьте, куда эти резисторы и конденсаторы ставить в матричную клавиатуру?

Опять ты «о своём, о девичьем» (С)
А если клавиатура на герконах!? Как в былые времена…

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

Бывают (у меня довольно часто) ситуации, когда свободной памяти для написания кода для подавления дребезга просто нет… часто это относится к девайсам на тини13… брать из-за этого более ёмкий МК или поставить дополнительные RC цепочки – я в большинстве случаях выбираю второе, так как это дешевле на порядок, да и кнопка может быть удалена от девайса на значительном расстоянии (несколько метров). Ты же в свою очередь поступай как считаешь нужным – я свой опыт тебе не навязываю.

[trofim2]

А что, у герконов нет дребезга?

[АСУ]

О чём думаем когда читаем пост!?

[trofim2]

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

[Alexeyslav]

Только вот теория должна подтверждаться практическими фактами на железе.

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

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

у герконов нет дребезга?

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

[АСУ]

[uquote="Alexeyslav",url="/forum/viewtopic.php?p=3288779#p3288779"]

Только вот теория должна подтверждаться практическими фактами на железе.

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

Кажется мне, если у вас не хватает памяти даже под отрабтку дребезга, костылей в ваших проектах сверх меры.

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

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

[trofim2]

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

[Demiurg]

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

[WiseLord]

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

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

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

[Alexeyslav]

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

[WiseLord]

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

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

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

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

[akl]

[uquote="WiseLord",url="/forum/viewtopic.php?p=3287793#p3287793"]... Минут за 30 набросал код (правда на C), который по вышеописанному принципу делает вроде как простую задачку, но с подвохами.

Вкратце - есть две кнопки, есть два светодиода. Кратковременное нажатие каждой кнопки зажигает свой светодиод на определённое время. Кнопки работают абсолютно независимо одна от другой.[/uquote]Как я понял из дизассемблера студии реакция идет на отпускание кнопки(ок). По мне, таким функционалом может обладать только одна кнопка - "RESET". Реакции на кратковременное нажатие кнопки нет.

[WiseLord]

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

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

[akl]

[uquote="WiseLord",url="/forum/viewtopic.php?p=3289467#p3289467"]Да, на отпускание. Потому как при нажатии кнопки в принципе нельзя понять, это нажатие или помеха (дребезг)...[/uquote] Извините, но вы написали чушь.

[ARV]

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

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

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

[WiseLord]

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

[dgrett]

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