Auf besonderen Wunsch eines einzelnen habe ich die Routine erweitert, um
auch die labrigsten Tasten der Welt entprellen zu können.

Diese Version ist also wirklich kugelsicher.

Es werden jetzt 4 gleiche Zustände hintereinander benötigt, um als
gültiges Drücken oder Loslassen erkannt zu werden.
Dadurch hat sich die Ausführungszeit von 10 auf 12 Zyklen verlängert.

Außerdem habe ich den Vorteiler verkürzt, da sonst durch das nun
4-malige Abtasten eine deutliche Verzögerung sichtbar wäre.


Die Funktionsweise ist folgende:

Die Bits der Register CT0, CT1 bilden für jede Taste einen Zähler 0..3.
Ist der Tastenzustand mit dem entprellten Zustand identisch, wird dieser
2-Bit Zähler permanent zurückgesetzt.

Nur wenn also 4-mal hintereinander der entgegengesetzte Tastenpegel
anliegt, kann dieser Zähler einmal rum zählen (= 4 Zustände 0..3) und
wenn dann immer noch der entgegengesetzte Tastenpegel anliegt, wird er
von dem entprellten Register (key_state) übernommen.
Da die Tasten low-activ sind, bedeutet dort eine 1 = Taste gedrückt.


Ich habs noch nicht getestet. Das Prinzip sollte das oben beschriebene
sein. Falls sich wider Erwarten doch ein Fehler eingeschlichen haben
sollte, sind sachliche Kommentare herzlich willkommen.


Peter

P.S.:
Beschimpfungen statt sachlichen Kommentaren bitte per E-Mail direkt an
mich richten, anstatt damit das Forum zu verunstalten.


Peter

Ups, da war ich wohl etwas zu hektisch.

Hier nochmal ohne Schreibfehler.


Peter

Und hier nochmal für die C-Freaks (Keil C51).


Peter

Hier findet man die nötige Theorie dazu:

http://www.ece.umd.edu/~msquared/rtas2000.pdf


Peter

und das ganze, wenn ich nur eine taste habe, die einen interrupt
auslöst?

Ja, für eine Taste sind 4 Register etwas viel Speicherverbrauch.

Hier im Zip-File:

http://www.mikrocontroller.net/forum/read-4-32158.html

findest Du die Routine "ovf0int.inc", die nur eine Taste abfragt und
dafür auch nur 4 Bits eines Registers benötigt.

Das Prinzip ist aber dasselbe.


Peter

@Martin,

"die eintastenroutine ist ok, aber ich meine natürlich wieder einmal
was anderes: die taste zu entprellen, die den interrupt auslöst!"


Wie Du bestimmt auch in den anderen Entprellroutinen gesehen hast, muß
man mindestens noch ein weiteres mal den Eingang nach einer Wartezeit
abtesten.

Warten in einem Interrupt ist jedoch tödlich, da solange ja auch alle
anderen Programmroutinen hängen bleiben.

Du must also einen Timerinterrupt verwenden, um die Wartezeit zu
realisieren.

Und daher ist es ziemlich witzlos, noch zusätzlich einen externen
Interrupt zur Tastenabfrage zu verwenden. Das kostet Dich nur unnötig
Code.

So ein Timerinterrupt ist auch ja sehr nützlich, um sämtliche anderen
Zeitabläufe zu machen.
Kein einziges meiner Programme kommt ohne den Timerinterrupt aus.


Peter

Habe soeben versucht, das Programm Get8key4.c51 (siehe Beitrag weiter
oben) nachzuvollziehen. Die Idee, die Zählbits auf verschiedene Bytes
zu verteilen und damit eine sehr kompakte und schnelle
Tastenentprellung zu realisieren ist wirklich Klasse. Würde mich
freuen, wenn jemand bereit ist etwas Hirnschmalz zu investieren um
meinen Überlegungen zu folgen. Vielleicht kapier' ich das Programm
aber auch einfach nicht. ;-)

  i = key_state ^ ~KEY_INPUT;  // key changed ?
Das entsprechende Bit in i ist 0 bei Änderung (Wenn key_state <>
KEY_INPUT)

  ct0 = ~( ct0 & i );    // reset or count ct0
? toggeln der Bits in ct0 ist Teil des Zählvorgangs, der in ct0 und ct1
abläuft. Das geschieht hier, wenn das entsprechende Bit in i == 1 ist,
also solange keine Änderung vorliegt. Ist i(n) = 0 (bei Änderung) wird
ct0(n) bei jedem Aufruf wieder auf 1 gesetzt. Laut Beschreibung im
ersten Beitrag sollte der Zähler aber permanent zurüchgesetzt werden
solange key_state == KEY_INPUT.

  ct1 = ct0 ^ ct1 & i;    // reset or count ct1
? Wie oben, bei i(n) = 0 (also bei Änderung, wenn key_state <>
KEY_INPUT) wird der Zähler zurückgesetzt.
? Beim Zählen würde der Zustand ct1(t) tatsächlich aus ct0(t-1) und
ct1(t-1) durch EXOR-Verknüpfung gebildet. Der Befehl oben verwendet
aber bereits ct0(t) anstelle ct0(t-1). Damit das wieder passt müsste
der Term (ct0 ^ct1) invertiert werden.

  i &= ct0 & ct1;    // count until roll over
? Auch diese Zeile ist mir nicht klar geworden.

Im Simulator macht der Programmcode aus Get8key4.c51 nicht was er
soll.

Hier ist meine Version:

  i = key_state ^ KEY_INPUT;
  ct0 = ~ct0 & i;
  ct1 = ~( ct1 ^ ct0 ) & i;
  i = ~ct1 & ~ct0 & i;
  key_state ^= i;

Habe den Programmcode durch den Simulator laufen lassen: -> geht!

Andi

@Andi,

die Signale CT0 und CT1 sind invertiert. Damit spart man etwas Code ein
(in Deinem Code sind 3 Invertierungen mehr). Ansonsten funktiert es
gleich.

Das ich ~KEY_INPUT nehme, liegt daran, daß man üblicher Weise die
Tasten gegen GND schaltet und somit den internen Pull-Up-Widerstand
nehmen kann.
Man spart also einen Widerstand ein.

Also:
Taste gedrückt -> KEY_INPUT = 0 -> key_state = 1


In meinem Scheduler Beispiel in der Codesammlung ist das auch auf dem
AVR verwendet worden (WINAVR).


Peter

@Andi,

aber super von Dir, daß du es nicht nur stumpf abkopiert hast, sondern
auch versucht hast, es nachzuvollziehen und das erfolgreich.


Peter

@Peter,

Danke für die Hinweise. Habe inzwischen auch herausgefunden warum Dein
Programm bei mir nicht richtig simulierte.
I. Mein Compiler wollte bei ct1 = ct0 ^ ct1 & i; Klammern haben, die
hatte ich falsch gesetzt. Jetzt gehts. Es compiliert auch tatsächlich
um zwei Befehle kürzer als meine Version.
II. Werden mit static deklarierte lokale Variablen (ct0 und ct1)
standardmässig vom Compiler initialisiert? Zumindest der Simulator
machts. Dann übernimmt Dein Programm KEY_INPUT bereits beim ersten
Durchlauf nach key_state. Meine Variante benötigt zunächst 4 Aufrufe
und entprellt so auch unmittelbar nach Programmstart anliegende
Schalterzustände. Macht in der Praxis wohl keinen Unterschied. Hat mich
aber bei der Simulation zunächst verwirrt.

Andi

ups und das ganze nun nochmal für richtige DAUs :)

Ich hab hier nen AT90S8535 in Betrieb und am PortD 8 Taster drann

