If-Schleife übersprungen

[K. S. (sime)]

Hallo ich hab hier mal ein Quellcode, bei dem ich meinen Fehler nicht 
finde. Ich denke aber, dass es irgenetwas naheliegendes sein muss.

*********************************************************************
# define F_CPU 3686400UL            
# include <avr/io.h>
# include <util/delay.h>
void start();    

void start()
{
  if (((~PINB) & 0b00001000) == 0b00001000)    
    {
      PORTA |=0b01000000;
    }
  else
    {
      PORTA &=0b10111111;
    }

  if ((PIND & 0b10000000) == 0b10000000)      
    {
      PORTA |=0b01000000;
    }
  else
    {
      PORTA &=0b10111111;
    }
}

int main(void)
{
  
  
  DDRA = 0b01000000;      
  DDRB = 0b00000011;        
  DDRC = 0b01000000;      
  DDRD = 0b00000000;          
  
  PORTA |= (1<<PORTB0)|(1<<PORTB1)|(1<<PORTB2);
  PORTA |= (1<<PORTB3)|(1<<PORTB4)|(1<<PORTB5);
  PORTA |= (1<<PORTB7);
  PORTB |= (1<<PORTB2)|(1<<PORTB3)|(1<<PORTB4);  
  PORTB |= (1<<PORTB5)|(1<<PORTB6)|(1<<PORTB7);  
  PORTC |= 0b10111111;            
  PORTD |= 0b11111111;            

  
  while(1)
    {
        start();
    
    }
}
******************************************

wenn die erste If-Bedingung erfüllt ist wird die zweite If-Schleife 
übersprungen, wenn die erste If-Bedingung nicht erfüllt ist und der 
Else-Zweig abgearbeitet wird, wird die zweite If-Schleife ganz normal 
abgearbeitet.
Ich habe keine Ahnung, warum die zweite Schleife übersprungen wird.
Es wäre schön wenn ihr mir weiterhelfen könnt.
Tschau
SIME

[Rene S. (Firma: BfEHS) (rschube)]

http://www.if-schleife.de/

[Martin S. (sirnails)]

Probiere doch mal die Kurzform:

void start()
{
  if (((~PINB) & 0b00001000) == 0b00001000) ? PORTA |=0b01000000 PORTA 
&=0b10111111;
  if ((PIND & 0b10000000) == 0b10000000) ? PORTA |=0b01000000 : PORTA 
&=0b10111111;
};

[K. S. (sime)]

Aha,
das könnte es sein.
Danke

[Martin S. (sirnails)]

Nachtrag: Doppelpunkt vergessen ....

void start()
{
  if (((~PINB) & 0b00001000) == 0b00001000) ? PORTA |=0b01000000 : PORTA 
&=0b10111111;
  if ((PIND & 0b10000000) == 0b10000000) ? PORTA |=0b01000000 : PORTA 
&=0b10111111;
};

[K. S. (sime)]

Aber eigentlich sollte es doch keinen Unterschied machen oder?

[Peter II (Gast)]

K. S. schrieb:
> Aber eigentlich sollte es doch keinen Unterschied machen oder?

würde ich auch sagen, der code sieht richtig aus. Die Frage ist welcher 
werte wirklich anliegen, das können wir leider nicht sehen.

[K. S. (sime)]

Ich habs durchgespielt mit F11 und dabei immer mal PINC3 gesetzt und 
nicht gesetzt.
Vielleicht liegts ja auch an meinen Einstellungen.

[Peter II (Gast)]

K. S. schrieb:
> Ich habs durchgespielt mit F11 und dabei immer mal PINC3 gesetzt und
> nicht gesetzt.
> Vielleicht liegts ja auch an meinen Einstellungen.

aber was hat das ganze mit PINC3 zu tun? kommt doch nirgends vor.

tausche doch mal beide If blöcke.

[K. S. (sime)]

sorry ich meinte B3

[K. S. (sime)]

Wenn ich die Blöcke tausche, gehts auch nicht.
Es muss irgend etwas Prinzipielles sein.

[Peter II (Gast)]

