Nút gỡ

Gần đây tôi đã đọc một bài viết về việc gỡ nút và tự hỏi liệu tôi có nên ghi nhớ điều này khi làm việc với, ví dụ, một Arduino (ATMega mC) không? Tôi cho rằng đó là một vấn đề, đặc biệt là khi làm việc với các ngắt.

Vì vậy, tốt hơn là phát hiện thoát trong mã, hoặc điều này nên được quan tâm với phần cứng? Xin hãy giải thích.

Tôi đặc biệt khuyên bạn nên nối một phạm vi (hy vọng bạn có một hoặc có thể sử dụng một cái để sử dụng) cho đến công tắc của bạn. Tôi đã thấy một dự án của một sinh viên có độ nảy trên công tắc của họ đã tăng từ 5v xuống -5v lên đến 4v xuống -3v rồi lên đến 2v rồi quay xuống 0v. Khi chúng ta nhìn vào trận hòa hiện tại trên một phạm vi, có một sự tăng đột biến rất lớn.

Trong trường hợp cụ thể của anh ấy, rất cần thiết cho anh ấy để công bố chuyển đổi của mình trong phần cứng.

Tuy nhiên, mặt khác, tôi đã thấy các công tắc có hiệu ứng nhỏ hơn nhiều có thể dễ dàng bị loại bỏ trong phần mềm.

Bạn cần phải cân nhắc các lựa chọn của bạn mặc dù. Nếu bạn có số lượng phần sụn rất phức tạp, việc thêm chi phí cho cả bạn với tư cách là một lập trình viên và việc sử dụng cpu có thể không đáng và bạn sẽ tốt hơn nếu chỉ thêm một chút phần cứng. Mặt khác, nếu bạn đang cố gắng giảm chi phí và kích thước, bạn sẽ muốn loại bỏ càng nhiều phần cứng càng tốt và làm tất cả trong phần sụn nếu bạn có thể.

Nếu bạn là một nhà thiết kế điện tử chuyên nghiệp thì rất có thể ông chủ của bạn thậm chí sẽ không cho phép bạn làm điều đó trong phần cứng. Lý do rất đơn giản: nếu lô sản xuất của bạn đủ lớn thì phần mềm hầu như miễn phí , trong khi phần cứng phải được trả cho mỗi đơn vị bạn sản xuất. Và trong khi điện trở và tụ điện rất rẻ, việc gắn chúng lên PCB có thể tốn gấp 20 lần giá mua.

Cho dù bạn gỡ lỗi trong phần mềm hay phần cứng, bạn vẫn phải chọn các nút bấm chất lượng. Nút 157ms khét tiếng từ bài viết chỉ đơn giản là không phù hợp với bất kỳ ứng dụng nào .
Tôi thường lấy mẫu nút ở các khoảng thời gian 32ms , đủ để thu hẹp thời gian gỡ lỗi của bất kỳ nút tốt nào. Tôi khá hâm mộ các thiết bị chuyển mạch Alps SKQG TACT.

Trên một vài thiết bị tôi đã thử nghiệm, nó có thời gian thoát ban đầu dưới 10ns. Mặc dù nó có tuổi thọ hoạt động là 100 000 chu kỳ, chúng tôi đã thử nghiệm nó cho 200 000 chu kỳ và thậm chí sau đó, việc gỡ lỗi 32ms là đủ. (Tôi đoán rằng tôi nên đã đo mức độ gỡ lỗi thực tế, nhưng mối quan tâm chính của chúng tôi tại thời điểm đó là hành vi của sản phẩm cuối cùng.

Nếu bạn thực sự muốn một giải pháp phần cứng, tôi thứ hai giải pháp flip-flop được đề cập trong bài viết là giải pháp tốt nhất về mặt kỹ thuật:

Ví dụ, flip-flop có thể được xây dựng với một cổng NAND kép , có sẵn trong một gói VSSOP8 nhỏ. Hạn chế chính của giải pháp này là bạn cần một nút bấm SPDT, trong đó SPST thường có sẵn hơn nhiều.

Có rất nhiều (và rất nhiều) cách khác nhau để gỡ nút. Cho dù bạn làm điều đó trong phần mềm hay phần cứng sẽ phụ thuộc vào yêu cầu dự án và loại chuyển đổi của bạn.

Dưới đây là một số liên kết đến các phương pháp khác nhau:

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

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

Bài báo đó là "kinh thánh" về tranh luận. Liên hệ bị trả lại có thể là một vấn đề với bất kỳ ứng dụng.

Nói chung, tốt nhất là gỡ lỗi các công tắc trong phần mềm vì điều chỉnh độ trễ cho các công tắc cụ thể dễ dàng hơn, vì chúng khác nhau về số lần nảy tiếp xúc. Việc phát hành bản phát hành chính cũng thường là cần thiết. Các nhà sản xuất thiết bị chuyển mạch thường chỉ định mức độ nảy cho sản phẩm của họ, thường là khoảng 10ms - 20ms.

Chuyển đổi có thể tiếp tục trong hàng chục mili giây. Nếu bạn đang bỏ phiếu chuyển đổi từ một thói quen ngắt chạy trên bộ đếm thời gian, thì việc thoát sẽ không thành vấn đề, bởi vì ngay cả khi bạn tình cờ thăm dò công tắc ở giữa cơn bão nảy, bạn sẽ có trạng thái mới ngay lập tức hoặc tệ nhất là lấy trạng thái cũ và không thấy trạng thái mới cho đến khi cuộc thăm dò dựa trên bộ đếm thời gian tiếp theo. Thăm dò ý kiến ​​từ một ISR được định thời gian như thế này tạo thành một hình thức gỡ lỗi phần mềm.

Tuy nhiên, nếu bạn đang sử dụng công tắc đó để gây gián đoạn và bạn mong rằng thói quen dịch vụ ngắt đó sẽ chạy nhanh, trong vòng chưa đến 10 mili giây, bạn sẽ cần gỡ lỗi phần cứng, nếu không, một sự kiện chuyển đổi có thể dẫn đến một số lượng ngẫu nhiên gián đoạn, và chắc chắn thường nhiều hơn chỉ là dự kiến. Mặt khác, nếu thói quen ngắt chạy đủ lâu, độ nảy của công tắc sẽ ổn định trước khi ISR ​​kết thúc và bạn sẽ ổn, nhưng hầu hết các ISR được xây dựng tốt sẽ không mất nhiều thời gian như vậy.

Cách tốt nhất để làm bất cứ điều gì là cách phù hợp với bạn nhất. Nhưng khi bạn đã có một vi điều khiển, bạn có thể gỡ lỗi trong phần mềm chỉ với chi phí cho một số nỗ lực mã.

Cách tinh vi nhất để gỡ lỗi trong phần mềm là kiểm tra các nút tại các thời điểm cách xa nhau hơn thời gian thoát dài nhất. 50 ms dường như là giới hạn trên của thời gian bật của các công tắc 'bình thường', vì vậy khi bạn có thể sắp xếp phần mềm của mình như thế này, bạn sẽ thấy rõ:

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

Một cách tiếp cận để thảo luận mà chưa được đề cập là sử dụng một công tắc ném hai lần với một cú ném gắn với VDD và cái kia chạm đất. Đưa nó vào một pin mà (thông qua phần mềm hoặc phần cứng) sẽ bị kéo yếu về trạng thái hiện tại. Cách tiếp cận như vậy sẽ cung cấp những lợi thế của công tắc hai lần, nhưng sẽ chỉ yêu cầu một chân I / O chứ không phải hai.