PIC: Problem mit state-maschine und Reihenfolge der Portabfrage

@ musicmiles (Gast)

>Nun habe ich eine kleine State-Maschine programmiert

Kleiner Tipp: Nutze symbolische Namen (#define oder enum) für die 
States, damit wird das Ganze deutlich besser lesbar, siehe 
Statemachine.

>über das verhalten des Microcontrollers. In der main-Funktion des
>Programms wird die state-maschine aufgerufen. Die state-maschine liest
>mithilfe der Funktion key_Handler() zuerst alle Eingänge und ein
>generiert aus dem aktuellen Zustand einen Status und arbeitet darauf hin
>die notwendigen (vom Status abhängigen) Aktionen ab.

Deine Struktur ist ungünstig. Die Aktionen gehören in die State machine. 
Ausserdem macht man eine Tasterentprtellung bzw. Flankenerkennung 
anders. Der Klassiker: Die Entprellroutin von Peter Danneger. ISt zwar 
für AVR, kann man aber leicht auf PIC anpassen.

Siehe Entprellung.

musicmiles schrieb:

BIst du sicher, dass deine Tasten im Ruhezustand eine 0 liefern und nur 
wenn gedrückt eine 1?

Wie sind deine Taster verschaltet? Schalten die nach GND oder schalten 
die nach Vcc? Gibt es Pullup bzw. Pulldown Widerstände?


(Ich geh mal davon aus, dass eine gedrückte Taste bei dir eine 1 
liefert)
Dein Code ist insofern ungünstig, weil du grundsätzlich immer nur die 
Taste mit der höchsten Bitnummer akzeptierst. Durch Drücken von RB7 kann 
ich damit alle anderen Tasten lahm legen. Und wenn deine 
Hardware-Entprellung zb wegen offener Eingänge doch nicht so gut 
funktioniert, wie du denkst, dann kann dir ein floatender Eingang mit 
einer Nummer höher als RB1 den RB1 lahmlegen. Vor allen Dingen dann, 
wenn der toggelt wie verrückt. Denn dein Code WILL ja den Eingang 11 mal 
hintereinander (mit jeweils 10ms Wartezeit dazwischen) auf Low sehen, 
ehe der Tastendruck akzeptiert wird. Jeder Toggler an einem Eingang 
startet diese 110ms wieder erneut.

>     if(PORTBbits.RB1==1)
>     {
>         state=1;
>         for(db_cnt = 0; db_cnt <= 10; db_cnt++)
>         {
>             __delay_ms(1);
>             if(PORTBbits.RB1==1)
>             {
>                 db_cnt = 0;
>             }
>         }
>     }

Das ist ziemlich kompliziert geschrieben. Wenn deine Hardware 
Entprellung funktioniert, dann ist das alles recht unnötig. Vor allen 
Dingen die Wartezeiten. Wenn die Hardware Entprellung in Ordnung ist, 
dann ist es so

1

     if( PORTBbits.RB1 == 1 )     // gedrückt ?

2

     {

3

       while( PORTBbits.RB1 == 1 )  // ja, warte aufs loslassen

4

         ;

5

       state = 1;

6

     }

viel simpler. Alleine dadurch, dass du da scheinbar einen delay 
brauchst, lässt mich daran glauben, dass deine Entprellung eben doch 
nicht so gut funktioniert, wie du denkst.

Karl Heinz schrieb:

> wenn der toggelt wie verrückt. Denn dein Code WILL ja den Eingang 11 mal
> hintereinander (mit jeweils 10ms Wartezeit dazwischen)


Entschuldigung. Es sind nur 1 ms und nicht 10. Demenstprechend dann auch 
11ms komplett und nicht 110.

Am grundsätzlichen Grundproblem ändert das allerdings immer noch nichts. 
Die Tastenabfrage ist so inakzeptabel. Durch drücken einer Taste und 
gedrückt halten der Taste kann ich den kompletten µC mit Ausnahme von 
Interrupt Routinen lahm legen.

musicmiles schrieb:

> mit. Und alle anderen Eingänge liegen definitiv auf low (werden durch
> den Schmitt-Trigger in Verbindung mit einem Pull_Down runtergezogen).

Dann musst du dir ansehen, wo der µC die Zeit vertödelt.
Ich denke immer noch, er hängt in irgendeiner anderen Tastenabfrage, 
weil die Eingänge nicht so ruhig sind, wie du glaubst das sie sind.

Mach dir dort halt mal ein paar Ausgaben zb mittels LED einschalten 
rein. Dann kommst du dem auf die Schliche