STM32 verweigert schleifen?!

[Flo (Gast)]

Hallo zusammen,
ich scheine wohl die seltsamstem Fehler mit meinem
STM32 zu haben.

so versuche ich eine dämlich schleife

int =0;

for (i=0; ende == 1; i++)
{
      if (i == 5)
        {
         GPIO_SetBits(GPIOE,GPIO_Pin_5);
         ende = 1;
        }
}

das ist eine einfach blöde schleife in der main()
an der der compiler auch nichts auszusetzen hat,
aber es tut sich nichts!

mach ich eine einfach abfrage außerhalb einer schleife z.B.

int i = 5;

if (i == 5)
    {
    GPIO_SetBits(GPIOE,GPIO_Pin_5);
    }

funktionierst tadellos

was kann denn sein?
ich verstehs einfach nicht

[Oliver J. (skriptkiddy)]

Hat ende vielleicht schon den Wert 1?

[(prx) A. K. (prx)]

Bitte den echten Code, nicht etwas Nachempfundenes. Denn
  int =0;
steht da bestimmt nicht.

[(prx) A. K. (prx)]

Steht da vielleicht so etwas wie:

int ende=0;
i=0;
while (ende == 1) ...

denn genau das ist die for-Schleife.

[Guest (Gast)]

> for (i=0; ende == 1; i++)

Meinten Sie: for (i=0; ende != 1; i++) ?

[Flo (Gast)]

also das ist meine main momentan,
unwichtige sachen habe ich auskommentiert und hier nicht reingesetzt!

das da unten geht zum beispiel auch nicht, warum auch immer

achja, und ihr könnt mich dutzen ;)

int main(void)
{ 
#ifdef DEBUG debug();
#endif

int ende = 0;
int i =0;

/*
 CCR1_Val =&CCR1;
 CCR2_Val =&CCR2;
 CCR3_Val =&CCR3;
 CCR4_Val =&CCR4;
 GPSKorrektur = &GPSK;
*/

RCC_Configuration();
NVIC_Configuration();
//NVIC1();
GPIO_Configuration();
//TIM_OUT_Configuration(CCR1_Val, CCR2_Val, CCR3_Val, CCR4_Val);
//TIM_IN_Configuration();
UART_Configuration();






while (1) 
  {
   
  for (i=0; ende == 1; i++)
    {
        if (i == 5)
          {
           GPIO_SetBits(GPIOE,GPIO_Pin_5);
           ende = 1;
          }
    }
  }   
}

[Guest (Gast)]

Wie gesagt, mit ende!=1 wird es funktionieren.

[Flo (Gast)]

oh mann, das war wohl einwenig zuviel desguten heute -_-

hab einen richtig fetten denkfehler gehabt,
wenn etwas ungleich ist, dann ist es ja wahr -_-
schön das man sich mit sowas dann 3std auseinandersetzt

danke für den hinweis

[Max (Gast)]

Hmm? Glaub morgen denkst nochmal drüber nach.
Wenn eine Bedingung erfüllt ist (sie führt nicht zum Widerspruch), dann 
ist sie wahr.


Es scheint mir eher, dass du hier Schleifenbedingung und 
Abbruchbedingung durcheinander bringst. Bei for (<a>;<b>;<c>) steht b 
für die Bedingung, die nötig ist um die Schleife zu wiederholen, nicht 
jedoch um auszutreten.

[Icke (Gast)]

Schleifen kann man ganz einfach mit einem break verlassen :-)

[High Performer (Gast)]

>  for (i=0; ende == 1; i++)
>    {
>        if (i == 5)
>          {
>           GPIO_SetBits(GPIOE,GPIO_Pin_5);
>           ende = 1;
>          }
>    }

Programmierer, die mir solchen Code abliefern, bekommen im Allgemeinen 
die Höchststrafe ;-) Gründe: Der Code ist so kompliziert wie nur 
möglich. Eine For-Schleife mit Abbruchbedingung, die auch noch vom 
Schleifenzähler abhängt im Schleifenrumpf. Was soll das? Aber scheinbar 
ist der Programmierer ja bereits selbst über dieses Konstrukt 
gestolpert.

Just my 2 cents.

[Flo (Gast)]

huch, da haben ja welche noch geantwortet :)

