Hallo, ich steige gerade in die µC Welt ein und bin noch am "rumspielen" um den Controller und die Elektronik drumrum kennenzulernen. Soweit funktioniert auch alles. Jetzt hat sich aber folgende Frage aufgetan: Welches sind die Vor und Nachteile der Entprellung mittels Schmitt Trigger und den diversen Softwarelösungen.? Die diversen Threads hierzu habe ich auch gelesen, und auch die sehr ausgereiften Lösungen gesehen/probiert/als Anregung genutzt. Ich habe mir zuerst eine (zugegebenermassen recht einfache) Softwarelösung implementiert, die funktioniert auch zufriedenstellend. Im Tutorial wurde dann die Lösung per Schmitt Trigger aufgezeigt, welche ich jetzt auch aufgebaut habe. Tut auch zufriedenstellend. Nun stellt sich mir die Frage der Vor und Nachteile. Da hier die Softwarvariante offensichtlich bevorzugt wird, muss das ja einen Grund haben. Vorteile Software: -leicht anpassbar an diverseste Schaltervarianten -schnell übertragbar da keine weitere Verdrahtung notwendig -funktioniert gleich bei verschiedendsten Controllervarianten Nachteile Software: -Wertvoller Speicherplatz geht für etwas drauf was auh in Hardare ginge -man verliert den Timer für andere Zwecke (soweit die Implementierungen die ich mir bisher zu Gemüte gefühert hab) Vorteile Schmitt Trigger: -keine weitere Software notwendig Nachteile Schmitt Trigger: -zusätzliche Bauteile und Verdrahtung notwendig -zusätzlicher Stromverbrauch Das ist jetzt das was ich jetzt erstemal sehe. Sicherlich gibt es da ja noch zig andere Gründe, Erfahrungswerte, Vor und Nachteile. Es ist mir klar, daswurde sicherlich shcon alles zig mal durchgekaut, aber ich habe bisher nur Threads zu den einzelnen Implementierungen gefunden, aber noch keine Gegenüberstellung. Daher wäre es nett wenn Ihr mich etwas erleuchten könntet. LG, Mitko
@ Mitko Rürup (eisfochel) >Vorteile Software: > -leicht anpassbar an diverseste Schaltervarianten > -schnell übertragbar da keine weitere Verdrahtung notwendig > -funktioniert gleich bei verschiedendsten Controllervarianten -keine zusätzliche Hardware nötig, Platz- und Kostenreduzierung >Nachteile Software: > - leicht erhöhter Speicherplatzverbrauch > - leicht erhöhte CPU-Last > -man verliert den Timer für andere Zwecke (soweit die Implementierungen > die ich mir bisher zu Gemüte gefühert hab) nicht wirklich, den Timer kann man auch für andere Sachen nutzen - nur für mässig schnelle Signale tauglich >Vorteile Schmitt Trigger: > -keine weitere Software notwendig - individuell an das Signal anpassbar - keinerlei CPU- und Programmlast >Nachteile Schmitt Trigger: > -zusätzliche Bauteile und Verdrahtung notwendig > -zusätzlicher Stromverbrauch kann man bei CMOS vergessen. MFG Falk
Mitko Rürup schrieb: > Nachteile Software: > -Wertvoller Speicherplatz geht für etwas drauf was auh in Hardare ginge > -man verliert den Timer für andere Zwecke (soweit die Implementierungen Falscher Ansatz. Speicher spielt heute keine Rolle. Externen Bauteile sind teuer. k.A. welche Implementierung du meinst, Tastenentprellen macht ein Timer idR problemlos neben seiner Hauptaufgabe.
Speicherplatz ist heute kein Problem mehr und eine gute Softwareentprellung frißt sowieso kaum Speicherplatz. Und ein extra Timer ist in den meisten Fällen auch unnötig, da bei Meßprozessen oft schon ein Timer alle 10...50msec einen Interrupt erzeugt um einen neuen Sample zu ziehen. Nichtsdestotrotz sollte eine µC-Schaltung aber Filter an den Ports für die Taster haben, um ESD und andere Störungen abzufangen.
Falk Brunner schrieb: > - nur für mässig schnelle Signale tauglich Danke für Deine Antworten. Verstehe ich das richtig, der Schmitt Trigger ist "langsamer"? Leider kann ich mir das Signal nicht anschauen, hab noch kein Oszi. Ich hatte mir das bisher so zusammengereimt das der sozusagen in Echtzeit ab erreichen der Schalt-Schwelle ein TTL-Signal rausgibt, und der Kondensator am Eingang die Verzögerung vorgibt. Was passiert dann wenn zwei Signale in zu schneller Abfolge kommen (z.Bsp. Wildestes drehen an nem Drehencoder)?
Prelli schrieb: > Speicherplatz ist heute kein Problem mehr und eine gute > Softwareentprellung frißt sowieso kaum Speicherplatz. Und ein extra > Timer ist in den meisten Fällen auch unnötig, da bei Meßprozessen oft > schon ein Timer alle 10...50msec einen Interrupt erzeugt um einen neuen > Sample zu ziehen. > > Nichtsdestotrotz sollte eine µC-Schaltung aber Filter an den Ports für > die Taster haben, um ESD und andere Störungen abzufangen. Ok, jetzt haste mich. Der letzte Satz sagt mir grad gar nichts. Hast Du mir bitte einen Link wo ich mich da einlesen kann?
me schrieb: > > Falscher Ansatz. > Speicher spielt heute keine Rolle. Externen Bauteile sind teuer. > k.A. welche Implementierung du meinst, Tastenentprellen macht ein Timer > idR problemlos neben seiner Hauptaufgabe. Ok danke, ich rechne mal die Zyklen aus die ich für das entprellen brauche. Ok, ist jetzt eher akademischer Natur, wills einfach wissen.
Mitko Rürup schrieb: > me schrieb: >> >> Falscher Ansatz. >> Speicher spielt heute keine Rolle. Externen Bauteile sind teuer. >> k.A. welche Implementierung du meinst, Tastenentprellen macht ein Timer >> idR problemlos neben seiner Hauptaufgabe. > > Ok danke, ich rechne mal die Zyklen aus die ich für das entprellen > brauche. Ok, ist jetzt eher akademischer Natur, wills einfach wissen. Ist unter "ferner liefen". Die PeDa Entprellung verbraucht (bei einer vernünftigen Taktfrequenz) weniger als 1 hunderstel Prozent Rechenzeit. Also völlig uninteressant. Die ~20 Taktzyklen alle ca. 10 Millisekunden hast du locker immer zur Verfügung.
> Verstehe ich das richtig, der Schmitt Trigger ist "langsamer"?
Deine alte Betrachtungsweise erscheint mir sinnvoller.
Widerstand und Kondensator sind langsam.
Der Schmitt Trigger wird nur gebraucht, um aus den langsam ansteigenden
Signalen wieder brauchbare Digital-Signale zu machen.
Mitko Rürup schrieb: > Falk Brunner schrieb: >> - nur für mässig schnelle Signale tauglich > > Danke für Deine Antworten. > > Verstehe ich das richtig, der Schmitt Trigger ist "langsamer"? Leider > kann ich mir das Signal nicht anschauen, hab noch kein Oszi. Darum gehts nicht. Ausserdem ist es umgekehrt. SW-Entprellung geht nur für mässig schnelle Signale. Wenn ich einen Taster an einem Eingang habe, dann kann kein Mensch einen Taster drücken und ihn 30 Millisekunden später schon wieder loslassen. So schnell bist du nicht. Habe ich also ein Eingangssignal, auf dem ich einen Wechsel von 0->1 feststelle und 5 Millisekunden später fällt dieses Signal wieder zurück 1->0, dann kann man davon ausgehen, dass dieses ein falsches Zurückfallen ist - ein Tastenpreller. Der Zeitunterschied zwischen der echten, durch Betätigung hervorgerufenen, Aktivität am Eingangspin und dem was mir die Mechanik antut ist groß genug, dass man das in Software leicht unterscheiden kann. Weiters ist der Zeitunterschied in einer Größenordnung, dass man ihn in SW leicht messen kann, ohne dass der µC nichts anderes mehr tut. Habe ich aber eine Welle die sich 1-tausend mal in der Sekunde dreht und bei jeder Umdrehung liefert mir ein Schalter ein Signal, dann hab ich ein Problem. Ich kann echtes Schaltsignal und das durch die Mechanik hervorgerufene falsche Signal nicht mehr unterscheiden. Die Zeitdifferenzen werden so gering, dass ich sie in Software nicht mehr (einfach) messen kann. Dann muss Hardware aushelfen.
Karl Heinz Buchegger schrieb: > Zeitdifferenzen werden so gering, dass ich sie in Software nicht mehr > (einfach) messen kann. Dann muss Hardware aushelfen. Frage wäre auch, wie gefährlich die eingehenden Signale sind. Wenn sich Buckel auf dem Schaltkreis bilden, hat die Schutzschaltung versagt. Dann sollte man einen "wartungsfreundlichen Aufbau" wählen.
Karl Heinz Buchegger schrieb: > Habe ich aber eine Welle die sich 1-tausend mal in der Sekunde dreht Die ist aber höllisch schnell, die Welle!
Ok, ich glaubich habs kapiert. An so Einsatzzwecke wie mit der rotierenden Welle hatte ich noch gar nicht gedacht. Klingt aber sehr sinnig. Dann bau ich jetzt mal die Entprellroutine in die Ausleseroutine für den Drehencoder ein. Vielen Dank für all die Antworten und Anregungen.
Knut Ballhause schrieb: > Die ist aber höllisch schnell, die Welle! FYI: http://www.jetcat.de/jetcatturbinen/helikopterturbinen.htm Christian
Knut Ballhause schrieb: > Karl Heinz Buchegger schrieb: >> Habe ich aber eine Welle die sich 1-tausend mal in der Sekunde dreht > > Die ist aber höllisch schnell, die Welle! Ich hab ja nicht gesagt, welchen Durchmesser sie hat :-)
>Ok, jetzt haste mich. Der letzte Satz sagt mir grad gar nichts. Hast Du >mir bitte einen Link wo ich mich da einlesen kann? Hier zum Beispiel: http://www.rotgradpsi.de/mc/etc/emv.html
Da kann/würde ich aber einen Geber verwenden, der nicht prellt. Z.B. eine Reflexlichtschranke oder einen Hallgeber. 60k U/min mit einem Mikrotaster zu messen dürfte schon mechanisch in Problemen resultieren.
Vorteile Software: - sehr hohe Bequemlichkeit: Einfach den Code einfügen, die gewünschte Ereignisabfrage aufrufen und dann die gewünschte Aktion ausführen. - sehr hohe Zuverlässigkeit: Unterdrückt nicht nur Prellen, sondern auch Störungen (EMV). Nachteile Software: - keine: Timer ist nicht verloren, kann noch andere Sachen machen. Code-, RAM-Verbrauch nicht signifikant, nichtmal beim ATtiny13. Peter
In den meisten Fällen hat der µC noch Platz im Flash, RAM und auch noch Rechenzeit frei. Es gibt aber halt auch einige seltene Fälle wo gerade die 2 Bytes RAM oder 20 Zyklen nicht mehr über sind. Meistens ist also die Softwarelösung einfach möglich und besser, weil die Resourcen frei sind, und für nicht genutzten Speicher gibt es kein Geld zurück.
@ Peter Dannegger (peda)
>Unterdrückt nicht nur Prellen, sondern auch Störungen (EMV).
Nö, das ist eine Illusion von Softwerkern. Es gibt genügend EMV-Effekte,
die an einer Softwareentprellung spielend vorbeiziehen, direkt oder
indirekt.
MFG
Falk
Falk Brunner schrieb: > Nö, das ist eine Illusion von Softwerkern. Na dann betriffts mich ja nicht, ich bin Hardwerker mit Nebentätigkeit Firmware. Falk Brunner schrieb: > Es gibt genügend EMV-Effekte, > die an einer Softwareentprellung spielend vorbeiziehen, direkt oder > indirekt. Ich meine das im Vergleich zu der "klassischen" falschen Abfrage per Interrupt, die fängt gerne mal EMI ein. Und dann wundert sich der Anfänger, wenn was passiert, obwohl er die Taste nichtmal berührt hat. Peter
Falk Brunner schrieb: > Nö, das ist eine Illusion von Softwerkern. Es gibt genügend EMV-Effekte, > die an einer Softwareentprellung spielend vorbeiziehen, direkt oder > indirekt. Du meinst die mit den internen Pullups? Wenns denn sein muss, löte ich 270 Ohm dran und dann passiert da garnüscht.
@ Peter Dannegger (peda) >Ich meine das im Vergleich zu der "klassischen" falschen Abfrage per >Interrupt, die fängt gerne mal EMI ein. Ok, da geh ich mit. >Du meinst die mit den internen Pullups? Nein, ich meine, dass man EMV-Probleme nur in wenigen Fällen durch Software lösen kann. Wenn EMV in die Resetleitung hustet, nützt dir die tollste Softwareentprellung nix. Und noch drei Dutzend andere Effekte, die mir spontan nicht einfallen. MfG Falk
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.