Ich programmiere mit dem CodeVision AVR Compiler und komme mit dem Code
selbst nicht zurecht. Ich weiß ja noch ncihtmal wie ich solche
Interupts verwende ob nun externe oder interne :(

Ich wäre dankbar für jede hilfe

@Robert,

ein komplettes C-Beispiel findest Du hier:

http://www.mikrocontroller.net/forum/read-4-49709.html

läuft zumindest unter WINAVR (AVR-GCC).


Allerdings solltest Du schon mal einen Blick in das Datenblatt werfen,
welche Bits man setzen muß, um einen bestimmten Interrupt freizugeben,
bzw. einen bestimmten Timermodus zu setzen.

Auch kann es sein, daß unter CV Interrupts anders deklariert werden
müssen, als unter WINAVR.


Peter

@Peter,

was ich noch nicht ganz kapiert habe: Wie oft muß der Schalter gleichen
Zustand haben, dass es als solcher erkannt wird?
Ist es richtig, daß es nach dem dritten mal soweit ist?

Armin

4 mal.

Kannst ja mal den Interrupt auf 1s runtersetzen und dann mitzählen.


Peter

Hi

ich habe mal das C-File in Codevision importiert und durchsimuliert.
In welcher Variablen steht jetzt eigentlich der entprellte
Tasten-Zustand?
In "key_press" oder in "key_state"?
Ich habe das so herausgefunden, daß eben dieser entprellte
Tastenzustand
nach 4 Zyklen in "key_state" drinsteht.
Das wirft aber die Frage auf, wozu die Variable "key_press" ist?

Oftmals will man ja etwas machen, wenn eine Taste gedrückt wird und
nicht, solange eine Taste gedrückt ist.

Und "key_press" reagiert eben genau auf den Vorgang des Drückens,
d.h. den Wechsel von losgelassen zu gedrückt.


Peter

Hallo,

ich denke ich habe Peters C-Code soweit verstanden.
Nochmal zusammengefasst in i steht für Tasten die eine
Veränderung seit dem letzten Aufruf erfahren haben eine "1"
und für Tasten die ihren Status behalten haben eine "0".
Alles darauf bezogen die Entprellung ist beendet.

Möchte ich jetzt eine Erkennung für gerade gelöste Tasten hinzufügen
müsste es doch wie folgt gehen:

i = key_state ^ (~console);   // key changed?
ct0 = ~(ct0 & i);        // reset or count ct0
ct1 = ct0 ^ ct1 & i;        // reset or count ct1
i &= ct0 & ct1;          // count until roll over?

// **** Release Erkennung
key_release |= key_state & i; // 1->0: key release detect
// ****

key_state ^= i;          // then toggle debounced state
key_press |= key_state & i;   // 0->1: key press detect


Zur Erklärung, in key_state stehen zu diesem Zeitpunkt der Zuweisung
noch die "gedrückten Tasten" vom Aufruf davor. In i die Tasten
deren Zustände sich geändert haben. Wenn also der Zustand einer Taste
zuvor 1 war und sie sich geändert hat müsste man dies mittels
und-Verknüpfung "mitbekommen". Somit müsste  key_state AND i die
gelösten Tasten ergeben.

Sehe ich das richtig ?

Grüße

Dirk

faszinierend, wie derart kleine stückchen code so viel interesse
hervorrufen; ich wünschte mir, ich könnte auch so kompakt und
einfallsreich programmieren...

übrigens, die c-version dieses entprell-codes sorgt seit ca. 4 monaten
täglich in meinem auto für die entprellung von vier (alten und
schlechten) tastern; bis jetzt hat die entprellung immer einwandfrei
funktioniert!

somit wäre an dieser stelle ein kompliment und dank an peter
angebracht!

Kann es sein, dass nach dem Reset, nach 4 Timer-zyklen key_press einmal
auf 255 geht ?
Ich hab hier nämlich das phänomen...

> faszinierend, wie derart kleine stückchen code so viel interesse
> hervorrufen; ich wünschte mir, ich könnte auch so kompakt und
> einfallsreich programmieren...

Das kommt schon, Peter kann es auch nicht von Geburt an.

>> Das wirft aber die Frage auf, wozu die Variable "key_press" ist?

Das ist wie in Hardware, du kannst direkt auf einen bestimmten Pegel am
Eingang reagieren oder du kannst Flanken-getriggert arbeiten also nur
bei Pegelwechsel eine Aktion ausführen. Flankengetriggert bedeutet
immer Taktbasierend. Wenn der Flankenwechsel so wei bei Peters
Entprellung sauber arbeitet ist eine Flankengetriggerte Auswertung von
Tasten immer vorzuziehen, das ist viel störunanfäliger als das reine
Polling. Denn der Informations-Gehalt einer Flankensteuerung enthält
zum Zeitpunkt des Auslösen ZWEI Informationen statt nur EINER. Nämlich
"jetzt hat sich der Pegel von 0 auf 1 geändert" statt "der Pegel ist
jetzt 1". Ein klemmender Schalter kann so eben nicht permanent schalten
sondern nur einmalig bevor er klemmt.

Gruß Hagen

Hallo,

ich bin gerade am Bau eines Belichtungstimers mit Atmel 90S2313 mit 4
7-Segmentanzeigen und 3 Taster als Eingang.

Die Taster sind Kurzhubtaster Reichelt 3301D, und ich habe die mit
folgendem Programm Code ohne Probleme in Betrieb.

        //--------------------------------
        if((PIND.6==0) && (S3==0)) // Start/Stop
        {
            S3=1;

            if(TCCR0==0)
            {
                TCNT0=0; // Timer löschen
                TCCR0=5; // Timer on 4mHz/1024 = 3,906 kHz
                 PORTB |= 0x80;  // Relais PB7 = 1
            }
            else
            {
                 TCCR0 = 0; // Timer off
                PORTB &= ~0x80;  // Relais PB7 = 0
            }

        }
        if(PIND.6==1)
            S3=0;

P.S ist mit CodeVision Programmiert

...wie war das denn jetzt mit Key_press ?
Ist das Normal, dass es nach dem Reset, nach dem 4.Zyklus einmal auf
255 geht ?
Wenn ja, kann man das vermeiden ?

"Ist das Normal, dass es nach dem Reset, nach dem 4.Zyklus einmal auf
255 geht ?"


Nein.

Hast Du die Tasten auch gegen GND geschaltet und die internen Pull-Ups
an oder externe Pull-ups gegen VCC ?


Peter

Da ich nur zwei Pins gebrauchen kann, hab ich diese am Anfang Deiner
Routine Maskiert, daher wäre eigentlich schon 255 ausgeschlossen.
Testen tue ich auf dem STK 500.
Ist mir auch erst aufgefallen, nachdem ich das key_press in ein
weiteres Register kopiert habe.

  in  save_sreg,SREG  ;Statusregister sichern
  in  iwr0,key_port  ;Port D einlesen
  andi   iwr0,0b00001100  ;nur Pin 2 und 3 sind interessant
  com  iwr0
  eor  iwr0,key_state  ;
  and  key_ct0,iwr0  ;
  and  key_ct1,iwr0  ;
  com  key_ct0    ;count
  eor  key_ct1,key_ct0  ;
  and  iwr0,  key_ct0  ;input AND last counterstate
  and   iwr0,  key_ct1  ;
  eor  key_state,iwr0  ;toggle state
  and  iwr0,key_state  ;0-1-transition
        or  key_press,iwr0  ;store key_press detect

  or  Status,key_press;Tastenergebnis auch in Status speichern

In der Mainloop lösche ich im Grunde nur noch key_press

@Buffy

"... 3 Taster als Eingang."

Wie soll das gehen, ich sehe da nur PIND.6 als Eingang ???


Neben dem Vorteil gleichzeitig 8 Tasten zu entprellen, zeichnet sich
mein Code doch gerade dadurch aus, daß der Timer durchlaufend ist und
somit z.B. als Systemuhr mit verwendet werden kann.

Als weiterer Vorteil werden die Tastendrücke gemerkt und können später
ausgewertet werden (Ich hasse es bei vielen kommerziellen Geräten, daß
man immer so elendig lange warten muß, bis man endlich die nächste
Taste drücken darf).

Daß daneben noch viele andere Code laufen, die eben nicht diese
Vorteile aufweisen, glaube ich Dir gern.


Peter

@Carsten:

Key_press kopiert man nicht.
Man maskiert es auch nur, wenn während eines bestimmten Programmstatus
einige Tasten gesperrt werden müssen, was im Normalfall nicht der Fall
ist.

Für key_press nutzt man ein oberes Register, um bitweisen Zugriff zu
erhalten. Die einzelnen Bits in key_press werden von der
Entprellroutine im Timer-Int gesetzt wenn eine Taste (erneut) betätigt
wurde und vom Hauptprogramm gelöscht, wenn der zugehörige Job erledigt
wird.

Will man in der Mainloop auf Tastendrücke reagieren, fragt man die
jeweilige Taste einzeln ab:

 sbrc key_press, tastenbit1  ;überspringe, wenn Bit gelöscht
 rjmp/rcall tast1            ;zur Abarbeitung, da Bit gesetzt ist
 sbrc key_press, tastenbit2  ;überspringe, wenn Bit gelöscht
 rjmp/rcall tast2
 ...

tast1:
 cbr key_press,1<<tastenbit1 ;Tastenbit1 löschen, Job wird erledigt,
 ... ;Job erledigen, den die Taste ausgelöst hat...
 rjmp mainloop / ret         ;fertig...

tast2:
 genauso...

...

War ein Bit gesetzt, wird die zugehörige Routine aufgerufen (die den
Job erledigt, den ein Tastendruck bewirken soll). Diese löscht erstmal
das eine Bit in kex_press, denn der zugehörige Job ist ja nun in
Arbeit, und er soll ja nur einmal ausgeführt werden. Dann wird der Job
erledigt und die Routine verlassen.
Ob man die Routine per rcall/ret aufruft oder per rjmp/rjmp, hängt von
anderen Faktoren ab (z.B. Hirarchie/Wichtigkeit der einzelnen Jobs).
Das Löschen aller Bits in key_press ist nur dann sinnvoll, wenn ein
Taster/Schalter so hohe Priorität hat, dass alle anderen Tastendrücke
annulliert werden müssen. Ansonsten löscht jede Tastenjobroutine nur
ihr eigenes Bit in key_press.

...

>>Das Löschen aller Bits in key_press ist nur dann sinnvoll, wenn ein
>>Taster/Schalter so hohe Priorität hat, dass alle anderen
>Tastendrückeannulliert werden müssen

oder, wenn man bulletproof die hektischen und unsinnigen Eingaben des
Benutzers löschen möchte, weil der höchst priorisierte Job die anderen
Jobs annuliert.

Zb. in Key_Press stehen die Tasten für Lautstärke +, Kanalwahl 12 und
Fernseher Off drinnen. Fernseher Off ist am höchsten priorisiert und
löscht demzufolge die anderen tasten ebenfalls, da diese dann keinen
Sinn mehr machen.

Daran erkennt man: bei einen guten Code weis der Initial-Programmierer
selber nicht sofort was man so alles mit dem Code in Zukunft noch
anstellen kann :-)

Gruß Hagen

