Tranh luận bằng cách bỏ qua dữ liệu?


7

Tất cả các thói quen gỡ lỗi phần mềm mà tôi đã thấy liên quan đến việc chờ đợi cho đến khi một số lần đọc tuần tự tín hiệu trở về 0 hoặc 1. Điều đó có ý nghĩa, tất nhiên. Nhưng nó có nghĩa là có một sự thỏa hiệp không thể tránh khỏi giữa độ mạnh và độ trễ. Càng nhiều bài đọc bạn yêu cầu chấp nhận thay đổi cấp độ, thời gian đáp ứng càng lâu.

Có vẻ như một sự thay thế đơn giản sẽ chỉ đơn giản là bỏ qua các bài đọc đầu vào trong một khoảng thời gian nhất định sau một cạnh. Nếu công tắc đã đọc 0 và sau đó một cuộc thăm dò duy nhất trả về 1, thì diễn giải điều này là logic 1 trong khoảng thời gian của thời gian thoát dự kiến. Tương tự như vậy khi chuyển từ 1 sang 0.

Rõ ràng điều này vẫn sẽ giới hạn tốc độ đầu vào tối đa. Nhưng nó cũng sẽ mang lại độ trễ cho một nút bấm xuống gần như bằng không, ngay cả trong thời gian gỡ lỗi cực kỳ dài.

Có vấn đề với phương pháp này? Nó có vẻ như là một cách tiếp cận rõ ràng để gỡ lỗi phần mềm, vì vậy tôi ngạc nhiên là nó dường như không được sử dụng.

Câu trả lời:


4

Tôi sẽ cung cấp một điều kiện Có .

Phương pháp đề xuất của bạn giả định tín hiệu tốt đẹp, sạch sẽ. Nếu bạn nhận được bất kỳ tiếng ồn trên dấu vết, bạn sẽ có nguy cơ hành động trên thông tin bị lỗi.
Ví dụ: Nếu có tín hiệu tăng điện áp trên tín hiệu khi bạn bỏ phiếu đầu vào, bạn sẽ đọc một 1trong chương trình của mình. Trong đề xuất của bạn, bạn sẽ cho rằng công tắc đã được nhấn (khi nó thực sự không hoạt động) cho đến khi bạn bỏ phiếu lại đầu vào sau "khoảng thời gian gỡ lỗi". Tại thời điểm đó bạn phát hiện ra rằng, oh chờ đã đùa, công tắc thực sự không được nhấn.
Vì vậy, trong khoảng thời gian của "khoảng thời gian gỡ lỗi", bạn đang tiếp tục thông qua chương trình của mình có lẽ hành động dựa trên thông tin bị lỗi mà công tắc đã được nhấn.

Về cơ bản nó đi xuống:
Bạn đang cố gắng bảo vệ chống lại cái gì?
Điều tồi tệ nhất có thể xảy ra nếu bạn sai?

Nếu bạn đang xây dựng một trò chơi trẻ em chạy bằng pin trong một hộp nhựa, có lẽ sẽ không có nhiều tiếng ồn điện để làm hỏng đầu vào của bạn; vì vậy việc thảo luận đơn giản hóa của bạn sẽ tốt
Tuy nhiên, nếu phần này của thiết bị hỗ trợ cuộc sống trong bệnh viện ... bạn có thể muốn sử dụng logic gỡ rối đầu vào mạnh mẽ hơn một chút.


Có ý nghĩa. Vì vậy, cách tiếp cận tốt nhất có thể là một phương pháp lai - một khoảng thời gian "phải đồng ý" ngắn, sau đó là một khoảng thời gian "ức chế" dài hơn.
Sneftel

@Sneftel Chắc chắn; đó chỉ là một câu hỏi về 'bạn đang cố gắng lọc cái gì?'
Adam Head

2

Vâng, nó sẽ làm việc.

Cách tiếp cận thông thường có ưu điểm là nó cũng sẽ loại bỏ tiếng ồn.

Thông thường cơ khí bị giới hạn 5msec, vì vậy tôi không nghĩ rằng bạn sẽ thấy sự khác biệt về thời gian phản hồi rõ ràng.


Bạn có tham chiếu cho tuyên bố rằng độ nảy được giới hạn dưới 5 ms không? Hồi ức của tôi là nó có thể dài hơn nhiều.
Joe Hass

Trên các công tắc nhỏ (ví dụ: công tắc khéo léo) từ các nhà cung cấp chung châu Á, kinh nghiệm của tôi là nó là đủ. Tôi đã tra cứu ba với thông số kỹ thuật tối đa, hai nói <1msec, một nói <3msec trên / 8msec tắt. 5msec là sự đảm bảo cho các bộ mã hóa cơ học mà chúng ta sử dụng. Tôi chắc rằng nếu bạn đã thử, bạn có thể tìm thấy một ví dụ ngược lại, ví dụ như một công tắc hành động nhanh, nhưng trên công tắc như độ trễ 20ms thậm chí còn ít chú ý hơn so với công tắc loại "bàn phím". "Một kích thước phù hợp với tất cả" Các nhà tranh luận Maxim sử dụng 20msec. Nếu nó bắt đầu leo ​​lên đến 50msec độ trễ gỡ lỗi, nó sẽ trở nên đáng chú ý trên bàn phím.
Spehro Pefhany

2

Điều đó sẽ làm việc, tất nhiên. Nhưng nó có thể đơn giản hơn nữa: Tôi luôn gỡ lỗi bằng cách đọc các pin cách nhau ít nhất 50 ms. Đơn giản và hiệu quả.

Điều đó thực sự giới thiệu độ trễ lên tới 50 ms. Tôi không nghĩ bất kỳ con người sẽ nhận thấy sự khác biệt. (Nút nhấn di chuyển trong 50 ms bao xa?)

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.