K. S. schrieb:
> Wenn ich die Blöcke tausche, gehts auch nicht.
> Es muss irgend etwas Prinzipielles sein.

was geht da nicht, wird der 1. Block wieder übersprungen oder diesemal 
der 2.?

[test (Gast)]

Rene Schube schrieb:
> http://www.if-schleife.de/

Es gibt die sogenannte if-goto schleife.

Wenn wir schon bei wichtigen C Konstrukten sind, möchte ich auf den 
limes Operator verweisen:

#define limes while

int n=42;
limes (n-->0) {
  foo(n);
}

[K. S. (sime)]

Wenn der erste If-Block erfüllt ist, wird die zweite If-Abfrage 
übersprungen und das Programm springt in die Zeile unter der Abfrage.

[Martin S. (sirnails)]

Hast Du die Kurzform mal ausprobiert? Es könnte ja sein, dass der 
Compiler aus irgendwelchen Gründen das zweite If als Bestandteil des 
Else des ersten if sieht.

Mache außerdem mal ein Semikolon nach der Klammer:

if (bed) {...} else {...}*;*

[Peter II (Gast)]

Martin Schwaikert schrieb:
> Hast Du die Kurzform mal ausprobiert? Es könnte ja sein, dass der
> Compiler aus irgendwelchen Gründen das zweite If als Bestandteil des
> Else des ersten if sieht.

warum sollte er das machen?

[K. S. (sime)]

test schrieb:
> #define limes while
>
> int n=42;
> limes (n-->0) {
>   foo(n);
> }

ich verstehe nicht warum du 42 gegen 0 gehen lassen willst, wo es doch 
die Antwort auf alle Fragen ist.
Nur leider hat das jetzt auch schon wieder nicht geklappt. Ich dachte 
eigentlich das der Code so funktionieren müsste und hatte gehofft 
irgendjemand weiß eine schnelle Lösung.
Kann vielleicht mal jemand das Programm kurz bei sich einspielen.
Vielleicht habe ich ja auch irgendeinen Mist beim AVR-Studio 
eingestellt.
Danke
SIME

[if-men (Gast)]

Peter II schrieb:
> Martin Schwaikert schrieb:
>> Hast Du die Kurzform mal ausprobiert? Es könnte ja sein, dass der
>> Compiler aus irgendwelchen Gründen das zweite If als Bestandteil des
>> Else des ersten if sieht.
>
> warum sollte er das machen?

wollte ich auch gerade fragen, denn der zweite IF hat überhaupt nicht 
mit den Varaiblen aus dem ersten IF zu tun...

[Karl H. (kbuchegg)]

Wie stellst du eigentlich fest, dass hier etwas abnormes passiert?

Wenn der Optimizer des Compilers eingeschaltet ist, dann zeigt dir der 
Simulator den Programmablauf nicht mehr genau so an, wie du ihn 
geschrieben hast.

[K. S. (sime)]

Ich bin darauf gekommen, als meine Hardware nicht das gemacht hat, was 
ich dachte geschrieben zu haben.
Daraufhin habe ich dann das mit den If-Blöcken versucht und bin es 
Schritt für Schritt durchgegangen und das überspringen der Schleife hat 
auch zu meinem Problem gepasst.
Darum denke ich, dass da irgend ein Fehler drinn sein muss.
Tschau
SIME

[Karl H. (kbuchegg)]

So
nachdem ich jetzt 3 mal die Stellen der Binärzahlen abgezählt habe und 
mich natürlich prompt 5 mal verzählt habe, darf ich vorschlagen, das 
ganze mal vernünftig zu schreiben, so dass man
a) das ganze schnell erfassen kann, und man
b) weniger Tippfehler machen kann?

void start()
{
  if (!( PINB & (1<<PB3)) )
    {
      PORTA |= (1<<PA6);
    }
  else
    {
      PORTA &= ~(1<<PA6);
    }

  if ( PIND & (1<<PD7) )
    {
      PORTA |= (1<<PA6);
    }
  else
    {
      PORTA &= ~(1<<PA6);
    }
}