Nundenn...
Key Press wird nach der Abarbeitung gelöscht.
Genauso tat ich und es war falsch, weil ich viel zu viel in der
main-loop gemacht hab.
Da meine Jobs aber nun mal Zeit in Anspruch nehmen (siehe Threat Timing
Problem) musste ich mir Flags setzen.

>Man maskiert es auch nur, wenn während eines bestimmten
>Programmstatus
>einige Tasten gesperrt werden müssen, was im Normalfall nicht der
>Fall ist.

Da bin ich ja mal gespannt, wie die Routine mein UART entprellt und
meine LED's.
Was spricht dagegen, den Port vor der Routine zu maskieren ???
Ich brauche nun mal nur zwei Eingänge.
Das ganze ist M.E. auch niemals nicht der Grund, dass die Routine bei
mir Zickt.
Fakt ist, wenn immer nur 0b00001100 als maximal gelesene Eingänge
kommen dürfen unten nicht 0b11111111 raus kommen oder ?
Das key_press nach der Abarbeitng (hier dem kopieren) gelöscht wird,
ist genau so richtig.
In Peter's Routine ist es auch nicht anders.
Wie gesagt, das letzte mal hab ich Mecker bekommen, weil ich den
Interrupt so lange unterdrückt habe, bis alles erledigt war. Jetzt hab
ich die M.E. einzige konsequenz daraus gezogen und wieder falsch :(
...

Was heißt nun "falsch"? Was in der einen Situation falsch erscheint,
ist in der anderen Situation richtig.

Wie Hagen richtig angemerkt hat, hat man bei diesem Profi-Code alle
Optionen offen. Im Prinzip meinte ich dasselbe, habe es aber wohl nicht
präziese genug formuliert. Nochmals meinen Dank an Peter für diesen
Code.

Ich habe meinen Beitrag eigentlich nur geschrieben, weil ich den
Eindruck hatte, dass du (Carsten) noch Verständnisprobleme mit der
Routine bzw. dem Umgang damit hast.

Du brauchst nur 2 Bits weil du nur 2 Tasten dran hast. Also brauchst du
auch nur 2 Bits in key_press auszuwerten. Machst du das im Ganzen
(key_press auf 0 prüfen), dann musst du es natürlich vorher maskieren.
Machst du es aber bitweise (so wie ich es beschrieb), dann soll es dich
doch nicht interessieren, ob USART und die anderen Portpins die
unbenutzten Bits in key_press setzen oder nicht, denn du fragst sie ja
nie wieder ab.

...

Ok, da gebe ich Dir Recht.

Generell sollte aber das Maskieren keine probleme für die Routine
bedeuten oder ?

@Carsten:

Abstrahiere doch mal...

Die ISR setzt die Bits in key_press, wenn eine Taste neu gerückt
wurde (Flanke). Damit wird sozusagen ein "Job" angemeldet, den das
Hauptprogramm irgendwann ausführen muss.

Wie du die "angemeldeten Jobs" abarbeitest und die zugehörigen
"Jobflags" (also die Bits in key_press) löscht ist von Fall zu Fall
unterschiedlich. Es hat (eigentlich) keine Auswirkungen auf die
ISR-Routine. Bei 2 Tasten würde ich sie einzeln abfragen (sbrc) und
einzeln löschen (cbr).

...

Es macht aber doch keinen Unterschied, ob ich ein eigenes Statusregister
verwende oder key_press.
Im Statusregister habe ich nebenbei noch andere Flags. Das
Statusregister ist für mich auch ein Speicher, der mir alle 30min einen
neuen Job aufdrückt, unabhängig vom Tastenzustand (Selbsthaltung). Das
ist notwendig um der Benachrichtigten Person so lange Messages zu
schicken, bis sie reagiert und den Reset-Knopf gedrückt hat.
Anders herum wirft diese Diskussion die Frage auf, ob es sinnvoll wäre,
eine Alles OK Meldung zu schicken, wenn der betreffende key-press
eingang wieder weg ist.
Das geht aber mit der Entprellung nicht, da die fallende Flanke nicht
ausgewertet wird :(
Stellt sich die Frage, wie man das einigermaßen sicher hin bekommt...
...Ein Eingang (entprellt) der ein Signal auslöst wie bei key_press.
Bleibt der Eingang High, tut sich nix. Wird der Eingang nach einer
gewissen Zeitspanne Low (entprellt) kommt wieder ein Signal.

Aber jetzt dämmert's...
Was, wenn key_press nicht gelöscht wird? Dann bleibt das auch bis zum
nächsten Reset an. <<...denk...denk...>>
Dann brauche ich den Speicher garnicht.

Vergiss nicht, dass dir neben key_press (den Flag, die dir sagen, dass
die Tasten erneut gedrückt wurden, also inzwischen mal losgelassen
waren) auch key_state zur Verfügung steht, mit dem du den aktuellen
Tastenzustand auswerten kannst.
Wer hindert dich daran, mit einer eigenen Routine den Flankenwechsel in
key_state zu erkennen und darauf zu reagieren?

Das Tastenflag in key_press stehen zu lassen halte ich für nicht so
gut. Denn dann wird ja der "Job" bei der nächsten Mainloop-Runde
erneut augeführt.

OT: Mich stört es etwas, dass wir solche banalen Dinge in der
Codesammlung diskutieren.

...

"Mich stört es etwas, dass wir solche banalen Dinge in der
Codesammlung diskutieren."


Ich denke mal, genau dazu ist die Codesammlung da.

Es gehört natürlich etwas Disziplin dazu, die Threads bis zum Ende zu
verfolgen, ob sich relevante Zusätze ergeben haben.


Zum Thema Ausmaskieren:

Das Ausmaskieren mit 0 bedeutet Taske gedrückt und somit ist der
Zustand 255 zumindest einmalig möglich.

Tritt er aber bei losgelassenen Tasten auf, dann könnte ein fehlender
Pull-Up die Ursache sein oder die Register wurden nicht initialisiert.


Du hast doch den Code aus dem 3. Posting genommen (das 1. ist buggy) ?

Da aber die Bits völlig unabhängig voneinander arbeiten, ist ein
Ausmaskieren schlichtweg unnötig, man testet einfach nicht die Bits,
die kein Tasten bedeuten.


Peter

Der Zustand tritt nur einmal nach dem Reset auf.
Ich denke schon, dass ich das dritte Posting gnommen habe, werde ich
aber nochmal prüfen.
Danke erstmal

@Peter:

Gut, dann brauche ich also kein schlechtes gewissen wegen Zumüllen der
Codesammlung haben... ;-)

...HanneS...

Kennt ihr schon den? Einfach und genial.

// Get debounced key state, TRUE if key was pressed
BOOL AT_DebouncedKey (void)
{
   static UINT16 state = 0;
   state = (state<<1) | RAWKEYPRESS | 0xe000;
   return (state == 0xf000);
}

Einfach periodisch aufrufen, RAWKEYPRESS ist das Portbit, 0 oder 1

@pittbull

"Kennt ihr schon den? Einfach und genial."

Ja kenn ich, der hat aber schon nen sooooo langen Bart:

http://www.mikrocontroller.net/forum/read-4-179926.html#new

Ist also weder einfach noch genial noch effizient.


Peter

ach, den kanntet ihr schon :-(

ich finde den jedenfalls nicht schlecht, ist hardwareunabhängig und
muss nicht inner isr laufen. ist übrigens von da:
http://www.ganssle.com/debouncing.pdf

Wenn ich das richtig sehe, ist er auch nicht störsicher während des
gedrückt haltens.
Ein einziges 1-Bit (Störimpuls) bewirkt den sofortigen Wechsel zu
losgelassen.

Meine Routine will aber mindestesn 4 Einsen hintereinander bis zum
nicht gedrückt, entprellt also beim Drücken und beim Loslassen.


"ist hardwareunabhängig und muss nicht inner isr laufen"

Trifft auch voll auf meine Routine zu.

Man kann sie auch im Main aufrufen und die rein zufällige
Programmlaufzeit als Abtastintervall nutzen.

Allerdings würde dadurch die Programmierung wesentlich umständlicher,
man müßte dann nämlich nach jeder Programmänderung prüfen, ob die
Laufzeit noch im optimalen Entprellinterval (2..50ms) liegt.

Oder man macht es wie leider so viele:

Einfach beide Augen zu und durch. Und dann eben den Kunden sich ärgern
lassen, wenns doch mal prellt oder er ne Taste länger drücken muß, ehe
sie reagiert.


Sowas ist aber nicht mein Stil und genau deshalb nehme ich eben den
Timerinterrupt.


Peter

klar ist der code laufzeitabhängig. inner main loop muss man die
konstanten anpassen wenn's nicht richtig funzt. um dem problem zu
entgehen kann man kann ihn natürlich auch in eine timer-isr packen,
geht aber auch ohne ;-)

>> "ist hardwareunabhängig und muss nicht inner isr laufen"
>> Trifft auch voll auf meine Routine zu.
sicher nicht (wenn du diesen assemblercode neinst). der braucht schon
hardwareunterstützung.

@pittbull

"sicher nicht (wenn du diesen assemblercode neinst"

Nein, ich meinte den C-Code darunter (4.Posting), hier mit 8051, im
Shedulerbeispiel mit AVR.
Die Unterschiede (8051/AVR) sind nur in der anderen
Timerinitialisierung und der anderen Interrupt-Syntax.


Peter

Hi,

ein bißchen OT beim austesten der Routine: aber bei mir im Simulator
(AVRStudio 4.11SP3) springt er bei reti wieder an die Adresse 0 und
fährt damit nochmals die init routine ab. Entsprechend kann ich den
Code-Schnipsel nicht nachvollziehen. Kann mir jemand auf die Sprünge
helfen was da passiert?

Aber zum Code: geschieht das zählen durch die xor und and
Verknüpfungen? Wo kann man dies mal nachlesen?

Viele Grüße
Olaf

Ha, der Stackpointer wird ja benutzt - alles klar :-)

