Tombol debouncing

32

Saya baru-baru ini membaca sebuah artikel tentang pelepasan tombol dan bertanya-tanya apakah saya harus mengingatnya ketika bekerja dengan, misalnya, sebuah Arduino (ATMega mC)? Saya menganggap itu adalah masalah, terutama ketika bekerja dengan interupsi.

Jadi apakah lebih baik mendeteksi bouncing dalam kode, atau haruskah ini dirawat dengan perangkat keras? Tolong jelaskan.

button debounce

— Vincent Van Den Berghe
sumber

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

— tyblu

17

Saya akan sangat menyarankan mengaitkan lingkup (mudah-mudahan Anda memiliki satu atau dapat menggunakan satu untuk digunakan) hingga saklar Anda. Saya telah melihat proyek siswa yang memiliki bouncing pada saklar mereka yang pergi dari 5V ke -5V ke 4V ke -3V kemudian ke 2V kemudian kembali ke 0V. Ketika kami melihat undian saat ini pada ruang lingkup ada beberapa lonjakan yang sangat besar.

Dalam kasusnya yang khusus, sangat diperlukan baginya untuk menghapus sakelar perangkat kerasnya.

Namun, di sisi lain, saya telah melihat switch yang memiliki efek jauh lebih kecil yang dapat dengan mudah dihapus dalam perangkat lunak.

Anda perlu mempertimbangkan pilihan Anda. Jika Anda memiliki jumlah firmware yang sangat kompleks, menambahkan overhead pada Anda sebagai programmer dan penggunaan cpu mungkin tidak sepadan dan Anda akan lebih baik hanya menambahkan sedikit perangkat keras. Sekarang di sisi lain, jika Anda mencoba untuk mendapatkan biaya dan ukuran turun, Anda akan ingin menghapus perangkat keras sebanyak mungkin dan melakukan semuanya dalam firmware jika Anda bisa.

— Kellenjb
sumber

Saya mengambil gambar bouncing switch dan mempostingnya di Wikipedia: en.wikipedia.org/wiki/File:Switch_bounce.JPG

— Thomas O

@ Thomas O, itu gambar bouncing yang cukup menyenangkan. Saya hanya ingin memastikan @Vincent Van Den Berghe mengerti bahwa tidak semua bouncing akan terlihat seperti itu. Bouncing itu terbatas pada 0-5v, tidak akan selalu terlihat seperti itu.

— Kellenjb

2

@Thomas O, sebagai catatan, kami telah membuat praktik siswa gagal yang mengambil gambar Oscope seperti itu. Flash pada layar mengerikan. Kami juga mengambil langkah lebih jauh dan mendorong siswa untuk mengumpulkan poin data aktual, menggunakan sesuatu seperti CSV atau labview, sehingga kemudian dapat dengan mudah digunakan dalam laporan dan analisis data.

— Kellenjb

@Kellenjb, saya akan segera mendapatkan printer untuk lingkup saya yang mendukung HP-IB. Juga saya telah menemukan mode "Olahraga" pada kamera saya dapat mengambil gambar yang bagus dari layar lingkup tanpa flash dan tanpa kabur.

— Thomas O

1

@Lundin Dalam lingkungan waktu-nyata Anda banyak bergantung pada interupsi. Jika Anda memiliki tombol tekan pada interupsi, Anda tidak benar-benar ingin sistem real-time Anda terganggu beberapa kali dengan sekali tekan tombol. Anda juga tidak ingin harus mendedikasikan sumber daya untuk menunggu 10 ms.

— Kellenjb

15

Jika Anda seorang perancang elektronik profesional kemungkinan bos Anda tidak akan membiarkan Anda melakukannya dalam perangkat keras. Alasannya sederhana: jika kumpulan produksi Anda adalah perangkat lunak yang cukup besar sebenarnya gratis , sedangkan perangkat keras harus dibayar untuk setiap unit yang Anda hasilkan. Dan sementara resistor dan kapasitor sangat murah, memasangnya pada PCB mungkin berharga hingga 20 kali lipat dari harga pembelian mereka.

Apakah Anda melakukan debounce pada perangkat lunak atau perangkat keras, Anda masih harus memilih tombol kualitas. Tombol 157ms yang terkenal dari artikel sama sekali tidak cocok untuk aplikasi apa pun .
Saya biasanya mencicipi tombol pada interval 32ms , yang cukup untuk menjembatani waktu debounce dari tombol yang bagus. Saya penggemar berat Alps Switch SKQG TACT.

Beralih kebijaksanaan Alps

