Pitanje:
Otklanjanje ignoriranjem podataka?
Sneftel
2014-02-04 01:51:14 UTC
view on stackexchange narkive permalink

Sve rutine opoziva softvera koje sam vidio uključuju čekanje dok se određeni broj uzastopnih očitavanja signala ne vrati 0 ili 1. To, naravno, ima smisla. Ali to znači da postoji neizbježni kompromis između robusnosti i latencije. Što više očitanja zahtijevate da prihvatite promjenu razine, to je duže vrijeme odziva.

Čini se da bi jednostavna alternativa bila jednostavno ignoriranje ulaznih očitanja određeno vrijeme nakon ruba. Ako je sklopka čitala 0, a zatim jedna anketa vraća 1, onda to tumačite kao logičnu 1 za vrijeme očekivanog razdoblja odbijanja. Isto tako pri prijelazu s 1 na 0.

Očito bi to ipak ograničilo maksimalnu ulaznu brzinu. Ali to bi također smanjilo kašnjenje pritiska jednog gumba na gotovo nulu, čak i za ekstremno duga vremena ponavljanja.

Postoje li problemi s ovim pristupom? Čini se kao očit pristup otkazivanju softvera, pa me iznenađuje da se čini da se ne koristi.

Tri odgovori:
Adam Head
2014-02-04 02:50:50 UTC
view on stackexchange narkive permalink

Ponudio bih uvjetni da .

Vaš predloženi pristup pretpostavlja lijepe, čiste signale. Ako biste primijetili bilo kakav šum na tragu, riskirali biste da djelujete na neispravne informacije.
Na primjer: Ako je na signalu bilo napona (skakova) napona kada ste anketirali ulaz, pročitali biste 1 u vašem programu. U svom biste prijedlogu pretpostavili da je prekidač pritisnut (kad doista nije) dok ponovno ne provedete ulaz nakon vašeg "intervala opoziva". U tom trenutku saznajete da, oh, samo se šalim, prekidač stvarno nije pritisnut.
Dakle, za vrijeme trajanja "intervala debouncea" nastavljate kroz svoj program koji vjerojatno djeluje na neispravne informacije da je prekidač je pritisnuto.

U osnovi se svodi na:
Od čega pokušavate zaštititi?
Što je najgore što se može dogoditi ako pogriješite?

Ako ste dječju igru ​​na baterije radili u plastičnoj kutiji, vjerojatno neće biti puno električne buke koja bi zeznula vaše ulaze; tako da bi vaše pojednostavljeno debouncing bilo sasvim u redu.
Međutim, ako je ovaj dio uređaja za održavanje života u bolnici ... možda biste željeli ići s malo robusnijom logikom debounkinga.

Ima smisla. Dakle, tada bi najbolji pristup mogao biti hibridni - kratko razdoblje "svi se moraju složiti", nakon čega slijedi dulje razdoblje "inhibiranja".
@Sneftel Naravno; samo je pitanje 'što pokušavaš filtrirati?'
Spehro Pefhany
2014-02-04 02:11:30 UTC
view on stackexchange narkive permalink

Da, to će uspjeti.

Konvencionalni pristup ima prednost što će odbiti i buku.

Obično je mehaničko odbijanje ograničeno na \ $ \ le \ $ 5msec, pa mislim da ne biste vidjeli razliku u prividnom vremenu odziva.

Imate li referencu za izjavu da je odskok ograničen na manje od 5 ms? Sjećam se da to može biti i duže.
Na malim prekidačima (npr. Prekidačima takta) generičkih azijskih dobavljača, moje iskustvo je da je to dovoljno. Potražio sam tri s maksimalnim naočalama, dva su rekla <1msec, jedan rekao <3msec on / 8msec off. 5msec jamstvo je za mehaničke kodere koje koristimo. Siguran sam da biste, ako ste pokušali, mogli pronaći kontra primjer, na primjer, veliki prekidač za snap-action, ali na takvom prekidaču kašnjenje od 20 ms čak je i manje primjetno nego na prekidaču tipa "tipkovnica". "Jedna veličina odgovara svima" Maximov razbacivač koristi 20msec. Ako počne puzati do kašnjenja od 50 ms, postat će vidljiv na tipkovnici.
Wouter van Ooijen
2014-02-04 02:44:31 UTC
view on stackexchange narkive permalink

To bi uspjelo, naravno. Ali to može biti još jednostavnije: uvijek se opovrgnem čitanjem pin-ova s ​​razmakom od najmanje 50 ms. Jednostavno i učinkovito.

To doista uvodi latenciju do 50 ms. Mislim da nijedan čovjek neće primijetiti razliku. (Koliko putuje gumb s tipkom za 50 ms?)



Ova pitanja su automatski prevedena s engleskog jezika.Izvorni sadržaj dostupan je na stackexchange-u, što zahvaljujemo na cc by-sa 3.0 licenci pod kojom se distribuira.
Loading...