hallo

hat schon jemand (ich wage es ja fast nicht zu fragen (schäm))
diese routine in basic (bascom) übersetzt
bei mir klappt es leider noch nicht

PeterL

@Peter und alle anderen die es wissen könnten

Ich versuche nun schon seit mehreren Tagen den Code aus dem 3. Post auf
meinem STK500 Board mit einem 8515 zum Laufen zu bekommen... Leider ohne
Erfolg.

Das Prinzip des Codes ist mir (nach seitenweisem malen der Register auf
Zettel gg) mittlerweile klar.

Wäre dankbar für ein paar Hinweise an welchen Stellen ich anpassen muss
um ihn mit meiner Hardware lauffähig machen zu können. Wenn ich mich
nicht täusche dann müsste ich die Interrupts anders programmieren
oder?

Danke
Christopher

@Christopher,

der einzige Unterschied dürfte der Hardwarestack des 1200 sein, Du mußt
also nur noch den Stackpointer setzen, dann sollte es laufen.


Peter

Interessante Routine, das Prinzip ist aber nicht neu. Das Grundprinzip
läßt sich übrigens vielseitig verwenden. Wer die Grundlagen wissen
will:

vertical counters:

http://www.everything2.com/index.pl?node_id=1145892
http://www.dattalo.com/technical/software/pic/vertcnt.html

Entprellroutine für PIC:

http://www.dattalo.com/technical/software/pic/debounce.html

Der eigentliche Entprellalgorithmus läßt sich übrigens auch recht
einfach in Hardware implementieren:

http://pdfserv.maxim-ic.com/en/ds/MAX6816-MAX6818.pdf (Figure 1, Seite
4)

Evtl. interessant für Verwendung mit CPLDs/FPGAs.

@Marko

"Evtl. interessant für Verwendung mit CPLDs/FPGAs."

Du wirst lachen. Ich habe zuerst einen Schaltplan gezeichnet, dann so
optimiert, daß möglichst wenig AND, OR, EXOR, NOT-Glieder vorkommen und
erst dann habe ich den Schaltplan in Software übertragen.

Daß sich sowas vertical counter nennt, habe ich dann mal im 8052-Forum
gelesen.

Eigentlich komisch, daß derart hocheffiziente Algorithmen so selten
verwendet werden.
Man sieht viel häufiger die Echtzeit vernichtende Warten im Interrupt
Methode (grr).


Peter

Hallo

danke für deinen Code, er funktioniert sehr gut (mspgcc). Ich habe nur
in der Zeile:
 key_press |= key_state & i;
Das |= durch ein = ersetzt.

Christian

Um es noch mal zusammenzufassen:
Wenn namhafte Hersteller diverser Fernbedienungen endlich mal Peters
Algorithmus verwenden würden anstatt einfach zu pollen, dann könnte man
sehr schnell bis gleichzeitig den Kanal wechseln und die Lautsträke
verändern. Das nervt nämlich wirklich wenn man nach dem Kanalwechseln
immer noch 1 Sekunde wartten muss bevor die nächste Eingabe erfolgen
kann... :-)
Hail to Peter
Ich verwende auch seine Routine und bin immer wieder erstaunt über die
flexible Lösung, welche er da gezeigt hat... RESPEKT

Hallo!

Ich muss erstmal ganz groß Danke sagen!
Die Entprell-Funktion aus der Get8key4.c51 funktioniert wunderbar.

In der key_press Variable kann ich wunderbar auf den Tastendruck (0->1)
reagieren.
Nur hab ich jetzt natürlich wieder ein spezielles Problemchen:
Ich müsste auch zusätzlich den Übergang (1->0) erkennen.
Damit möchte ich unterscheiden, ob eine Taste nur kurz angetippt wurde
(toggelt dann eine LED) oder länger gedrückt gehalten wird (LED soll
dann solang leuchten).

Der Code ist so herrlich kompakt, dass ich leider Probleme hab, ihn so
genau zu verstehen, um diese Funktion hinzuzufügen.
Vielleicht kann mir da jemand auf die Sprünge helfen?

Viele Grüße,
Daniel

mach mal aus dieser zeile;
 i = key_state ^ ~KEY_INPUT;
einfach das:
 i = key_state ^ KEY_INPUT;
und schon haste das umgekehrt

Hier mal ein Bespiel mit kurz/lang Erkennung:

http://www.mikrocontroller.net/attachment.php/2524...


Peter

Wunderbare Diskussion !

Ich habe aber noch eine weitere Frage,
bis jetzt wird ja nur die "0->1: key pressing detect" in der
Variable
key_press gespeichert.
Ich bräuchte aber auch noch die Info, wann die Taste wieder losgelassen
worden ist.
Hat das schon mal jemand in den obigen Code implementiert ?

Gruß
Ralph

Hallo Peter,
ich nutze deine Routine mit Lang/kurz-erkennung recht gern und viel,
muss aber zugeben, dass ich noch nicht ganz durchgestiegen bin ;-)
Bisher hat das aber nie zu Problemen geführt.

Jetzt hab ich aber mal eine Anwendung wo ich die Taster an PortG vom
Mega64 angeschlossen habe. 5 Taster an PG.0-PG.4
Die Funktionen get_key_press und get_key_short funktionieren bei allen
Tasten auch einwandfrei, aber get_key_long und get_key_rpt funktionieren
nur an PG.1 und PG.2.
Ich hab schon alles aus dem Programm rausgenommen was irgenwie stören
könnte, aber ich komm einfach nicht dahinter...
ist das vieleicht Prinzipbedingt, da der PortG ja nur 5 Bits hat? Wenn
ja, warum gehn dann grad bit 1 und 2?

Hoffe auf Erleuchtung.

Gruß
Fabian

hallo zusammen,

ich bin noch ganz ganz neu auf dem gebiet avr mc. habe noch nichmal das
equiptment hoffe aber das es die nächsten tage bald mit der post kommt
;)

naja wollte aber vorher schonmal anfangen ein testprogramm mit leds und
schaltern zu schreiben und bin dann über die routine von Peter Dannegger
gestossen.
mir ist beim code aufgefallen das es "fälle" gibt wo die routine sprich
overflow interrupt nicht 4 mal durchlaufen wird sondern das es bis zu 7
durchläufen brauch bis key_state und key_press richtig gesetzt sind.

ich benutze mal dezimalzahlen und beziehe mich auf den c-code der
routine http://www.mikrocontroller.net/articles/Entprellung und nehme
ein beispiel wo die routine 7 mal durchlaufen wird
z.B.
ich gehe mal von der situation aus das : KEY_PIN = 1 ist was bedeutet
alle taster bis auf pin0 gesetzt.

wenn nun KEY_PIN während 3 interrupt overflow auf 3 steht (taster pin0
u. pin1 nicht gesetzt) und beim nächsten overflow auf 2 (taster pin1
nicht gesetzt), wechselt key_state auf 3 und nicht auf 2. erst nach 3
weitereren interrupt durchläufen wechselt key_state auf 2 und setzt
key_press wie gewollt.

das geht auch mit anderen fällen wobei der durchlauf von 5 bis max 7
liegen kann je nachdem wielang der kurze KEY_PIN wechsel anliegt.

kann das einer bestättigen oder definitiv verneinen? ich bin linux
benutzer und kann das ganze leider nich ausführlich in avrstudio testen.
hier noch von meiner seite grossen respekt an peter dem dieser
algorithmus eingefallen

Ich kenne ja nur die Assembler-Routine, muss aber sagen, dass sie exakt
funktioniert. Dezimale "Zahlenwerte" (Zählerstände) nützen Dir beim
Versuch, den Algorithmus nachzuvollziehen nichts, da die beiden Bits des
jeweiligen Prellzählerstandes in zwei verschiedenen Registern liegen.
Denn jedes involvierte Byte enthält ja die Bits von 8 zu entprellenden
Eingängen parallel.

MfG

ich benutze nur dezimal in meinem beispiel um die schreibweise
0b00000001 für  dezimal 1 und 0b00000011 für 3 usw zu verkürzen.

Hast Du beim "Testen" auch auf die Variablen ct0 und ct1 geachtet? Die
verkörpern nämlich den eigentlichen Prellzähler. Das sind zwei
8-Bit-Variablen, von denen jede je ein Bit der acht vorhandenen
Zweibit-Zähler enthält.

Wenn Du meinst, dass Du auf AVR-Studio verzichten möchtest weil...
Naja, das ist nicht mein Problem.

MfG

danke erstmal Werbungverschmäher für deine flotten antworten.
ja auf ct0 und ct1 habe ich geachtet denn sonst würde nix passieren.

ich versuche das ganze mal zu erklären so wie ich mir vorstelle das
diese routine funktioniert:

KEY_PIN eingabe : 255
i='0'  ct0='255'  ct1='255'  i='0'  key_state='0'  key_press='0'

KEY_PIN eingabe : 254
i='1'  ct0='254'  ct1='255'  i='0'  key_state='0'  key_press='0'

KEY_PIN eingabe : 254
i='1'  ct0='255'  ct1='254'  i='0'  key_state='0'  key_press='0'

KEY_PIN eingabe : 254
i='1'  ct0='254'  ct1='254'  i='0'  key_state='0'  key_press='0'

