mikrocontroller.net

Forum: Projekte & Code Tasten entprellen


Autor: Peter Dannegger (peda)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Es wurden ja schon öfters Entprellroutinen vorgestellt, aber diese hat 
den Vorteil, besonders kurz und schnell zu sein.

Außerdem werden alle 8 Tasten gleichzeitig bearbeitet, es können also 
alle exakt zur selben Zeit gedrückt werden.
Andere Routinen können z.B. nur eine Taste verarbeiten, d.h. die zuerst 
oder zuletzt gedrückte gewinnt oder es kommt Unsinn heraus.

Die eigentliche Einlese- und Entprellroutine ist nur 8 Instruktionen 
kurz. Der entprellte Tastenzustand ist im Register "key_state".
Mit nur 2 weiteren Instruktionen wird dann der Wechsel von Taste offen 
zu Taste gedrückt erkannt und im Register "key_press" abgelegt.

Im Beispielcode werden dann damit 8 LEDs ein- und ausgeschaltet.

Jede Taste entspricht einem Bit in den Registern, d.h. die Verarbeitung 
erfolgt bitweise mit logischen Operationen.

Zum Verständnig empfiehlt es sich daher, die Logikgleichungen mit 
Gattern für ein Bit = eine Taste aufzumahlen.

Die Register kan man sich als Flip-Flops denken, die mit der 
Entprellzeit als Takt arbeiten. D.h. man kann das auch so z.B. in einem 
GAL22V10 realisieren.

Als Kommentar sind neben den einzelnen Instruktionen alle 8 möglichen 
Kombinationen der 3 Signale dargestellt.


Peter

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Peter,

Dein Programm ist zwar besser als - wie anderswo erwähnt - Monoflops 
einzusetzen; es funktioniert aber nur auf dem Papier, da es ideale 
Taster voraussetzt.
Reale Taster prellen aus Erfahrung mehr, als das ideale Datenblatt 
angibt: insbesondere im Laufe der Zeit und bei Feuchtigkeit. Ein typisch 
schlechter Taster ist z.B. einer, wie man ihn bei der 
Hausinstallationstechnik findet. Die Kontakte sind für hohe Ströme 
ausgelegt und nicht für geringes Prellen.

Für eine sauberes Entprellen kommt man nicht umhin, den Tastenzustand 
wiederholt auf Gleichheit zu überprüfen und danach auszuwerten.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Michael,

ich habs aber nicht nur auf dem Papier (Bildschirm) getestet.

Ich habe das Program auf dem AVR Testboard ausprobiert und dabei keine 
einzige Fehlfunktion feststellen können.
Wenn man das Entprellen testweise rausnimmt, sieht man auch wunderschön, 
wie diese kleinen Taster prellen können.

Allein durch das Abtasten in einem festen Zeitrahmen ergibt sich schon 
eine gewisse Entprellwirkung. Der anschließende Vergleich gibt dem 
Preller dann entgültig den Rest.

Ich habe bei allen meinen Projekten bisher immer nur 1-mal auf 
Gleichheit mit dem vorherigen Zustand geprüft und dananch keine Preller 
mehr entdeckt.

Es würde mich aber freuen, wenn Du es mal testen könntest. Vielleicht 
hast Du ja einen Taster, der so miserabel ist, daß wirklich mal 1 
Preller auf 1000 Betätigungen durchkommt.

Dann kann der Kode kann nach dem gleichen Prinzip leicht auf den 
Vergleich von 3 Registern erweitert werden.
Spätestens dann sollte die Prellsicherheit über 1/1000000 liegen.

Also, wenn Du da mal praktische Statistiken hättest, statt nur zu 
behaupten, es ginge nicht, das würde mich wirklich freuen.

Dann würde ich auch gerne den Vergleich auf 3-fach erweitern.
Damit sollte man dann sogar die Kontakte in einem Airbus zuverlässig 
entprellen können.


Peter

