switch Anweisungen funktioniert nicht

[Bruno (Gast)]

Hi,
der folgende Quellcode funktioniert nicht, und ich weiß nicht wieso.
Eigentlich sollte der richtig sein, doch bei der switch-Anweisung
springt er immer zur letzten case-Auswahlt. Der default-Teil wird auch
korrekt aufgerufen.
Bin echt für jede Hilfe dankbar, denn so langsam zweifel ich an meinem
Verstand.

Bruno

[Rolf Magnus (Gast)]

Woher weißt du denn, daß er zum letzten case springt? Sie machen doch
alle das gleiche.
Außerdem: bist du sicher, daß du nur die die Pull-up-Widerstände von
PortD abhängig von den Tasters ein- und ausschalten willst?

[Bruno (Gast)]

Tschuldigung, dass hatte ich vergessen dabei zu schreiben. Mein Fehler.
Ich hab zuerst ein wesentlich größeres Programm geschrieben, in dem ich
mit Tastern etwas auf einem display ausgeben will. Beim Debuggen im
AVRStudio ist mir dann aufgefallen, dass die switch anweisung eben
nicht funktioniert. Darauf hin hab ich das Programm so weit Schritt für
Schritt gekürzt, bis dass nur noch die switch Anweisung übrig war. Und
dort hab ich dann mal nur die Ausgabe auf PORTD getestet, aber es
funktioniert immer noch nicht. Ich hoffe, dass ich diesmal nichts
vergessen hab zu erwähnen.

Bruno

[Falk W. (dl3daz)]

> bei der switch-Anweisung springt er immer zur letzten case-Auswahlt.
Welchen Wert hat "tasters" denn?

Falk

[Bruno (Gast)]

Die Watch Anzeige vom AVRStudio zeigt immer den richtigen Wert an, also
wenn ich Bit 1 von PORTB setzt, dann eben eins. Wenn ich nur das fünfte
setzte eben 0x10. Und egal welchen Wert tasters hat, also 1,2,4,8 oder
16, er springt immer zur letzten case-Anweisung. Jede andere Zahl wird
von der default-Anweisungen auch verarbeitet.

Bruno

[Falk W. (dl3daz)]

Setze doch in den verschiedenen case-Zweigen mal eine Variable und sieh
nach, welchen Wert die am Ende hat.

Ich habe schon Debugger gesehen, die gerade solche Sachen schlampig
anzeigen.

Sonst fällt mir nix mehr ein.

Falk

[Jörg W. (dl8dtl) (Moderator)]

Nicht der Debugger dürfte Schuld sein, sondern die Optimierung des
Compilers, die das alles weitestgehend zusammenfasst, sodass sie dem
Debugger nur noch sehr spärliche Zeilennummerninformationen zukommen
lassen kann.

Grundregel #1: benutze keine degradierten Modelle, um die Unfähigkeit
von Compilern oder Debuggern, den Code ,,richtig'' anzuzeigen,
nachzuweisen.  Ziel der Optimierung des Compilers ist es ja gerade,
derartige degradierte Fälle (die man in der Praxis oft schreibt, weil
es die Lesbarkeit verbessert) zusammenzufassen.

Man kann das natürlich durch Ausschalten der Optimierun
,,beseitigen'', allerdings debuggt man dann auch einen komplett
anderen Code -- und kann es genauso gut auch gleich sein lassen.  Es
ist praktikabler, sich an die vermeintlich seltsamen Hin- und
Hersprünge des Debuggers beim schrittweisen Abarbeiten optmierten
Codes zu gewöhnen und dafür den endgültigen Code zu debuggen.

[Falk Willberg (dl3daz) (Gast)]

> Nicht der Debugger dürfte Schuld sein, sondern die Optimierung
> des Compilers
Autsch. Übersetzt heißt der Code ja: "Egal, was kommt (1,2,4,...),
setze PORT=var". Optimiert steht dann "PORT=var" und der Debugger
sucht sich einen Wolf, wo das im Source steht ;-)

Dann war der Tip mit dem setzen einer Variablen mit unterschiedlichen
Werten (versehentlich) nicht verkehrt.

73,
Falk (der dem perl-debugger dennoch Bösartigkeit unterstellt)

[Fritz G. (fritzg)]

Sollte da nicht auf jedenfall ein

DDRB=0xff;

rein? Sonst ist es kein Eingang.

[Rolf Magnus (Gast)]

Genau das Gegenteil ist der Fall. Ein DDRB=0xff stellt Port B komplett
auf Ausgang um.

[Fritz G. (fritzg)]

Sorry, ist wohl noch zu früh am morgen :-(

[Thomas Pototschnig (Gast)]

imho ist der Codeschnippsel oben nicht so besonders toll -
Du solltest auf_jeden_fall die nicht benutzten Bits aus deiner
Tastervariable ausmaskieren. Also:
[...]
tasters = PINB & 0x1f;
[...]

Wenn sonst an den anderen Pins etwas anderes als LO anliegt, wird die
Switch-Anweisung nie greifen. Bei DDRB = 0x00 und PORTB = 0xff, sind
die Bits von PINB 5-7 immer auf HI wenn nichts angeschlossen ist und es
wird niemals funktionieren.
Furchtbar schlecht also.

Außerdem sollte man eigentlich die internen Pullups aktivieren und
außen die Schalter auf Masse schalten. Aber das ist wohl eher
Geschmackssache.