Jetzt sieht man auch auf einen Blick, dass beide ifs denselben Pin am 
Port A bedienen. Ist das so gewollt?

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Ich würde einfach mal mit 2 Eingängen dann auch 2 getrennte Ausgänge 
manipulieren. So wie das hier jetzt voneinander abhängt und letztlich 
auf 1 Ausgang geht, könnte für manchen der Eindruck einer gewissen 
Abhängigkeit entstehen...

[Karl H. (kbuchegg)]

K. S. schrieb:

> Daraufhin habe ich dann das mit den If-Blöcken versucht und bin es
> Schritt für Schritt durchgegangen und das überspringen der Schleife hat
Wenn dich schon jemand darauf hinweist, dass if keine Schleife ist, dann 
solltest du das auch annehmen.
Eine 'Schleife' ist nicht etwas in dem { } Klammern vorkommen, sondern 
eine Schleife ist etwas, in dem Code (potentiell) wiederholt wird, so 
wie in einem for, while. Darum heißßt es Schleife, weil es 'im Kreis rum 
geht', genau wie ein Tonband, welches man zu 'einer Schleife' 
zusammengeklebt hat.

Ein if trifft einfach nur eine Auswahl aus 2 Möglichkeiten und das hat 
mit einer Schleife genau gar nichts zu tun. Das ist eine Abfrage.


> Darum denke ich, dass da irgend ein Fehler drinn sein muss.

Also in realer Hardware.
Da hier der A-Port im Spiel ist.
AVcc ist angeschlossen?

Dir ist bewusst, dass du am A-Port denselben Ausgangspin ansteuerst. Ist 
das so gewollt?

[K. S. (sime)]

Karl Heinz Buchegger schrieb:
> Dir ist bewusst, dass du am A-Port denselben Ausgangspin ansteuerst. Ist
> das so gewollt?

ja.
ich habe zwei verschiedene Taster die jeweils die selbe LED zum leuchten 
bringen sollen.
Das mit der If- Schleife tut mir leid ich habe extra Blöcke geschrieben 
aber in der nächsten Zeile ist es mir wieder rausgerutscht
SIME

[Karl H. (kbuchegg)]

K. S. schrieb:
> Karl Heinz Buchegger schrieb:
>> Dir ist bewusst, dass du am A-Port denselben Ausgangspin ansteuerst. Ist
>> das so gewollt?
>
> ja.
> ich habe zwei verschiedene Taster die jeweils die selbe LED zum leuchten
> bringen sollen.

Dann musst du das grundsätzlich anders machen.

Denn dein erster if setzt zwar die LED richtig, aber dein zweites if 
ändert das gleich wieder.

mit dem einen Taster kannst du die LED schon einschalten. Aber wenn der 
zweite Taster nicht gedrückt ist, dann brennt die nur ein paar 
Mykro-Sekunden lang. Und so schnell kannst du nicht schauen.

ALso: Du hast einen Logikfehler.


Was du wirklich willst:
Wenn der eine Taster gedrückt ist ODER der andere (oder beide), dann 
schalte die LED ein, ansonsten aus.
(Apropos: wie sind deine Taster eigentlich verschaltet? Den einen fragst 
du auf 0 ab, den anderen auf 1)

void start(void)
{
  if (!(PINB & (1<<PB3)) ||
      !(PIND & (1<<PD7)) )
    PORTA |= (1<<PA6);
  else
    PORTA &= ~(1<<PA6);
}

[K. S. (sime)]

Karl Heinz Buchegger schrieb:
> ALso: Du hast einen Logikfehler.

Ich habe jetzt auch mal in dem zweiten Block einen anderen Ausgang 
gesetzt.
Jetzt wird beim durchlaufen mit F11 trotzdem wieder der zweite Block 
übersprungen.
Ich weiß ehrlich gesagt nicht wie der Optimizer funktioniert aber 
eigentlich müsste doch jede Zeile die genutzt wird beim F11-Betrieb 
angesprochen werden oder?

[Karl H. (kbuchegg)]

K. S. schrieb:
> Karl Heinz Buchegger schrieb:
>> ALso: Du hast einen Logikfehler.
>
> Ich habe jetzt auch mal in dem zweiten Block einen anderen Ausgang
> gesetzt.
> Jetzt wird beim durchlaufen mit F11 trotzdem wieder der zweite Block
> übersprungen.

