Отменяющие кнопки

Недавно я прочитал статью о том, как отлаживать кнопки, и мне было интересно, стоит ли об этом помнить при работе, например, с Arduino (ATMega mC)? Я предполагаю, что это проблема, особенно при работе с прерываниями.

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

Я настоятельно рекомендую подключить прицел (надеюсь, у вас есть один или вы можете его использовать) к своему коммутатору. Я видел проект студента, у которого был скачок на переключателе, который снизился с 5 В до -5 В до 4 В до -3 В, затем до 2 В, затем снова до 0 В. Когда мы смотрели на текущую ничью на прицеле, был какой-то очень очень большой всплеск.

В его конкретном случае ему было очень и очень необходимо разобрать аппаратный коммутатор.

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

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

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

Независимо от того, используете ли вы программное обеспечение или аппаратное обеспечение, вам все равно придется выбирать качественные кнопки. Печально известная кнопка 157мс из статьи просто не подходит ни для какого приложения.
Я обычно пробую кнопку с интервалами 32 мс , что достаточно, чтобы преодолеть время отказов любой хорошей кнопки. Я большой поклонник Alps SKQG TACT Switches.

На тех немногих устройствах, которые я тестировал, начальное время отказов было менее 10 нс. Несмотря на то, что срок его службы составляет 100 000 циклов, мы проверили его на 200 000 циклов, и даже тогда было достаточно 32 мс. (Полагаю, мне следовало измерить фактический уровень отказов, но в то время нашим основным интересом было поведение конечного продукта. В любом случае, мы использовали его вне спецификации.)

Если вам действительно нужно аппаратное решение, я рекомендую решение SR триггер, упомянутое в статье, как технически лучшее решение:

Триггер может быть построен с двойным NAND- шлюзом, который, например, доступен в небольшом пакете VSSOP8. Основным недостатком этого решения является то, что вам нужна кнопка SPDT, где SPST гораздо более доступен.

Есть много (и много) различных способов отменить кнопки. Делаете ли вы это в программном или аппаратном обеспечении, зависит от требований вашего проекта и типа коммутатора.

Вот несколько ссылок на разные методы:

http://www.ganssle.com/debouncing.htm

http://hackaday.com/2010/11/09/debounce-code-one-post-to-rule-them-all/

Эта статья является "библией" о разоблачении. Отказов контактов может быть проблемой с любым приложением.

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

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

Однако, если вы используете этот переключатель, чтобы вызвать прерывание, и ожидаете, что подпрограмма обслуживания прерываний будет работать быстрее, менее, чем, скажем, за 10 миллисекунд, вам понадобится аппаратная отладка, иначе одно событие переключения может привести к несколько случайному числу прерывания, и, конечно, часто больше, чем ожидалось. С другой стороны, если подпрограмма прерывания выполняется достаточно долго, отскок переключателя будет установлен до того, как ISR завершит работу, и все будет в порядке, но большинство правильно построенных ISR не занимают столько времени.

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

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

forever loop
   wait (at least) 50 ms
   check buttons
   do procesing
end loop

Один из подходов к устранению неполадок, который еще не был упомянут, заключается в использовании переключателя двойного броска, один из которых привязан к VDD, а другой - к земле. Вставьте это в штырь, который (через программное или аппаратное обеспечение) будет слабо вытянут в его текущее состояние. Такой подход обеспечит преимущества двухпозиционного переключателя, но потребует только один вывод ввода-вывода, а не два.