Hallo, nach http://www.mikrocontroller.net/articles/Entprellung#Einfacher_Taster sollte sich bei geschlossenem Schalter der Kondensator über R2 entladen. Das tut er bei mir aber nicht vollständig: ich messe jeweils eine unterschiedliche Spannung zwischen 1,8-2,8V an ihm, je nach Messung/Test. Entsprechend liegt am Ausgang des Schmitt Triggers Murks an. Dimensioniert ist die Schaltung wie im verlinkten Artikel beschrieben: R1 10kOhm R2 22kOhm C1 1µF (Elko 50V) VCC 5V IC Texas Instruments 34CCP1K E4 SN74HC14N R1, R2 und C1 habe ich gemessen. Die passen soweit (10%). Einen Abblockkondensator habe ich bei meinen Tests keinen verwendet. Bei VCC=3,3V funktioniert die Schaltung, ich brauche aber 5V. Wenn ich allerdings vor den Eingang des Schmitt Triggers noch einen 15kOhm Widerstand einfüge, entlädt sich der Kondensator zumindest soweit (<0,08V), daß der Schwellwert des Triggers unterschritten wird und dieser sauber schaltet. Nach https://www.youtube.com/watch?v=tmjuLtiAsc0 aufgebaut, also mit R1=10k, R2=1k und C1=10µF, funktioniert die Schaltung bei 5V. Noch was: in dem Video wird erwähnt, R2 müsse sehr viel kleiner sein als R1 (R2 << R1). Beim verlinkten Artikel ist jedoch R2 > R1! Woran liegt es, daß C1 nicht tief genug entlädt? Am Unterschied R1/R1? Grüße, Markus
:
Bearbeitet durch Moderator
Irgendwie passen deine Messungen nicht zusammen. Wenn bei gedrücktem Taster am Eingang um die 2,3V zu messen sind, ist entweder der Taster hochohmig (~R1) oder es fließen durch R2 ca. 100µA nach GND - d.h. SN74HC14N ist kaputt (Ii<±1µA), Lötrückstände o.ä. Da hülfe auch ein zusätzlicher Rx in Serie zum Eingang nicht. Wie hast du denn den 15k-Widerstand angeschlossen - vom Eingang nach GND oder tatsächlich in Serie? Welcher Spannungsabfall tritt an R2 auf? Normalerweise hängt das Verhältnis R1/R2, so wie im Artikel beschrieben, nur vom gewünschten Zeitverhalten ab - "(R2 << R1)" stimmt also nicht generell.
Hallo Nun, man kann das Problem auf verschiedene Art und Weise angehen. Eine davon wäre Beispielsweise die Lade/Entladezeit deines Kondensators zu berechnen. Tau = R * C Tau = 22k * 1uF = 22ms T = Tau * 5 = 22ms * 5 = 110ms Sogesehen braucht es also theoretisch 110ms um den Kondensator vollständig zu laden bzw zu entladen. Hier liegt allerdings die Benonung auf THEORETISCH. Hier kommen dann Einflüsse wie Kondensatortyp usw ins Spiel. Zunächst einmal: Ein Elko ist hier in meinen Augen nicht richtig. Soweit ich das hier im Forum richtig verstanden habe, sind Elkos eher Träge, eignen sich also nicht für schnelles Auf/Entladen. Ich schlage dir vor: - Entweder du nimmst einen anderen Kondensator (Keramik?) - Du machst R2 kleiner. Ersetz die 22kOhm durch einen kleineren Widerstand und versuchs dann noch einmal. Eine weitere Frage: Wohin gehst du mit dem Taster? Falls du mit dem Teil auf einen uC gehst, würde ich das ganze Softwaremässig entprellen. Hoffe ich konnte dir etwas weiterhelfen Gruss
Markus schrieb: > Das tut er bei mir aber nicht vollständig Mach doch mal ein oder zwei leserliche Foto von deinem Aufbau (300kB reichen da völlig). Denn wenn die Schaltung so aufgebaut ist, wie sie gezeichnet ist, dann funktioniert sie. > Noch was: in dem Video wird erwähnt, R2 müsse sehr viel kleiner sein als > R1 (R2 << R1). Beim verlinkten Artikel ist jedoch R2 > R1! Das ist irrelevant. San Lue schrieb: > Soweit ich das hier im Forum richtig verstanden habe, sind Elkos eher > Träge, eignen sich also nicht für schnelles Auf/Entladen. Da hast du aber grundsätzlich was falsch verstanden. In dem Zeitbereich, der hier interessiert, sind die auf jeden Fall "schnell" genug. Erst, wenn es mal Richtung 100kHz geht, also t=10us, dann muss man sich so einen Elko mal näher anschauen...
:
Bearbeitet durch Moderator
> San Lue schrieb: >> Soweit ich das hier im Forum richtig verstanden habe, sind Elkos eher >> Träge, eignen sich also nicht für schnelles Auf/Entladen. > Da hast du aber grundsätzlich was falsch verstanden. In dem Zeitbereich, > der hier interessiert, sind die auf jeden Fall "schnell" genug. Erst, > wenn es mal Richtung 100kHz geht, also t=10us, dann muss man sich so > einen Elko mal näher anschauen... Markus schrieb: > Hallo, > > das Problemchen löst Du ganz einfach, indem Du dem Taster parallel jeweils einen 100 nF-Kondenstator direkt + 22 kOhm Widerstand nach MASSE legst! Da in Deiner Schaltung der Widerstand direkt am Invert-Eingang liegt und dieser ja Spannung führt - aber der Widerstand zu groß ist, um den Pegel gegen NULL zu ziehen, kann sich dieser Kondensator dort natürlich nicht vollständig entladen. Nimm den Widerstand da raus, dann "nullt" sich auch dein Taster bzw der Inv-Eingangspin am IC. bzw. leg zumindest PARALLEL zum Taster ODER BESSER: in Reihe so 22 Kohm-Widerstand nach Masse. Musst das testen, ist aber simpel zu verstehen. Gruss
IC Texas Instruments 34CCP1K E4 SN74HC14N als Anmerkung vielleicht noch: Tausche mal den IC SN 74HC14N gegeb einen einfachen TOSHIBA CD4014 aus wirst sehen, das Entprell-Problem löst sich schon auf... Gegebenfalles gehen auch: MOTOROLA MC147414 oder VALVO V 4014, oder RCA RCD40014 Deine Version aus der SN-Reihe hat das Problem vermutlich, dass da entweder nichtgenutzte EIn/Ausgänge den IC intern zum Schwingen anregen, oder aber dieser bereits magnetisch aufgeladen ist und daher dieses Problem macht. Diese MOS-ICs sollte man nur mit geerdeten Handschuhen anfassen! Probier mal die genannten - die sind ja Bau/Pinkompatible Typen Hoffe der Tip hilft weiter Gruss aus Aachen
ZeilenTrafo schrieb: > Da in Deiner Schaltung der Widerstand direkt am Invert-Eingang > liegt und dieser ja Spannung führt - aber der Widerstand zu groß ist, um > den Pegel gegen NULL zu ziehen, kann sich dieser Kondensator dort > natürlich nicht vollständig entladen. Woher beziehst du deine Weisheiten? Wie gesagt, bei funktionierendem SN74HC14 treten maximal 1µA (typ. 0,1nA) als Input current auf - ist ja kein TTL wie z.B. SN74LS14 mit Iil=-400µA.
(R2 << R1) schrieb: > ZeilenTrafo schrieb: >> Da in Deiner Schaltung der Widerstand direkt am Invert-Eingang >> liegt und dieser ja Spannung führt - aber der Widerstand zu groß ist, um >> den Pegel gegen NULL zu ziehen, kann sich dieser Kondensator dort >> natürlich nicht vollständig entladen. > > Woher beziehst du deine Weisheiten? Wie gesagt, bei funktionierendem > SN74HC14 treten maximal 1µA (typ. 0,1nA) als Input current auf - ist ja > kein TTL wie z.B. SN74LS14 mit Iil=-400µA. Weisheiten? Warum? Wie kommst darauf? Jeder Elektroniker weiß, daß man Tasten mit nem Kondensator entprellt. Und reicht das nicht aus, benutzt man dazu einen Widerstand nach NULL, also Masse als "Entladehilfe"! Entweder hast den ersten Beitrag nicht verstanden, oder suchst du hier Krach? Jaklar, Du kannst 1µA - oder gar 1 nA messen!! versteh schon - träum mal weiter! Diese Angaben sind illusorisch - auch wenn sowas in Datenblättern zum IC steht.. Jeder weiß, der Ahnung hat, dass es bauartbedingte grobe Abweichungen der Daten gibt, gerade bei diesen 74xxxx/40xxx Typen, die genug für Probleme sorgen können, und ein Austausch solcher ICs leichter ist, als sich mit irgendwelchen nA-Messparametern rumschlagen zu müssen (woher auch immer Deine Angaben beziogen hast.) Aber wenn hier wer mit solchen Daten umsich wirft, tut sich grob gesagt hier verdammt WICHTIG! Musste dir gefallen lassen. Ich hab das Problem des Fragenden verstanden und lediglich meine jahrelangen Erfahrungen versucht weiterzugeben. Du magst es nicht, wenn DU nicht Recht behälst, stimmts? Wirste da gleich agro? Könnte man annehmen. Was solls, geh ich nicht weiter darauf ein. Bringt nichts. Zeilentrafo
ZeilenTrafo schrieb: > Deine Version aus der SN-Reihe hat das Problem vermutlich, dass da > entweder nichtgenutzte EIn/Ausgänge Nicht genutze Eingägne MÜSSEN bei allen CMOS Bausteinen beschaltet werden. Sonst floatet der solange, bis etwa Vcc/2 anliegen und beide Eingangstransistoren leiten. Fazit: hohe Stromaufnahme und dubioses Verhalten... ZeilenTrafo schrieb: > Da in Deiner Schaltung der Widerstand direkt am Invert-Eingang liegt > und dieser ja Spannung führt Wieso sollte ein CMOS Eingang Spannung ausgeben? ZeilenTrafo schrieb: > Jeder weiß, der Ahnung hat, dass es bauartbedingte grobe Abweichungen > der Daten gibt, gerade bei diesen 74xxxx/40xxx Typen, die genug für > Probleme sorgen können Ja klar, man darf natürlich nicht TTL und CMOS gleichsetzen und beliebig austauschen. Aber diese strunzeinfache und langsame Inverterschaltung hier muss jedes der CMOS-IC können. > (woher auch immer Deine Angaben beziogen hast.) Aus dem Datenblatt? Ich warte noch immer auf ein Foto der Schaltung. Bis dahin kann man nur raten (=im Nebel stochern) statt raten (=Hilfe geben)...
:
Bearbeitet durch Moderator
ZeilenTrafo schrieb: > Jeder Elektroniker weiß, daß man Tasten mit nem Kondensator entprellt. Nö. Ich bin Elektroniker und Kondensatoren kommen mir schon lange nicht an die Tasten. Steuerungen baut heutzutage kaum noch einer als IC-Grab auf. Man nimmt einen MC um schneller und flexibler zu sein und der macht das bischen Entprellen nebenbei.
ZeilenTrafo schrieb: > Tausche mal den IC SN 74HC14N gegeb einen einfachen TOSHIBA CD4014 aus > wirst sehen, das Entprell-Problem löst sich schon auf... Gegebenfalles > gehen auch: 74HC14 != CD4014 Der CD4014 ist ein 8 Bit Schieberegister und der 74HC14 ein Schmitttrigger. Das austauschen koennte etwas problematisch sein.
ZeilenTrafo schrieb: > Jeder Elektroniker weiß, daß man Tasten mit nem Kondensator entprellt. so ein Quatsch. Jeder Elektroniker weiß, dass zu R-C noch mindestens ein R gehört. Dazu noch der Pullup, achja, die Schaltung war schon verlinkt. Nur die Deppen von Pollin schalten Kondensatoren parallel zu den Tastern. Und jeder Simpel macht es nach. Im Übrigen hat Peter D. recht, wer tut sich noch so ein Bauteilgrab an?
Hallo, Foto siehe Anhang. Das freihängende rote Kabel dient als Taster und schließt beim Verbinden mit GND. Vom Schmitt Trigger nutze ich nur einen Ein/Ausgang, die anderen hängen in der Luft. Hatte letztens gelesen, im Gegensatz zu TTL sei das bei CMOS so i.O. Da ließ ich mir wohl einen Bären aufbinden. Der Schmitt Trigger Ausgang hängt an einem Port Expander (MCP23S08), um u.a. Tastendrücke Interrupt-gesteuert zu verarbeiten, was soweit auch funktioniert. Zum Pollen meine ich im µC keine Zeit verbrauchen zu können, da andere zeitkritische Aufgaben auf ihn warten (sofern meine Vorstellungen so überhaupt umsetzbar sind, andere Geschichte). Vielleicht bewerte ich das mangels Erfahrung auch über. Der µC (nicht im Bild) und die beiden Breadboards hängen an derselben Stromversorgung, trotzdem habe ich VCC und GND durchverbunden. Die grüne LED wird von der ISR gesteuert, um Tastendrücke anzuzeigen. Hatte vergessen zu erwähnen: C1 entlädt sich sauber, wenn der Schmitt Trigger Eingang nicht angeschlossen ist (langes grünes Kabel abgezogen). Ich habe nochmal gemessen: Ohne dem zusätzlichen 15kOhm Widerstand - also bei der Schaltung wie verlinkt - liegt bei geschlossenem Schalter 2,5V an C1 an (entlädt sich nicht ausreichend), nicht immer aber oft. An R2 flimmert dann die Spannungsanzeige des Multimeters. Aus dieser Zustand kommt die Schaltung durch Tasterbetätigung nicht mehr selbstständig heraus, erst nach separatem Entladen (Überbrücken) des Kondensators. Grüße, Markus
Markus schrieb: > Vom Schmitt Trigger nutze ich nur einen Ein/Ausgang, die anderen hängen > in der Luft. Hatte letztens gelesen, im Gegensatz zu TTL sei das bei > CMOS so i.O. Da ließ ich mir wohl einen Bären aufbinden. Ganz schlechte Idee, es ist genau umgekehrt. Bei TTL zieht der Multiemittertransistor den Eingang schon von alleine auf High. CMOS ist so hochohmig da duempelt der Eingang irgendwo rum zwischen 0 und 1. Also lege mal die nicht benutzten Eingaenge auf 0 oder 1 und spendier dem IC einen Abblockkondensator.
Markus schrieb: > Foto siehe Anhang. Oje. a) ALLE Eingänge eines CMOS-IC gehören an eine definierte Spannung, also auch die 5 unbenutzen Gatte an GND. b) Markus schrieb: > Einen Abblockkondensator habe ich bei meinen Tests keinen verwendet. Man verwendet IMMER Abblockkondenstaoren, auch wenn das mit dem Problem wohl nichts zu tun hat. c) Markus schrieb: > Dimensioniert ist die Schaltung wie im verlinkten Artikel beschrieben: > R1 10kOhm > R2 22kOhm > C1 1µF (Elko 50V) Scheiss Wiki. Die Berechnung dort ist kompliziert, geht aber von falschen Annahmen aus. Die Prellzeit (von dort konservativ angenommenen 10ms, 5ms täten es auch, aber egal) eines Tasters ist die ganze Zeit, in der der Kontakt zwischen EIN und AUS wechselt. RC muss während EINER PHASE DER PRELLZEIT, also nur während der Zeitdauer eines EIN-Zustandes den C langsamer aufladen, als die Hysterese, und nicht die Schwellspannung, des Schmitt-Treiggers beträgt, beim 74HC14 also ca. 0.1 x VCC. R1 sollte wesentlich kleiner als R2 sein, damit (zumindest beim symmetrischen HC) die Entlade- und die Aufladezeit etwa gleich sind, also z.B. 2k2 und 22k. Glücklicherweise berechnet das Wiki immer zu grosse Werte, so daß es funktioniert, wenn man nicht wie im Wiki im letzten Satz den 74LS14 nimmt, der nämlich einen viel zu hohen Eingangsstrom hat um ihn vernachlässigen zu können. Da braucht man 120 Ohm statt 22k. Markus schrieb: > C1 entlädt sich sauber, wenn der Schmitt > Trigger Eingang nicht angeschlossen ist (langes grünes Kabel abgezogen Die 15k sind nicht wichtig aber auch nicht schädlich. Derzeit spricht einiges dafür, daß du einen 74LS14 statt eines 74HC14 verwendest. Aber vielleicht sollte man es auch mit Abblockkondenstaor direkt zwischen VCC und GND des iC probieren nach dem manalle ungenutzen Eingänge an GND gelegt hat.
Hallo, ich hab bzgl. CMOS/TTL und offener Eingänge noch mal nachgelesen. Ja, genau anders rum. Die unbenutzen Eingänge des Schmitt Triggers liegen jetzt an GND: C1 entlädt sich nun immer sauber, kein Spannungsflimmern an R2 mehr. Es handelt sich schon um einen 74HS14, steht so drauf. Abblockkondensator habe ich noch keinen da, kommt aber sicher. Das hat sich mir im Gegensatz zu offenen Eingängen schnell eingeprägt. Bis zur nächsten Bestellung muß sich aber noch etwas mehr ansammeln, damit sich das Porto rentiert. Bzgl. R1=2k2: ich hab' kein Oszi hier, um die Zeitverläufe nachzuvollziehen. Ob ich mit einem per USB an PC angeschlossen Multimeter diese sehen kann? Muß ich mal verproben. Das Multimeter habe ich erst seit kurzem. Vielen Dank soweit, auch für die Geduld mit meinen Anfängerfehlern, und viele Grüße, Markus
Markus schrieb: > Ob ich mit einem per USB an PC angeschlossen Multimeter diese sehen > kann? Nein. Zu langsam bzw. zu schnell...
Markus schrieb: > Zum Pollen meine ich im µC keine Zeit verbrauchen zu > können, da andere zeitkritische Aufgaben auf ihn warten Ein Erwachsener braucht typisch 300ms zum Drücken und 300ms zum Loslassen. Tasten abfragen/entprellen ist also in keinster Weise zeitkritisch (<1% CPU-Last).
Hallo Peter, Peter Dannegger schrieb: > Ein Erwachsener braucht typisch 300ms zum Drücken und 300ms zum > Loslassen. dann bin ich nicht erwachsen :-) . Ich schaffe, ohne mich sonderlich anzustrengen, locker 6x pro Sekunde einen Taster zu drücken. 600ms pro Anschlag scheint mir schon sehr langsam. Beim Einstellen von Werten (hoch- bzw. runterstellen) tippe ich für gewöhnlich mehrmals hintereinander einzeln, wenn mir der Key-Repeat-Delay oder die Key-Repeat-Rate zu langsam oder gar nicht vorhanden ist. > Tasten abfragen/entprellen ist also in keinster Weise zeitkritisch (<1% > CPU-Last). Ja, aber was passiert bei anderen Aufgaben, die in Summe entsprechend Zeit brauchen? Die kleinen µCs können ja kein Multi-Threading und sind keine Number-Cruncher. Dann verpaßt man Anschläge, wenn man pollt. Oder man baut in seinen übrigen Code Aufrufe an das Keyboard-Polling mit der dazugehörigen Folgeverarbeitung ein => Spaghetti-Code, klares No-Go. Polling ginge auch Timer-Interrupt-gesteuert und mit einem Buffer, oder statt Buffer besser per Event-Handling, Queue und Listener (auch für andere Aufgaben als Keyboard-Input) eine externe Flußkontrolle gebaut (Hollywood-Principle: don't call us, we call you), statt die Anwendung zyklisch und an geeigneten Stellen nach Input suchen zu lassen. Die Anwendung hat ja anderes zu tun (Fachkram), als sich um die Kritikalität von User-Input zu kümmern (Technikkram): Separation of Concerns. Dann wäre es egal, wie lange der Rest braucht. Es ginge bei ausreichend groß dimensionierter Queue zumindest kein Anschlag verloren. Hmm, klingt auch ok. Muß ich mir noch überlegen. Queue und Dingens hab' ich ja schon alles am Laufen, bisher bzgl. Keyboard halt über HW-Interrupt gefüttert. Interrupt-gesteuerte Keyboard-Treiber - nicht Timer-Interrupt-gesteuert sondern per Hardware - und Software-Entprellen beißen sich, oder? Grüße, Markus
Markus schrieb: > Es handelt sich schon um einen 74HS14, steht so drauf. Sowas gibts nicht. Schau nochmal. Mach notfalls ein Foto. XL
Markus schrieb: > Die kleinen µCs können ja kein Multi-Threading Falsch > Dann verpaßt man Anschläge, wenn man pollt. Nur wenn man sich dämlich anstellt. > Polling ginge auch Timer-Interrupt-gesteuert Was heißt hier "ginge"? Zum Pollen von Tasten nimmt man genau einen Timerinterrupt, nicht anders. > Anwendung hat ja anderes zu tun (Fachkram), als sich um die Kritikalität > von User-Input zu kümmern (Technikkram): Separation of Concerns. > Dann wäre es egal, wie lange der Rest braucht. Es ginge bei ausreichend > groß dimensionierter Queue zumindest kein Anschlag verloren. Das ist hier kein Buzzword-Bingo. Buffer solltest du genau einen brauchen. Wenn ein Gerät auf einen Tastendruck so lange nicht reagiert, daß der Anwender noch einen weiteren Tastendruck schafft, dann ist es zu langsam. Die Nutzer werden es nicht akzeptieren. > Interrupt-gesteuerte Keyboard-Treiber - nicht Timer-Interrupt-gesteuert > sondern per Hardware - und Software-Entprellen beißen sich, oder? Richtig. Nur Deppen hängen einen prellenden Taster direkt an einen Eingang der Interrupts auslöst. Wenn Interrupt, dann muß in Hardware entprellt werden. Aber wie diverse Vorredner schon sagten, ist es wesentlich sinnvoller, im Timerinterrupt zu pollen und die Entprellung in Software zu machen. Das kostet vielleicht 20..100 CPU-Zyklen und muß ja nur ca. 100 mal pro Sekunde gemacht werden. Auch ein lahmer µC mit 1MHz Takt schafft aber 10.000 Zyklen pro 1/100stel Sekunde. XL
Markus schrieb: > Ja, aber was passiert bei anderen Aufgaben, die in Summe entsprechend > Zeit brauchen? Die kleinen µCs können ja kein Multi-Threading Können sie, die Frage ist, ob auch der ungelernte Hobbyprogrammierer es kann. Man baut einen Zeitgeber-Interrupt (keinen Pin-Change-Interrupt)
Markus schrieb: > Die kleinen µCs können ja kein Multi-Threading Man muss nur so programmieren, dass die Hauptschleife mindestens 1 mal pro 10ms durchlaufen wird, dann kann man ganz einfach per Polling entprellen... Das haben wir schon im Beitrag "Re: Arduino UNO | IF Schleife |" diskutiert. Hier im Beitrag "Re: LED blinkt während Programmablauf" blinken sogar 3 LED komplett unabhängig voneinander. Und ich könnte da ohne jeglichen Aufwand zusätzliche aufgaben in der Hauptschleife unterbringen. Z.B. auch eine Tasterentprellung. Diese Funktion rufe ich dann einfach nur alle 30ms (oder so) auf:
1 | |
2 | :
|
3 | :
|
4 | // Und hier das tun, was sonst noch zu tun ist.
|
5 | if (tiAkt>tiEntprell) { // Zeit für nächsten Aufruf der Entprellung? |
6 | tiEntprell=tiAkt+700; // nächsten Zeitpunkt ausrechnen |
7 | TastenEntprellen(); // Entprellroutine vom PeDa aufrufen |
8 | }
|
9 | |
10 | // Aber nichts, womit unnötig Zeit verplempert wird!
|
11 | // Also kein delay() oder nischtnutzige Zählschleifen.
|
12 | :
|
13 | :
|
Oder umgedreht: Ist bei dir ein delay() oder wait() im Programm? Dann ist das Programm noch nicht fertig!
Axel Schwenke schrieb: > Nur Deppen hängen einen prellenden Taster direkt an einen > Eingang der Interrupts auslöst. Wenn Interrupt, dann muß in Hardware > entprellt werden. Seh' ich anders. Da man hier immer nur diese Aussage zu lesen bekommt, ohne Erklärung warum, würdest Du das bitte mal machen. Axel Schwenke schrieb: > Aber wie diverse Vorredner schon sagten, ist es > wesentlich sinnvoller, im Timerinterrupt zu pollen... Das möchte ich natürlich nicht, mit meiner obigen Provokation, außer Frage stellen!
Markus schrieb: > dann bin ich nicht erwachsen :-) . Ich schaffe, ohne mich sonderlich > anzustrengen, locker 6x pro Sekunde einen Taster zu drücken. Ich meinte nicht, was man schaffen kann, sondern wie lange man typisch auf einer TV-FB, an der Waschmaschine, Kaffemaschine und sonstigen Geräten drückt. Probiers aus, schreib ein kleines Meßprogramm auf dem AVR, häng eine Taste ran und laß verschiedene Personen drücken. Daß eine Gamer PC-Tastatur schneller sein muß, ist klar.
Teo Derix schrieb: > Seh' ich anders. > Da man hier immer nur diese Aussage zu lesen bekommt, ohne Erklärung > warum, würdest Du das bitte mal machen. Warum ? Du willst es doch sowieso nicht verstehen. Denn es wurde schon tausende mal geschrieben, und dein Betonkopf ignoriert es offenkundig.
Peter Dannegger schrieb: > Markus schrieb: >> dann bin ich nicht erwachsen :-) . Ich schaffe, ohne mich sonderlich >> anzustrengen, locker 6x pro Sekunde einen Taster zu drücken. > > Ich meinte nicht, was man schaffen kann, sondern wie lange man typisch > auf einer TV-FB, an der Waschmaschine, Kaffemaschine und sonstigen > Geräten drückt. Auch schlechte Taster, prellen nur in seltenen Fällen, länger als 20-30mS. Bei einer sicheren Entprellzeit von 50mS, sind wir dann schon bei >20x, um was zu verpassen.
MaWin schrieb: > Warum ? > Du willst es doch sowieso nicht verstehen. Wie könnte ich, wenn es keiner erklärt. Ich bin halt ein Ungläubiger :) MaWin schrieb: > Denn es wurde schon tausende mal geschrieben, > und dein Betonkopf ignoriert es offenkundig. Wo? Wenn dann bin ich ein Blindschädel :) PS: Ich hätte doch dazu schreiben sollen "MaWin, wir hatten das schon mal! Eine Begründung konntest/wolltest Du da auch nicht geben" PPS: das "-1" ist NICHT von mir!
:
Bearbeitet durch User
Teo Derix schrieb: > Axel Schwenke schrieb: >> Nur Deppen hängen einen prellenden Taster direkt an einen >> Eingang der Interrupts auslöst. Wenn Interrupt, dann muß in Hardware >> entprellt werden. > > Seh' ich anders. Warum? Erkläre das doch bitte auch. > Da man hier immer nur diese Aussage zu lesen bekommt, ohne Erklärung > warum, würdest Du das bitte mal machen. Ist doch banal. Jedes Prellen des Tasters löst dann einen Interrupt aus. Du bekommst also für ein einmaliges Ereignis "Nutzer drückt Taste" u.U. Hunderte Interrupts. Und falls du nach dem ersten Interrupt die Interruptquelle für deine Entprellzeit sperrst, dann erkennst du nicht, wenn es gar keine richtige Betätigung war, sondern nur ein Spike auf der Leitung. Einen Timer brauchst du übrigens trotzdem (ich unterstelle mal daß du nicht so dämlich bist, in der ISR für die Dauer der Entprellzeit zu warten). Ach ja. Es gibt doch einen Spzialfall, wo man tatsächlich einen prellenden Kontakt direkt einen Interrupt auslösen läßt. Das ist dann, wenn der µC im Tiefschlaf auf eine Tastenbetätigung warten soll. Der (Pin Change) Interrupt weckt dann den µC auf. Die Erkennung ob wirklich eine Taste gedrückt wurde (und welche) macht dann aber wieder eine Polling-Routine im Timerinterrupt. XL
Axel Schwenke schrieb: > Ist doch banal. Jedes Prellen des Tasters löst dann einen Interrupt aus. > Du bekommst also für ein einmaliges Ereignis "Nutzer drückt Taste" u.U. > Hunderte Interrupts. Na endlich mal einer der das anspricht > Und falls du nach dem ersten Interrupt die Interruptquelle für deine > Entprellzeit sperrst, und gleich noch die Erklärung wie's doch geht > dann erkennst du nicht, wenn es gar keine richtige > Betätigung war, sondern nur ein Spike auf der Leitung. Erkennst man auch nicht ohne Interrupt, wenn man den Zustand der Taste nicht nochmals nach der Entprellzeit überprüft! Naturlich bekommt man beim Pollen nicht jeden Dreck mit und kann sich das meist sparen. > Einen Timer > brauchst du übrigens trotzdem Hab NIE etwas Anderes behautet! > (ich unterstelle mal daß du nicht so > dämlich bist, in der ISR für die Dauer der Entprellzeit zu warten). DANKE :) Axel Schwenke schrieb: > Ach ja. Es gibt doch einen Spzialfall, wo man tatsächlich einen > prellenden Kontakt direkt einen Interrupt auslösen läßt. Das ist dann, > wenn der µC im Tiefschlaf auf eine Tastenbetätigung warten soll. Ein paar mehr gibt's da schon, wenn auch nicht wirklich für Usereingaben. PS: Um's nochmals zu betonen: Auch ich halte das Tastenabfragen mittels Interrupt für seltenst sinnvoll. Mich störten nur die hier immer wieder auftauchenden, dogmatischen Aussagen wie: Verboten, darf man nicht, funktioniert nicht...
Hallo, Axel Schwenke schrieb: > Markus schrieb: >> Es handelt sich schon um einen 74HS14, steht so drauf. > > Sowas gibts nicht. Schau nochmal. Mach notfalls ein Foto. Tippfehler, sollte 74H_C_14 heißen. > Markus schrieb: >> Die kleinen µCs können ja kein Multi-Threading > > Falsch Ok, ich meinte preemptives Multi-Threading. Bei kooperativem Multi-Threading muß der Entwickler u.U. eher auf den reibungslosen Ablauf seiner Software achten, weshalb er m.E. mehr Geschick benötigt, keinen Spaghetti-Code zu produzieren. > Das ist hier kein Buzzword-Bingo. Darf ich die Dinge nicht beim Namen nennen? Kümmerst Du Dich in Deinen Anwendungen nicht darum, die jeweiligen Aufgaben, die inhaltlich nichts miteinander zu tun haben, voreinander abzuschotten? Das macht m.E. auch bei kleineren Anwendungen Sinn, weil es - geschickt angewendet - immer demselben einheitlichen Schema folgt und man dadurch leichter den Überblick bewahrt. Dann kann man auch viel leichter Funktionalität aus der einen Anwendung in eine andere übernehmen. Ich sollte vielleicht erwähnen, daß ich aus der Informatikwelt stamme, überwiegend Frameworks schreibe und nutze, bisher aber nichts Hardware-nah mit mehr oder weniger begrenzten Resourcen entwickelt habe. Ob sich meine Vorstellungen in der Welt der Microcontroller umsetzen lassen, wird sich zeigen. Lothar Miller schrieb: > Hier im > Beitrag "Re: LED blinkt während Programmablauf" blinken sogar 3 LED > komplett unabhängig voneinander. Ja, sowas schwebt mir vor, wenn ich nicht per Interrupt Tastatureingaben verarbeite. Nur würde ich dann das Entprellen, Buffern (oder Enqueuen) und die Zeitsteuerung etc. noch wegkapseln. > Oder umgedreht: Ist bei dir ein delay() oder wait() im Programm? Dann > ist das Programm noch nicht fertig! Einen delay/wait verwende ich nur beim Initialisieren. Die typischen Kardinalfehler mit delay/wait kenne ich. Grüße, Markus
Teo Derix schrieb: > Axel Schwenke schrieb: >> ... falls du nach dem ersten Interrupt die Interruptquelle für deine >> Entprellzeit sperrst, > > und gleich noch die Erklärung wie's doch geht Wie es nicht richtig gut, aber wenigstens ein bisschen geht. >> dann erkennst du nicht, wenn es gar keine richtige >> Betätigung war, sondern nur ein Spike auf der Leitung. > > Erkennst man auch nicht ohne Interrupt, wenn man den Zustand der Taste > nicht nochmals nach der Entprellzeit überprüft! Genau das macht ja die Entprellroutine. Sie prüft ob der Zustand der Leitung eine gewisse Mindestzeit stabil bleibt. Und damit erledigt sie das Problem von Spikes/Glitches gleich mit. > Naturlich bekommt man beim Pollen nicht jeden Dreck mit und kann sich > das meist sparen. Kann man nicht. Weil man ja entprellen will bzw. muß. >> Ach ja. Es gibt doch einen Spzialfall, wo man tatsächlich einen >> prellenden Kontakt direkt einen Interrupt auslösen läßt. Das ist dann, >> wenn der µC im Tiefschlaf auf eine Tastenbetätigung warten soll. > > Ein paar mehr gibt's da schon, wenn auch nicht wirklich für > Usereingaben. Butter bei die Fische! Was sind denn nun die besonderen Anwendungen, die es erlauben/erfordern einen prellenden Kontakt Interrupts auslösen zu lassen und um deretwillen du den in 99% (IMHO) aller Fälle richtigen Tip "Tasten immer pollen" so vehement ablehnst? XL
Markus schrieb: >>> Es handelt sich schon um einen 74HS14, steht so drauf. >> Sowas gibts nicht. Schau nochmal. Mach notfalls ein Foto. > Tippfehler, sollte 74H_C_14 heißen. OK >>> Die kleinen µCs können ja kein Multi-Threading >> Falsch > Ok, ich meinte preemptives Multi-Threading. Immer noch falsch. Multitasking ist eine reine Softwaresache. Es ist vollkommen unerheblich, ob das ein µC oder ein Pentium-Prozessor ist. Der Schduler eines präemptiven Multitasking-Betriebssystems ist im wesentlichen eine zyklisch aufgerufene Timer-ISR. >> Das ist hier kein Buzzword-Bingo. > Darf ich die Dinge nicht beim Namen nennen? Kümmerst Du Dich in Deinen > Anwendungen nicht darum, die jeweiligen Aufgaben, die inhaltlich nichts > miteinander zu tun haben, voreinander abzuschotten? Ich tue das durchaus. Nur eben ohne dabei mit Buzzwords und Anglizismen um mich zu werfen wie ein wildgewordener Marketingfuzzi. XL
Hallo Axel, Axel Schwenke schrieb: >>>> Die kleinen µCs können ja kein Multi-Threading >>> Falsch >> Ok, ich meinte preemptives Multi-Threading. > > Immer noch falsch. Multitasking ist eine reine Softwaresache. Es ist > vollkommen unerheblich, ob das ein µC oder ein Pentium-Prozessor ist. > Der Schduler eines präemptiven Multitasking-Betriebssystems ist im > wesentlichen eine zyklisch aufgerufene Timer-ISR. schön Haare gespalten. Hättest auch gleich sagen oder Dir das Wort "Umgebungen" zu µCs selber dazudenken können. Grüße, Markus
Axel Schwenke schrieb: > Wie es nicht richtig gut, aber wenigstens ein bisschen geht. Wie so sollte das "nicht richtig gut" gehen? Erklärung bitte. Oder besser, was für Probleme handle ich mir den ein wenn ich das mit Interrupt mache? (Probleme, keine Anfänger Fehler) Axel Schwenke schrieb: > Genau das macht ja die Entprellroutine. Sie prüft ob der Zustand der > Leitung eine gewisse Mindestzeit stabil bleibt. Nein, muss sie nicht, wenn es nur unkritische Benutzereingaben sind und man nicht in einer EMV verseuchten Umgebung arbeiten muss (ist aber ein andres Thema). Hauptsache nicht jedes Prellen wird als Tastenbetätigung interpretiert. Stop/Start..., wo's halt nicht drauf ankommt, wie oft oder lange die Taste, gedrückt wurde. Axel Schwenke schrieb: >> Naturlich bekommt man beim Pollen nicht jeden Dreck mit und kann sich >> das meist sparen. > > Kann man nicht. Weil man ja entprellen will bzw. muß. Macht eine simple Hardware-Entprellung auch nicht! Axel Schwenke schrieb: > Butter bei die Fische! Was sind denn nun die besonderen Anwendungen, die > es erlauben/erfordern einen prellenden Kontakt Interrupts auslösen zu > lassen Na alles wo man sich keine (größeren) Verzögerungen leisten kann/will. Zeiterfassung, Positionsbestimmung über Endeschalter... Axel Schwenke schrieb: > um deretwillen du den in 99% (IMHO) aller Fälle richtigen Tip > "Tasten immer pollen" so vehement ablehnst? Geht das schon wieder los! BITTE unterstelle mir keine Aussagen, die ich NIE getroffen habe! Teo Derix schrieb: > PS: Um's nochmals zu betonen: > Auch ich halte das Tastenabfragen mittels Interrupt für seltenst > sinnvoll. > Mich störten nur die hier immer wieder auftauchenden, dogmatischen > Aussagen wie: Verboten, darf man nicht, funktioniert nicht...
Teo Derix schrieb: > Oder besser, was für Probleme handle ich mir den ein wenn ich das mit > Interrupt mache? (Probleme, keine Anfänger Fehler) Nun ja das es ohne Hardwareentprellung dann mal so eben einige 100 Interrupts im uC ausgeloest werden. Man kann die jetzt im uC unterdruecken ist aber nicht gerade die saubere Art. Teo Derix schrieb: > Na alles wo man sich keine (größeren) Verzögerungen leisten kann/will. > Zeiterfassung, Zeiterfassung ja. > Positionsbestimmung über Endeschalter... bestimmt nicht, so schnell ist keine Mechanik. Eine SPS laesst sich da auch einige ms Zeit.
Lothar Miller schrieb: > Nicht genutze Eingägne MÜSSEN bei allen CMOS Bausteinen beschaltet > werden. Sonst floatet der solange, Stimmt, ich habs nur nicht erwähnt, weil ich der Meinung war, das weiß der Projekt-Schreiber schon . Lothar Miller schrieb: > Wieso sollte ein CMOS Eingang Spannung ausgeben? Wieso sollte ein CMOS Eingang Spannung ausgeben? Nun, das entnahm ich der Beschreibung seiner Schaltung. Ob das tatsächlich so ist - du , da bin ich überfragt, obwohl: CMOS-Baustein oder nicht CMOS - Soweit ich weiß - bitte entschuldige, wenns dumm klingt: gibt doch Spannungspegel an Ein und Ausgängen aus - zumindest legt man ja an EINGÄNGE auch Spannungen / (Flanken-Pegel) oder so änlich an, oder seh ich das falsch? Ob das nun was mit der CMOS-Technologie zu tun hat - nee, das hat was STÖREMPFINLICHKEIT "magnetischer Selbsterregung" bzw. "statischer Aufladung" zu tun, soweit ich in der Schule vor Jahren aufgepasst hab - auch hat man das früher im Unterricht behandelt. Und das mögen diese CMOS-Bausteine nicht. Daher soll man diese ja nicht mit blanken Fingern ohne "Erdungsband" berühren - so stehts zumindest in den Baustein-Unterlagen, VRT-Band usw. Und zweitens, wie du selbst erwähntest: man muss diese bausteine auch immer an den Versorguungspins mit einem Kondensator abblocken. dDas weiß ich auch (schon). Aber diese strunzeinfache und langsame Inverterschaltung hier muss jedes der CMOS-IC können. SOweit ich weiß, können diese CMOS-Bausteine das auch, (unter bestimmten "Vorsichtsmaßnahmen" allerdings, wie zuvor erwähnt habe!) aber das war ja nicht das Thema hier. > (woher auch immer Deine Angaben beziogen hast.) Aus dem Datenblatt? Wieso? Die Angaben stehen darin zum Beispiel zu jedem IC. Aber das gehörte nicht zu meinem Beitrag oben. Danke aber, dass erwähnt wurde. Und dass auf ein Schaltungs-Foto wartest? Hast es denn nun bekommen? ich seh nich keines. Aber liegt daran, dass es dunkel draussen gerade ist. Des war ein Scherz, der erlaubt sein darf bitte. So: Alles beantwortet? ok, dann les ich nun weiter. Danke für die Infos. Hab zwar nichts gelernt, aber davon ganz viel. Gruß dennoch. Zeilentrafo
Niemand muß die SW-Entprellung benutzen. Sie spart aber einige Bauteile ein und kostet fast keine CPU-Zeit. Außerdem habe ich gemerkt, wird das Programmieren damit deutlich einfacher. Man schnappt sich einfach das Drück- oder Repeatereignis und macht die Aktion.
Axel Schwenke schrieb: > Nur Deppen hängen einen prellenden Taster direkt an einen > Eingang der Interrupts auslöst. Wenn Interrupt, dann muß in Hardware > entprellt werden. Helmut Lenzen schrieb: > Nun ja das es ohne Hardwareentprellung dann mal so eben einige 100 > Interrupts im uC ausgeloest werden. Man kann die jetzt im uC > unterdruecken ist aber nicht gerade die saubere Art. Teo Derix schrieb: > Mich störten nur die hier immer wieder auftauchenden, dogmatischen > Aussagen wie: Verboten, darf man nicht, funktioniert nicht... Mich stört das auch. Dass es elegant geht und auch keinen Timer braucht, ist in der Codesammlung nachzulesen: Beitrag "EIN-AUS mit Taster per Interrupt, ATtiny25 o.ä." Mir ist klar, dass das einigen Schreihälsen nicht gefällt :-)
m.n. schrieb: > Dass es elegant geht und auch keinen Timer braucht, > ist in der Codesammlung nachzulesen: > Beitrag "EIN-AUS mit Taster per Interrupt, ATtiny25 o.ä." Sorry aber DAS geht mal garnicht! So ein Monster, inklusive Waits, für eine popelige Taster Abfrage, kommt mir NIEMALS in die ISR! Waits und elegant, passt einfach nicht zusammen, egal ob in oder außerhalb, einer ISR!
Teo Derix schrieb: > So ein Monster, inklusive Waits, für eine popelige Taster Abfrage, > kommt mir NIEMALS in die ISR! Hier geht es um das Ein-Ausschalten einer Schaltung. Das Programm habe ich (so hoffe ich) nachvollziehbar geschrieben und kommentiert. Ich weiß, die Gurus hier machen das anders. Was stört Dich an 'wait', wenn der Einschaltvorgang anstatt 100ms nur 2-3ms dauert? Einen Beitrag weiter ist das gesamte Programm gestrafft. Anlage: toggle_int.lss Ohne Wartezyklen geht es natürlich auch: Beitrag "Schrittmotor als Drehgeber mit Dynamik, AVR" Sieh Dir 'ISR(PCINT2_vect)' an. Monster? Fehlanzeige! Alles schön per Interrupt und nichts für Angsthasen :-)
Hallo, ich bin von der Hardwarelösung nun völlig abgekommen und nutze Peter Danneggers Komfortroutine, erweitert für beliebig viele Tasten, in eine Template Class gegossen, die mein Timer Callback Interface implementiert und Key-Events auslöst, auch Key-Repeats. Danke Peter. Funktioniert wunderbar. Viele Grüße, Markus
Bitte 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.