Ich möchte eine (in den meisten Fällen bessere) Alternative zum traditionellen Entprellen vorstellen (s. Anhang). Wozu aufwändig und für jede Taste extra prüfen, ob speziell diese betreffende Taste nun endlich sitzt, wenn es mit nur einem Schlag möglich ist, alle Mücken totzuschlagen? Wie das geht? So: Die Taste kommen und all ihre Geschäfte erledigen lassen, ohne auf das Prellen zu achten. Dann, wenn die Routine abgearbeitet ist, einfach prüfen, ob ALLE Tasten frei sind. Vorteile: - Die entfallende Differenzierung zwischen den Tasten spart Zeilen. - Die Routine wird SOFORT abgearbeitet, ohne Entprellzeit-Verluste. - Manche Tasten sollen auch beim loslassen prellen (was selber nicht wie), was mit einer herkömmlichen Entprellroutine nicht in den Griff zu bekommen wäre. Mit meiner - schon! Natürlich gibt es Fälle, wo auch ich mich zurück zur Tradition besinnen würde - wenn z.B. gleichzeitig viele Tasten gedrückt sein müssten - aber auch das Problem löste ich bisher immer (bis zu 6 Tasten gleichzeitig), und zwar in dem ich in der vorgestellten Warteroutine einfach nach diesen anderen Tasten pollte. Seit Jahren keine Probleme, auch nicht in Kommerziellen Programmen. mfg Richard.
"Manche Tasten sollen auch beim loslassen prellen (was selber nicht wie), was mit einer herkömmlichen Entprellroutine nicht in den Griff zu bekommen wäre." Wie kommst Du denn bloß darauf ? Klar entprellen herkömmliche Routinen auch beim Loslassen, z.B.: http://www.mikrocontroller.net/forum/read-4-20549.html#new Und wesentlich aufwendiger ist es auch nicht. Allerdings wesentlich vorteilhafter, da der Programmablauf nicht gehemmt wird (Deine Routine bleibt stehen, solange eine Taste gedrückt ist). Auch werden die Tastendrücke gemerkt, wenn die CPU gerade noch was anderes macht. Ich ärgere mich jedesmal, wenn ich bei einer kommerziellen Fernbedienung immer erst warten muß, bis eine Taste abgearbeitet ist, ehe man die nächste drücken darf. Das Prellen beim Loslassen kommt daher, weil die Kontaktzungen wunderschön federn. Peter
>...Das Prellen beim Loslassen kommt daher, weil die Kontaktzungen
wunderschön federn""
Vielen Dank, dass wird wohl so sein!
Danke für das Riesen-Programm mit vielen benötigten Registern, aber
mein Anliegen war ein anderer - siehe "Vorteile" (Ok, Punkt 3
schenk' ich dir - obwohl deine Routine wohl KEINE herkömmliche ist).
Und wenn das Programm stehen bleibt, so liegt es nur am Programmierer,
denn auch aus der Warteroutine heraus kann man in die grosse weite Welt
hinausschauen (s. meine Standardversion im Anhang)!
Auch die Interrupt-Flags werden Hardwaremässig gesetzt und gehen in die
Warteschlange (bei zeitunkritischen Interrupts auch kein Problem).
Und auch die Fernbed.-Programmierer haben sich was gedacht.
Mein Cordless (ERICSSON) scheint übrigens auch ein blutechter
"Waitfreekey'er" zu sein!
Aber natürlich gibt es Grenzen, die ich (und Du) auch überaus deutlich
angedeutet haben.
Fazit: Wenn Du "wesentlich vorteilhafter" schreibst, so darfst Du's
nicht verallgemeinern und musst dich im selben Atemzug auf die Angabe
beschränken, WANN es der Fall ist!
mfg Richard
Hat Peter doch gemacht, meiner Meinung nach. Davon mal abgesehen hat deine Routine nichts mit "Entprellen" zu tun, sondern nur mit Abwarten ob keine Taste mehr gedrückt ist. Ich frage mich was dies nunmit "Ent-Prellen" zu tuen haben soll. Ein Prellen ist wie ein Störsignal das nun durch die Softare ge-filtert werden muß. Einfach abwarten und Tee trinken ist für mich keine aktive Filterung. Mir fällt da auch noch ein anderer wichtiger Vorteil von peters code ein. Er De-Bounced = filtert nämlich wirklich, d.h. es ist mit seinem Code sehr einfach möglich auf ein Flanken-Wechsel der Tasten zu reagieren. Warum das gut ist ? Weil gerade ausgelutschte Gummitasten auf Fernbedienungen zb. die Eigenart entwickeln zu verkleben. Dein Code würde nun in einer Endlosschleife darauf warten das diese Tasten wieder "losgelassen" werden und dabei den Rest der kompletten Software blockiern. Bei peters Code läuft der Timer im Hintergrund und in der Hauptschleife reagiert man nur auf "Taste X wurde gedrückt". D.h. der Code kann nicht hängen in der Timer ISR und auch nicht in der Hauptschleife. Denn erst nachdem die klebende Taste wieder "losgelassen" wurde kann in Peters Code wieder ein "Taste X wurde gedrückt" Signal auftreten. Ergo: die klebende Taste blockiert ausschließlich nur ihre eigene Funktion in der Software, der Rest kann komplett weiterlaufen und auch weiter bedient werden. Ehrlich gesagt: ich halte dies für einen sehr guten präventiven und ausfallsicheren Ptrogrammierstil und würde immer den Code von Peter vorziehen. Im grunde ist es eh Quatsch sich darüber zu streiten welcher Code besser ist, sie sind von der Qualität garnicht vergleichbar. Gruß Hagen PS: nur mein 10 Cent Meinung als professioneller Programmmierer :-)
"Danke für das Riesen-Programm mit vielen benötigten Registern," Nun das ist ja auch nicht ein kleines Codefragment, wie Deines, sondern es liefert ja schon die fix und fertig entprellten Bits und obendrein die Flankenerkennung von losgelasen nach gedrückt. Wenn Du mal Deine Routine für alle 8 Tasten komplettierst dürfte sie wesentlich größer sein. "...musst dich im selben Atemzug auf die Angabe beschränken, WANN es der Fall ist!" Das ist eigentlich immer der Fall, alle die meine Routine kennen gelernt haben, benutzen nichts anderes mehr. Der Meilenstein ist nämlich, man fügt sie nur in den Haupt-Timerinterrupt ein und vergißt sie dann einfach. Man ist also wesentlich flexibler im Programmablauf und kann die entprellten oder flankenerkannten Bits genau an den Stellen testen, wo es benötigt wird. Wie Du ja richtig sagst, muß man bei Dir quasi alle Funktionen um Deine Routine drumherum bauen, was den Programmfluß verkompliziert, sowie Änderungen oder Erweiterungen schwerer macht. "Und auch die Fernbed.-Programmierer haben sich was gedacht." Nein, sie haben bloß keine Ahnung von Ergonomie oder Programmierung. Wenn man für eine bestimmte Funktion immer die gleichen 5 Tasten drücken muß, dann will man das auch hintereinander tun können. Peter
"Die Routine wird SOFORT abgearbeitet, ohne Entprellzeit-Verluste." Es hat sich in meiner Praxis als äußerst sinnvoll erwiesen, beim Drücken erstmal zu warten, ob es nur ein Störimpuls war oder wirklich längere Zeit gedrückt. Kein Mensch kann nämlich feststellen, ob etwas in der gleichen µs angeschaltet wird oder erst 40ms später. Dagegen kenne ich einige Geräte, die bei Annäherung mit einem elektrostatisch geladenen Pullover verrückt spielen, nur weil der Programmierer unbedingt "sofort" reagieren mußte. Peter
>>"Und auch die Fernbed.-Programmierer haben sich was gedacht." >Nein, sie haben bloß keine Ahnung von Ergonomie oder Programmierung. >Wenn man für eine bestimmte Funktion immer die gleichen 5 Tasten >drücken muß, dann will man das auch hintereinander tun können. Mal losgelösst vom eigentlichen Thema, aber obige Bemerkung stimme ich zu 100% zu. Ich ärgere mich JEDEN Tag über meine Philips Fernbedienung. Jeder Laie und auch meine Freundin finden sie schnuckelig und hübsch, aber bedienbar ist sie nicht. Überladen, kompiliziert, japanisch. Und es ist nicht die einzigste Fernbedienung die regelrecht anti-ergonomisch konstruiert ist. Ne amerikanische lernfähige von All-In-One habe ich auch, die saugt die teuren Batterien in 3 Wochen leer, hat zwar ein Display aber dieses zeigt nur die englische Zeitangaben an, sprich 12 Stunden und AM/PM mehr nicht. Und last but not least kann ich damit jeden Einbrecher erschlagen, sprich im Grunde ist sie nur mit beiden Händen bedienbar. Mit der Philips Fernbedienung vom Fernseher stoße ich wenn ich nicht aufpasse an meine Wohnzimmerdecke an, wahnsinn ist noch das man si aufklappen kann um nochmal 50 Tasten mehr zu bekommen. Das Ding wird dann so lang das ich mich ducken muß und die 50 zusätzlichen Tasten sind auf einem 5*5 cm großem Feld angebracht. Ich weis ja nicht ob die Japaner so kleine Finger haben oder mit Eßstäbchen die Tasten bedienen, ich auf alle Fälle komme damit nicht zurecht. Besonders weil gleich neben dem 5*5cm für 50 Tastenfeld mindesten dreimal soviel Platz vorhanden ist. Naja, wollte damit nur mal sagen das die heutige Ergonomie bei den Fernbedienung wirklich schlecht ist. Gruß Hagen
Hallo Richard... Ich kann nur bestätigen, was Peter schrieb: > Das ist eigentlich immer der Fall, alle die meine Routine kennen > gelernt haben, benutzen nichts anderes mehr. Ich hatte anfangs meine Schwierigkeit, Peters Routine zu verstehen, aber seit ich sie verstanden habe, benutze ich nix anderes mehr. Die Routine bietet mir den (entprellten) Tastenzustand von 8 Tastern/Schaltern und die 8 "Tastenflags", die einen neuen Tastendruck signalisieren. Dabei können sich Tastendrücke zeitlich überlappen oder gleichzeitig erfolgen, sie funktioniert immer zuverlässig. Vergleiche doch mal nicht nur die Anzahl der Zeilen (7 sind es bei dir auch nicht), sondern die benötigte Rechenzeit (in Takten), dann wirst du einen Unterschied feststellen. Peters Routine setzt allerdings voraus, dass man Warteschleifen den Rücken kehrt und die gesamte Zeitsteuerung einem Timer überlässt. Dies wiederum setzt voraus, dass man es beherrscht, Interrupts sinnvoll einzusetzen. ...
Vielen Dank für eure Beiträge. Ich habe gegen die Peters Routine eigentlich nicht viel einzuwenden. Vielleicht hätte ich meinen Beitrag "Eine OFT ausreichende Alternative zum Entprellen" nennen sollen - denn mir hat sie schon oft gute Dienste geleistet. OHNE die Timer (die sind bei mir oft sowieso mit Aufgaben überhäuft) und ganz OHNE Hängenbleiben, wenn die Taste ständig gedrückt wird (s. meinen zweiten Dateianhang weiter oben). In meinem jetzigen Projekt (geht nach Osten) musste ich auch zwischen den zeitlichen Längen der Tastenbetätigungen differenzieren, wobei auch verschiedene Tastenkombinationen berücksichtigt werden mussten. Das alles war mit meiner Routine ziemlich komfortafel zu lösen. Mein Programm "begleitet" die Taste, solange sie noch gedrückt bleibt und kann auf diese Weise wunderschön die Verweildauer beobachten und nach den anderen Tasten Ausschau halten. Klar ginge es auch anders (wieder mit Timern und temporären Statusregistern etc.), aber wäre das auch elegant? mfg Richard
>Klar ginge es auch anders (wieder mit Timern und temporären >Statusregistern etc.), aber wäre das auch elegant? Ja klar doch, oder ist es eleganter wenn du deinen BMW ohne Räder fährst nur weil du sparsam sein willst ? Ich frage mich wozu der Timer und die Register denn gut sein sollen wenn man sie nicht auch auslastet. Im Grunde aber egal, denn jeder soll so programmieren wie er möchte. Aus meiner Sicht hat Peter passend zum Thema seine berechtigten Kritiken samt konstruktiver Lösung gepostet. Und jeder kann und soll für sich selber entscheiden was für ihn die passende Lösung ist. Ein wesentlicher Vorteil deiner Lösung besteht darin das man sie zb. in einer Quick&Dirty Lösung schnell einbauen kann und sie vom Fachverständnis längst nicht so kompliziert wie Peter seine ist. Gruß Hagen
>"...Ich frage mich wozu der Timer und die Register denn gut sein
sollen wenn man sie nicht auch auslastet."
Stell dir vor, dass all deine Timer schon allesamt am Laufen sind,
immer wieder neue Werte bekommen etc., und nun kommst du daher und
meinst: "Hey, Timer0! Sag mir mal Bescheid, wenn die Taste nicht mehr
prellt!"
Natürlich ist auch diese Nuß zu knacken (bei jeder TCNT-Zuweisung erst
nachschauen, ob da irgendwo noch eine Taste am Drücken ist, falls ja -
alten Zählerstand speichern, neuen Wert für's Ende der Beobachtung
berechnen, das neue Ende einstellen (falls die betreffenden
Controllbits noch überhaupt zur Verfügung stehen) und darauf hoffen,
dass dein Programm noch versteht, was du von ihm willst :)
Es sind schon viele Weltraumsonden verlorengegangen, nur weil die
Programmierer versucht hatten, ein unnachahmlich ausgeklügeltes
Kunstwerk zu erschaffen!
Da haue ich lieber Klotze mit'm Beil, die dann aber auch nicht
umfallen!
Na dann viel Spaß und baue dein Handy aus "Klotze mit'n Beil". Aber auch diesen Punkt hat Peter in seinem Thread schon angesprochen. Denn meistens benutzt man MCU's die mehr als nur 1 Timer besitzen und die meiste Software die ich dafür gesehen habe verteilt die Resourcen so das einer der Timer ein langsammer (Millisekunden) multipurpose Timer darstellt. Dieser Timer erledigt dann viele verschiedene Aufgaben gleichzeitig, eben zb. Tasten entprellen + RC5 Decoder + RC5 Encoder + Task Sheduller + Motor Treiber + blinkdene LED Ansteuerung + Lauftext auf dem LCD. All das lässt sich in einen Timer reinpacken. Wichtig ist doch nur das alle diese Funktionen auch modularisiert und rel. unabhängig voneinander wiederverwendet werden können. Und genau diese Wiederverwendbarkeit ist auch mit Peters Code gegeben. Und falls diese 2-3 Timer dir immer noch nicht ausreichen dann nimm eine größere MCU, denn meistens reichen die anderen Resourcen dann auch nicht mehr aus. Ich jedenfalls verteile die vielen Unteraufgaben lieber auf separate Resourcen so das am Ende die Hauptschleife der Anwendung nur ein reines Steuerwerk/FSM darstellt. In deinem Falle vermute ich das das Program komplett aus einer einzigsten Main Loop besteht und diese aus Spaghetticode. Denn exakt dies ist der Unterschied wenn man die Software Ereigbnis gesteuert programmiert. Statt also auf einen Satus X an Port Z zu reagieren sollte man auf einen Statuswechsel von X nach Y reagieren. Ich will hier aber keinen Krieg anzetteln und auch nicht deinen Source ansich. Man kann ihn benutzen, er funktioniert seiner Aufgabe entsprechend, ist kurz und leicht verständlich. Denoch darfst du nicht davon ausgehen das man eine Technologie entwickeln kann ohne die dafür nötigen und ausgefeilten Methoden. Ich meine damit das man eben mit einem Klotz und einem Beil nicht erwarten kann das daraus eine komplizierte, laufsichere, schnelle und miniturisierte Anwendung wird. >>"...Ich frage mich wozu der Timer und die Register denn gut sein >sollen wenn man sie nicht auch auslastet." >Stell dir vor, dass all deine Timer schon allesamt am Laufen sind, >immer wieder neue Werte bekommen etc., und nun kommst du daher und >meinst: "Hey, Timer0! Sag mir mal Bescheid, wenn die Taste nicht mehr >prellt!" Und nun stell dir vor ich baue meine Software nach deiner Methode, ich habe alle Timer alle IRQ's noch frei aber in meiner Main Loop einen 16 Kb großen Spaghetticode der alle Ereignisse die reinkommen und verarbeitet werden müssen durch Schleifen pollen tut. Nun meine 16Kb Flasj sind verbraucht also nehme ich eine größere MCU mit 256 Kb Flash und 10 verfügbaren Timern und mache dort mit der gleichen Methode weiter. Wie du siehst deine Argumentationslogik kann insich auch mit sich selber widerlegt werden. Fakt ist in der MCU stehen Timer und Register zur Verfügung und es ist allemale elegant diese auch zu nutzen. Gruß Hagen
Noch ein Argument,eher technischer Natur. Also das Prellen ansich ist ein physikalischer Vorgang. Er zeichnet sich dadurch aus das zeitlich nicht periodische Störsignale entstehen. Technologisch entgegenwirken tut man indem man mit exakter zeitlich periodischer Abtastung antwortet. Die meisten Systeme arbeiten exakt so und aus diesem Ziel entwickelte sich als Maßname die Computertechnik. Hört sich verrückt an ist aber so, denn der Takt bzw. die Logik der getakteten Systeme liegt in deren Störsicherheit begründet. Also das Prellen von Tasten wird am besten ausgeschaltet indem man mit periodischen Abtasten reagiert und bestensfalls noch einen digitalen Filter nachschaltet (wie in Peters Source :) Nun bei deiner Methode benutzt du eine solche Abtastung die auf Grund der Abarbeitungszeiten der Machinenbefehle entsteht. Die Periodik der Abtastung ist also ganz entscheidend von der Ausführungsgeschwindigkeit und den Taktzyklen der Befehle abhängig. Dies ist ein enormer Nachteil gegenüber der Lösung von Peter. Denn was macht man wenn immer mehr Funktionen in der Main Loop() integriert werden müssen ? Neben diesen Aufgaben die auch zeitlich aperiodisch erfolgen willst du mit deiner Methode die Tasten pollen. Dies führt zwangsläufig zu einer aperiodischen Abtastung und ergo kann dies die physikalische Zielsetzung nicht mehr erfüllen. Gruß Hagen
>"...Und falls diese 2-3 Timer dir immer noch nicht ausreichen dann nimm eine größere MCU..." -> Danke, aber es reicht mir alles und alles funktioniert bestens (ausser bei diesem diesem doofen PowerDown, der nach 5-10 Stunden Schlaf oft nicht mehr korrekt sich aufpäppelt und resettet werden muss). ------- @Orakel >"...In deinem Falle vermute ich das das Program komplett aus einer einzigsten Main Loop besteht und diese aus Spaghetticode..." -> Ob du glaubst oder nicht, aber meine "Loop" besteht aus nur 10 Zeilen! (Nun bloß nicht meckern, dass es ZU WENIGE sind!) loop: sbis PIND, 4 rcall ... sbis PIND, 1 rcall ... sbis PIND, 5 rcall ... sbis PIND, 0 rcall ... rjmp loop -------------- >"...Dies führt zwangsläufig zu einer aperiodischen Abtastung..." -> HALLO, wir reden hier NICHT von der Abtastfrequenz in einer Messschaltung (die selbstverständlich periodisch sein soll), sondern nur von einem bloßen Tastenwächter! >"... kann dies die physikalische Zielsetzung nicht mehr erfüllen." ->Jetzt muss ich die selben Behauptungen erdulden, gegen die sich schon Peter einmal wehren musste. Nun bin also ich dran: hast du irgendwelche BEWEISE, dass mein Code nicht wunderbar funktioniert? Hast du wirklich schon damit experimentiert, oder was war das für Äußerung? >"...Und nun stell dir vor ich baue meine Software nach deiner Methode, ich habe alle Timer alle IRQ's noch frei aber in meiner Main Loop einen 16 Kb großen Spaghetticode" @Orakel: ->Kein Kommentar mfg Richard
> Nun bin also ich dran: hast du irgendwelche BEWEISE, dass mein Code
nicht wunderbar funktioniert?
Rigardo ist hier nur uneinsichtig und besteht darauf, daß sein Code
seinen Zweck in seinen Augen sehr gut erfüllt. Das trifft meiner
Meinung nach zu, solange die Software nicht (viel) mehr erledigt, wie
auf Tastendrücke zu warten. (Die Mainloop aus dem letzten Postings
beweists. :) ALLE anderen Fälle/Argumente wurden von Peter und Hagen
schon ausführlich dargelegt.
----, (QuadDash).
Danke, ----, meine Routine darf also als ethnische Minderheit
weiterleben!!!
>"...die Software nicht (viel) mehr erledigt, wie
auf Tastendrücke zu warten."
->Die Software ist mehrere Tausend Zeilen lang, benutzt alle mega8 -
Pins (inclusive Reset-Pin als I/O), alle Timer MEHRFACH, mehrere IRQ's
und ist absolut kein "Spaghetticode"!
mfg Richard
@Richard, mach Dir nichts draus. Ich hab auch lange nach der Devise programmiert: "Ein Genie beherrscht das Chaos". Aber irgendwann kommt mal der Zeitpunkt, wo man in den vielen Projekten die Übersicht verliert und sich auch fragt, warum fange ich immer wieder von vorne an. Und dann beginnt man alles in kleine Module zu unterteilen, die leicht zu überschauen und möglichst universell sind, möglichst wenig die anderen Tasks behindern und möglichst unabhängig (z.B. von der Taktfrequenz) sind. D.h. die man quasi wie Bausteine einfügen und dann (fast) vergessen kann. Jetzt entwickele ich also nach der Devise: "Teile und herrsche". Und wenn ich mal alte Programme von mir ansehe, kriege ich das kalte Grausen. Peter
Guten Tag miteinander, jeder hat das Recht der freien Meinungsäußerung, das ist auf jeden Fall klar. Manche Menschen meinen jedoch, ihre Meinung anderen Menschen aufzuoktruieren zu müssen. So etwas kann ich nicht verstehen. Ich glaube, daß sich die meisten ernsthaften Programmierer (auch wenn sie weniger Ahnung haben oder Anfänger sind) immer ein bißchen Mühe geben und es so gut wie möglich probieren. Ich sage nicht, daß es so oder so richtig ist. Jeder macht´s so wie er´s meint und am besten kann. Ich entprelle auch schon seid Jahren mit Timer-Interrupt. Durch direkten Kontakt zu ATMEL werde ich meine Entprell-Routine (C-Code) dort hinschicken. Mit etwas Glück gewinnt man nämlich dort einen Preis in Höhe von 500 Euro, wenn die "Application Note" veröffentlicht wird. Falls vorher Interesse am Quellcode besteht, einfach bescheid geben. Die Application Note wird "Efficient Port Debouncing" heißen. Viele Grüße, Robby
ja also ich hätte interresse daran!! mfg mathias
Hallo Mathias, die Routine ist aber in C geschrieben! (Wenn das in Ordnung ist). Robby
Nachtrag für Mathias, die Routine kann theoretisch beliebig viele Tasten entprellen. Sie ist EMV-Fest und geprüft. Ich werde aus der bisherigen Version eine programmieren, die eine Matrix entprellt. Gruß
kling toll und C ja das ist sowie so neben java meine lieblings sprache!! mfg mathias
@Robby ja und bekommt man jetzt deinen Code oder nicht?? mfg mathias
@Mathias, nimm doch einfach meine Routine. Im Scheduler-Beispiel ist eine C-Anwendung dazu. Für ne Matrix ist auch ein Beispiel von mir in der Codesammlung, ist allerdings etwas schwerer zu verstehen, da sie mehrere Tasten gleichzeitig kann. Peter
@Peter
>"...Jetzt entwickele ich also nach der Devise: "Teile und
herrsche".
Peter, du bist weise. Darf ich auch deine Routine benutzen? (hiermit
erkläre ich die meine zum Aprilscherz :)
schmunzel Wie ein Zitat (aus dem Zusammenhang gerissen), doch plötzlich ein einem völlig neuen Licht erscheinen kann. Soo habe ich Peters Devise noch garnicht gesehen. ;-) ----, (QuadDash).
Man kann auch noch etwas anders, aber ähnlich ran gehen.
Mit Polling - ohne Timer (wenn keine mehr frei sind):
3 static Variablen:
LastState
Counter
Stable (boolean - gibt an, ob der Zustand der Tasten stabil ist)
(N kann fest eingeproggt werden und ist je nach tasten typ (prellzeit)
ca. 10 - 40 sein muss man probieren oder ausrechnen)
* Zustand der Tasten einlesen
* Mit gespeichertem Wert (LastState) vergleichen
-> Wenn gleich, dann (Counter) erhöhen
-> Wenn ungleich, dann (Counter) zurücksetzen,
neuen Wert (LastState) speichern
* Gespeicherten Zähler mit einer festen Anzahl (N) vergleichen
(um zeilen/zeit zu sparen gleich den neuen wert nehmen)
-> Wenn wert erreicht, dann Variable (Stable) setzen,
Zähler auf N - 1 (um beim nächsten lauf auf N zu kommen)
-> Wenn wert nicht erreicht (Stable) zurückstellen
Im Hauptprogramm wird dann die Funktion aufgerufen und wenn (Stable)
gesetzt ist, dann kann der Zustand der Tasten ausgewertet werden.
Natürlich frisst das Rechenzeit (blockiert aber nicht das Hauptprogramm
(wenn nicht hauptsächlich tasten ausgewertet werden und darauf reagiert
wird) und im schlimmsten Fall erwischt man (bei periodischen Abfragen)
immer die Zeit in der der Nutzer wie wild entnerft auf die Taste haut.
Für 90% (grobe Abschätzung noch oben) der Fälle geht das aber...
UND WAS DAS GANZE ENTPRELLEN BETRIFFT:
NOT-AUS SCHALTER SOLLTEN GAR NICHT (ODER WENN ÜBERHAUPT NUR WENIG)
ENTPRELLT WERDEN...
Wenn man so gar nicht mit seiner Fernbedienung fertig wird und zu viele
Tasten drauf sind (und dass sind es meistens) dann kann man sich doch
eine selber bauen: Tasten-Matrix + kleiner uC der die Matrix auswertet
und den RC5 (wird meistens verwendet) sendet
Die Tasten-Matrix kann dabei recht klein gewält werden:
1 An/Aus -Taste
4 Lautstärke/Programm Wahl
evtl. noch Stumm-Taste, Favorite-Sequenz (Favorite-Programm,
automatische Sleep-Timer einstellung, ...)
@Hagen:
Jep, Japaner haben sehr kleine Finger (ca. 70% so groß wie unsere)...
Schau dir doch mal z.B. die Handies an, die die entwerfen und bauen...
12 Tasten auf nicht mal 4 cm2. Da kann kaum ein Europäer mit seinen
riesen Griffel damit tippen...
@Marcel: ich bin mit dem Entprellen nicht deiner Meinung. Deine vorgeschlagene Methode kann im schlechtesten Falle ein schlimmeres "Software"-Prellen verursachen als das Hardwareprellen ist. Also der beste Vergleich der mir einfällt ist: Man baute vor einiger Zeit sehr stabile Brücken und trotzdem konnte man sie sehr einfach zum Einsturtz bringen, einfach indem man eine Kompanie Soldaten im Gleichschritt drübermarschieren lies. Nun, in deiner Methode benutzt du KEINE feste und periodische Zeitbasis die aus Sicht des Systemes "Prellen" ein äußeres und unabhäniges System ist. Aber das ist im Grunde die einzigste Möglichkeit. So wie du es machst hängt es sehr stark von der Art und Weise des Prellvorganges ab wie effizient die Methode ist. Stell dir zwei Arten von Prellen vor: einmal ein normales Prellen eines Tasters, ca. 1ms pro Periode und maximal 10 mal nacheinander. Nun vergleiche dies mit einem Extremfall wo der taster mit 1 MHz prellt und das 1000'ende male hintereinaner. Oder bei einem Fall wo der Taster nicht mehr genügend mechanischer Gegenspannung besitzt und die Kontakte lose aufeinander liegen, sprich ein langsammes aber periodisches Prellen vorkommt weil das Gerät in einem Auto liegt und die Straße eine Pflasterstraße ist. Durch deine Methode entsteht kein definiertes Verhalten sondern nur ein Verhalten das zeitlich das eigentliche Prellen nachsimuliert, so wie ein Nachbeben ein zeitliches Dämpfungsglied im elekrtonische Sinne. Schwierig zu erklären. Alleine deine Aussage: "N je nach Taster 10 bis 40" das ist sowas wie "man nehme 2-3 Eßlöffel Zucker, je nach Geschmack". Nun, Prellen ist aber ein definierter leicht chaotischer physikalischer Vorgang, das hat nichts mit unseriösen Kochrezepten zu tun. Das ist KEIN persönlicher Angriff gegen dich oder deine Methode, sondern eine in meiner langjährigen Programmiererpraxis immer wiederkehrende Erkenntnis. Ich habe nämlich feststellen müssen das die wenigsten Programmierer die Software/Programmierung ansich als exakte Formel, als exakte Abbildung realer Vorgänge sehen bzw. eben die Genauigkeit bei der Analyse einer gegebenen Aufgabe walten lassen. Man analysiert die eigentliche Aufgabenstellung zur Erreichung eines Ziels nicht gründlich und nicht wissenschaftlich genug. Stattdessen baut man halbseidene Lösungen deren eigentliche Funktionsweise keinesfalls nachweislich beweisbar ist. Hauptsache es hat den Anschein das es funktioniert. Einfachstes Beispiel: Programmiere einen Lottozahlen Generator ! Eine beliebte Aufgabe für meine damaligen Lehrlinge. Keiner hat es auf Anhieb richtig gelösst. Alle haben per Zufall 6 Zahlen aus 49 möglichen gezogen und falls bei der Ziehung eine Zahl doppelt vorkam so wurde einfach eine 7'te, 8'te oder 9'te Zahl gezogen. Es fehlte also an der Fähigkeit der "Problemanalyse". Obwohl die Aufgabe trivial erscheint: "bilde die Lottoziehungs-Machine aus dem ZDF nach", und dort werden eben keine Kugeln in die Urne zurückgeschmissen weil es eben unmöglich ist eine Zahl mehrfach zu ziehen. Ja, klar am Ende kamm immer eine Reihe von 6 Zahlen raus bei denen keine mehrfach vorkam, aber die Wahrscheinlichkeiten das eine bestimmte Zahl gezogen wurde entsprachen eben NICHT der Problemstellung ! Ich weis das ich nerve, aber für meinen Teil empfinde ich diese Punkte eben als wichtig. Gruß Hagen
> Wenn man so gar nicht mit seiner Fernbedienung fertig wird und zu > viele Tasten drauf sind (und dass sind es meistens) dann kann man > sich doch eine selber bauen: Tasten-Matrix + kleiner uC der die > Matrix auswertet und den RC5 (wird meistens verwendet) sendet Tja ich weis und ich habe es versucht. Es scheiterte NICHT an der Elektronik/Software die ist trivial. Es scheiterte am Gehäuse. Entweder man findet eine alte Fernbedienung die dem eigenen Geschmack entspricht (in meinem Falle war das aussichtslos) oder man muß sein eigenes Gehäuse konstruieren und fertigen lassen. Dies ist aber zu teuer. Mit halbem Auge schaue ich immer noch in den diversen Märkten rum, selbst auf dem Trödler merke ich das ich unbewusst nach einem praktischen Gehäuse suche. Tasten sollten groß sein, Gehäuse so kompakt und klein wie möglich,inetwa Zigarettenschachtel groß. 1 Taster On/Off, 4 taster Gerätewahl, 1 zentraler Ok Button, 4 Cursortaster, 4 Funktionstaster und maximal 6 Programkurzwahltaster. Taster MÜSSEN farblich Hintergrundbeleuchtet sein und unterschiedliche Formen besitzen, sprich der Tastsinn muß unterschiedlich sein. Taster müssen weich mit definiertem Anschlag arbeiten. Bei Berührung oder Bewegung der Fernbedienung muß die Hintergrundbeleuchtung einschalten. In etwa so wäre meine Ideal-Fernbedienung aufgebaut. Gruß Hagen
Hallo Jungs, wenn ich auch ein wenig Zeit von Euch bekomme, meine Routine so vorzubereiten, daß keine Firmeninterna mehr drin ist?
Hallo Jungs, im Anhang dieses Forumsbeitrags befindet sich nun alle Dateien. Bitte erst durchlesen und dann Fragen stellen. Servas.
Hi Robby, sorry wenn ich das so sagen muß, aber hast du dir Peters code mal ganz genau angeschaut ? Ich erkenne da nämlich keinen wesentlichen Unterschied in der Funktionsweise, Peters Code ist halt technisch gesehen ein bischen cleverer durch dessen boolsche Codierung der 4 bis 8 Filterebenen auf kompaktere Art und Weise. Ansonsten ist alles berücksichtigt was berücksichtigt werden muß. Ein strikt periodisches und vom Prozessortakt unabhängiges Sampling der Eingangssignale das den zeitlichen Erfordernissen des Bedieners angepasst werden kann, ein Filter der die einkommenden Daten kontinuierlich filtert und eben ganz wichtig im Hauptprogram wird ein Tasten-Flankenwechsel ausgewertet statt eines Port Status. Funktionstechnisch erkenne ich also keine wesentlichen Unterschiede oder geniale Neuerungen. Gruß Hagen
Herzlichen Glückwunsch. Ich habe nichts Gegenteiliges behauptet. Die Version ist auch "Kugelsicher", wie man so schön sagt.
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.