Guten Tag, welche Vorteile hat eine Entprellung mit Hardware im Gegensatz zu einer Entprellung mit Software? Als großes Nachteil sehe ich hier die Kosten für die zusätzlichen Bauteile
die Zeitkonstanten .. Unterhalb von 10ms sollte man gar nicht dran denken. Und ein paar Zeilen Code sind immer guenstiger wie Bauteile. Diese Zeilen muss man genau einmal erdenken, und kann sie immer wieder copy/pasten.
lorch schrieb: > Als Nachteil sehe ich hier die Kosten für die zusätzlichen Bauteile Und die nötige Platinenfläche... Und die fehlende "Updatemöglichkeit"... Und keine Möglichkeit, für "besondere Fälle" die Entprellung zu umgehen...
lorch schrieb: > Als großes Nachteil sehe ich hier die Kosten > für die zusätzlichen Bauteile Ja stimmt, Kondensatoren und Widerstände sind auch die teuersten Bauteile auf einer Schaltung.
lorch schrieb: > welche Vorteile hat eine Entprellung mit Hardware im Gegensatz zu einer > Entprellung mit Software? Keine, aber wenn man keine Software hat, sondern z.B. ein FlipFlop direkt per Tastendruck bedienen will, muss man es eben in Hardware machen. Obwohl - manche Leute wollten schon Widerstände durch uC ersetzen, da könnte ein kleiner uC vor dem FlipFlop doch die Enprell-Hardware sein. http://www.dse-faq.elektronik-kompendium.de/dse-faq.htm#F.29.1
Der Vorteil von Hardware ist das du 1. keine Rechenzeit brauchst 2. keinen Speicher für Entprellung belegst. MfG
Michael B. schrieb: > da könnte ein kleiner uC vor dem FlipFlop doch die Enprell-Hardware sein. Natürlich könnte man dann auch gleich das Flipflop ersetzen...
@Michael Bertrandt >Obwohl - manche Leute wollten schon Widerstände durch uC ersetzen, da >könnte ein kleiner uC vor dem FlipFlop doch die Enprell-Hardware sein. Dieser Widerstand hätte damit auch alle positiven Eigenschaften einer SW-Entprellung, wie Updatefähigkeit ... ;-)
Kann es sein, dass hier um das, in den Brunnen gefallene Kind diskutiert wird? Die Antwort auf die Frage ergibt sich doch von selber! Spätestens, wenn man die bösartige und hinterhältige Frage aufwirft, warum bzw. wodurch entsteht das Prellen überhaupt. Es ist überhaupt kein Problem, zwei Kontakte, ohne prellen zu schließen. "Muttu nur langsam machen". Bei größeren Strömen freuen sich dann endlich mal die Hersteller selbiger und prellfreier Kontakte und außerdem knistert es nicht mehr nur im Kamin. Falls es nicht jemand schafft die Physik zu überlisten, sollten schon die Kosten und die unvermeidlichen Nebeneffekte jeden zur Vernunft bringen.
Sebastian S. schrieb: > Es ist überhaupt kein Problem, zwei Kontakte, ohne prellen zu schließen. > "Muttu nur langsam machen". Das ist absoluter Unsinn. Ein leitfähiges Staubkorn bildet den ersten Kontaktpunkt, nur ein paar Atome gross, und wird weggebrannt, dann ist der Kontakt wieder offen bis der nächste Oberflächenbuckel anmarschiert kommt. Prellfreie Kontakte gibt es bei qucksilberbenetzten Reed-Relais.
einer schrieb: > Der Vorteil von Hardware ist das du > 1. keine Rechenzeit brauchst > 2. keinen Speicher für Entprellung belegst. > > MfG + einfache Software/einfaches Interrupthandling Nicht entprellt per Interrupt ist aufwändiger..
lorch schrieb: > Als großes Nachteil sehe ich hier die Kosten > für die zusätzlichen Bauteile Dafür entstehen keine Kosten für den µC und die Programmierung. Umgerechnet auf 1000000 Geräte ergibt sich eine Ersparnis von € 9500,73.
abc schrieb: > Nicht entprellt per Interrupt ist aufwändiger.. In 99,99% der Fälle ist ein Interrupt für Taster in einem normalen Programmablauf nicht nötig. So einen Interrupteingang für einen Taster braucht man eigentlich nur, um einen uC vom Standby aufzuwecken. Und dann ist ein prellender Taster auch nicht schlimm... Oder andersrum: wer für "normale" Benutzereingaben einen Interrupt braucht, der hat einen Fehler im Programm/Konzept.
:
Bearbeitet durch Moderator
Lothar M. schrieb: > Und dann ist ein prellender Taster auch nicht schlimm... ..., denn das Entprellen erfolgt natürlich nicht Polaritätswechsel-Interrrupt, sondern in der per Timer-Interrupt o.ä. periodisch gestarteten Entprellroutine. > In 99,99% der Fälle Das mag auf der meisten netzgespeisten Anwendungen sicherlich zutreffen, aber diese stellen sicherlich nicht mehr die überragende Mehrheit aller Microcontroller-Anwendungen dar. Bei batteriegespeisten Anwendungen dürfte der Anteil der per Taster aufzuweckenden Geräte wesentlich höher sein.
Mitlesa schrieb: > Ja stimmt, Kondensatoren und Widerstände sind auch die > teuersten Bauteile auf einer Schaltung. So was schreibt auch nur ein Hobby-Bastler der keine Ahnung hat. Wenn du Produkte in ein umkämpftes Segment lieferst (liefern musst) - hier wird teilweise nur minimal über HK verkauft - dann denkst du über jedes Bauteil zweimal nach ;)
m.n. schrieb: > Umgerechnet auf 1000000 Geräte ergibt sich eine Ersparnis von € 9500,73. Das finde ich für eine halbe Stunde Arbeit ganz ok, selbst wenn es brutto ist. Und auch bei drei Geräten für zuhause implementiere ich die Softwareentprellung schneller, als zum Lötplatz zu latschen, Lupenbrille aufzusetzen, 3*R und 3*C rauszusuchen, aufzulöten und zu testen.
lorch schrieb: > welche Vorteile hat eine Entprellung mit Hardware im Gegensatz zu einer > Entprellung mit Software? Ohne den Kontext zu kennen, sehe ich keine Möglichkeit diese Frage zu beantworten.
U. C. schrieb: > lorch schrieb: >> welche Vorteile hat eine Entprellung mit Hardware im Gegensatz zu einer >> Entprellung mit Software? > > Ohne den Kontext zu kennen, sehe ich keine Möglichkeit diese Frage zu > beantworten. Machen wir es doch wie bei Radio Eriwan: ein klares JEIN! Noramlerweise wird jeder Kontakt/Eingang nicht nackt auf die CPU gehen. Da kommt in irgendeiner Form immer ein bisschen RC hin, schon mal meistens für die EMV/ESD. Auch wenn der Markt heiss umkämpft ist dann laufen dort Stückzahlen und in Stückzahlen kostet auch die Platine und die Bauteile etwas. Aber auch die Entwicklung/Test von Routinen kostet etwas. Dürfte sich die Waage halten. Und in der SW vernünftig "zu entprellen" und sich nicht nur auf die HW zu verlassen - auch schon mal wegen EMV/ESD - ist auch Stand deer Technik. Es wird je nach Gegebenheiten in der Industrie ein Mix von beiden sein. Den Bastler stört das alles nicht die Bohne - der macht das wie er will. Ist ja nur SEIN Produkt ohne Anspruch auf Reproduzierbarkeit (no flame!). rgds
Ich verwende meist eine Kombination von Beidem. Ein Pull-up für den Taster/Schalter und einen kleinen C nach GND um auch auf langer Leitung die "Antenne" am Taster (wenn er etwas weiter von der Platine weg ist) zu entstören. Softwareseitig wird dann meist 200-300ms entprellt.
Ingo L. schrieb: > Softwareseitig wird dann meist 200-300ms entprellt. Das sind genau diese Geräte, die ich am liebsten anzünden würde. Einmal zu schnell gedrückt, bewegt sich nix. Nochmal drücken? Abwarten ob der erste Drücker etwas bewirkt hat? Ich bin nach Jahren wieder zur Hardware Entprellung zurück gekehrt. Schließlich zeigt sich diese "nicht so schnell drücken" Philosophie an vielen Geräte, die sich auf Kosten des Bedieners die paar Cent gespart haben ...
Entpreller schrieb: > Ich bin nach Jahren wieder zur Hardware Entprellung zurück gekehrt. Entweder so oder gleich per Interrupt. Da liegen die Entprellzeiten dann im ms-Bereich ;-)
Andreas S. schrieb: > Bei batteriegespeisten Anwendungen dürfte der Anteil der per Taster > aufzuweckenden Geräte wesentlich höher sein. Richtig, aber ab den Augenblick, wo der Controller "normal" läuft, wird der Taster nicht mehr per Pinchange-Interrupt abgefragt, sondern z.B. im Timer-Interrupt gepollt. Und weil das Aufwecken jeweils einmalig passiert, macht es nichts aus, wenn der Taster prellt. 6a66 schrieb: > Noramlerweise wird jeder Kontakt/Eingang nicht nackt auf die CPU gehen. > Da kommt in irgendeiner Form immer ein bisschen RC hin, schon mal > meistens für die EMV/ESD. So ist es. Aber ein RC-Glied an sich entprellt nicht. Es filtert nur. Zusammen mit einem Schmitttrigger-Eingang kann es dann allerdings je nach Bemessung dann auch entprellen. Dazu muss man aber den Eingang seines uC verstanden haben...
Mitlesa schrieb: > Ja stimmt, Kondensatoren und Widerstände sind auch die > teuersten Bauteile auf einer Schaltung. Nun habe ich aber 10 Schalter mit 10xR + 10xC die ich kaufen und Bestücken lassen muß. Jedes dieser Bauteile muß ich in der MTBF Analyse bewerten und beschreiben was passiert bei: 1: Kurzschluss 2: Unterbrechung 3: Wert Veränderung Schon mal in der Situation gewesen das selbst einzelne 0402 Bauteile nur noch mit Mühe unterzubringen waren ? Für Hobby Heimwerken spielt das natürlich alles keine Rolle.
Der Entprellkondensator schließt auch Störungen durch Elektromagnetische Felder kurz. Das kann je nach Anwendungsfall hilfreich sein, besonders bei langen Leitungen. Zum Beispiel, wenn es sich um ein batteriebetriebenes Gerät handelt, welches die meiste Zeit schläft und durch einen Taster aufgeweckt wird. Da will man ungewollte Aufweck-Vorgänge vermeiden, damit die Batterie lange hält. Für mich als Hobbybastler ist der größte Vorteil von Entprell-Kondensatoren (gegenüber Software) der, dass die Software einfacher wird. Da gebe ich gerne ein paar Cent mehr aus.
lorch schrieb: > Als großes Nachteil sehe ich hier die Kosten > für die zusätzlichen Bauteile Kosten für C 1c; kosten für R : 1c Aufwand für Programmierung/test/: 1h Rest kannst du selber rechnen. Die Hardwarelösung hat den Vorteil das auch wenn der Programmier die Entprellung vergisst(weil er die Firmware from die Scratch neu schreibt) das ganze immer nocht tut - ist also Idiotensicher.
Durchstapler schrieb: > Kosten für C 1c; kosten für R : 1c Kosten für Bestückung von X bis Y je nach Losgröße > Aufwand für Programmierung/test/: 1h Serien von 1Stk bis 1.000.000 Stück > Rest kannst du selber rechnen. Wenn man das kann, ja.
Durchstapler schrieb: > Kosten für C 1c; kosten für R : 1c > > Aufwand für Programmierung/test/: 1h Das finde ich einen interessanten betriebswirtschaftlichen Ansatz. Dagegen ist jede Milchmädchenrechnung hochwissenschaftlich. Stückzahlen? Tastenanzahl je Gerät? Bestückungskosten Bauteile? Kosten Schaltplan-, Layout- und Stücklistenerstellung? Kosten Materialbeschaffung und -Vorhaltung?
Lothar M. schrieb: > Es filtert nur. Zusammen mit > einem Schmitttrigger-Eingang kann es dann allerdings je nach Bemessung > dann auch entprellen. Dazu muss man aber den Eingang seines uC > verstanden haben... ist ja richtig. Das "Filtern" ist ja schon mal das was ein Großteil der Fraktion als "Entprellen" kennt und was schon mal einen guten Teil der Störungen entfernt. Jetzt kommt es noch drauf an was man danach noch als "SW-Entprellung" hinterherschiebt. Ingo L. schrieb: > softwareseitig wird dann meist 200-300ms entprellt. Entpreller schrieb: > Das sind genau diese Geräte, die ich am liebsten anzünden würde. Einmal > zu schnell gedrückt, bewegt sich nix. Klar kann das auch ZUUU konservativ gehalten werden. Die Frage ist: was passiert wenn es zu schnell geht oder warum so konservativ? Einen einfachen Taster kann ich problemlos mit RC beruhigen, da braucht's nichts mehr in SW hinterher, die Konstante nur lange genug machen (e.g. RC-Glied am Reset Taster). Auf der anderen Seite sind dann die Steuerungseingänge die durch die halbe Halle geschleift werden, die fangen alles Mögliche auf und sollen noch problemlos erkannt werden. rgds
Durchstapler schrieb: > lorch schrieb: > Kosten für C 1c; kosten für R : 1c > Aufwand für Programmierung/test/: 1h Einmal die Lib schreiben und bei allen Projekten weiterverwenden? Somit kannst Du die Stunde durch die Projekte teilen.
Ich gehe ja schon so weit selbst die Taster einzusparen und durch Kapazitive Taster zu ersetzen. Wozu Quarz wenn es der interne RC auch tut ? Sparen tut man in erster Instanz in der Entwicklung und solange ich Hardware nicht im Raumschiff Enterprise Replikator für lau bekomme ist keine Hardware immer billiger als Hardware. Keine Hardware muß nicht bestückt werde, keine Hardware kann auch nicht ausfallen. Hobby Heimbasteln unterliegt vollkommen anderen Anforderungen.
Entpreller schrieb: >> Softwareseitig wird dann meist 200-300ms entprellt. > > Das sind genau diese Geräte, die ich am liebsten anzünden würde. Wenn der Taster nunmal diese Zeit prellt lässt sich daran nichts ändern. Wenn der Taster aber nur 20ms prellt und ich ganz hastig drücken will ändere ich in meinem #define für die Entprellzeit einfach eine Zahl und schwupps is die Zeit anders. Alles halb so wild, kannst dein Feuerzeug in der Tasche lassen ;).
:
Bearbeitet durch User
Lothar M. schrieb: > In 99,99% der Fälle ist ein Interrupt für Taster in einem normalen > Programmablauf nicht nötig. So einen Interrupteingang für einen Taster > braucht man eigentlich nur, um einen uC vom Standby aufzuwecken. Und > dann ist ein prellender Taster auch nicht schlimm... Hmmm. Vorige Woche ein DMX-Tester im Auftrag gebaut. 4x4 Tastatur, jeder Taster prellt unterschiedlich lang. Mit LCD-Ausgabe, langer Tastendruck wiederholt Zeichen. Ohne Softwareentprellung läuft da nichts...
Eine richtig gemachte Hardware Entprellung mit Flipflop hat imho eine riesen Vorteil gegenüber vielen anderen Lösungen. Funktioniert auch noch wenn durch Alterung die Prellzeit extrem lang geworden ist. Ich besitze mindestens 10 Geräte bei denen die Bedienung nach ein paar Jahren nahezu unmöglich geworden ist. Beispiel eine USB Umschaltbox 4 PCs an einen Scanner. Einknopfbedienung hat ein Jahr funktioniert danach fast immer 2 Sprünge jetzt 3-5 Sprünge pro Tastendruck. mfg Michael
Wenn Platz da ist, immer mit einem Tiefpass und einem Schmitt-Trigger dahinter entprellen. Sauber, effizient und kostet nicht die Welt.
michael_ohl schrieb: > Beispiel eine USB Umschaltbox 4 PCs an einen > Scanner. Einknopfbedienung hat ein Jahr funktioniert danach fast immer 2 > Sprünge jetzt 3-5 Sprünge pro Tastendruck. Mach sie mal auf: Hardwareentprellung ?
Wie lange hält denn eigentlich so ein Taster, wenn er bei jeder Betätigung einen niederimpedanten MLCC kurzschließen muss?
michael_ohl schrieb: > Funktioniert auch noch > wenn durch Alterung die Prellzeit extrem lang geworden ist. Hm, das ist aber ein primitiver Entprellalgo wenn der stumpf eine Zeit X abwartet. Jeder von euch hat etwas auf dem Tisch liegen das seid Jahren trotz erheblicher Beanspruchung und reiner Softwareentprellung tatellos funktioniert. Die Tastatur. Bülent C. schrieb: > Wenn Platz da ist, immer mit einem Tiefpass und einem Schmitt-Trigger > dahinter entprellen. Sauber, effizient und kostet nicht die Welt. Aber bitte mit Röhrentechnik um ja nicht zu modern zu werden. Marek N. schrieb: > Wie lange hält denn eigentlich so ein Taster, wenn er bei jeder > Betätigung einen niederimpedanten MLCC kurzschließen muss? Das ist jetzt hoffentlich keine ernst gemeinte Frage ?
Michael K. schrieb: > Das ist jetzt hoffentlich keine ernst gemeinte Frage ? Für Threads, die den Begriff "Entprellkondensator" beinhalten, gilt automatisch BGB §118.
Dauergast schrieb: > Für Threads, die den Begriff "Entprellkondensator" beinhalten, gilt > automatisch BGB §118. Cooler Paragraph, nur leider nicht anwendbar weil es ja um Willenserklärungen und nicht um dusselige Fragen geht. Die Frage ob ein Kondensator, entladen über ~0R, also einen annähernd unendlich hohen Strom einen (Tastatur-) Taster beschädigt ist tatsächlich einer dieser dumme Fragen von denen man sagt es gäbe sie nicht.
Michael K. schrieb: > Die Frage ob ein Kondensator, entladen über ~0R, also einen annähernd > unendlich hohen Strom einen (Tastatur-) Taster beschädigt ist > tatsächlich einer dieser dumme Fragen von denen man sagt es gäbe sie > nicht. Das Problem ist, dass gefühlt 98% aller "Entprellungen" genauso gemacht werden: Kerko parallel zu Taster. Darum meine [s]dusselige[/s] ketzerische Frage.
Es gibt noch eine Alternative zum Kondensator am Taster: Ein Taster, welcher umschaltet. Beide Kontakte (Schließer und Öffner) an zwei NAND-Gatter (welche als Flipflop geschaltet werden - mit Pullups) und man kann sich den Kondensator sparen. Okay, den Kondensator braucht man dann wieder als Entkoppel-Kondensator für das Gatter-IC ;-) Einen solchen umschaltenden Taster kann man natürlich auch direkt an zwei µC-Pins anschließen und man bildet das Flip-Flop softwaremäßig nach. Dann gehts sogar mit Pin-Change-Interrupts: Interrupt auf Pin1 setzt ein Flag, Interrupt auf Pin2 setzt das Flag zurück. Die HW-Lösung ist natürlich hardware-aufwendig - dafür aber narrensicher. Die Software-Lösung verschwendet einen zusätzlichen Pin. Daher ist das obige wahrscheinlich nicht gerade praxisrelevant. Ich wollte es nur wegen der Vollständigkeit erwähnen :-)
40 Beiträge in 4 Tagen zum trivialsten Problem der Welt... Da fällt einem echt nichts mehr ein. Wenn man sich aber in der Realität bei vielen Geräten ansieht wie Drehgeber reagieren, könnte man schon der Meinung sein, die angehenden Ingenieure sollte wenigsten 1 Semester Vorlesung zum Thema haben.
Frank M. schrieb: > Einen solchen umschaltenden Taster kann man natürlich auch direkt an > zwei µC-Pins anschließen und man bildet das Flip-Flop softwaremäßig > nach. Dann gehts sogar mit Pin-Change-Interrupts: Interrupt auf Pin1 > setzt ein Flag, Interrupt auf Pin2 setzt das Flag zurück. Jetzt wird mir auch klar warum man mittlerweilen für einen Toster einen Controller mit 128Pins braucht.
Ja, man sieht leider in vielen kommerziellen Geräten, die Unsitte, daß der Programmierer denkt, ein Delay sei Entprellen. Und dann muß sich der Kunde damit rumärgern, wenn die Tasten und Drehgeber oxydieren, verschmutzen oder die Federkraft nachläßt. Nur weil es schlechte Eingabe-Libs gibt, ist das noch lange kein Grund für Hardwareentprellung. Die Programmierer kommen oft aus der PC-Programmierung und kennen daher nicht die Grundlagen Hardware naher Applikationen. Auch machen viel Eingabe-Libs ja nicht nur das bloße Entprellen, sondern bereiten die verschiedensten Ereignisse fertig auf, daß die Applikation nur noch darauf reagieren muß. Das Entprellen ist also nur eine ganz kleine, aber trotzdem wichtige Teilaufgabe, die verstanden und richtig implementiert werden muß. Mir stehen da regelmäßig die Haare zu Berge, wenn ich sehe, welch immenser Aufwand in der Mainloop getrieben wird, um nach der Hardwareentprellung die Ereignisse zu generieren und dabei vielleicht sogar auf minmale/maximale Durchlaufzeiten spekuliert wird. Und vor allem, wie dieser immense Aufwand bei jedem Projekt, jeder Taste von neuem getrieben wird. Nur weil man nicht einsehen will, daß eine separate Eingabe-Lib um Längen besser ist und einem einen Haufen Arbeit abnimmt.
Peter D. schrieb: > Nur weil man nicht einsehen will, daß eine > separate Eingabe-Lib um Längen besser ist und einem einen Haufen Arbeit > abnimmt. Sowas geht aber nur wenn die Anforderungen ähnlich sind. Viel wichtiger als eine Lib für solche trivialen Sachen wie Tastenabfragen ist ja wohl im Gesamtkontext festzulegen wie und wo das gemacht wird. Und das kann sich von Projekt zu Projekt schon grundlegend ändern. Einen Vorteil von Hardwareentprellung konnte ich auch noch nie und nirgends entdecken. > Auch machen viel Eingabe-Libs ja nicht nur das bloße Entprellen, sondern > bereiten die verschiedensten Ereignisse fertig auf, daß die Applikation > nur noch darauf reagieren muß. Solange es um die Tasten und Drehgeber geht gebe ich dir Recht. Da gibt es eine ziemlich gradlinige Programmierung wie bei PC-Programmen. Häufig kommen aber noch Endschalter, Relaiseingänge und vieles mehr hinzu. Da liegen die Verhältnisse dann doch schon etwas anders und eine universelle Lib würde zur Eierlegendenwollmilchsau verkommen. Ich jedenfalls habe noch kein Projekt gehabt bei dem die Tastenabfrage gegenüber dem restlichen Teil auch nur annähernd in den Breich von über 1% des Aufwands oder der nötigen Intelligenz gekommen ist.
tmp schrieb: > Einen Vorteil von Hardwareentprellung konnte ich auch noch nie und > nirgends entdecken. Der Vorteil ergibt sich doch schon, wenn im "System" kein µC vorhanden ist. Zudem kann die Entprellung bei schnelleren Signalen parallel zum µC-Programm ablaufen, ohne daß ein Eingang periodisch mit 10 kHz abgetastet werden muß. Einfach mal die Scheuklappen abnehmen und nach Bedarf entscheiden und nicht nach 'Religion' ;-)
Ein anderer wesentlicher Punkt wurde hier noch gar nicht angesprochen, nämlich die Tastendruckauswertung bei Systemen mit erhöhten Anforderungen bezüglich der funktionalen Sicherheit. Neben der Entprellung müssen hier ggf. noch Plausibilitätsbetrachtungen angestellt werden. Eine Hardwareentprellung mit Umschalter und Flipflop wäre zwar die beste Methode, um festzustellen, ob eine vollständige Schalter-/Tasterbewegung von Endstellung zu Endstellung stattgefunden hat. Allerdings fehlt hierbei ggf. eine zeitliche Überwachung, z.B. bei einem Schalter, der zwischen den Endstellungen festgeklemmt ist. Mit einer softwaremäßigen Auswertung der Taster-/Schalterkontakte kann man hingegen solche Plausibilitätsprüfungen wesentlich einfacher realisieren. Jedoch ist der Zertifizierungsaufwand für eine Softwarelösung ggf. beträchtlich höher. Benötigt man aber ohnehin den Microcontroller, dürfte sich der Mehraufwand in Grenzen halten.
Aber wenn man per Software entprellt, muss jeder Taster einzeln behandelt werden oder nicht? Und wenn man dann 30 Taster in seiner Schaltung hat, wird das softwaremäßig doch gar nicht mehr machtbar, da man zu wenige Timer (bzw. Interrupts) hat? Dann könnte man doch sagen, bei einer hohen Anzahl an Tastern (z.B. 30) ist eine Hardwareentprellung deutlich sinnvoller.
jogl schrieb: > Und wenn man dann 30 Taster in seiner Schaltung hat, wird das > softwaremäßig doch gar nicht mehr machtbar, da man zu wenige Timer (bzw. > Interrupts) hat? Nicht jeder kann sich den Luxus leisten, für jeden einzelnen Taster einen Timer zu verschwenden. Du hast doch auch nicht einen Koffer voller Armbanduhren bei dir, nur weil du mehrmals am Tag die Uhrzeit wissen möchtest.
Hi >Aber wenn man per Software entprellt, muss jeder Taster einzeln >behandelt werden oder nicht? Nein, die >Und wenn man dann 30 Taster in seiner Schaltung hat, wird das >softwaremäßig doch gar nicht mehr machtbar, da man zu wenige Timer (bzw. >Interrupts) hat? Du hast das Prinzip nicht verstanden. Es reicht 1 (in Worten ein ) Timer. MfG Spess
jogl schrieb: > Aber wenn man per Software entprellt, muss jeder Taster einzeln > behandelt werden oder nicht? Nein, auf Maschinenebene werden (beim 8-Bitter) 8 Taster in einem Rutsch behandelt, denn ein Byte hat nunmal 8 Bits. Das kostet bei Verwendung von 4 Registern weit unter 20 Prozessortakte je 20 ms. Werden die Daten im RAM gehalten, kostet es ein paar Takte mehr. Die Software-Entprellung mit einem Timer (der nebenher noch andere Dinge takten bzw. synchronisieren kann) kann bedeutend mehr Taster entprellen, als über die Pins an den Mikrocontroller angeschlossen werden können. Bei vielen Tastern nimmt man eh eine Matrix, die man natürlich auch in Software entprellen kann/muss/sollte. Selbst das Entprellen von über Schieberegisterketten eingelesener Taster ist in Software absolut kein Problem und kostet kaum Ressourcen, wenn man es richtig macht. ...
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.