KEY_PIN eingabe : 254
i='1'  ct0='255'  ct1='255'  i='1'  key_state='1'  key_press='1'

KEY_PIN eingabe : 254
i='0'  ct0='255'  ct1='255'  i='0'  key_state='1'  key_press='0'

so nun benutze ich mal ein anderes beispiel bei dem 7 durchläufe statt 4
vorkommen:

KEY_PIN eingabe : 254
i='0'  ct0='255'  ct1='255'  i='0'  key_state='1'  key_press='0'

KEY_PIN eingabe : 252
i='2'  ct0='253'  ct1='255'  i='0'  key_state='1'  key_press='0'

KEY_PIN eingabe : 252
i='2'  ct0='255'  ct1='253'  i='0'  key_state='1'  key_press='0'

KEY_PIN eingabe : 252
i='2'  ct0='253'  ct1='253'  i='0'  key_state='1'  key_press='0'

KEY_PIN eingabe : 253
i='3'  ct0='254'  ct1='255'  i='2'  key_state='3'  key_press='2'

KEY_PIN eingabe : 253
i='1'  ct0='255'  ct1='254'  i='0'  key_state='3'  key_press='0'

KEY_PIN eingabe : 253
i='1'  ct0='254'  ct1='254'  i='0'  key_state='3'  key_press='0'

KEY_PIN eingabe : 253
i='1'  ct0='255'  ct1='255'  i='1'  key_state='2'  key_press='0'

KEY_PIN eingabe : 253
i='0'  ct0='255'  ct1='255'  i='0'  key_state='2'  key_press='0'

entweder liege ich total falsch oder er registriert erst nach 7 ints das
richtige key_state

Also C ist nicht mein Ding. Ich nutze die Tastenentprellung nach Peter
Dannegger in ASM in verschiedenen Varianten und Modifikationen.
Hier eine Version, die neben dem entprellten Tastenzustand nur die
Flanken des Tastendruckes erfasst:

Tastenabfrage: ;Entprellroutine geklaut bei Peter Dannegger...
 in scan,tap   ;Tastenport einlesen (gedrückt=L)
 com scan      ;invertieren (gedrückt=H)
 eor scan,tas  ;nur Änderungen werden H
 and tz0,scan  ;Prellzähler unveränderter Tasten löschen (Bit0)
 and tz1,scan  ;Prellzähler unveränderter Tasten löschen (Bit1)
 com tz0       ;L-Bit zählen 0,2,->1, 1,3,->0
 eor tz1,tz0   ;H-Bit zählen 0,2,->tz1 toggeln
 and scan,tz0  ;Änderungen nur dann erhalten, wenn im Prellzähler
 and scan,tz1  ;beide Bits gesetzt sind (Zählerstand 3)
 eor tas,scan  ;erhaltene Änderungen toggeln alten (gültigen) Tastenstatus
 and scan,tas  ;nur (neu) gedrückte Tastenbits bleiben erhalten
 or tfl,scan   ;und zugehörige Bits setzen (gelöscht wird nach Abarbeitung)
 ;in "tas" steht jetzt der gültige Tastenzustand,
 ;in "tfl" die Flags der neu gedrückten, noch nicht abgearbeiteten Tasten...

Diese Variante arbeitet mit Registern und im Interrupt. Gelegentlich
nutze ich diesen Algorithmus auch mit temporären Registern in der
Mainloop und halte die Variablen im SRAM. Mit kleinen Zusätzen lässt
sich auch (nur oder zusätzlich) das Loslassen der Taster erfassen und /
oder auch ei Repeat bei Dauerdruck.

Da dieser Algorithmus mit 2-Bit-Prellzählern (bei mir tz0 und tz1)
arbeitet, muss ein veränderter Eingangspegel (also Taster gedrückt oder
losgelassen) exakt 4 mal stabil erfasst worden sein, damit die Änderung
übernommen wird, sich also der Wert von tas ändert.

Da der Controller nur Maschinencode (ASM) kann, der C-Code auch nur in
ASM (bzw. Maschinencode) übersetzt wird, solltest Du das mal in ASM
durchspielen.

MfG

@peter nein die initialisierung is schon durch siehe i=0 u. ct0,ct1 =
255
so dann hier noch mal die mundgerechte version in der hoffnung das es
dann mal angeschaut wird ohne gleich ratschläge zu geben:

KEY_PIN eingabe : 11111111
i='0'  ct0='11111111'  ct1='11111111'  i='0'  key_state='0'
key_press='0'

KEY_PIN eingabe : 11111110
i='1'  ct0='11111110'  ct1='11111111'  i='0'  key_state='0'
key_press='0'

KEY_PIN eingabe : 11111110
i='1'  ct0='11111111'  ct1='11111110'  i='0'  key_state='0'
key_press='0'

KEY_PIN eingabe : 11111110
i='1'  ct0='11111110'  ct1='11111110'  i='0'  key_state='0'
key_press='0'

KEY_PIN eingabe : 11111110
i='1'  ct0='11111111'  ct1='11111111'  i='1'  key_state='1'
key_press='1'

KEY_PIN eingabe : 11111110
i='0'  ct0='11111111'  ct1='11111111'  i='0'  key_state='1'
key_press='0'

so nun benutze ich mal ein anderes beispiel bei dem 7 durchläufe statt 4
vorkommen:

KEY_PIN eingabe : 11111110
i='0'  ct0='11111111'  ct1='11111111'  i='0'  key_state='1'
key_press='0'

KEY_PIN eingabe : 11111100
i='10'  ct0='11111101'  ct1='11111111'  i='0'  key_state='1'
key_press='0'

KEY_PIN eingabe : 11111100
i='10'  ct0='11111111'  ct1='11111101'  i='0'  key_state='1'
key_press='0'

KEY_PIN eingabe : 11111100
i='10'  ct0='11111101'  ct1='11111101'  i='0'  key_state='1'
key_press='0'

KEY_PIN eingabe : 11111101
i='10'  ct0='11111110'  ct1='11111111'  i='10'  key_state='11'
key_press='10'

KEY_PIN eingabe : 11111101
i='1'  ct0='11111111'  ct1='11111110'  i='0'  key_state='11'
key_press='0'

KEY_PIN eingabe : 11111101
i='1'  ct0='11111110'  ct1='254'  i='0'  key_state='11'  key_press='0'

KEY_PIN eingabe : 11111101
i='1'  ct0='11111111'  ct1='11111111'  i='1'  key_state='10'
key_press='0'

KEY_PIN eingabe : 11111101
i='0'  ct0='11111111'  ct1='11111111'  i='0'  key_state='10'
key_press='0'

alles toll, aber das Problem bleibt

ich kann selten immer 8 Bits eines Ports verwenden, einige Bits sind
immer reserviert, um trotzdem diese Routine zu nutzen hab ich sie
gedoppelt

-------------------------------------------------
#define KEY_PORT        PORTC
#define KEY_PIN         PINC
#define KEY_PIN2        PIND
#define KEY1            2
#define KEY2            3
#define KEY3            4
#define KEY4            5
#define KEY5            6
#define KEY6            7
#define KEY7            1
-------------------------------------------------

  i = key_state ^ ~KEY_PIN;                       // key changed ?
  ct0 = ~( ct0 & i );                             // reset or count ct0
  ct1 = ct0 ^ (ct1 & i);                          // reset or count ct1
  i &= ct0 & ct1;                                 // count until roll
over ?
  key_state ^= i;                                 // then toggle
debounced state
  key_press |= key_state & i;                     // 0->1: key press
detect

  if( (key_state & REPEAT_MASK) == 0 )            // check repeat
function
       rpt = REPEAT_START;                          // start delay
  if( --rpt == 0 )
  {  rpt = REPEAT_NEXT;                            // repeat delay
        key_rpt |= key_state & REPEAT_MASK;
    }

  i2 = key_state2 ^ ~KEY_PIN2;                       // key changed ?
  ct02 = ~( ct02 & i2 );                             // reset or count
ct0
  ct12 = ct02 ^ (ct12 & i2);                          // reset or count
ct1
  i2 &= ct02 & ct12;                                 // count until roll
over ?
  key_state2 ^= i2;                                 // then toggle
debounced state
  key_press2 |= key_state2 & i2;                     // 0->1: key press
detect

-------------------------------------------------

uint8_t get_key_press( uint8_t key_mask )
{ static uint8_t key_mask2;
  cli();                                          // read and clear
atomic !
  key_mask2=key_mask;
  key_mask &= key_press;                          // read key(s)
  key_press ^= key_mask;                          // clear key(s)
  key_mask2 &= key_press2;                          // read key(s)
  key_press2 ^= key_mask2;                          // clear key(s)
  sei();
  return (key_mask || key_mask2);
}
-------------------------------------------------

wüsste gerne ob es eine bessere Möglichkeit gibt verschiedene Ports zu
nutzen und davon jeweils nur die von Tasten benutzten Bits zu maskieren,
damit andere Signale keine Taste simulieren

Mal ne generelle Frage unabhängig der hier vorgestellten Methoden:

Warum per Software entprellen ??

Ich habe mal gelernt, dass man bei einfachen Schaltungen (und bei
Schaltungen ohne µC eh nicht anders lösbar) die Tasten elektronisch
entprellt ....

Das müsste doch per Kondensator oder so recht günstig gehen ....

> Warum per Software entprellen ??

Gerät in der Massenproduktion mit vier Tastern:

Du willst 100.000 Stück davon bauen und verkaufen. Ein RC-Glied pro
Taster kostet etwa 4 Cent. Davon 4 Stück pro Gerät mal 100.000 =
16.000,- Euro.

Dabei sind die Kosten für Bestückung, Lagerhaltung, höhere Ausfallrate
(mehr Bauteile!), größere Platinenfläche etc. noch gar nicht
eingerechnet.

Alternative: Software. Eine halbe Stunde für einen Programierer: 100,-
Euro.

Ergänzung, für jedes eingesparte Bauteil, entflechten, verdrahten, löten
ist der Hobbyist dankbar und wenn eh ein MC on Board ist , wieso nicht
per SW ?

Ok ok, ....

Ich wusste nicht, dass Ihr gleich 100.000 Stück baut .... gg

Ich tue in der zwischenzeit komplett alle Ports immer über Interrupts
einlesen. Dann habe ich globale Variablen mit dem namen PORTX_STATE
PORTX_PRESS PORTX_UNPRESS für jeden PORT. Und habe dann alle Eingänge
schön entprellt.

Hallo, ich verwenden auch den Code hier, funktioniert wirklich gut.
Prozessor ARM7 (LPC2148).

Mein Problem, beim ARM hat man ja nur 2 Ports mit je 32 I/O´s ich habe
jetzt einfach den code auf uint32_t geändert, es funktioniert auch aber
gibts auch etwas eleganteres.

Kann man die Pins die man möchte auch irgendwie zusammen mappen auf ein
Byte  (meisten braucht man ja nicht mehr wie 8 Taster)?

Wenn alle nacheinander sind ginge es ja, aber wenn ich zum Beispiel -
P0.14, P0.15, P0.30, P0.1 usw. verwenden will sind diese ja über die 32
I/O´s verteilt, sehe da keine ander Möglichkeit bis jetzt.


Wie so muss man bei den Interrupt immer ein und auschalten, reicht es
nicht wenn man nur die paar Zeilen mit einem Flag ein und ausschaltet?
Wenn man zum Beispiel mit dem Interrupt auch einen digitalen Regler
triggern möchte ist das etwas problematisch. Gibts auch eine ander
Lösung?


danke

okay funktionieren tut es aber trotzdem, wird aber dann mal zu einem
Fehler führen oder.

Aber zu dem andern Problem gibts wohl nichts anderes oder?

Habe es jetzt so gemacht funktionier weis nur nicht ob das richtig ist!
Das mit den IRQ´s ist ja nicht so einfach wie bei den AVR´s.

uint32_t get_key_press(uint32_t key_mask )
{
    unsigned cpsr;
    
    //cli();
    cpsr = disableIRQ();                  // disable global interrupts
    T0MCR &= ~(TMCR_MR0_I);                 // disable MR0 interrupt
    restoreIRQ(cpsr);                     // restore global interrupts
    
    key_mask &= key_press;            // read key(s)
    key_press ^= key_mask;            // clear key(s)
  
    //sei();
    cpsr = disableIRQ();                  // disable global interrupts
    T0MCR |= TMCR_MR0_I;                  // enable MR0 interrupt
    restoreIRQ(cpsr);                     // restore global interrupts
  
    return key_mask;
}

danke

Okay stimmt, ich wollte nur sicher gehen und nur den Timer abschalten,
und die IRQ's gleich wieder aktivieren.

Danke.

Hallo Hannes,

Ich meinen natürlich den Interrupt des Timers nicht den Timer selbst,
schon klar. Das habe ich doch oben auch gemacht denke ich, ich habe ja
nur den MR0 IRQ ausgeschalten --> wäre das nicht korrekt so? Hab
nochmals im Manual nachgesehen wüsste nicht wie man den IRQ sonst
abschaltet falls man das mal möchte.

>Ich glaube, Du solltest versuchen, die Rourtine zu verstehen, ehe Du sie
>modifizierst.

Hast natürlich volkommen recht, dennoch weis ich nicht was du genau
meinst denn das Beispiel von oben funktioniert, nur ist es wie Herr
Danneger geschrieben hat vollig unsinnig was das Timing betrift. Deshalb
mach ich es jetzt auch so wie vorgeschlagen.

Hallo Leute,

ich finde den Code schön kompakt (auch wenn man erst eine Weile
nachdenken muss, bevor man ihn versteht :-). Ich hatte das Problem, auch
das Loslassen einer Taste erkennen zu wollen, und habe daher folgende
Ergänzung ersonnen (braucht ein weiteres Register).

Lieben Gruß,
Wiener Würstchen

#define KEY_INPUT  P2

char key_state, key_press;

/* neue Zeile hier...
char key_release;
*/  


void to_int( void ) interrupt INT_T0
{
  static char ct0, ct1;
  char i;

  i = key_state ^ ~KEY_INPUT;  // key changed ?
  ct0 = ~( ct0 & i );    // reset or count ct0
  ct1 = ct0 ^ ct1 & i;    // reset or count ct1
  i &= ct0 & ct1;    // count until roll over 
  key_state ^= i;    // then toggle debounced state
  key_press |= key_state & i;  // 0->1: key pressing detect

/* neue Zeile hier...
  key_release |= ~key_state & i;  // 0->1: key release detect
*/  
}

Hallo Leute,
ich weiß zwar nicht, ob das Thema bereits geschlossen ist, aber ich hab
da eine Frage.

Ich benutze diese Entprellung ebenfalls. Gedacht ist es für eine
"selbstgebaute" Fernbedienung. Ich will eine Art Steuerkreuz bauen, d.h.
wenn man z.b. links und oben gleichzeitig drückt, soll es Diagonal
gehen, aber die Entprellung erkennt die Tasten nur einzeln. also wenn
ich eine ausgabe mache kommt erst oben und dann links, oder umgekehrt.

Woran kann das liegen? ich verwende einen AT90CAN128 und arbeite mit
AVR-Studio 4 und WIN-AVR

Da mit der Routine alle Tasten parallel ausgewertet werden, gibt es
keine Priorisierung, bspw. in der Form, dass bei zwei exakt
gleichzeitig gedrückten Tasten immer eine bestimmte der beiden zuerst
ausgewertet wird.

Allerdings wirst es nur dann schaffen, zwei Tasten (aus Sicht der
Routine) "gleichzeitig" zu drücken, wenn die Zykluszeit, mit der die
Routine aufgerufen wird sehr groß ist. Ansonsten wird praktisch immer
eine Zeitdifferenz und damit eine von zwei Tasten als erste erkannt
werden.

Wie ist denn der genaue Ablauf vom Aufruf der Entprell- und der
Anzaigeroutine?

Hallo!

Ich habe mich mit dem schon ganz oben diskutiertem Code
auseinandergesetzt:

KEY_INPUT=11111110; //Um Tastendruck zu simulieren.

while(1){
  i = key_state ^ ~KEY_INPUT;  // key changed ?
  ct0 = ~( ct0 & i );    // reset or count ct0
  ct1 = ct0 ^ ct1 & i;    // reset or count ct1
  i &= ct0 & ct1;    // count until roll over 
  key_state ^= i;    // then toggle debounced state
  key_press |= key_state & i;  // 0->1: key pressing detect
}

Jetzt stellen sich mir einige Fragen. (Ich arbeite mit cvavr und
simuliere das ganze mit einer schleife im avr studio))
1.Durchlauf:

i = 00000000 ^ ~(11111110) = 1
ct0 = ~(00000000 & 00000001) = ~(00000000) = 11111111
ct1 = 11111111 ^ 00000000 & 00000001 = 11111111 (weil & höhere
Priorität)
bzw = (11111111 ^ 00000000) & 00000001  = 00000001

Ob mit oder ohne Klammersetzung, die Bits Null der Bytes ct0 und ct1
sind bei mir schon bei ersten Durchlauf High, was zur Folge hat, dass
auch key_state nach dem ersten durchlauf High wird!! :-(
Ich bin leider noch auf keinen grünen Zweig gekommen, vielleicht kann
mir das jemand genau erklären, wär super!

Vielen Dank im Voraus!

Mfg Jürgen

Hab den Code jetzt folgendermaßen umgeschrieben:

  i = key_state ^ ~KEY_INPUT;  // key changed ?
  ct0 = (~ct0) & i ;    // reset or count ct0

  damit korrekt mit i verundet werden kann

  ct1 = ((ct0 ^ ct1) ^ i) & i;    // reset or count ct1

  Alt: ct1 = ct0 ^ ct1 & i;
  ct1 UND i würde Null ergeben, ^ ct0 ergibt dann 00000001;
  Falls XOR vor UND kommen würde, was ja glaub ich nicht so ist (oder?)
  würde ebenfalls 00000001 herauskommen. Daher statt
  ct1 = ct0 ^ ct1 UND i;
  ct1 = ct0 ^ ct1 XOR i; Das zusätzliche &
  UND i bewirkt ein rücksetzen des
  Bits im ct1 Byte wenn die entprellung fertig ist!

  i &= ct0 & ct1;    // count until roll over
  key_state ^= i;    // then toggle debounced state
  key_press |= key_state & i;  // 0->1: key pressing detect

Ich hab das ganze getestet und es funktioniert einwandtfrei! :-)
Trotzdem bitte ich euch um eine kurze erklärung warum der Code im obigen
Post nicht funktioniert (bzw wo meine unfähigkeit liegt den Code richtig
zu verwenden, weil richtig is er sicher da er von profis ist! ;-)
Übrigends, Ausgangssituation: Alles Null, dann ein Taster (bit 0)
gedrückt.

Jürgen