Im Simulator.

Nochmal: Wenn der OPtimizer des Compilers eingeschaltet ist, dann zeigt 
der der Debugger den Ablauf nicht unbedingt genau so, wie du ihn 
geschrieben hast. Der Optimizer des Compilers kann, darf und wird da die 
Anweisungen umgruppiere, so dass der Debugger keine einwandfreie 
Zuordnung mehr machen kann, welche Assemblerinstruktionen jetzt zu 
welchem C Code gehören.

Wichtig ist ob die Pins genau das tun, was du programmiert hast!

Und im Zweifel gilt immer:
wie sieht das Programm jetzt aus? Ohne aktuellen Code kann dir hier 
keiner auseinanderdividieren was wirklich passiert.

[K. S. (sime)]

Karl Heinz Buchegger schrieb:
> nd im Zweifel gilt immer:
> wie sieht das Programm jetzt aus? Ohne aktuellen Code kann dir hier
> keiner auseinanderdividieren was wirklich passiert.

also hier mal der aktuelle Code:
**************************************

# define F_CPU 3686400UL
# include <avr/io.h>
# include <util/delay.h>
void start();

# define F_CPU 3686400UL            
# include <avr/io.h>
# include <util/delay.h>
void start();    

void start()
{
  if (((~PINB) & 0b00001000) == 0b00001000) //wenn die Bedingung        
                                            //erfüllt ist     
    {
      PORTA |=0b01000000;                   //springt er hierher
    }
  else
    {
      PORTA &=0b10111111;                    //lässt das aus
    }

  if ((PIND & 0b10000000) == 0b10000000)   //lässt aber auch diesen
                                           //Block komplett aus
    {
      PORTC |=0b01000000;
    }
  else
    {
      PORTC &=0b10111111;
    }
}

int main(void)
{
  
  
  DDRA = 0b01000000;      
  DDRB = 0b00000011;        
  DDRC = 0b01000000;      
  DDRD = 0b00000000;          
  
  PORTA |= (1<<PORTB0)|(1<<PORTB1)|(1<<PORTB2);
  PORTA |= (1<<PORTB3)|(1<<PORTB4)|(1<<PORTB5);
  PORTA |= (1<<PORTB7);
  PORTB |= (1<<PORTB2)|(1<<PORTB3)|(1<<PORTB4);  
  PORTB |= (1<<PORTB5)|(1<<PORTB6)|(1<<PORTB7);  
  PORTC |= 0b10111111;            
  PORTD |= 0b11111111;            

  
  while(1)
    {
        start();
    
    }
}

*******************************************

[Karl H. (kbuchegg)]

Und?
Wenn du am Ende der Funktion, nach dem Rücksprung, dir im Simulator die 
Bits vom Port C im I/O View ansiehst, sind die richtig gesetzt oder 
nicht?

(Ansonsten schalt halt mal den Optimizer aus)

[K. S. (sime)]

Karl Heinz Buchegger schrieb:
> Ansonsten schalt halt mal den Optimizer aus)

hab ich gemacht.
Jetzt läufts und meine LEDs auch so wie sie sollen.
Danke und sorry das ich nicht eher nach dem Optimizer gefragt habe.
Ich hab jetzt so viel in meinem eigentlichen Programm rumgewühlt, dass 
ich nicht mal mehrt sagen kann was der Grund für den Fehler war.
Jetzt läufts wieder.

Vielen Dank an alle.

Tschau
SIME

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

K. S. schrieb:
> Karl Heinz Buchegger schrieb:
>> Ansonsten schalt halt mal den Optimizer aus)
> hab ich gemacht.
> Jetzt läufts und meine LEDs auch so wie sie sollen.
> Danke und sorry das ich nicht eher nach dem Optimizer gefragt habe.
Das sollte dir klar sein: ein anderes Verhalten beim Zu- und Abschalten 
des Optimierers deutet auf einen Programmfehler hin.

[Justus S. (jussa)]

bei dem kurzen Programm könnte man sich doch auch mal den erstellen 
Assembler-Code anschauen...

