Как обычно, во всём приходится находить компромис.
Все-таки перевел на цену в рублях…
Я исхожу из того, что Ардуино - это хобби, а потому - экземпляр, как правило, единственный. А в этом случае стоимость комплектующих вообще не имеет значения.
Резистор (если покупать в розницу от сотни) 0.4-0.5 руб, конденсатор 0.1 - 0.5-0.8 руб, каков же должен быть размер партии, чтобы это оправдывало удорожание разработки софта?
Резистор, конденсатор, топология ПП - это всё копеечка до копеечки. Конечно, всё это оправдано при большом производстве. Но, даже в DIY - зачем платить больше, когда можно обойтись меньшим, притом, более элегантно.) ВозьмиТЕ даже токоограничивающие резисторы, хотя бы.)
Ну, DIY - довольно широкая область интересов: кому-то интересно реализовать достаточно обширную функциональность, по возможности менее задумываясь о частностях, а кому-то - при ограниченной функциональности вылизать все до совершенства. И при этом еще следует учитывать, что понятие совершенства тоже субъективно.
Вот пример выше: отключить прерывание на некоторое время. Но вот чтобы вовремя включить его обратно, нужен либо лишний таймер, либо некоторые ограничения на остальной код.
Ну и объем кода растет в любом случае, а скорость его работы, напротив, снижается.
Что то мне не понятно. Во первых для опроса кнопок совсем не нужны прерывания. Если это не так, значит не всё красиво в вашей программе.
И непонятно зачем его (прерывание) отключать на какое то время? Обычно прерывание отключается на ТОБОЙ оговоренное время, как правило минимальное, что бы ни что не мешало выдержать какие то временные нормы.
Это не моя идея - она содержится в посте №58.
А основной вопрос: программное подавление дребезга кнопок.
Лично мое мнение - что целесообразнее давить его аппаратно. Но если есть какие-либо соображения, показывающие преимущества программного решения, не имеющего неприятных побочных эффектов, с удовольствием выслушаю.
Так это ж классика. Опрашиваем кнопки с заданным периодом, меньше длительности дребезга, 30…50 мс обычно. Смотрим изменение состояния кнопок, запоминаем при изменении, заряжаем таймер на величину дребезга. Когда таймер исчерпался, получаем состояние кнопок. Какие проблемы?
Пока навскидку вижу две проблемы:
- 30-50 мс может быть недопустимо долго,
- свободных аппаратных таймеров может не оказаться (а с учетом первого пункта программные могут не подойти).
Очередной диспут про “курицу и яйцо”
Как нет? Есть. повторить кейс на макетке. Это, чтобы не вникать в азы программирования, как Дмитрий рекомендует. Если на макетке взлетит - браться за фен/паяльник. Либо за учебник С++
Учитывая, что ёмкость в 0.1 мкФ, плюс это очень короткий импульс, я не думаю, что там какие-то дикие токи, которые могут как-то повлиять на что-либо.
Если бы всё было так просто - это всё не растянулось бы на 70 постов.
На самом деле легко
Я испробовал 3 библиотеки: button.h, gyverbutton.h,. troykabutton.h. Ни одна не помогла, хотя до этого, сколько устройств я собирал, Не помогли даже внешние прерывания. Помогло лишь копание в аппаратной составляющей. С чего Вы решили, что поможет именно библиотека shButton?
Я ничего не решал. Вы усомнились, что дребезг легко давится программно. Эта библиотека это делает. Легко. Впрочем, как и все три вышеназванные. Собственно, подавление дребезга - основная функция подобных библиотек.
А то, что у вас чего-то не получается - совсем не показатель
ЗЫ: если у вас все работало, но после какой-то из доработок вдруг стало тормозить, стоит подумать, что проблема в изменениях в коде, а не в гипотетической порче МК в процессе прошивки
Вангую. что у вас просто не было подтяжки на пине. То, как вы описали, как у вас срабатывает кнопка при прикосновении к плате - очень характерная картина.
Только не надо теперь убеждать, что подтяжка была. Я вполне готов поверить, что вы ПЫТАЛИСЬ ее сделать - но 70 постов ветки показывают. что у вас это не получилось.
1 лайк
В том, что дребезг легко давится программно, я нисколько не сомневаюсь. Я всегда делал это при помощи библиотек и того же тривиального millis(). А глючить МК стал после неудачной загрузки скетча, как я и написал. И эта неудачная загрузка произошла вовсе не из-за дребезга контактов. Моё видение ситуации такое: при подключении программатора МК начинает получать питание, из-за чего он начинает немного нагреваться. Из-за этого происходит тепловое расширение его корпуса. Из-за того, что пин А0, к которому была припаяна кнопка, был плохо пропаян, то во время загрузки скетча пин потерял контакт с платой, “проскользив по плате” вследствие ещё большего нагрева от загрузки скетча. В результате во время загрузки МК получил произвольный сигнал на Пине А0, из-за чего произошёл сбой загрузки. И после этого кнопка начала глючить. В пользу этого говорят следующие факты:
- Глюки кнопки исчезли именно после пропайки пина МК
- Я конечно же пытался загрузить те версии скетча, при которых кнопка не глючила, но это не дало результатов.
- Даже простейшая программа вида if(digitalRead(ButtonPin)==HIGH) {digitalWrite(ledPin, HIGH} работает с глюками, хотя она должна работать железобетонно, не взирая ни на какие дребезги.
Отсбда и вопрос: причем тут дребезг?
я вас убеждать ни в чём не собираюсь. Ситуация забавная в том, что резистор на 10К, подтягивающий пин, я как раз таки и не пропаивал. Он в смд исполнении, и припаян к плате добротно, в его контакте сомнений не было никаких. Замеры тестером это многократно подтвердили. А то, что этот резистор (,разумеется подтягивающий пин к +Vcc) стоял изначально, я писал об этом. Во что верить - в свои вангования или в факты, решать вам.
Дальше можно не читать. Считаете, что чип накрылся - поменяйте чип. Это таки проще, чем разводить флуд на 77 постов.
1 лайк
Чип целый. Зачем его менять? Для чего палить с пушки по воробьям, когда можно обойтись малой кровью? Это всё равно, что если прибор сломался - надо купить новый вместо того, чтобы разбираться, почему он сломался.
Получилось? Обошлись?
Я по секрету скажу. Если прибор сломался, нужно покупать новый. Или чинить старый, но чипы неремонтопригодны.