PS: Ich bin noch kein Profi, also seid nicht zu streng! ;-)

Stimmt! War meinerseits nicht optimal getestet, da ich KEY_INPUT immer
"gedrückt" initialisiert habe, sonst hätte ich das selbst merken können.
Allerdings freut es mich sehr zu so einem genialen Code einen nützlichen
Beitrag geleistet zu haben! :-)

Jürgen

> In der Regel schaltet man ja Geräte nicht mit gedrückten Tasten ein, so
> daß es kaum auffällt.

Das kommt schon vor:
Gerät geht bei nicht-Benutzung/per Kommando schlafen und
wird per Tastendruck (IRQ) geweckt bzw. eingeschaltet.

In diesem Einschaltvorgang wird anhand der gedrückten Tasten festgelegt,
was passiert.

Mein Heizgriffregler hat z.B. zwei Tasten, eine davon fungiert via INT0
als Ein-Taste. Wenn die zweite beim Einschalten gedrückt war, kommt man
in den Programmiermodus für Heizleistung und Anheizzeit, wenn nicht,
ist man im Standardbetrieb - Anheizen für programmierte Zeit und danach
programmierte Heizleistung (z.Z. 40% vom Maximum).

Läuft übrigens mit den hier beschriebenen Entprellroutinen.. ;-)

Ahoi, Martin

> und zwar würde ich gerne zum besseren verständnis erklärt haben was mir
> nun das register key_state sagt.

Key_state wird von der Routine benötigt, um den entprellten Zustand der
Tasten (also den gegenwärtig für den Controller gültigen Zustand) zu
speichern und mit den neu eingelesenen Bitmustern zu vergleichen (EXOR).

Key_state kann vom Programm (nur lesend) genutzt werden, um
Tastenzustände zu überprüfen.

Also key_press meldet (und merkt sich) neue Tastendrücke, key_state
zeigt den gegenwärtigen (aber entprellten, daher leicht verzögerten)
Zustand. Dies kann z.B. für "Shift-Tasten" genutzt werden, also zur
Überprüfung, ob während eines Tastendruckes auch eine weitere Taste
gedrückt war.

KH

Also wie gesagt hab mir die routine von P.D. nochmal angeschaut und
meine das der übergang taste gedrückt-->losgelassen auch entprellt wird.
Kann mir das jemand bestätigen?

MfG Florian

Ja, es wird das Drücken und das Loslassen entprellt.

Es wird in Originalversion nur beim Drücken die Flanke separiert und per
Key-press gemeldet (was ja auch sinnvoll ist).

Manchmal kann es aber auch sinnvoll sein, dass man auch die
Loslass-Flanke meldet, dann greift die Erweiterung, die Hannes
vorgestellt hat.

Und manchmal (z.B. beim Verändern von Zahlenwerten) braucht man eine
Funktion für Autorepeat. Dann greift die Erweiterung, die im Wiki
vorgestellt wurde Entprellung.

KH

Ich glaube, jetzt kann man den Thread eigentlich mal sperren denn es
wurde doch alles gesagt.

@ Peter Dannegger,
habe mit großem Interesse diese Thread und auch noch weitere Beiträge
von Dir gelesen. Besteht die Möglichkeit über direkten Email-Kontakt mit
Dir in Verbindung zu treten ?
Falls ja, sende bitte eine kurze Mail, ich nehme dann Kontakt zu Dir
auf.

Gruß, Peter [ GrzeschikP (ät) AOL Punkt COM ]

Hallo Experten,

bitte helft mir mal:

Das passende Assembler-Programm "get8keyb.asm" funktioniert auf meinem
MEGA16.

Aber das entsprechende "C-Programm" krieg ich nicht auf die Reihe. Bin
noch nicht solange in "C" unterwegs.

Meine Frage:

Von welchen Stellen im Programm werden die Funktionen

u8 get_key_press( u8 key_mask )

u8 get_key_rpt( u8 key_mask )

und

u8 get_key_short( u8 key_mask )

aufgerufen? Ich weiß nicht, wie der Programmzähler dort hin kommt. In
diesem Thread konnte ich das nicht rauslesen.
Hier noch einmal das Programm von Peter

/************************************************************************/
/*                                                                      */
/*    Debouncing 8 Keys        */
/*        Sampling 4 Times        */
/*    With Repeat Function        */
/*                                                                      */
/*     Author: Peter Dannegger                                 */
/*          danni@specs.de                                  */
/*                                                                      */
/************************************************************************/
// Target: ATMega48

#include <io.h>
#include <interrupt.h>

typedef unsigned char  u8;
typedef signed short  s16;

#define  XTAL    8000000L        // 8MHz

#define KEY_PIN    PINB
#define KEY0    0
#define KEY1    1
#define KEY2    2
#define  KEY3    3

#define LED_DDR    DDRC
#define LED_PORT  PORTC
#define LED0    0
#define LED1    1
#define LED2    2

#define REPEAT_MASK  (1<<KEY3^1<<KEY2^1<<KEY1^1<<KEY0)
#define REPEAT_START  10          // after 100ms
#define REPEAT_NEXT  20          // every 200ms

u8 key_state;                // debounced and inverted key state:
                    // bit = 1: key pressed
u8 key_press;                // key press detect

u8 key_rpt;                // key long press and repeat


ISR( TIMER0_COMPA_vect )          // every 10ms
{
  static u8 ct0, ct1, rpt;
  u8 i;

  i = key_state ^ ~KEY_PIN;          // key changed ?
  ct0 = ~( ct0 & i );              // reset or count ct0
  ct1 = ct0 ^ (ct1 & i);          // reset or count ct1
  i &= ct0 & ct1;              // count until roll over ?
  key_state ^= i;              // then toggle debounced state
  key_press |= key_state & i;          // 0->1: key press detect

  if( (key_state & REPEAT_MASK) == 0 )      // check repeat function
     rpt = REPEAT_START;          // start delay
  if( --rpt == 0 ){
    rpt = REPEAT_NEXT;            // repeat delay
    key_rpt |= key_state & REPEAT_MASK;
   }
}



u8 get_key_press( u8 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;
}

u8 get_key_rpt( u8 key_mask )
{
  cli();                  // read and clear atomic !
  key_mask &= key_rpt;                              // read key(s)
  key_rpt ^= key_mask;                              // clear key(s)
  sei();
  return key_mask;
}

u8 get_key_short( u8 key_mask )
{
  cli();                // read key state and key press atomic !
  return get_key_press( ~key_state & key_mask );
}

u8 get_key_long( u8 key_mask )
{
  return get_key_press( get_key_rpt( key_mask ));
}

int main( void )
{
  TCCR0A = 1<<WGM01;              // Mode 2: CTC
  TCCR0B = 1<<CS02^1<<CS00;            // divide by 1024
  OCR0A = (s16)(XTAL / 1024.0 * 10e-3 - 0.5);    // preload for 10ms
  TIMSK0 = 1<<OCIE0A;              // enable timer interrupt

  LED_PORT = 0xFF;
  LED_DDR = 0xFF;
  sei();

  for(;;){                  // main loop

    switch( get_key_long( 1<<KEY1^1<<KEY0 )){

      case 1<<KEY0:          LED_PORT ^= 1<<LED0; break;

      case 1<<KEY1:          LED_PORT ^= 1<<LED1; break;

      case 1<<KEY1^1<<KEY0:  LED_PORT ^= 1<<LED2; break;
    }

    switch( get_key_rpt( 1<<KEY3^1<<KEY2 )){

      case 1<<KEY2:          LED_PORT ^= 1<<LED0; break;

      case 1<<KEY3:          LED_PORT ^= 1<<LED1; break;

      case 1<<KEY3^1<<KEY2:  LED_PORT ^= 1<<LED2; break;
    }
  }
}

Hallo,

habe mal Peters Original der individuellen Tastenabfrage angehangen.

Im Main wird nachgesehen, ob eine entsprechende Taste gedrückt wurde.
Dies geschieht mit dem if, der Abfrageart der Taste und der
entsprechenden Taste die definiert wurde.

//Für kurzen Tastendruck:
if( get_key_short( 1<<KEY1 ))
{
      -Tu was
}
//Für langen Tastendruck:
if( get_key_long( 1<<KEY1 ))
{
      -Tu was
}
//Für die Repeat Funktion:
if( get_key_press( 1<<KEY2 ) || get_key_rpt( 1<<KEY2 ))
{
      -Tu was
}

Hoffe, konnte helfen.

Gruß Tobi

Den Code einfach ein zweites Mal mit geänderten Variablen- und
Port-Namen anhängen, das Ganze evtl. noch etwas nachoptimieren.

Oder: Alle 8-Bit-Variablen in 16 Bit ändern und beim Einlesen der Ports
die beiden 8-Bit-Werte zu einem 16-Bit-Wert zusammenfassen. Dies ist für
die C-Variante sicher der elegantere Weg.

>Kann mir mal jemand nen Tipp geben, wie ich das auf einen zweiten Port
>erweitern kann.
Mein erster Ansatz wäre es aus den benötigten Registern (key_xxx, ct0,
ct1, i, ...) Integer (16bit) zu machen. Zusätzlich muss dann noch die
Zeile

i = key_state ^ ~KEY_INPUT

entsprechend angepasst werden. Damit sollte es im Wesentlichen schon
funktionieren. Es kann aber sein, dass ich noch eine Kleinigkeit
vergessen habe...

Siehe auch yalus Beitrag oben.

Welche Version für Assembler ist die aktuelle, die oben angegebene oder
die im Tutorial ? Worin unterscheiden sie sich ?