Pada beberapa perangkat yang saya uji memiliki waktu pentalan awal kurang dari 10ns. Sementara itu memiliki masa operasi 100 000 siklus, kami mengujinya untuk 200 000 siklus dan bahkan kemudian 32ms debounce sudah cukup. (Saya kira saya seharusnya mengukur tingkat debounce yang sebenarnya, tetapi minat utama kami pada saat itu adalah perilaku produk akhir. Bagaimanapun, kami menggunakannya di luar spesifikasi.)

Jika Anda benar-benar menginginkan solusi perangkat keras, saya berikan solusi SR flip-flop yang disebutkan dalam artikel sebagai solusi terbaik secara teknis:

sirkuit debounce

Flip-flop dapat dibangun dengan gerbang NAND ganda , yang tersedia dalam paket VSSOP8 kecil, misalnya. Kelemahan utama dari solusi ini adalah Anda memerlukan tombol tekan SPDT, di mana SPST jauh lebih umum tersedia.

— stevenvh
sumber

12

Ada banyak (dan banyak) cara berbeda untuk melonggarkan tombol. Apakah Anda melakukannya dalam perangkat lunak atau perangkat keras akan tergantung pada persyaratan proyek Anda dan jenis switch.

Berikut ini beberapa tautan ke berbagai metode:

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

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

— Toby Jaffey
sumber

Saya akan pergi mendapatkan tautan ke ganssle ketika saya melihat pertanyaan itu.

— Kortuk

Artikel ganssle adalah alasan saya mengajukan pertanyaan ini, itu tertaut dalam pertanyaan saya :) Terima kasih atas tautannya ke potongan kode debounce.

— Vincent Van Den Berghe

Maukah Anda menyimpulkan beberapa use case untuk menggambarkan kapan harus menggunakan soft / hardware? (ini mungkin subjektif, tapi saya tetap ingin beberapa contoh)

— Vincent Van Den Berghe

1

@Vincent, Kellenjb menyimpulkannya pada jawabannya bagaimana memutuskan. Saya tidak mengklik tautan Anda karena memiliki nama yang lucu, sekarang setelah saya mengkliknya saya melihat ganssle!

— Kortuk

Jika itu adalah konsensus / aturan umum maka memang, tidak perlu untuk lebih banyak contoh.

— Vincent Van Den Berghe

6

Artikel itu adalah "alkitab" tentang debouncing. Kontak bouncing dapat menjadi masalah dengan aplikasi apa pun.

Umumnya lebih baik untuk mendebokan sakelar dalam perangkat lunak karena lebih mudah untuk menyesuaikan penundaan untuk sakelar tertentu, karena sakelar-sakelar kontak mereka berbeda. Debouncing rilis kunci juga sering diperlukan. Switch produsen sering menentukan jumlah bouncing untuk produk mereka, biasanya sekitar 10 ms - 20 ms.

— Leon Heller
sumber

Mengapa orang memilih ini?

— Toby Jaffey

Poin bagus tentang pelepasan kunci!

— Vincent Van Den Berghe

1

Saya tidak downvote, tetapi hanya mengatakan untuk melakukannya dalam perangkat lunak adalah ide yang buruk. Ini adalah ide yang bagus untuk dikarakterisasi.

— Kortuk

Saya mengatakan "secara umum", yang merupakan kasus, dan memberikan alasannya. Ini juga meminimalkan biaya BOM dan meningkatkan keandalan.

— Leon Heller

itu hanya meningkatkan keandalan jika sinyal tetap dalam batas aman dari pengontrol Anda. Tindakan ini akan meningkatkan keandalan jika Anda mengurangi jumlah komponen tanpa menambah keausan komponen. Saya tidak mengatakan bahwa saya tidak setuju dengan konsep posting Anda, tetapi saya selalu bekerja dengan para insinyur yang baru saja datang ke lapangan dan jawaban seperti ini dan mereka akan menghapus semuanya dalam perangkat lunak. Anda harus selalu mencirikan. Saya juga tidak menurunkan suara Anda, tetapi saya juga tidak mengungguli, saya pikir jawaban luas seperti perangkat lunak berisiko pengembang baru mempertaruhkan perangkat keras mereka.

— Kortuk

1

Beralih bouncing dapat berlangsung selama puluhan milidetik. Jika Anda mengambil jajak pendapat dari rutinitas interupsi yang berjalan pada penghitung waktu, bouncing tidak akan menjadi masalah, karena bahkan jika Anda melakukan polling switch di tengah-tengah badai bouncing, Anda langsung mendapatkan status baru segera , atau paling buruk mendapatkan status lama, dan tidak melihat status baru hingga jajak pendapat berbasis waktu berikutnya. Polling dari ISR berjangka waktu seperti ini merupakan bentuk pelepasan perangkat lunak.