[Karl H. (kbuchegg)]

Justus Skorps schrieb:
> bei dem kurzen Programm könnte man sich doch auch mal den erstellen
> Assembler-Code anschauen...

Wenn ich alle Aussagen so im Kontext zusammensetze, haben wir wieder mal 
den Fall, dass dieser Code nicht der ist, der eigentlich Probleme macht.

[Martin S. (sirnails)]

Peter II schrieb:
> Martin Schwaikert schrieb:
>> Hast Du die Kurzform mal ausprobiert? Es könnte ja sein, dass der
>> Compiler aus irgendwelchen Gründen das zweite If als Bestandteil des
>> Else des ersten if sieht.
>
> warum sollte er das machen?

Um auszuschließen, dass der Compiler das Programm so umstrukturiert, 
dass die zweite If-Abfrage als Bestandteil des Else-Zweiges der ersten 
Bedingung verarbeitet wird - genauso eben, wie ich es schon geschrieben 
habe!

K. S. schrieb:
> Danke und sorry das ich nicht eher nach dem Optimizer gefragt habe.

Der Optimizer ist gut und tut genau das, was er soll - er optimiert und 
rationalisiert. Wenn er Code findet, der unsinnig ist, wird er in die 
Tonne getreten. Genau das passiert wohl bei Dir auch. Ich persönlich 
habe die Erfahrung gemacht, dass man gerade zum Herumprobieren den 
Optimizer auslassen sollte, es sei denn, man schreibt seinen Quelltext 
so, dass der Compiler ihn nicht einfach weglöscht.

Richtig ärgerlich kann es dann nebenbei werden, wenn der Debugger auf 
einen Fehler hinweist, der in einer Berechnung stattfindet, und man 
einfach nicht versteht, warum er dabei auseinanderfliegt. Irgendwann 
einmal merkt man, dass der Optimizer eine Zeile Code entfernt hat, und 
alle Haltepunkte um eine Zeile verschoben sind und der Fehler eigentlich 
ganz woanders auftritt.

[Karl H. (kbuchegg)]

Martin Schwaikert schrieb:
> Peter II schrieb:
>> Martin Schwaikert schrieb:
>>> Hast Du die Kurzform mal ausprobiert? Es könnte ja sein, dass der
>>> Compiler aus irgendwelchen Gründen das zweite If als Bestandteil des
>>> Else des ersten if sieht.
>>
>> warum sollte er das machen?
>
> Um auszuschließen, dass der Compiler das Programm so umstrukturiert,
> dass die zweite If-Abfrage als Bestandteil des Else-Zweiges der ersten
> Bedingung verarbeitet wird - genauso eben, wie ich es schon geschrieben
> habe!

Du greifst da jetzt aber nach einem Strohhalm.
Sicher, es gibt schon mal dumme Fehler in einem Compiler, aber so ist 
das dann auch wieder nicht, dass Compiler völlig ungetestet auf die 
Menschheit losgelassen werden. So ein Fehler fällt beim ALLERERSTEN 
Programm, welches diese Compilerversion compiliert sofort auf. Zumal man 
sich schon sehr anstrengen muss, um so ein Verhalten in die Grammatik 
reinzukriegen.

> rationalisiert. Wenn er Code findet, der unsinnig ist, wird er in die
> Tonne getreten. Genau das passiert wohl bei Dir auch.

Genau das ist in der überwiegenden Mehrzahl der Fälle das eigentliche 
Problem. C lässt ein paar Dinge offen bzw. hat ein paar Dinge, die ein 
Optimizer ausnutzen kann und wird, die aber der Absicht des 
Programmierers zuwider laufen. Das Problem ist nicht der Optimizer, 
sondern dass der Programmierer mit seinen Kenntnissen noch nicht soweit 
ist, diese Dinge zu wissen und entsprechend zu programmieren.
Womit wir wieder bei meinem Lieblingsthema sind: die 'Ausbildung' vieler 
'Programmierer' die hier aufschlagen ist unter aller Sau. Wer analog so 
vorbereitet in den Strassenverkehr gehen würde, würde an der nächsten 
Strassenecke sofort vom nächsten Passanten wegen Gefahr im Verzug aus 
dem Verkehr gezogen und bis zum Eintreffen der Polizei festgehalten 
werden. Nur beim Thema 'Ich werde jetzt Programmierer' ist das ein 
kleineres Kavaliersdelikt, wie ich mir von so manchem schon habe sagen 
lassen müssen. Denn, hey, ICH brauch doch kein Buch! Wozu denn? Ich will 
ja nicht Profi werden.