bin da ein laie,
entwickel noch das feingefühl dafür,
ich sollte mir nochmal die unterlagen rausholen,
weil ich schön regelmäßig dran hängen bleibe :P

[Joe-C (Gast)]

Moin,

Ich gehe mal davon aus, das mit "funktionieren Schleife" und ähnlichem 
gemeint ist, dass der Pin5 am GPIOE auf High geht.
Das würde ja nur passieren, wenn i==5 ist. Deshalb soll i in der 
Schleife ja nach oben gezählt werden (mit i++).

for (i=0; ende == 1; i++)
{
  if (i == 5) {
    GPIO_SetBits(GPIOE,GPIO_Pin_5);
    ende = 1;
  }
}

Da müsste folgendes Passieren:
- Start der Schleife i wird auf 0 gesetzt
- if bedingung (i==5) nicht erfüllt, da i==0
- Schleife wird beendet, da die Wiederholbedingung ende==1 nicht erfüllt 
ist

Dass es so nicht geht, wurde ja schon beschrieben. Nun zur nächten 
Variante...

for (i=0; ende != 1; i++)
{
  if (i == 5) {
    GPIO_SetBits(GPIOE,GPIO_Pin_5);
    ende = 1;
  }
}

Da müsste folgendes Passieren:
- Start der Schleife i wird auf 0 gesetzt
- if bedingung (i==5) nicht erfüllt, da i==0
- nächster schleifendurchlauf, i dann 1
- if bedingung (i==5) nicht erfüllt, da i==1
- nächster schleifendurchlauf, i dann 2
- if bedingung (i==5) nicht erfüllt, da i==2
- nächster schleifendurchlauf, i dann 3
- if bedingung (i==5) nicht erfüllt, da i==3
- nächster schleifendurchlauf, i dann 4
- if bedingung (i==5) nicht erfüllt, da i==4
- nächster schleifendurchlauf, i dann 5
- if bedingung (i==5) erfüllt, Set GPIOE_Pin5, ende dann 1
- Schleife wird beendet, da die Wiederholbedingung ende!=1 nicht erfüllt 
ist

Hier ein anderes Beispiel.

for (i=0; i < 6; i++)
{
  if (i == 2) {
    i++;
    continue; //schleifendurchlauf abbrechen und nächsten durchlauf starten
  }
  if (i == 5) {
    GPIO_SetBits(GPIOE,GPIO_Pin_5);
    break; //schleifendurchlauf abbrechen und schleife verlassen
  }
}

Da müsste folgendes Passieren:
- Start der Schleife i wird auf 0 gesetzt
- if bedingung (i==2) nicht erfüllt, da i==0
- if bedingung (i==5) nicht erfüllt, da i==0
- nächster schleifendurchlauf, i dann 1
- if bedingung (i==2) nicht erfüllt, da i==1
- if bedingung (i==5) nicht erfüllt, da i==1
- nächster schleifendurchlauf, i dann 2
- if bedingung (i==2) erfüllt, i dann 3, nächster schleifendurchlauf, i 
dann 4
- if bedingung (i==2) nicht erfüllt, da i==4
- if bedingung (i==5) nicht erfüllt, da i==4
- nächster schleifendurchlauf, i dann 5
- if bedingung (i==2) nicht erfüllt, da i==5
- if bedingung (i==5) erfüllt, Set GPIOE_Pin5, Schleife wird beendet
(obwohl die schleife weiter laufen werden würde, solange i<9 ist, wird i 
nicht höher als 5, da die Schleife mit break verlassen wurde. Einen 
Schleifendurchlauf mit i==3 gibt es hier auch nicht.)

Ich hoffe, es hilft weiter...

MFG

[Peter D. (peda)]

High Performer schrieb:
> Programmierer, die mir solchen Code abliefern, bekommen im Allgemeinen
> die Höchststrafe ;-)

Sehe ich auch so.
Der besseren Verstehbarkeit und vor allem der geringeren 
Fehleranfälligkeit wegen, sollten alle 3 Ausdrücke im for die gleiche 
Variable benutzen.

Nur weil man einen 32Bit Boliden benutzt, muß man nicht unnütz mit 
Variablen um sich schmeißen.
Insbesondere Variablen, die 1000 Zeilen vorher gesetzt werden, verwirren 
Dich nur selbst.
Jede Variable muß einen triftigen Grund haben, warum Du sie erzeugst.