Ich habe gestern versucht, die im Tutorial aufgeführte Fassung im
Debugger vom AVR Studio nachzuvollziehen und gleichzeitig auf Papier.
Die Werte auf Papier erhielt ich zwar auch im AVR Studio, aber sie
ergeben keinen Sinn (nach dem 4. Durchlauf ist key_press immer noch 0).

Wo findet sich in der Tutorial-Fassung ein Zähler, der bis 4 zählt ? Die
einzigen Variablen, die in jedem Durchlauf übernommen werden, sind
key_old, key_state und key_press, iwr0 und iwr1 werden jedesmal
verworfen (werden sogar extra auf dem Stack geschrieben) ???

P.S.: Die oben angegebene Version liefert im Debugger von AVR Studio
4.12 die Meldung 'Invalid opcode 0xffff at address 0x000899 und springt
nicht mehr aus der Interruptroutine heraus).

Wäre klasse, wenn mir jemand weiterhelfen kann.

> iwr0 und iwr1 werden jedesmal verworfen

Verworfen??? - Das sind doch aber die 8 Zweibit-Zähler...

Bit 0 jedes der 8 Zähler befindet sich in iwr0, Bit 1 in iwr1. Gezählt
wird global (bzw. static), die Werte müssen also zwischen den Aufrufen
der Routine erhalten bleiben. Wenn Du die löscht (verwirfst,
überschreibst), dann kann da ja nix zählen.

...

Vielen Dank für die Antworten!

@Hannes Lux:
Sie sind der Auslöser, daß ich mir diesen Code antue ;-) Eigentlich gehe
ich gerade Ihren Code zum R/C-Sender durch und bin dabei auf die
Tastenentprellung gestoßen. Wenn es nicht stört, würde ich mich nochmals
gesondert mit Fragen zu Ihrem Code an Sie wenden.

@Peter Dannegger / all:
Die zwei 8-Bit-Zähler iwr0 und iwr1 stelle ich mir bislang wie folgt
vor:

1. Zyklus:
iwr0: 00 00 00 00
iwr1: 00 00 00 00

2. Zyklus:
iwr0: 00 00 10 00
iwr1: 00 00 00 00

3. Zyklus:
iwr0: 00 00 00 00
iwr1: 00 00 10 00

4. Zyklus:
iwr0: 00 00 10 00
iwr1: 00 00 10 00 (jetzt wird key_press gesetzt)
            ^
(für den Fall, daß Bit 3 bei PIND gesetzt ist)

Ist das soweit richtig ?
Ich werde mir das ganze heute abend, nach der Arbeit, nochmals zu Gemüte
führen.

> Wenn es nicht stört, würde ich mich nochmals
> gesondert mit Fragen zu Ihrem Code an Sie wenden.

Nur zu. Antwort kann aber etwas dauern, da ich nicht immer online bin.

> iwr0 und iwr1 ...

Das war natürlich Blödsinn von mir, sorry, ich war auf die
Prellzähler-Bytes aus...

...

Mal eine ganz dumme Frage:
Worauf bezieht sich "4-Abtastung" ? Bedeutet das, daß die
Interrupt-Routine viermal 'erfolgreich' durchlaufen werden muß oder wird
innerhalb eines Interrupts viermal abgetastet (PINB wird aber ja nur
einmal eingelesen?) ?

> Bedeutet das, daß die
> Interrupt-Routine viermal 'erfolgreich' durchlaufen werden muß

Genau!
Bei Durchlaufen erhöhen "erfolgreiche" Bits ihren Zählerstand (COM,
EOR), während "nicht erfolgreiche Bits" ihren Zählerstand löschen (AND,
AND).

Hier mal zum Vergleich eine anders kommentierte Version, vielleich
helfen die anderen Kommentare beim Verständnis:

Tastenabfrage:  ;Entprell-Algorithmus geklaut bei Peter Dannegger...
 cbr flags,1<<entprell ;Jobflag löschen
 in tmp,tap         ;Tastenport einlesen (gedrückt=L)
 com tmp            ;invertieren (gedrückt=H)
 andi tmp,alltast   ;ungenutzte Bits ausblenden
 eor tmp,tas        ;nur Änderungen werden H
 and tz0,tmp        ;Prellzähler unveränderter Tasten löschen (Bit0)
 and tz1,tmp        ;Prellzähler unveränderter Tasten löschen (Bit1)
 com tz0            ;L-Bit zählen 0,2,->1, 1,3,->0
 eor tz1,tz0        ;H-Bit zählen 0,2,->tz1 toggeln
 and tmp,tz0        ;Änderungen nur dann erhalten, wenn im Prellzähler
 and tmp,tz1        ;beide Bits gesetzt sind (Zählerstand 3)
; Loslasserkennung in diesem Programm deaktiviert
; push tmp           ;Kopie
; and tmp,tas        ;nur die Tasten erhalten, die jetzt losgelassen wurden
; swap tmp           ;ins andere Nibble (das ist ja frei)
; or tfl,tmp         ;Bits im anderen Nibble setzen (alternativ)
; or tlf,tmp         ;Bits im anderen Register setzen (alternativ)
; pop tmp            ;alten Wert
 eor tas,tmp        ;erhaltene Änderungen toggeln alten (gültigen) Tastenstatus
 and tmp,tas        ;nur (neu) gedrückte Tastenbits bleiben erhalten
 or tfl,tmp         ;und zugehörige Bits setzen (gelöscht wird nach Abarbeitung)
 ;in "tas" steht jetzt der gültige Tastenzustand,
 ;in "tfl" die Flags der neu gedrückten, noch nicht abgearbeiteten Tasten...
Tastendauer:
 mov tmp,tas        ;Tastenzustand kopieren
 andi tmp,wietast   ;nur Tasten mit Wiederholfunktion stehen lassen
 tst tmp            ;ist eine Taste betätigt?
 breq Tastendauer0  ;nein, Dauer auf Startwert...
 dec twz            ;ja, Zähler runter
 brne Tastenabfrage_e   ;Dauer abgelaufen? - nein...
 or tfl,tmp         ;ja, noch aktive Tasten übernehmen (alternativ)
; or twf,tmp         ;ja, noch aktive Tasten übernehmen (alternativ)
 ldi twz,twz1       ;und Zähler auf Wiederholwert setzen
Tastenabfrage_e:

...

Die Funktionsweise von Hannes` Code kann ich jetzt im Debugger
nachvollziehen, die Entprellung funktioniert tatsächlich...
Faszinierend!
Der im Tutorial wie auch im Artikel über Entprellung angegebene Code
funktioniert bei mir jedoch nicht, auch nach zehnmaligem Durchlaufen
ändert sich der Zustand von key_press nicht (bei dem Code im
Entprellungs-Artikel ist zudem der Stackpointer nicht initialisiert).

> ist zudem der Stackpointer nicht initialisiert

Es gibt inzwischen einige (neuere) AVRs, die den SP beim Reset
automatisch initialisieren.

> ...funktioniert bei mir jedoch nicht...

Dazu kann und werde ich nichts sagen, das Tutorial ist nicht gerade
meine erste Anlaufstelle. Ich habe den Algorithmus aus dem Anhang des
ersten Beitrags dieses Threads hier, also von hier:
Beitrag "Tasten entprellen - Bulletproof"
http://www.mikrocontroller.net/attachment/1925/Get8keyb.asm

Ich habe die Routine allerdings an meinen (nicht gerade professionellen)
Stil angepasst, sowohl die Variablen-Namen als auch die Kommentare. Da
ich den Algorithmus genial finde, nenne ich im Kommentar auch
grundsätzlich den Autor, denn ich will mich nicht mit fremden Federn
schmücken. Meist lasse ich diese Routine auch nicht direkt im Timer-Int
laufen, sondern in einem Job der Mainloop, der vom Timer (nebenbei)
synchronisiert wird. Ich habe auch Varianten im Einsatz, wo die
Variablen im SRAM gehalten werden weil mehrere Tastenports (an
Schieberegistern) entprellt werden müssen. Die Routine hat sich bei
meinen Basteleien in verschiedensten Varianten bestens bewährt. Deshalb
hier nochmal ein besonderes Dankeschön an Peter.

...

Hallo,

ich verwende die Entprell-Routine von Peter und möchte bei zwei Tastern
zwischen kurzem und langem Drücken unterscheiden, um diese mehrfach zu
verwenden.
Das funktioniert aber nur teilweise. Ich habe exakt das Beispiel unten
aus http://www.mikrocontroller.net/articles/Entprellung kopiert.
REPEAT_START und REPEAT_NEXT sind beide 50, also 500 ms. Der Interrupt
kommt alle 10 ms.
Das Problem ist, dass Gelegentlich ein kurzes Drücken als langes erkannt
wird. Es passiert z.B. bei Tastendrücken von 125 ms (mit DSO gemessen),
dass diese mit get_key_long erkannt werden.

Hast jemand eine Idee, woran das liegen kann? Ich bin verzweifelt. :-(

Gruß
martin

Hallo,

vielen Dank für die schnelle Antwort. Leider hat mein Kunde sich keine
Gedanken zur Bedienbarkeit gemacht und einfach 4 Tasten platziert. Die
zwei anderen sind schon anders belegt.
Die beiden Tasten, bei denen zwischen kurzem und langem drücken
unterschieden werden soll, werden nicht gleichzeitig betätigt. Das oben
beschriebene Problem taucht auch bei einer einzelnen Taste auf.

Gruß
Martin