Autor: Michael (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Hallo Peter,

ich sagte doch, Deine Routine ist immerhin besser als Monoflops, 
zumindest für Bastelanwendungen. Baue ein Gerät, teste es durch, und es 
wird immer funktionieren. Verkaufe dieses schöne Gerät nach z.B. Mexico, 
und da funktioniert es dann nicht mehr. So ist das Leben !
Vielleicht ist es doch besser, ein paar mehr Byte zu programmieren ?

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schade, Du bleibst also auf dem "Immer-Schlechtmachen-Trip" :-(
Beweisen oder Testen hätte mir besser gefallen.

Warum sollen denn die AVRs in Mexico nicht mehr funktionieren ???


Ich baue Geräte, die intern viele Hochspannungen erzeugen müssen (bis 
15kV), d.h. die machen sich ihre Störungen selber.
Wenn da die Tasten spinnen würden, könnte das lebensgefährlich sein.
Nach Mexico haben wir, glaube ich, noch nichts verkauft, nur USA, Japan, 
Indien usw.


Peter

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nun gut, ich wollte Dir gerne wie immer das letzte Wort lassen; nun habe 
ich doch mein AVR-Starterkit (4-5 Jahre alt) ausgepackt.
Je nach Taste habe ich Preller alle 5-6 Mal. Entweder geht die LED ganz 
aus oder flackert aus-ein (je nach Taste). Habe ich doch gleich gesagt!

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Michael,

ich hab mir gestern die Finger wund gedrückt (>1000) und keinen einzigen 
Preller gesehen.

Ich habe noch das alte STK von 1997 und die Taster machen auch keinen 
labrigen Eindruck (deutlicher Druckpunkt).
Den 1200 betreibe ich mit 11.0592MHz.

Wie gesagt, in nun schon über 12 Jahren Praxis verwende ich diese 
Prinzip auf 8051-ern und bisher ist weder mir noch den Kunden ein derart 
massives Prellen bei nur 5-6 Betätigungen aufgefallen.

Ich habe also absolut keine Erklärung dafür, warum es bei Dir nicht 
funktioniert.


Peter

Autor: Michael (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Sorry, jetzt habe ich's begriffen: Dein AVR-Programm ist eine Falle !
 Du bist ja der Fan von dem ollen 8051, dem Prozessor mit dem 8-Bit 
Stackpointer, der bei rekursiver Programmierung meist das Handtuch 
wirft. Wenn dann das obige Programm auf einem AVR scheinbar anfängt zu 
spinnen, ist es wieder ein trefflicher Grund, über die hervorragenden 
AVR-Prozessoren zu schimpfen.
Ganz schön clever !

Scherz beiseite: warum zierst Du Dich so, auch 'mal die Erfahrungen 
anderer Leute anzunehmen ? Deine 'quick and dirty'-Programmierung ist 
mir schon öfter aufgefallen. Im Laufe der Zeit relativiert sich das 
'quick'; übrig bleibt dann nur 'dirty'.

Autor: Oliver K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Peter,

ich finde Deinen Code super!

Habe mich bloß gewundert, warum der achte Taster nicht funktioniert. 
Fälschlicherweise hatte ich das STK verdächtigt. Es ist aber unschuldig. 
Der At1200 hat nur die Pins PD0 -> PD6.

Grüße
Oliver

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Michael,

wenn einer Grund hat, auf den AVR zu schimpfen, dann bist das doch 
alleine Du.

Bei mir läuft es doch einwandfrei und bei Oliver auch.
Nur Du meldest laufend Probleme an.

Und dann wieder diese Beschimpfungen.
Der Code ist doch klar, knapp und logisch:
- Das SREG wird gesichert.
- Die Arbeitsregister (IWR0, IWR1) sind exclusiv den Interrupts 
zugeordnet, so daß sie nicht gepusht werden müssen.
- Das Rückgaberegister auslesen und löschen ist schön mit CLI/SEI 
geklammert.

Sämtliche AVR-Fallgruben sind also gesichert.
Der Code ist somit ohne jegliche Problem in größere Projekte 
einzubinden.

Es mag ja sein, daß ich, der mit TTL groß geworden ist, logische 
Operationen (EOR, AND, COM, OR) etwas leichter verstehe als andere.


Ich weiß wirklich nicht was Dir für eine Laus über die Leber gelaufen 
ist, andere immer so zu beschimpfen.

Dein Entprellcode, der nur eine Taste gleichzeitig kann, ist  dagegen 
wirklich 'quick and dirty'.


Peter

Autor: Dirk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nach dem Lesen der Diskussion habe ich noch eine andere
Frage:

Muß man Tasten eigentlich entprellen?
Wenn man davon ausgeht, das Tasten nicht länger als 100ms prellen (eher 
viel kürzer) reicht es aus die Taste(n) alle
110 ms abzufragen.

Was sagt Ihr dazu ?

Autor: Sebastian__ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Dirk,
nein es reicht nicht,.. da du ja wenn du zb. keinen IRQ verwendest nicht 
weist ob die taste wirklich gedrückt wurde oder nicht,.. das, was da an 
dem eingang als zustand anliegt kann ja das resultat des tastenprellens 
sein.
am besten die taste mehrere male abfragen und wenn du immer das gleiche 
ergebniss hast is es schon richtig, wenn nicht wiederhole die abfrage 
bis du mal was richtiges einliest.

das is schnell einfach zu implementieren, verbraucht keine irqs und es 
funktioniert,.. jedenfalls bei allen tasten die ich bis jetzt verwendet 
habe.

MfG
Sebastian

Autor: Fino (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Dirk

Versuchs damit: Für jede Taste richtest Du einen Zähler ein. Alle 10ms 
Taste abfragen. Wenn Taste gedrückt dann Zähler um 1 erhöhen, wenn nicht 
Zähler löschen. Wenn Zähler = 5 dann gewünschte Aktion durchführen. Dann 
kannst Du ja bei Bedarf auch noch abfragen ob der Zähler z.B. > 50 ist 
und damit eine verzögerte Repeat-Funktion realisieren. Hab ich schon 
vielfach und ohne Probleme so gemacht, Codebeispiel gibts auf Wunsch.

Fino

Autor: Steffen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei Anwendungen mit einer Tastatur zur Zifferneingabe ist es dem 
Anwender (in den meisten Fällen) eigentlich egal ob 20 oder 200ms 
vergehen, bis auf den Tastendruck reagiert wird. Also reicht eine 
Abfrage alle 100ms aus. Dann kann es max. passieren, das die Taste bei 
der ersten Abfrage noch prellt und nicht erkannt wird. Bei der nächsten 
Abfrage wird der Tastendruck aber auf jeden Fall erkannt.

Das funktioniert allerings nicht, wenn eine schnelle Reaktion auf die 
Betätigung einer Taste benötigt wird. Dann zählt aber schon der erste 
Impuls um eine Reaktion auszulösen (evtl. zweite Abfrage zur Absicherung 
gegen kurze Störimpulse)und alle nachfolgenden müssen dann durch die 
Software abgeblockt werden bis die Prellzeit vorbei ist bzw. ein 
sauberer (nicht mehr wechselnder) Pegel anliegt.

Es kommt immer auf die konkrete Anwendung an ob und wie entprellt werden 
muss.

MfG
Steffen

Autor: Dirk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Steffen,

genau das meinte ich mit meiner Frage.
Danke für die Bestätigung.

MfG
Dirk

Autor: Guestbook (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Aber sonst geht es euch gut sfg

Was bedeutet eigentlich das Prellen bei Tasten ? Ich kenne ja Zeche
prellen, aber bei Tasten ?

Autor: Florian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Könnte man das Prellen nicht auch durch nen Kondensator abfangen????

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Florian,

z.B. bei einer Matrixtastatur geht das nicht.

Wenn die Tasten jede einen einzelnen Portpin und der MC
Schmitt-Trigger-Eingänge hat, dann ginge das.

Bloß Du brauchst dann für jede Taste und für jedes Board die
Kondensatoren.

Die paar Zeilen Code mußt du dagegen nur einmal erstellen oder kopieren
und kannst sie dann ganz ohne Löten in beliebig vielen Projekten für
beliebig viele Tasten verwenden. Kostet Dich dann keinen Pfennig mehr.


Peter

Autor: Rainer D (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich enprelle die Tasten folgendermaßen:

1. Überprüfung ist Tastenpin auf high (Tastendruck, Preller ausgelöst
durch Tastendruck) und temoräre Variable auf low.

2. Wenn ja Aktion auführen und temp-var=high setzen.

3. in einer Timer-ISR wird die temp-var alle 100ms zurückgesetzt wenn
der Tasenpin low und die temp_var high ist.

Bis jetzt hat das immer sehr gut funkioniert und die Schaltung reagiert
im selben Moment in dem die Taste gedrückt wird.

MfG
Rainer

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Rainer,

niemand hat behauptet, daß es nur eine Möglichkeit gibt.

Ich habe nur gesagt, daß dieser Algorithmus besonders wenig Rechenzeit
und Speicherplatz benötigt. Außerdem kann er bis zu 8 Tasten und merkt
sich die Betätigung, auch wenn das Hauptprogramm gerade mal nicht
sofort die Taste abfragen kann.
Außerdem belegt er keinen Interrupt, d.h. der Timer kann immer noch
weitere Sachen machen, da er frei durchläuft.


Das ich auch beim Drücken verzögere, hat den Sinn, daß ich nicht
jedesmal, wenn sich einer mit elektrostastisch geladenen Pullover den
Tasten nähert, diese dann sofort verrückt spielen.

Der Mensch reagiert eh nicht schneller als etwa 300ms, da ist eine
Verzögerung um weitere 20ms völlig bedeutungslos.
D.h. für einen Menschen betrachtet, reagiert meine Routine auch im
selben Moment.


Peter

Autor: Rainer D (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Peter,

ich wollte nur mal posten wie ich meine Tasten entprelle....
Meine Routine belegt auch keinen Interrupt. der Timer ist auf immer für
andere Zwecke zu benuzten ich schreib nur am Schluß dieser Timer ISR
eine Schleife rein die obengenanntes überprüft...

Na ja was heißt wenn das Hauptprogramm mal keine Zeit hat? Wenn ich
davon ausgehe das der Taster mindestens 100ms gedrückt ist laufen bei
einem mit 4MHz getakteten AVR 400'000 Befehle drüber....ich hab noch
kein Programm verbrochen das soviel Rechenoperationen benötigt. Bei
Warteschleifen im Quellcode - sorry - da ist die Programmierung nicht
gerade die beste......

Und was die Rechenzeit angeht, die betrachte ich erst gar nicht wenn
ich eh von vorherein schon sage das 20ms nicht ins Gewicht fallen,
Das entspricht wieder 80'000 Instructions @4MHz :-). Aber wir
programmieren hier ja schließlich keine Airbag-Steuerung :-) .....
IHMO sind 99% der Themen die hier im Forum behandelt werden (meine
Projekte eingeschlossen) für die MCUs sowieso Schlaftabletten.
:-)

MfG
Rainer

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Bei Warteschleifen im Quellcode - sorry - da ist die Programmierung
nicht gerade die beste......"


Du sprichst mir voll aus dem Herzen. Leider sieht man immer wieder
Programme, wo eine ganze Sekunde oder noch länger nutzlos verpulvert
wird und dann die Klagen kommen, die CPU ist zu lahm.

Das schärfste, was ich gesehen habe, war eine DCF77-Routine, die
geschlagene 2 Minuten dauerte, also absolut völlig praxisfern.


Ich benutze immer die Main-Loop Methode und wenn ein Prozeß mal warten
muß, dann aber schleunigst zurück zu Main und den nächsten Prozeß an
die Reihe gelassen.
Bisher habe ich immer Durchlaufzeiten von nicht über 500ms erreicht,
d.h. meine Geräte reagieren auf jeden Tastendruck quasi sofort.


Leider ist das bei industriellen Heimgeräten (Videorekorder, TV, HiFi,
Waschmaschine) nie der Fall, sowas programmieren wohl ausschließlich
Stümper :-(
Schlimmer noch, die puffern nicht mal !
Wenn ich also für das Erhöhen der Helligkeit beim TV 5 Tastendrücke
brauche, muß ich immer ewig warten, bis das Menü jede einzelne Taste
auch angezeigt hat.

Und moderne HiFi Anlagen haben längere Bootzeiten, als früher die
Röhrengeräte zum Aufheizen brauchten, völlig indiskutabel.
Muß mir meine nächste HiFi-Anlage wohl doch wieder selber bauen :-(


So, nun genug Frust abgelassen, muß ja auch mal sein.


Peter

Autor: Rainer D (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

für "Warteschleifen" hab ich in jedem größeren AVR mind. 2 Timer ...
aber das ist anscheinend schwer sich vorzustellen das man ein Programm
zu großen Teilen (die kleinen bei mir ganz) in die ISRs reinschreiben
kann. Das finde ich das ist eigenlich am "schwierigsten" am  MC
Programmieren... ne Struktur zu finden in der keine Warteschleifen
benötigt werden. Wenn ich mir die (meisten) LCD Librarys z.B. anschau
.... schüttel graus ... da läufts mir kalt den Rücken runter. Da werden
doch mal eben >10k Taktzyklen vernichtet - das ist eigentlich wertvolle
Zeit um Strom zu sparen oder etwas anderes zu machen und nicht nur
verschachtelte char variablen zu erhöhen....

g Ein wenig größer betrachtet: Deßhalb brauch ich nun schon einen
>2GHz (besser 3GHz) PC um schnell Surfen zu können g. Mit einem <=1
GHz Teil wird ja mein Modem/ISDN sooooo stark runtergebremst....

MfG
Rainer

Autor: Andreas Böhme (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zwar Off-Topic:

@Peter: Meinst Du mit DCF77 zufällig die ELV Lösung von vor ca. 10
Jahren ? Da war aber nicht nur die Synch Zeit von 2 Minuten störend :)

Gruß,
  Andreas

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Andreas,

nein, ich meinte das hier:

http://www.c51.de/c51.de/Dateien/Liste.php3?showHe...

DCF77.ZIP



Peter

Autor: Thomas K (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Peter!

Beistrich sagt man bei uns in Österreich!
Ich weiß nicht ob ihr auch Semicolon sagt, wir nennen's jedenfalls
Strichpunkt :)


MfG,
Thomas K



PS.: Vielleicht sollte man gewissen Leuten hier die Unfähigkeit einen
Knopf zu drücken unterstellen :P

Autor: ulrich strehmel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo peter dannegger
bin neu im internet  forum  chat deshalb mich bitte
korrigieren wenn ich unsinn mache.
spreche Sie an,weil mir Ihre wortbeiträge und stil gut gefallen haben;
auch ich habe in chats "experten" erleben dürfen (wurde verarscht,da
neu)
seit 4 jahren mit 8515 auf assembler (stk200 alt).
einstieg als autodidakt mit stk200 Buch:S.Volpe: AVR yC
und atmel-datenblättern.
wesentliche subsysteme des 8515 durchprobiert (timer/irq/aco)
projekte: LED-Laufschrift (512LEDS),
4x7segment LED decoder in assembler (leds direkt an ports/muxen der 4
segmente).etc etc
suche hilfe von profi bei detailproblemen (habe eins mit ACO und
int, das auch atmel nicht lösen kann).

andere frage:kann man an den 8515 2 16bit parallel-audio-wandler
(A-D  D-A)
an die ports anschließen,um ein digitales audio subwoofer filter
(parameter: 6 12 18 24dB/okt // grenzfrequenz 20 - 200 Hz
Bessel Butterworth) zu realisieren ?
hat der 8515 genug rechenleistung ? (für stereo werden 2 Stück
mit identischem programm eingesetzt --> mono signal pro 8515)
welche algorithmen kommen zum einsatz (FIR oder IIR - Filtermodell
und wie funktionieren sie?)(es geht um multiply-befehle).
Idee:alle datenwörter durch 2 geteilt (rechtsschieben 1bit)/ror
und schon ist es halb so laut (wenn doch alles so einfach wäre...).
las schon einige bücher zum thema aber die mathe ist grausam.
deshalb einstieg schwierig.
antwort wäre nett.
ich kann auch verstehen,das Sie vielleicht keine lust haben,
"die welt schlauer zu machen".
nett,wenn sie mir auch dies kurz mailen an:
bukongahelas0815@netscape.net
oder tel
02741/935248
danke

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Ulrich,

Als Neuling in Foren das hier beachten:

http://www.lugbz.org/documents/smart-questions_de.html

Dann wird man auch nicht mehr freundlich darauf hingewiesen, daß man in
mehrere große Fettnäpfchen getreten ist (was Du als "verarscht"
empfunden haben magst).

Deine gröbsten Fehler sind:
- falsche Rubrik (Überschrift der Rubrik nicht gelesen)
- neue Frage nicht als neuen Beitrag gestellt
- für persönliche Beiträge gibts E-Mail


Peter

Autor: Vitali Tscheroun (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich weiss gar nicht was diese ständigen Diskussionen über Tasten
entprellen sollen. Und die ganzen entprellkods aus dem Forum finde ich
doof. Ich progge es folgender maassen: wenn einer der Tasten betätigt
wird läuft eine Zeit ab (frei ein zu stellen,je nach Anwendung) erst
dann wird das Hauptprogramm abgearbeitet. Und wenn mitten im Programm
in einer Schleife meinentwegen,wieder Eingänge abgefragt werden
müssen,dann wird davor wieder eine verzögerung programmiert.
Also total easy und garantiert kein prellen!!!
Gruss.
Vitali.

Autor: Uwe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi!
@Vitali
Schade! Du hast leider den Sinn nicht verstanden weshalb dein Posting
auch sinnlos ist.

MFG Uwe

Autor: Vitali Tscheroun (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Uwe,wenn du möchtetst kann ich dir genauer erklären was prellen ist.
Jeder der probleme mit Tasten prellen hat, wird für sich schon eine
Lösung finden.Ich habe meine eigene Lösung dafür, die sich bei meinen
Projekten bewärt hat.

MfG.
Vitali.

Autor: ulrich strehmel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
danke peter für antwort aber ich weis leider nicht welche
rubrik wo gemeint ist.der begriff ist klar,
aber in diesem zusammenhang ?
werde die empfohlene hilfeseite besuchen und hausaufgaben machen.
oder problem:wie stelle ich einen neuen beitrag ?
diese fragen sind rhetorisch und harren keiner beantwortung.
erst mal selber lesen.und nur noch zum konkreten thema schreiben.
klar.danke.uli

Autor: Michael Baldischweiler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Peter,

wenn Dir was an meiner DCF77-Routine nicht passt, dann kanst Du sie ja
mal verbessern. Unter der Vorraussetzung, dass diese in einem recht
gestörtem Umfeld läuft und der DCF77 keine sauberen Bit-Werte liefert.
Ich habe bis jetzt nur diese eine Lösung. Die eigentliche Applikation
mißt Daten. Die Abspeicherung der Zeiten muß über DCF77 ohne Ausfälle
abgeglichen werden. Es darf maximal ein DCF77-Ausfall (1 min) erlaubt
werden. Ansonsten muß eine Störmeldung per SMS gesendet werden. Am
Anfang war das der reinste SMS-Generator !!
Viel Spaß beim tüfteln !!

Autor: Fritz Fisch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Meine Güte selten soviel nütziches über das Entprellen von Tasten
gefunden. Da kann ich mich mit meinem sinnvollen Kommentar nur
anschließen :)

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Michael

"wenn Dir was an meiner DCF77-Routine nicht passt"


ich meinte konkret diesen Code:

// Modulname:    $Source:
C:/c51_buecher/Teil2/software/Peripherie/DCF77/rcs/DCF77_lib.c $
// User:         $Author: MEBA $
// Version:      $Name: $  $Revision: 1.1 $
// Datum:        $Date: 2001/02/03 11:03:35Z $


Er ist doch sehr aufwendig und dadurch schwer zu verstehen.
Wenn ich das richtig sehe, wartet es 512/3 Pegelwechsel, d.h. die CPU
ist quasi 85 Sekunden tot.


Wenn man noch Pech hat, liegt die Minutenpause gerade in der Mitte,
d.h. man hat 42 alte Bits und 42 neue, die gesamte Zeit- und
Datumsinformation ist dann fürn Arsch.

Auch so völlig ohne jede Notwendig 1024kB SRAM zu verschwenden, um
wahnsinnsschnelle 1Bit/Sekunde zu puffern ist auch nicht gerade die
feine Englische.



Meinen Code findest Du z.B. hier:

http://www.specs.de/users/danni/appl/soft/c51/thcl...

Die Impulszeitmessung erfolgt im Timer-Interrupt und die Auswertung
ganz nebenbei im Main.
Im Beispiel erfolgen noch mehrere Temperaturmessungen, ohne daß sich
beides ins Gehege kommt.
Ausgelastet ist der 2051 damit aber noch lange nicht, viele weitere
Funktion könnten also noch mit eingebaut werden.


Es ist auch ein exzellentes Beispiel, wie man Tabellengesteuert mehrere
ähnliche Aktionen (einen bestimmten Wert zu einer bestimmten Adresse
addieren) extrem Code sparend ausführen kann anstelle einer riesigen
Statemaschine (switch).


Durch die Überprüfung der Pulsanzahl, der Pulsdauer, der Pulspausen und
schließlich der Parität ergibt sich auch eine exzellente
Fehlererkennung, da ja Störungen asynchron und nicht Pegelgleich sind.



"Es darf maximal ein DCF77-Ausfall (1 min) erlaubt
werden."

Warum ?
Was machst Du dann bei Gewitter oder Wartungsarbeiten am Sender ?

Es reicht doch, wenn einmal am Tag eine fehlerfreie Information
empfangen wurde und die dann den internen Takt synchronisiert.
Ich mache es jedenfalls so und habe die Uhr in der Nähe des PCs stehen.
D.h. sobald der Monitor an ist und stört, läuft sie einfach intern
weiter.



Peter

Autor: Michael Baldischweiler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Peter,
wenn der DCF77-Empfang gestört ist, kann es zwei Möglichkeiten geben:
1. Es ist bekannt, dass durch eine Wetterlage oder durch
Wartungsarbeiten das DCF77 zur Zeit nicht arbeitet. Dann kann dies der
eigentlichen Meßstation mitgeteilt werden.
2. Oder es gibt Probleme an der Stelle, wo die Meßeinrichtung steht. In
diesem Fall muß sofort weitergemeldet werden, dass unter anderm das
DCF77 Signal nicht mehr empfangen werden kann. Es hat sich
herausgestellt, dass eine "statische Luftaufladung im großen Stil",
den Empfang stört. Da die Meßstation nichts weiter macht als eine
Luftsäuremessung, und eine Temperturmessung pro Minute, wollte ich
keine Interrupts einführen. Der Sensor für die Luftsäuremessung ist
zudem sehr träge, sodas eine häufigere Abfrage sich nicht lohnt.
Das DCF77-Signal ist zu einem weiteren Indikator geworden für die
Messstation, nicht mehr und nicht weniger :-)

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Da die Meßstation nichts weiter macht als eine
Luftsäuremessung, und eine Temperturmessung pro Minute, wollte ich
keine Interrupts einführen."


Ich habe absolut keine Idee, warum diese Sachen gegen den Einsatz eines
Interrupts sprechen sollen ?

Ich benutze Interrupts sehr gerne.
Und wenn dadurch der Code einfacher wird, dann ist daß auf alle Fälle
ein gutes Argument für den Interrupt.

Interrupts sind ja quasi eine 2.CPU, die parallel zu den anderen
Routinen arbeitet.
D.h. um eine Aufgabe, die der Interrupt erledigt, brauch ich mich dann
nicht mehr im Main kümmern.
Und ich brauche auch kein Nebenwirkungen mehr zu befürchten, die Länge
des Durchlaufs des Main behindert ja nicht den Interrupt.


Peter

P.S.:
Habe ich nun irgendwas übersehen, oder stimmt das oben wirklich, also
CPU 85s tot und 1024Byte RAM-Verschwendung.
Ich komme ja fast immer mit den 128Byte des 2051 aus.

Autor: Hagen (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hi

@Peter, ich habe mir erlaubt deine Routine als erstes Projekt für mein
neues AVR Hobby zu benutzen, bin also Einsteiger. Allerdings
programmiere ich professionell schon über 15 Jahre. Deine Methode ist
super gut und macht genau das was Software meiner Meinung nach machen
soll, Hardwarekosten senken. Man denke nur mal an ein 8x8
Matrixkeyboard. Beim Testen konnten keine Preller festgestellt werden
obwohl bei meinem STK500 der SW3 ab&zu klemmt. D.h. gerade solche
Taster fangen öfters an zu prellen.

Ich habe den Code für das STK500 Board angepasst. Die jetzige Routine
demonstriert das Entprellen von Tasten, Tastenwiederholungen mit
Zeitverzögerung und das Ansteuern einer LED per Pulsweiten Modulation.
Die Taktfrequenz/Inversion/Pulsweite der PWM kann über die entprellten
Taster eingestellt werden. Den Code poste ich hier weil ich selber als
Anfänger nicht viele gute und einfach zu verstehende Beispiele gefunden
habe. Achso, wichtig am Source war es für mich den Sleep Mode der MCU
zu nutzen !

Da es mein erstes AVR Projekt ist würde ich mich über Feedback von euch
freuen, eg. Was habe ich falsch gemacht bzw. was geht zu verbessern.
Allerdings soweit ich das verstanden habe ist PWM auf den meisten
AVR's ziemlich ineffizient wenn man die Basisfrequenz der PWM fleißend
einstellen will, richtig ?


Gruß Hagen

Autor: Carsten (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
...hallo Hagen,
ich bin beim MC Programmieren absoluter Neuling.
Wo finde ich PE2 ?
Hab jetzt mal alle LED's auf Bort B angeklemmt.
Sieht ja lustig aus, wie das flackert.
Was mache ich denn, wenn ich einzelne Ports anderweitig benötige ?
Ich würde gerne Port D für ein LCD und eine UART-Verbindung nutzen.
Ich versuche das mal zu verstehen, was Du in Deinem Proggi tust aber da
Du immer mit dem Ganzen Port arbeitest, ist es wahrscheinlich recht
aufwändig, das auf einzelne Ports umzubauen.
Da wäre es doch bestimmt einfacher die Pins einzeln abzufragen, oder ?

Autor: Carsten (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Hagen

Hast Du mal die Taster abgeklemmt,
Ziemlich wildes Verhalten.
Da man bei Überwachungsaufgaben meistens nur einen Öffner oder einen
Schließer hat, ist das nicht wirklich sicher.
Bei undefiniertem Zustand spinnt mein STK 500 zumindest völlig.

Autor: Carsten (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Peter:
Sag mal, was bedeutet eigentlich diese Zeile ?
ldi  wr0, 1<<CS02^1<<CS00

ldi ist klar. wr0 auch aber das mit den '<' Zeichen habe ich schon
mehrfach gesehen aber keine wirkliche Erklärung dazu.

Autor: peter dannegger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das ist der schiebe links operator:

1<<0 = 1
1<<1 = 2
1<<3 = 4
...
1<<7 = 128


Peter

Autor: Carsten (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
heisst das Du schiebst hier eine 1 nach bit 0...7 ?
Dann schiebst Du aber nicht sondern setzt das entsprechende Bit auf
eins.
Würde 0<<1 bedeuten bit 1 ist 0 ?

Autor: Carsten (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was beduten diese Zeilen dann genau ?

init:
  ldi  wr0, 0xFF
  out  ddrb, wr0
  ldi  wr0, 1<<CS02    ;divide by 256 * 256
  out  TCCR0, wr0
  ldi  wr0, 1<<TOIE0    ;enable timer interrupt
  out  TIMSK, wr0

wird hier wr0 auf 00000100 gesetzt ? (CS02 ist Bit2 von TCCR0, wenn ich
nicht irre).
wird wr0 vorher komplett gelöscht ?
wr0 = 4 oder 0b00000100 wäre doch viel einfacher nachvollziehbar.

Autor: plitzi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Carsten

Ich würde z.B. "1<<6" mit "eine 1 um 6 Bitpositionen nach links
verschoben" übersetzen. Das Ergebnis ist genau wie Du sagts, dass das
entsprechnede Bit gesetzt ist. Der Vorteil des Schiebeoperators
gegenüber z.B. einer direkten binären Darstelleung ("0b01000000")ist,
dass ich den Schiebeoprator z.B. auch mit definierten Pinnummern
verwenden kann und damit beim Quelltextschreiben nicht so viel denken
muss. Das ganze funktioniert auch mit einer 0 (z.B."0<<7" = "eine 0
um 7 Bitpositionen nach links verschoben"), was aber zumindest im
Zusammenhang mit einem ldi nicht allzuviel Sinn macht. Ich verwende es
trotzdem im Zusammenhang mit der Portinitialisierung. Dann kann ich
ohne die Pinnummer oder deren Namen zu schreiben oder zu löschen
entscheiden, ob der Ausgang 1 oder 0 sein soll usw.

z.B.

ldi RG0,1<<pSpiEn|1<<pSCK|0<<pMOSI|1<<pMISO|1<<pLed1|1<<pLed2

Ist zwar einmal etwas Schreibarbeit, aber aus meiner Sicht recht
flexibel und gleich einigermaßen dokumentiert.

Jörg

Autor: hanes (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Heinz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also ich habe mir mal die debounce_keys.c angeschaut von Peter Fleury,
wobei im Header steht:

"based on algorithm of Peter Dannegger", daher hier die Frage..


Was ich nicht verstehe ist, wie ich diese Port(8PIN) Entprellung in
meinem Programm nutzen kann...

Ich möchte nicht, dass die Tastenabfrage in dieser for(;;)
Endosschleife läuft, da kann cih ja nebenbei mein Programm nicht mehr
abarbeiten....

Wenn ich diese for Schleife aber weglasse, dann funzt das Programm ja
net richtig(wegen den Timern..?!)...?

Danke

Autor: peter dannegger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du weißt, wovon Du sprichst, aber die anderen nicht.

Also immer einen Link angeben, worauf man sich bezieht !

Oder die Source als Anhang.



Peter

Autor: rapeur (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,
ich habe alle ihre Beitrage über Tasten entprellen gelesen und probiert 
aber immer noch nicht geschaft.
#include <p18F4550.h>
#include <stdio.h>

diese Beispiele habe ich probiere,
char key_state;
char key_press;


#define KEY_PIN PORTDbits.RD0


  void debounce(void)
 {
 static char ct1;
 static char ct0;
 static  char i;
  i = key_state^~KEY_PIN; //key changed
 ct0 = ~(ct0 & i); // reset or count ct0
 ct1 = ~(ct1 & i); // reset or count ct1
 i &= ct0 & ct1 ;  // count until roll over
 key_state ^=i ; // then toggle debounce state
 key_press |= key_state &i; // 0->1 :key_press detect
 return key_press;
 }
 was ich gespaltet habe
unsigned char Read_buttons(static unsigned char task_old)
{
unsigned char task_old=PORTDbits.RD0
return task_old;

}

unsigned char REread_buttons (unsigned char PORTDbits.RD0, unsigned char 
task_old)
{
    unsigned char b;
    unsigned char ret;

    SPS_Timer0_FKT();    //wartezeit von 6ms
    b = PORTDbits.RD0;     // Taster auslesen
    ret = (b&task_old);  // einmalig 1, wenn zum ersten Mal gedrückt 
(kein Repeat)
     if(task_old==0)
     {
       task_old=1;

     ret=(task_old&b);

     } // wird erst wieder 1, wenn mindestens einmal eine 0 gelesen 
wurde

    return ret ;

}


unsigned float test=0;

void ENTPRELLUNG(unsigned char *PORTD, unsigned char PORTDbits.RD0)
{
  if(!(*PORTD &(1<<PORTDbits.RD0)))
  {

  if(!(*PORTD &(1<<PORTDbits.RD0)))
  {
      test++;
  if(test==4000)
  {
    test=0;

    return 1;
  }
    }
    }

    return 0;
}

ich habe immer noch nicht geschafft konntent sie mir helfen.
Gruß

Autor: Verprellter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie kann man über so ne Trivialaufgabe eigentlich so lange öffentlich 
labern...?

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Verprellter wrote:
> Wie kann man über so ne Trivialaufgabe eigentlich so lange öffentlich
> labern...?


Es gibt reichlich Geräte, die zeigen, daß das Thema nicht trivial ist 
bzw. nicht verstanden wird.
Ständig muß man sich über prellende Tasten oder verlorene Tastendrücke 
ärgern.

Oft denken die Leute, daß der Kunde bei einfachen Geräten keine 
funktionierende Entprellung haben will.
Die internen Ablaufzeiten werden schon irgendwie mehr schlecht als recht 
ne rein zufällige Entprellung ergeben.
Dabei paßt eine funktionierende Entprellung selbst in nen kleinen 
6-Pinner PIC.

Aber auch bei Fahrstuhlsteuerungen habe ich schon prellende Tasten 
erlebt.


Peter

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
rapeur wrote:
> Hallo zusammen,
> ich habe alle ihre Beitrage über Tasten entprellen gelesen und probiert
> aber immer noch nicht geschaft.

Was soll der Code machen?

Wo ist das Main?

Längeren Code als Dateianhang.

Was ist "unsigned float"?

Wird Dein Code ohne Fehler und Warnungen übersetzt?

Entscheide Dich für einen Entprellcode, 2 verschiedene zusammen zu 
pappen ist unsinnig und kann nicht funktionieren.

Alle Compiler kennen Bytevariablen und logische Operationen mit 
Bitmasken.
Manche Compiler unterstützen aber auch Bitvariablen.
Finde heraus, was Dein Compiler kann und entscheide Dich für eines 
davon. Beides zu mischen ist verboten (zumindest für Anfänger).


Peter

Autor: Leyna S. (leyna)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Peter,
ich bin letzte Woche in das Thema µC eingestiegen und habe mir erst mal 
die kompletten Tutorials zu diesem Thema durchgelesen.
Um erst einmal ein paar grundlegende Sachen zu verstehen und 
auszuprobieren, habe ich unter anderem auch deinen Algorithmus zum 
Entprellen von Tastern verwendet. Ich habe allerdings etliche Male 
versucht mir klar zu machen, wie dein Algorithmus funktioniert, aber ich 
habe es nicht geschafft. Könntest du mir vielleicht deine Vorgehensweise 
erklären?
Konkret habe ich folgende Fragen: Welche Bedeutung haben iwr0, iwr1 und 
key_state? Welchen Zweck erfüllen die einzelnen boolschen Operationen, 
z.B. wozu invertierst du key_old? Wieso heißt es in der Beschreibung, 
die Tasten werden 4 mal abgetastet? Ich habe das ganze mal mit einem Bit 
simuliert und erst nachem 2mal hintereinander eine 1 und 2mal 
hintereinander eine 0 anlagen, wird der Tastendruck als solcher 
gewertet. Wie speichert aber dein Algorithmus "2mal 1 und 2mal 0 
hintereinander"? Ich finde es erstaunlich, dass das ganze nur mit 
boolschen Operationen funktioniert, aber wie gesagt, verstehen tue ich 
es noch nicht ganz.
Danke schon mal.

Autor: DeppchenDoof (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mir gehts genauso wie Dir, ist wohl nix für Anfänger...

Ich hab jetzt auch einige Zeit dran geknabbert und stelle mir die 
gleichen Fragen. Jetzt hab ich mal versucht, das mit AVM-Studio 
nachzuvollziehen aber so wie es da steht, funktioniert es scheinbar 
garnicht. Egal was eingelesen wird, key_press bleibt bei mir am Ende 
immer 0x00.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Leyna S. wrote:
> Konkret habe ich folgende Fragen: Welche Bedeutung haben iwr0, iwr1

Interrupt-Working-Register 0, 1 usw.
Da der AVR ja viele Register hat, ist es effizient, einige davon für 
Interrupts zu reservieren, spart viel PUSH/POP ein.


> key_state?

Merkt sich den entprellten Tastenstatus.

> Welchen Zweck erfüllen die einzelnen boolschen Operationen,
> z.B. wozu invertierst du key_old?

Weil die Tasten low-aktiv sind, aber ich dann später in der 
Tastenauswertung lieber ne 1 für Gedrückt haben will.

> Wieso heißt es in der Beschreibung,
> die Tasten werden 4 mal abgetastet?

Ist bei dem obigen Code auch nicht der Fall
Der mit der 4-fach Abtastung ist der hier:

Beitrag "Tasten entprellen - Bulletproof"


> Ich habe das ganze mal mit einem Bit
> simuliert und erst nachem 2mal hintereinander eine 1 und 2mal
> hintereinander eine 0 anlagen, wird der Tastendruck als solcher
> gewertet.

Ja, stimmt.

Wie speichert aber dein Algorithmus "2mal 1 und 2mal 0
> hintereinander"?

Mit Hilfe von "key_old".

> Ich finde es erstaunlich, dass das ganze nur mit
> boolschen Operationen funktioniert

Ich habs mit Gattern erstmal für nur 1 Bit entwickelt.


Peter

Autor: DeppchenDoof (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Kann mir denn jemand verraten, warum das bei mir nicht funktioniert? Ich 
meine doch, ich hätte den Code 1:1 übernommen (ergänzt um 
Stackpointer-Initialisierung), von pind werden auch Werte eingelesen, 
aber am Ende der Verknüpfungs-Orgie bleibt key_press irgendwie immer 
ohne Wert. Was mach ich denn falsch?

Autor: Peter Dannegger (peda)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
DeppchenDoof wrote:
> Kann mir denn jemand verraten, warum das bei mir nicht funktioniert?

Nein.
Ich hab Deinen Code auf mein STK500 gebrannt, er läuft wie dumm.

Ich hab zwar keinen Mega8515, sondern nen Mega162, aber die sind ja 
kompatibel.
Anbei mal das Hex aus Deinem Code für den Mega8515.


Peter

Autor: DeppchenDoof (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jesses, ich doof, kaum macht mans richtig, schon gehts. Hätte ich nur 
mal aufmerksam gelesen ("Ich habe das ganze mal mit einem Bit
simuliert und erst nachem 2mal hintereinander eine 1 und 2mal
hintereinander eine 0 anlagen, wird der Tastendruck als solcher
gewertet.") oder wahlweise einfach schonmal selbst mitgedacht... =)

Brennen wollte ich das ja nur, wenn ichs auch verstehe, deswegen bin ich 
noch mit dem Simulator zugange. Aber den sollte man dann vielleicht auch 
richtig bedienen...

Vielen Dank für Deinen Beistand!

Autor: Christian T. (tschaboo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Peter,

jetzt, wo ich die Funktionsweise deines Algorithmus endlich kapiert 
habe, muss ich sagen, dass dieser echt genial ist! Er ist, wie beworben, 
kurz und schnell.

Probleme hatte ich hauptsächlich deswegen, weil die Funktionsweise unter 
http://www.mikrocontroller.net/articles/AVR-Tutorial:_Tasten schlicht 
falsch beschrieben ist. Gemeldet wird die Flanke dann, wenn zwei Mal die 
Taste gedrückt war und davor zumindest zwei Mal nicht gedrückt war, 
richtig?

Ich würde das auch selber ändern, fühle mich hier aber noch nicht so 
heimisch. Das ist mein erster Post, mit Mikrokontrollern arbeite ich 
seit gestern :)

Und was in diesem Thread geschimpft wurde ... da dreht's einem ja fast 
den Magen um. Danke, dass du deine Routine trotzdem veröffentlicht hast.

LG,
Christian

Autor: Magnus C. (tiny_brain)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Peter,

zunächst mal herzlichen Dank für Deine Beiträge und den Code zum Thema 
Tastenentprellung.

Ich habe Deine IRQ-Routine eine ganze Weile nicht verstanden, daher habe 
ich das Ganze mal in Excel simuliert. Dabei ist mir (durch Zufall) 
aufgefallen, dass die Routine bei verschiedenen Sequenz von 
"Verprellern" (also h/l-Folgen) in einen Status fällt, der den 
Tastendruck komplett ignoriert.

Ich habe das Excelsheet mal im Anhang dazugepackt. Ich habe es mehrfach 
überprüft und glaube nicht, einen Fehler gemacht zu haben. Wenn Du 
magst, kannst Du ja mal reinschauen. Ich habe zuerst gedacht, es ist ein 
Excel-Problem, aber das hat sich nicht bestätigt. Habe dann auf Deinem 
Ansatz (mit Interstates) aufgesetzt die Routine verändert. Das 
Codestückchen habe ich interessehalber dazu gepackt.

Übrigens, da ich viel mit Tinys (wenig Pins) mache, diese 
Tastenentprellung funktioniert auch für Eingänge, die gleichzeitig auch 
als Ausgang genutzt werden. Daher am Anfang die Abfrage auf DDR-Status. 
So kann man eine Einknopfbedienung bauen, bei der nur ein Pin benutzt 
wird. Auch bei "schnell, also zwischen 10-500ms" blinkenden LEDs 
funktioniert die Tastenerkennung super.

Beste Grüße
Magnus

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Magnus C. schrieb:
> Ich habe Deine IRQ-Routine eine ganze Weile nicht verstanden, daher habe
> ich das Ganze mal in Excel simuliert. Dabei ist mir (durch Zufall)
> aufgefallen, dass die Routine bei verschiedenen Sequenz von
> "Verprellern" (also h/l-Folgen) in einen Status fällt, der den
> Tastendruck komplett ignoriert.

Um einen Zustandswechsel zu akzeptieren, erwartet die Routine viermal 
aufeinanderfolgend low bzw. high.
Kürzere Wechsel werden ignoriert. Du kannst z.B. 3  low und 3  high 
ständig im Wechsel senden, es ändert sich nichts.


> Ich habe das Excelsheet mal im Anhang dazugepackt.

Ich hab kein Excel.

Ich hab aber gesehen, daß Du den Code völlig umgestellt hast.
Das könnte natürlich eine andere Funktion bewirken.
Warum nimmst Du nicht den funktionierenden Code?

http://www.mikrocontroller.net/articles/Entprellun...


> Übrigens, da ich viel mit Tinys (wenig Pins) mache, diese
> Tastenentprellung funktioniert auch für Eingänge, die gleichzeitig auch
> als Ausgang genutzt werden.

Das macht nichts.
Die Pins werden unabhängig entprellt, man muß auf Ausgänge keine 
Rücksicht nehmen.


Peter

Autor: Magnus C. (tiny_brain)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Peter,

danke für die schnelle Antwort.

1) Ich betrachtete bei der Simulation nur einen Pin. Mir ist klar, dass 
bei Deiner Programmierung jeder Pin einzeln betrachtet wird. Das mit dem 
Zustandswechsel kann man in der Simulation sehr schön sehen. Daher 
behaupte ich, dass bei bestimmten Prellsituationen (L-H-H-H-H-L-L-H...H) 
die einzelne Taste nicht erkannt wird. Der Code ist damit ein bisschen 
buggy. Daher habe ich ihn umgestellt. In der Simulation funktioniert 
"meine" Änderung ohne die Effekte.
Die Fehlersituation ist im Testfeld so gut wie nicht zu simulieren. Es 
könnte einfach nur so sein, dass man hin und wieder die Taste drückt und 
nix passiert.
Schade, dass Du kein Excel hast, sollte Dich das Ergebnis aber 
interessieren, kann ich versuchen es auch anders auszugeben, dann kann 
man nur nicht so schön spielen, denn das Excel-Sheet rechnet.

2) Ich meine nicht unterschiedliche Pins, sondern den gleichen Pin zur 
Ausgabe einer LED und Tastereingabe. Man benutzt Taster gegen Masse, LED 
gegen Plus, PORTnx=0 gesetzt -> Schalten der LED mit DDRnx, in den 
Dunkelphasen der LED kann man den Taster abfragen (und der User sieht 
seinen Tastendruck durch LED-Leuchten). Ich gebe dann das Feedback über 
unterschiedliche Blinkfrequenzen. Funktioniert super!

LG
Magnus

Autor: Peter Dannegger (peda)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Magnus C. schrieb:
> Daher
> behaupte ich, dass bei bestimmten Prellsituationen (L-H-H-H-H-L-L-H...H)
> die einzelne Taste nicht erkannt wird. Der Code ist damit ein bisschen
> buggy.

Mit dieser schwammige Behauptung kann bloß niemand was anfangen.

Warum schreibst Du nicht einfach die magische Kombination auf, die 
Deiner Meinung nach buggy sein soll?


> Daher habe ich ihn umgestellt. In der Simulation funktioniert
> "meine" Änderung ohne die Effekte.

Er ist zumindest deutlich aufwendiger (2 zusätzliche if-Anweisungen).
Aber solange ich nicht weiß, wogegen er helfen soll, kann ich ihn nicht 
beurteilen.

Dazu brauchts auch kein Excel, schreib einfach die Sequenz hin 
(0-0-1-1-..) und gut is.

Anbei noch ein Testprogramm, womit man schön auf STK500 simulieren kann, 
da mit 1s entprellt wird, d.h. man muß >4s drücken oder loslassen.


> Die Fehlersituation ist im Testfeld so gut wie nicht zu simulieren.

Was soll denn das nun wieder heißen?
Wie hast Du dann den Fehler festgestellt?

Ist es denn wirklich so schwer, einen aussagekräftigen Fehlerreport zu 
verfassen?


Peter

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Magnus C. schrieb:
> 2) Ich meine nicht unterschiedliche Pins, sondern den gleichen Pin zur
> Ausgabe einer LED und Tastereingabe. Man benutzt Taster gegen Masse, LED
> gegen Plus

Daran stört mich, daß die LED nicht reagiert, solange die Taste gedrückt 
ist.
Daher benutze ich folgende Lösung:

Beitrag "Taster + LED am selben Draht (4*)"


Peter

Autor: Magnus C. (tiny_brain)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Hallo Peter,

mach Dich locker!
Ich will Dich bestimmt nicht ärgern. Trotzdem befürchte ich, habe ich 
recht. Ich habe den Fehler in einer Simulation bemerkt!!

Eine logische Folge hatte ich oben genannt. Es gibt mehrere.

Danke für die STK500-Routine, ich werde meine logische Folge mit Deinem 
Code testen und dann berichten.

Grüße
Magnus

Autor: Magnus C. (tiny_brain)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Peter,

cool, das ist definitiv besser als meine Lösung. Danke für den Hinweis!

Gruß
Magnus

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Magnus C. schrieb:
> mach Dich locker!

Naja, Du behauptest, da wäre ein Fehler, kannst ihn aber in keinster 
Weise belegen.

Der Code wird auch von vielen anderen benutzt und verstanden, da sollte 
ein Fehler schon längst aufgefallen sein.

Da er nur logische Operationen benutzt, ist er fehlerfrei. Ansonsten 
müßte man AND/OR/XOR/NOT und Zähler mit D-FF neu definieren. Ich hab ihn 
nämlich erst als Logik-Schaltplan entwickelt mit nem GAL.

Viel warscheinlicher ist daher, daß der Fehler in dem Code liegt, den Du 
nicht gezeigt hast und Deine Änderung nur die Symptome bekämpft, nicht 
aber die Ursache.
Sehr häufig gemachte Fehler sind Atomic- und Volatile-Fehler.

Wichtig ist natürlich, genau die Reihenfolge der Operationen 
einzuhalten, sonst funktioniert der Zähler nicht richtig.


> Ich will Dich bestimmt nicht ärgern. Trotzdem befürchte ich, habe ich
> recht. Ich habe den Fehler in einer Simulation bemerkt!!

Dann müßtest Du ihn ja auch reproduzieren können. Und dann auch 
beschreiben.
Bisher hast Du aber nicht mal ein kleinstes Pfitzelchen konkretes 
gesagt.

Kommt mir so vor, wie die vielen, die eine Bug im C-Compiler finden und 
dann später feststellen, das der Fehler doch auf der anderen Seite des 
Bildschirms lag.


> Eine logische Folge hatte ich oben genannt. Es gibt mehrere.

Wo denn bitte.

Wenn der Fehler in Excel auftritt, ist das nur ein Beweis, daß die 
Umsetzung in Excel fehlerhaft ist. Oder kann man in Excel etwa direkt 
C-Code eingeben?
Wenn Du etwas simulieren willst, nimm besser den Simulator im AVRStudio. 
Der ist deutlich näher an der Realität als Excel.


Peter

Autor: Magnus C. (tiny_brain)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Trotzdem befürchte ich, habe ich
> recht. Ich habe den Fehler in einer Simulation bemerkt!!

....sorry, ich hatte unrecht!!
Ich habe mit Deiner Routine meine Sequenzen getestet und habe einen 
Fehler in der Simulation gefunden. Deine Routine funktioniert 
einwandfrei. Ich werde Deinen Code zukünftig in meinen Tastenabfragen 
einbauen.

Danke nochmals für die Unterstützung!

Beste Grüße
Magnus

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also manchmal... lach

Autor: Hannes Lux (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Also manchmal... lach

Ja, manchmal fällt es wirklich schwer, sich zurück zu halten... ;-)

...

Autor: Bernhard (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Peter,

du hast oben geschrieben, dass Du die Routine schon längere Zeit für 
8051er verwendest. Könntest du vielleicht auch eine 8051er adaptierte 
Version des Sourcecodes online stellen?

Wäre super.

Autor: Alex Bürgel (Firma: Ucore Fotografie www.ucore.de) (alex22) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich möchte an dieser Stelle mal einen großen Dank an Peter Dannegger 
aussprechen. Ich benutze die "C-Komfortroutine" inzwischen in einigen 
Projekten und die ist wirklich klasse. Einfach und Zuverlässig.

Vielen Dank & viele Grüße,
Alex

Autor: Bernd Stein (bernd_stein)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
peter dannegger schrieb:
>...
> Die eigentliche Einlese- und Entprellroutine ist nur 8 Instruktionen
> kurz.
>...
Hallo,

gehe ich richtig in der Annahme das es sich dabei um die beiden letzten 
Zeilen handelt die wegfallen könnten ?

  and  iwr1, iwr0         ;                    00000010
  or   key_press, iwr1    ;store key press detect

>...
>
> Zum Verständnig empfiehlt es sich daher, die Logikgleichungen mit
> Gattern für ein Bit = eine Taste aufzumahlen.
>
> Die Register kan man sich als Flip-Flops denken, die mit der
> Entprellzeit als Takt arbeiten.
>...
>
Das habe ich gemacht, weil ich dachte dann würde ich die Routine 
verstehen.
Aber ehrlich gesagt hat das nur alles verschlimmert. Nun versteh ich 
noch weniger.

Irgendwie habe ich auch das Programm nicht richtig in Logikgatter 
umgewandelt, denn beim Exklusiv Oder-Gatter ( 8 ) Ausgang ( key_state ) 
ist mir beim durchspielen ein Fehler aufgefallen.

Danach dann ganz deutlich das beim Oder-Gatter ( 10 ) Ausgang
( key_press ) erst recht etwas nicht stimmt, denn key_press bleibt ja, 
wenn einmal auf eins immer auf eins.

Wo sind meine Fehler oder besser wie sieht der Logik-Gatter-Plan richtig 
aus ?

Anbei noch meine Umwandlung vom Programm in eine Logik-Gatter-Schaltung.

Bernd_Stein

Autor: Bernd Stein (bernd_stein)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernd Stein schrieb:
> ...
> Wo sind meine Fehler oder besser wie sieht der Logik-Gatter-Plan richtig
> aus ?
>
>...
>
Habe inzwischen im zweitletzten Beitrag zur erweiterten bzw. noch 
sichereren Entprellung den dazu passenden Logikgatterplan gefunden.

http://www.mikrocontroller.net/attachment/125089/D...

Beitrag "Tasten entprellen - Bulletproof"

Mal sehen wie ich damit zurecht komme.

Bernd_Stein

Autor: Conny G. (conny_g)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Herzlichen Dank an Peter für die geniale Entprellroutine.
http://www.mikrocontroller.net/articles/Entprellun...

Gestern eingebaut und nach kaum einer halben Stunde perfekt 
funktionierende Taster gehabt.

Danke!!

Vg,
Conny

Autor: Thomas O. (kosmos)
Datum:
Angehängte Dateien:

Bewertung
-1 lesenswert
nicht lesenswert
ich gehe in dem Fall so vor, erstmal mit dem Oszi oder zur Not mit dem 
LA das Prellen des Tastern feststellen, danach mache ich meine 
Entprellroutine mit entsprechenden Sicherheitsabstand da die Tastern 
auch mal altern.

Beispiel 1: Bei Flankenwechsel High/Low, Aktion auslösen, Interrupt 
sperren und Interrupt erst wieder nach z.B. 5 mSek per Timer aktivieren.

Beispiel 2: Nach Flankenwechsel und Verzögerungszeit, wird mehrmals der 
Zustand eingelesen und mit den letzen beiden malen verglichen.

Beispiel 3: Ware eine zusätzlich Plausibilität, man vergleicht also ob 
es sein kann das jemand den Taster nur 2mSek lange gedruckt hat und 
ignoriert das dann z.B. komplett.

Autor: Harald Fuckar (haraldwien)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wahrscheinlich weil ich ein AVR+Assembler-Neuling bin:
Ich komm' einfach nicht dahinter wozu der Label "get8key:" in der 
einfachen Entprellroutine von Peter gut ist?
Gibt's jemand der mich aufklärt?

Aber in Wien würde man zu der Entprellroutine - anerkennend! - sagen: 
"Der Beda is a Hund!", was hierorts  durchaus als Kompliment gilt!
Servus aus Wien
Harald

Autor: Conny G. (conny_g)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Harald Fuckar schrieb:
> Ich komm' einfach nicht dahinter wozu der Label "get8key:" in der
> einfachen Entprellroutine von Peter gut ist?

Ich bin jetzt auch kein Asm Crack, aber das Label hat m.E. keine 
Funktion (mehr):
Man dürfte es auch nicht von ausserhalb anspringen (oder planen so etwas 
zu tun), weil dann Register zurückgesichert werden, deren Absichern man 
übersprungen hat. Und das beim Anspringen zu berücksichtigen - da wird 
es m.E. etwas zu hacky.

Man könnte es als descriptiven Funktionsnamen verstehen oder es ist ein 
Relikt aus dem Originalcode wovon Peter abstrahiert und hier eingestellt 
hat.
Ansonsten: wer kann sich ein nutzloses Label schon leisten! Man muss 
zeigen, was man hat :-)

Autor: Heiner (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Harald Fuckar schrieb:
> Ich komm' einfach nicht dahinter wozu der Label "get8key:" in der
> einfachen Entprellroutine von Peter gut ist?


Tja, das kommt davon, wenn man schlecht geschriebenen/dokumentierten
Code verwendet. Hier recht es sich, dass nicht sauber programmiert 
wurde.


lg Heiner

Autor: Harald Fuckar (haraldwien)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo @conny_g!
Ja, das hab' ich auch vermutet, dass dieser Label ein "Überbleibsel" 
ist. Na, dann sind wir ja schon zwei, die das denken.

Heiner schrieb:
> Tja, das kommt davon, wenn man schlecht geschriebenen/dokumentierten
> Code verwendet. Hier recht es sich, dass nicht sauber programmiert
> wurde.

Lieber Heiner.
Dein Kommentar ist leider nicht sehr konstruktiv und hilft überhaupt 
nicht. Wenn Du Kritik äußerst, bitte konkret werden, damit auch andere 
davon profitieren können.
Im übrigen: Wenn die mit "recht" das Wort gemeint hast, dass sich von 
"Rache" ableitet, dann solltest Du in Zukunft "rächt" schreiben.
Ich vermute mal, dass "Rächtschreiben" nicht Deine Sterke ist ;-)
Aber unsachlich kritisieren ...

Autor: Harald Fuckar (haraldwien)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jetzt, nachdem ich mir nochmals die Peter-Danegger-Entprellung zugeführt 
habe, habe ich doch noch folgende Fragen:

1. Ich möchte eine Taste drücken und eine Zeitlang halten. Und solange 
die Taste gedrückt ist, möchte ich vom uC eine Aktion ausführen lassen 
(z.B. Klingeln). Erst wenn die Taste wieder losgelassen wird, möchte ich 
auch die Aktion beenden. Bei diesem Beispiel gibt es zwei Flanken 
LOW>HIGH=TasteIstGedrücktWorden und HIGH>LOW=TasteIstLosgelassenWorden.
Über Betrachtungsweisen bzgl. PullUp vs PullDown habe ich mich hier 
bereits informiert - sie sind aber nicht ggst. Thema.
Wenn ich Peter Danegger's "Einfache Tastenentprellung und Abfrage" 
richtig verstanden habe, bekomme ich aber bei der Methode nur gemeldet, 
dass eine Taste (im ActiveLowMode) gedrückt wurde. Das Loslassen der 
Taste, also die gegenteilige Flankenänderung krieg ich damit aber nicht 
mit - oder?
Die erweitere Funktion "Tastenentprellung, Abfrage und Autorepeat" ist 
aber für meine Aufgabenstellung auch nicht geeignet, da sie ja das 
wiederholte Drücken einer Taste simuliert. Das entspricht aber nicht der 
(meiner Beispiel-) Realität. Ich möchte gerne erkennen, dass eine Taste 
gedrückt oder losgelassen wurde UND sie dabei ordentlich entprellen.
Mein erster Ansatz war ja mit einer Interrupt-Logik (Interrupt, wenn 
Tastenpin sich ändert). Dann bin ich über's Entprellen ins Grübeln 
gekommen und hab' hier im Forum gelesen, dass eine Interrupt-Lösung für 
Tastendrücke "PfuiGack" ist.
Und jetzt steh' ich schön da und weiß nicht wie ich's möglichst 
ordentlich mach', das Entprellen. Denn wenn's das nicht geben würde, wär 
die Elektronikwelt aber sowas von einfach und sonnig ;-)

Kann mir wer raten?

Autor: Conny G. (conny_g)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Harald Fuckar schrieb:
> Kann mir wer raten?

Ich weiss jetzt nicht, ob Du die ASM oder die C-Version anschaust, aber 
muss man nicht einfach in dieser Routine:
///////////////////////////////////////////////////////////////////
//
// check if a key has been pressed. Each pressed key is reported
// only once
//
uint8_t get_key_press( uint8_t key_mask )
{
  cli();                                          // read and clear atomic !
  key_mask &= key_press;                          // read key(s)
  key_press ^= key_mask;                          // clear key(s)
  sei();
  return key_mask;

das
  key_press ^= key_mask;                          // clear key(s)

weglassen?

Autor: Harald Fuckar (haraldwien)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke @conny_g für Deine Antwort!

Ich glaub' ich hab' die Lösung - für mich - gefunden:

Kostet mich ein Register:
Ich merk' mir den "alten" key_state-Wert im Register key_stalt.
Und wo bisher temp1 auf 0 abgefragt wurde, vergleiche ich die beiden 
Register. Hat sich bei einer oder mehreren der betrachteten Tasten was 
geändert, dann muss ich nur die entsprchende Aktion starten: Also z.B.: 
LED1 aus wenn Status der Taste1 "nicht gedrückt", LED1 ein wenn Status 
der Taste1 "gedrückt", usw.
Und dann muß ich mir natürlich den aktuellen key_state-Inhalt für den 
nächsten Vergleich in key_stalt holen.

Auf diese Art kann ich die Vorteile der Peter-Danegger-Entprellung 
nutzen und hab' dazu die von mir gewünschte Lösung - PRIMA!

Na der Peter Danegger wird "Schnackerl" (Schluckauf) haben.
(Sagt man in Wien, wenn von einem gesprochen oder an einen gedacht wird 
;-)

Autor: Heiner (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
>(Sagt man in Wien, wenn von einem gesprochen oder an einen gedacht wird
>;-)

Also in den letzten 100 Jahren ist nicht viel sinnvolles aus
Oesterreich gekommen. Und das oben stehende wird daran nichts aendern.

lg Heiner

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.