Kleiner Code ist oftmals auch einfacher zu verstehen.


Peter

[Flo (Gast)]

Danke Joe-C für die ausführliche Erklärung.
Sowas hilft echt weiter :)
Werde mal meinen Quellcode dahingegen mal optimieren ;)

Peter, ich hätte auch den Code reingepostet,
der ist bloß inzwischen überdeminsional. :P

[Peter D. (peda)]

Ich schreibe Schleifen gerne abwärts zählend, dann sehe ich sofort im 
ersten Ausdruck die Anzahl der Durchläufe.
Auch lege ich die Schleifenvariable im for an, dann weiß der Compiler, 
sie ist danach wieder ungültig.

  for( uint8_t i = 123; i; i-- ){
    // mache was
  }

Ich finde das am besten lesbar und am wenigsten fehleranfällig.


Peter

[Flo (Gast)]

das habe ich auch schon versucht,

nur witzigerweise verweigert mein compiler das,
warum auch immer?!

so muss ich nach funktionsaufruf,
eine lokale variable erstellen,
mit der gearbeitet werden kann.


ich werds mal gleich nochmal ausprobieren,
und die fehlermeldung posten

[Flo (Gast)]

meinte nicht das runterzählen,
sondern die variable innerhalb des for aufrufes zu initialisieren

[H.Joachim S. (crazyhorse)]

Will mein Compiler auch nicht, nimmt nur Variablen, die direkt am Anfang 
der Funktion erzeugt werden.

void test (){
uint8_t i;
for (i=0;i<20; i++)
   {
   }
}
wird akzeptiert

void test (){

for (uint8_t i=0;i<20; i++)
   {
   }
}

das aber nicht.

Gibts da einen Standard? Oder kann das jeder Compilerbauer handhaben wie 
er will?
Ist kein wirkliches Problem, nur interessehalber.

[(prx) A. K. (prx)]

H.joachim Seifert schrieb:

> Will mein Compiler auch nicht, nimmt nur Variablen, die direkt am Anfang
> der Funktion erzeugt werden.

Das geht auch erst mit C99 (oder C++). Kann sein, dass der Compiler das 
nicht kennt, kann sein, dass man das erst per Option freigeben muss.

[Flo (Gast)]

also habe folgendes gemacht,
ich habe eine funktion erstellt

void delay(int g)
{  
  for (int r=0; r!= g; r++)
      {
        GPIO_SetBits(GPIOE,GPIO_Pin_4);
      }
  
        GPIO_ResetBits(GPIOE,GPIO_Pin_4);
}

beim Compilieren kommt folgende Fehlermeldung:

main.c(498): error:  #29: expected an expression
main.c(498): error:  #20: identifier "r" is undefined



die routine ist eigentlich klar,
mach solange weiter bis r g entspricht,
oder anders gesagt,
mach solange weiter wie r ungleich g ist.


aber folgendes akzeptiert der compiler

void delay(int g)
{
 int r=0;  
  for (; r!= g; r++)
      {
        GPIO_SetBits(GPIOE,GPIO_Pin_4);
      }
  
        GPIO_ResetBits(GPIOE,GPIO_Pin_4);
}

seltsam, oder?

[Flo (Gast)]

ok, joachim, ich war zu langsam :P
siehe mein post :D

[Peter D. (peda)]

Beim GCC muß man
--std=gnu99
angeben.

Braucht man aber eh für die atomic.h.


Peter

[(prx) A. K. (prx)]

Sich über den Compiler zu mokieren, ohne darauf hinzuweisen um welchen 
es dabei überhaupt geht, ist unhöflich und bringt nichts.

[H.Joachim S. (crazyhorse)]

@Flo:
Das ist dasselbe wie bei mir (ausser dass du bei der Deklaration direkt 
einen Wert (0) zuweist und nicht erst in der Schleife.

[Flo (Gast)]

A.K.

wenn du mir, ohne mich vorher zu lynchen,
verräts wo man das nachschauen kann,
verrate ich es dir...

habe gerade in keil gesucht,
nichts dazu gefunden (compiler)

[(prx) A. K. (prx)]

http://www.keil.com/support/man/docs/armccref/armccref_BCFJIIJJ.htm