[Martin S. (sirnails)]

Karl Heinz Buchegger schrieb:
> Du greifst da jetzt aber nach einem Strohhalm.
> Sicher, es gibt schon mal dumme Fehler in einem Compiler, aber so ist
> das dann auch wieder nicht, dass Compiler völlig ungetestet auf die
> Menschheit losgelassen werden.

Nein, das nicht. Der "Dumme" sitzt da zumeist vorm Bildschirm. Ich 
persönlich hatte schonmal den Fall, dass ein fehlender ";" hinter einer 
Anweisung (obwohl in diesem Zusammenhang nicht nötig, und deshalb auch 
nicht geschrieben) dazu führte, dass er die nächste Zeile noch als einen 
Befehl mit aufnahm. Leider habe ich kein konkretes Beispiel mehr, da es 
schon etwas länger her ist, aber ich hatte damals ein ähnliches 
verhalten. Allerdings unter Visual Studio 2010 und nicht speziell beim 
µC.

Karl Heinz Buchegger schrieb:
> Genau das ist in der überwiegenden Mehrzahl der Fälle das eigentliche
> Problem. C lässt ein paar Dinge offen bzw. hat ein paar Dinge, die ein
> Optimizer ausnutzen kann und wird, die aber der Absicht des
> Programmierers zuwider laufen.

Mit Sicherheit. Wie ich ja auch geschrieben hatte schreibt man mal 
schnell ein paar Zeilen Code, die einfach wegrationalisiert werden, da 
sie bei genauerem Betrachten unsinnig sind.

[Andreas B. (andreas_b77)]

Martin Schwaikert schrieb:
> Peter II schrieb:
>> Martin Schwaikert schrieb:
>>> Hast Du die Kurzform mal ausprobiert? Es könnte ja sein, dass der
>>> Compiler aus irgendwelchen Gründen das zweite If als Bestandteil des
>>> Else des ersten if sieht.
>>
>> warum sollte er das machen?
>
> Um auszuschließen, dass der Compiler das Programm so umstrukturiert,
> dass die zweite If-Abfrage als Bestandteil des Else-Zweiges der ersten
> Bedingung verarbeitet wird - genauso eben, wie ich es schon geschrieben
> habe!

Die Variablen PORT und PIN Variablen sind aber volatile, da hat der 
Compiler nicht viel Spielraum. Insbesondere muss er die Reihenfolge der 
Zugriffe einhalten und darf keine Zugriffe wegoptimieren, außer sie 
wären in nicht erreichbarem Code.


> Richtig ärgerlich kann es dann nebenbei werden, wenn der Debugger auf
> einen Fehler hinweist, der in einer Berechnung stattfindet, und man
> einfach nicht versteht, warum er dabei auseinanderfliegt. Irgendwann
> einmal merkt man, dass der Optimizer eine Zeile Code entfernt hat, und
> alle Haltepunkte um eine Zeile verschoben sind und der Fehler eigentlich
> ganz woanders auftritt.

Die Debugging-Information stimmen natürlich mit dem erzeugten 
(optimierten) Code überein, da können sich nicht einfach alle 
Haltepunkte um eine Zeile verschieben. Wenn das passiert dann stimmt 
eher der Code mit den Debugging-Informationen, den der Debugger sieht, 
nicht mit dem überein, der tatsächlich ausgeführt wird, d.h. es ist ein 
Benutzerfehler.

Optimierter Code kann im Single Step im Debugger bei den Source Code 
Zeilen in nicht nachvollziehbaren Schritten vor und zurück springen und 
mancher Code kann schlicht nicht mehr existieren. Aber der Debugger wird 
nicht konstant um eine wegoptimierte Zeile daneben liegen.