Tastenmatrix erkennt 2 Tasten bei einer gedrückten Taste

[Taster (Gast)]

Hallo miteinander,

ich bin gerade dabei eine 4x4 Tastenmatrix mit Hilfe eines Mega328 
auszuwerten.

Meine Schaltung sieht folgendermaßen aus:

      PD5   PD4   PD3   PD2
       |     |     |     |
       |     |     |     |
PB1----a-----b-----c-----d
       |     |     |     |
PB0----e-----f-----g-----h
       |     |     |     |
PD7----i-----j-----k-----l
       |     |     |     |
PD6----m-----n-----o-----p

Dabei werden PD5 - PD2 als Eingang mit aktivem Pullup und PB1, PB0, PD7 
und PD6 mit hochomig initialisiert.
Dann multiplexe ich die Reihen in einem Timerinterrupt alle 10 ms und 
lese dabei PD5 - PD2 aus.
Nun hab ich folgendes Problem, dass wenn ich die Taste a drücke, erkennt 
er einen Tastendruck auf a und e. Drücke ich Taste e, dann erkennt er 
einen Tastendruck auf e und i. Drücke ich jedoch eine beliebige andere 
Taste (außer a und e), so erkennt er korrekt nur eine Taste.

Mein Code:
Init:

   // Ausgangspins fuer Tastenmatrix setzen
   // Reihen auf Eingang ohne Pullup
   DDRB &= ~(1 << 1);
   DDRB &= ~(1 << 0);
   DDRD &= ~(1 << 7);
   DDRD &= ~(1 << 6);
   // Spalten auf Eingang mit Pullup
   DDRD &= ~(1 << 5);
   DDRD &= ~(1 << 4);
   DDRD &= ~(1 << 3);
   DDRD &= ~(1 << 2);
   PORTD |= (1 << 5);
   PORTD |= (1 << 4);
   PORTD |= (1 << 3);
   PORTD |= (1 << 2);

ISR:

ISR(TIMER1_COMPA_vect)
{
   DDRD &= ~((1 << 7) | (1 << 6));
   PORTD &= ~((1 << 7) | (1 << 6));
   DDRB &= ~((1 << 1) | (1 << 0));
   PORTB &= ~((1 << 1) | (1 << 0));
   switch (btn_row)
   {
      case 0:
            DDRB |= (1 << 1);
            PORTB &= ~(1 << 1);
         break;
      case 1:
            DDRB |= (1 << 0);
            PORTB &= ~(1 << 0);            
         break;
      case 2:
            DDRD |= (1 << 7);
            PORTD &= ~(1 << 7);
         break;
      case 3:
            DDRD |= (1 << 6);
            PORTD &= ~(1 << 6);      
         break;
   }
   btns[btn_row][0] = (!(PIND & (1 << 5))) ? 1 : 0;
   btns[btn_row][1] = (!(PIND & (1 << 4))) ? 1 : 0;
   btns[btn_row][2] = (!(PIND & (1 << 3))) ? 1 : 0;
   btns[btn_row][3] = (!(PIND & (1 << 2))) ? 1 : 0;
   btn_row++;
   if (btn_row >= 4) {btn_row = 0;};
}

Vielleicht kann mir jemand auf die Sprünge helfen. Danke im vorraus.

[c-hater (Gast)]

Taster schrieb:

> Vielleicht kann mir jemand auf die Sprünge helfen. Danke im vorraus.

Hmm...

Ich würde von einem "Timing"-Problem ausgehen (eigentlich eher: 
Crosstalk).

Also, wenn ich mit meiner Annahme Recht habe, sollte es genügen, immer 
nach der "Aktivierung" einer jeden Spaltenleitung erst einen kleinen 
Moment zu warten, bevor du die Zeilenstati einliest. Der kleine Moment 
sollte so etwa in der Größenordnung einiger (sehr weniger) µs liegen. 
Vielleicht zum Testen erstmal 2 oder 3.

Wenn das nicht zum Erfolg führt, solltest du überprüfen, ob für alle 
Zeileneingänge wirklich die Pullups aktiviert sind (ich hatte keine 
Lust, deinen Code durchzusehen).

[Taster (Gast)]

c-hater schrieb:
> Also, wenn ich mit meiner Annahme Recht habe, sollte es genügen, immer
> nach der "Aktivierung" einer jeden Spaltenleitung erst einen kleinen
> Moment zu warten, bevor du die Zeilenstati einliest. Der kleine Moment
> sollte so etwa in der Größenordnung einiger (sehr weniger) µs liegen.
> Vielleicht zum Testen erstmal 2 oder 3.

Habe nun ein Delay von 2 µs hinzugefügt und tadaa. Nun werden auch a und 
e richtig erkannt.
Danke schön

[Marc V. (Firma: Vescomp) (logarithmus)]

Taster schrieb:
> Vielleicht kann mir jemand auf die Sprünge helfen. Danke im vorraus.

 Ist das Ganze nicht verkehrt herum ?
 PB.0 / PB.1 / PD.6 / PD.7 als Ausgang mit Pullup.
 PD.2 -> PD.5 als Eingang mit Pullup.
 In der ISR ein Ausgang nach dem anderen auf Low schalten, paar Takte
 warten, PinD einlesen, AND mit 0x3C, auswerten.

[c-hater (Gast)]

Taster schrieb:

> Habe nun ein Delay von 2 µs hinzugefügt und tadaa. Nun werden auch a und
> e richtig erkannt.

Gut. Nun solltest du noch versuchen, das Delay so weit wie möglich zu 
verkleinern. Die 2..3µs waren recht großzügig angegeben, wahrscheinlich 
genügt auch ein wesentlich kürzeres Delay im Bereich einiger 10 bis 
einiger 100 ns bereits, um den crosstalk ausreichend abebben zu lassen.

[Sascha W. (sascha-w)]

@Taster,

du könntest auch erst den Zustand einlesen und im Anschluss die Pins 
umschalten, so liegt der Zustand bis zum nächsten Aufruf der ISR stabil 
an.

Sascha

[Taster (Gast)]

8 NOPs sind ausreichend. Macht bei 16 MHz eine Dauer von 500 ns

[c-hater (Gast)]

Sascha Weber schrieb:

> du könntest auch erst den Zustand einlesen und im Anschluss die Pins
> umschalten, so liegt der Zustand bis zum nächsten Aufruf der ISR stabil
> an.

Genau das ist tatsächlich die bestmögliche Lösung des Problems, denn sie 
kommt ohne jedes Delay in einer ISR aus