[uquote="КРАМ",url="/forum/viewtopic.php?p=4658500#p4658500"]1. Нарисуйте эпюру с нажатием и отпусканием кнопки с дребезгом и наложите на нее опрос с интервалом больше дребезга.
И вы внезапно обнаружите, что захват нажимаемой кнопки во время дребезга НИЧЕМ НЕ ГРОЗИТ…
2. Помех на кнопке кроме дребезга быть не может по определению. Там смещение чистым питанием через резистор порядка 1...10 кОм.
Метод, которым вы создаете интервал опроса значения не имеет. Но интервал создаваемый таймером выглядит куртуазнее. И не нужно обрабатывать захват в прерывании от таймера. Достаточно просто захватить порт и выставить флаг требования обработки. Хотя и в прерывании
по таймеру обработка тоже не сильно тяготит.[/uquote]
1 Сомнительно, что дребезг ничем не грозит.
Рассмотрим случай, когда есть режим нажатия на 2 кнопки. У второй кнопки свой режим.
Вы нажали на 2 кнопки. Первая кнопка из-за дребезга была прочитана, как не нажатая, вторую, как нажатая. Соответственно, перешли на режим второй кнопки. Это ошибка, очень плохо. Жмёшь одно, получаешь другое.
В моём варианте такого нет.
Разработал свой алгоритм давно, решил проверить. Программа простая, написать – несколько минут, макетные платы есть.
Работает чётко, даже когда вторую кнопку нажимаю чуть-чуть раньше первой, читается, как нажатые две кнопки.
2 Сомнительно, что помех не может быть по определению.
Обычно питание от сети 220 вольт. В сети бывают короткие даже киловольтовые импульсы. Даже если у вас на столе не было сбоев, не факт, что у пользователя их не будет.
Проверку на сбои из-за помех надо проводить согласно ГОСТу, а не доверяться «определению».
А с такими испытаниями были проблемы. Полноценное оборудование для такой проверки стоит дорого даже для завода. Можно заказать испытание аппарата, но это тоже стоит дорого. Каждый раз после доработки заказывать испытание – в трубу вылетишь.
Может быть, сейчас ситуация лучше, не знаю.
В этом плане программная защита – хороший простой и бесплатный вариант.
Программа простая, фактически несколько ассемблерных команд плюс задержка. Для последней обычно использую программную задержку, это будет всего одна команда: Delay 30 ms.
В ассемблере, который из прошлого века, такой команды нет, но тогда у разработчика в арсенале должны быть программы задержки.
[uquote="Just_Fluffy",url="/forum/viewtopic.php?p=4658498#p4658498"]
AQ29 писал(а):На фоне решения Adrift табличный вариант выглядит чудовищной растратой памяти. Но СИ-шникам, похоже, такие растраты привычны
Ну куда уж нам всем.... Главное - нужно применять современный супер-пупер-турбо-ассемблер.
Тогда алгоритмы сами пишутся.
Так вот, решение должно быть в голове. А только потом уже переложено на язык программирования. И не важно, какой это язык будет. И если есть задача выжать из кода максимум быстродействия - то и на асме можно применить табличное решение. Это ценой расхода ОЗУ/флеша сэкономит пару тактов.[/uquote]
Насчёт того, что алгоритмы сами пишутся – это, конечно, перебор.
Но если на другом языке программу писать в разы удобнее, и при этом он почти не увеличивает код и не замедляет программу, он будет лучше.
В этом плане, на мой взгляд, выбор языка важен.
Сомнительно, что для вашей второй задачи табличный вариант сэкономит пару тактов.
Как я представляю, в табличном варианте надо прочитать байт из флеша. Но это долгая операция. Для этого вроде как надо записать в регистры Z начальный адрес таблицы и прибавить байт. Это будет 4 команды. Плюс команда LPM, получается 5 команд, как и в решении Adrift. Но LPM – длительная команда, 3 цикла, так что вроде как табличный вариант проигрывает.
[/uquote]