Namun, jika Anda menggunakan sakelar itu untuk menyebabkan interupsi, dan Anda mengharapkan rutin layanan interupsi itu berjalan dengan cepat, dalam waktu kurang dari 10 milidetik, Anda akan memerlukan pelepasan perangkat keras, jika tidak satu peristiwa sakelar dapat menghasilkan jumlah acak yang agak acak. menyela, dan tentu saja seringkali lebih dari yang diharapkan. Di sisi lain, jika rutin interupsi berjalan cukup lama, bouncing switch akan menetap sebelum ISR selesai, dan Anda akan baik-baik saja, tetapi kebanyakan ISR yang dibangun dengan baik tidak membutuhkan waktu terlalu lama.

— JustJeff
sumber

Memiliki saklar untuk menyebabkan interupsi adalah ide yang bagus. Tetapi begitu Anda mendapatkannya, jangan izinkan interupsi lebih lanjut - matikan dan mulai waktu untuk waktu debounce yang ditentukan.

— Lundin

@Lundin - jika timer tersedia, Anda bisa menggunakan timer untuk menerapkan pendekatan yang disurvei, dan tidak perlu repot beralih menghasilkan interupsi sama sekali.

— JustJeff

0

Cara terbaik untuk melakukan apa pun adalah cara yang paling cocok untuk Anda. Tetapi ketika Anda sudah memiliki mikrokontroler Anda dapat melakukan debounce pada perangkat lunak hanya dengan biaya beberapa upaya kode.

Cara terpenting untuk melonggarkan perangkat lunak adalah dengan memeriksa tombol pada saat-saat yang lebih jauh daripada waktu bouncing terpanjang. 50 ms tampaknya merupakan batas atas pada waktu pentalan sakelar 'normal', jadi ketika Anda dapat mengatur perangkat lunak Anda seperti ini, Anda berada di tempat yang jelas:

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

— Wouter van Ooijen
sumber

Dan gunakan timer on-chip di MCU Anda untuk ini.

— Lundin

Itu tentu saja mungkin, tetapi Anda dapat menulis banyak program tanpa.

— Wouter van Ooijen

3

Perangkat lunak profesional dalam produk berkualitas akan selalu menggunakan timer on-chip. Hobi dapat lolos dengan beberapa "NOP" untuk pemungutan suara putaran atau mati menunggu. Tetapi tidak ada alasan untuk melakukan ini dalam produk nyata, tidak peduli persyaratan waktu nyata Anda. "Saya tidak tahu bagaimana timer bekerja dan loop mati ini membutuhkan waktu 10 detik untuk menulis sendiri malas saya" bukan argumen yang valid untuk seorang insinyur.

— Lundin

Lembu jantan. Profesional harus efektif, yang (tergantung pada proyek yang dihadapi) dapat berarti (antara lain) 'menggunakan perangkat keras seefektif mungkin' atau 'menggunakan waktu profesional seefektif mungkin'. Jadi kedatangan Anda tentu berlaku dalam beberapa kasus (mungkin semua kasus yang telah Anda tangani) itu pasti tidak berlaku dalam semua kasus.

— Wouter van Ooijen

Untuk mengimplementasikan timer on-chip, Anda membutuhkan waktu paling lama satu jam. Ini bukan sesuatu yang kompleks, itu adalah teknik roti & mentega setiap hari. Anda bahkan tidak dapat berinvestasi satu jam dalam proyek Anda untuk mendapatkan solusi yang jauh lebih baik dan kualitas yang lebih baik secara keseluruhan? Ya baiklah ... jika Anda tidak tahu banyak tentang pemrograman, mungkin perlu waktu seminggu. Tapi mungkin Anda seharusnya tidak bekerja dengan perangkat lunak di tempat pertama ... atau mungkin Anda harus bekerja lebih banyak dengannya, jadi Anda akan belajar menerapkan hal kecil yang sederhana ini dalam waktu singkat.

— Lundin

0

Salah satu pendekatan untuk melonggarkan yang belum disebutkan adalah dengan menggunakan saklar lemparan ganda dengan satu lemparan terikat ke VDD dan yang lainnya ke ground. Masukkan itu ke dalam pin yang (baik melalui perangkat lunak atau perangkat keras) akan ditarik dengan lemah ke kondisi saat ini. Pendekatan semacam itu akan memberikan keuntungan dari saklar lemparan ganda, tetapi hanya akan membutuhkan satu pin I / O daripada dua.

— supercat
sumber