Atmel Studio 7 Bug? Bei For-Schleife und == Abfrage

[Malte H. (avr_alvarr)]

Hallo erstmal,

ich habe mich schon des oefteren hier im Forum bei Problemen informiert 
und bin bis jetzt auch immer fuendig geworden.

Jedoch bin ich jetzt auf eine Eigenart in Atmel Studio gestossen, welche 
fuer mich keinen Sinn ergibt.

Zu meiner Person sei noch gesagt, dass ich das Programmieren lediglich 
als Hobby ausuebe und die Kenntnisse auf einem mittel-niedrig Level 
sind, da ich erst vor ein paar Monaten von Basic auf C gewechselt habe.

Nun zu meinem Problem:

Wenn ich folgenden Code Compilieren moechte, dann funktioniert das zwar, 
was aber auffaellig ist, sind folgende Daten aus dem Output:
(Und das Programm funktioniert auch nicht)

Program Memory Usage   :  130 bytes
Data Memory Usage   :  0 bytes

Aendere ich jetzt jedoch (i=0; i==18; i++) in (i=0; i<18; i++), dann 
zeigt mir der Output folgendes an und das Programm funktioniert wie 
erwartet:

Program Memory Usage   :  424 bytes
Data Memory Usage   :  144 bytes

Der Code ist erst mal nur ein Test zum Testen der Hardware: (F_CPU ist 
mit 16MHz in den Symbols angegeben)

#include <util/delay.h>
#include <avr/io.h>
#include <stdio.h>
#include <avr/interrupt.h>
#include "light_ws2812.h"
#include "LightDefs.h"

struct cRGBW led[36];

int main(void)
{
  int i;
  while(1)
  {
    for (i=0; i==18; i++)
    {
      led[i].r=0;led[i].g=20;led[i].b=0;led[i].w=0;   
      if (i>0) {led[(i-1)].r=0;led[(i-1)].g=0;led[(i-1)].b=0;led[(i-1)].w=0;}    
      led[(i+18)].r=0;led[(i+18)].g=20;led[(i+18)].b=0;led[(i+18)].w=0;  
      led[(i+17)].r=0;led[(i+17)].g=0;led[(i+17)].b=0;led[(i+17)].w=0;    
      ws2812_setleds_rgbw(led,36);
      _delay_ms(50);  
    }
  }
}

Natuerlich sollte man sowieso mit <> abfragen, jedoch kann es doch mal 
vorkommen, dass man mit == abfragen kann oder stehe ich jetzt total auf 
dem Schlauch?

Auf jeden Fall bedanke ich mich schon mal fuer`s durchlesen meines 
Problems und lasse mich gerne eines Besseren belehren ;)

Malte

[Daniel F. (df311)]

der 2 parameter in for ist die fortsetzungsbedingung (solange erfüllt 
mach)
d.h. bei i=0 als start ist die bedingung i==18 nicht erfüllt, daher wird 
die schleife nie ausgefürt.

p.s. <> ist in c !=

[Conny G. (conny_g)]

Der 2. Parameter der for Schleife ist die Durchlaufbedingung, d.h. die 
Schleife wird nur ausgeführt wenn true.
Der Compiler stellt fest, dass der Startwert bereits nicht der 
Durchlaufbedingung genügt und optimiert die ganze Schleife weg.

[Adam P. (adamap)]

Du sagst dem Compiler folgendes:
1. i ist 0
2. solange i gleich 18 ist, verarbeite und erhöhe i

...Dies trifft NIE zu, da i am Anfang 0 ist und somit ist die Bedingung 
nicht erfüllt, es wird "entfernt".

[Andy (Gast)]

du hast die for-Schleife bzw. deren Bedingungen nicht richtig 
interpretiert.
es Heißt wörtlich:
Starte mit "i gleich 0",wiederhole so lange "i gleich 18" ist und 
"erhöhe i um 1" nach jeder Runde.
Macht so keinen Sinn, gell ;)

[50c (Gast)]

Malte H. schrieb:
> for (i=0; i==18; i++)

..."übersetzt" heißt das, der mittlere Part des for, solange wie i 
gleich 18 ist.

...und der Compiler merkt, dass dies nie sein wird und optimiert das 
gesamte for einfach mal weg...

[Yalu X. (yalu) (Moderator)]

Irgendwie verstehe ich dich nicht ganz: Du änderst in deinem Code die
Bedingung i<18 in i==18, was logischerweise ein völlig anderes Verhalten
des Programms bewirken muss, und wunderst dich darüber so sehr, dass du
gleich einen Bug in den Entwicklungstools vermutest?

[Malte H. (avr_alvarr)]

Wow, seid ihr schnell!!!

Ist ja schon ein bisschen peinlich jetzt fuer mich...

Aber nun gut. Hab wirklich komplett falsch "Gedacht" bei dem zweiten 
Parameter...

Jetzt macht das Alles einen Sinn ;)

Vielen lieben Dank fuer eure freundlichen und aufklaerenden Antworten.

Das zeigt mir, dass ich nach einem Jahrzent vb-fun.de fuer Basic jetzt 
ein neues super C Forum gefunden habe.

Wuensche euch allen noch einen schoenen Tag.

Gruss,

Malte

[Malte H. (avr_alvarr)]

Hab den 2. Parameter komplett missverstanden.
Ich dachte (warum auch immer), dass die Schleife ausgefuehrt wird, bis 
der Wert im zweiten Parameter erreicht wird...
Aber nun gut. Ab in die Ecke der Schande mit mir ;)

[Jim M. (turboj)]

Malte H. schrieb:
> Ich dachte (warum auch immer), dass die Schleife ausgefuehrt wird, bis
> der Wert im zweiten Parameter erreicht wird...

Dann besorge Dir mal ein richtiges Buch über die Programmmiersprache C, 
z.B. den K&R.

Die ist nämlich ohne zusätzliche Literatur relativ schlecht 
verständlich, und hat viele fiese Fußangeln für Anfänger.

[Sebastian S. (amateur)]

Langer Rede kurzer Sinn:
Der Compiler macht, was Du ihm sagst – und nicht was Du meinst.

Ob der, der an der Tastatur sitzt, weiß was er sagt, ist etwas anderes.

Natürlich sind immer die anderen schuld.

[Frank M. (ukw) (Moderator)]

Außerdem rate ich Dir die Nutzung von Leerzeichen vor und hinter 
Operatoren und den Beginn einer neuen Zeile nach einem Semikolon (außer 
bei for()).

Das hier

      led[i].r=0;led[i].g=20;led[i].b=0;led[i].w=0;   
      if (i>0) {led[(i-1)].r=0;led[(i-1)].g=0;led[(i-1)].b=0;led[(i-1)].w=0;}    
      led[(i+18)].r=0;led[(i+18)].g=20;led[(i+18)].b=0;led[(i+18)].w=0;  
      led[(i+17)].r=0;led[(i+17)].g=0;led[(i+17)].b=0;led[(i+17)].w=0;    
      ws2812_setleds_rgbw(led,36);

kann man nicht lesen - jedenfalls nicht, ohne Kopfschmerzen zu bekommen. 
Tippfehler (Vertauschung von g und b) kann man in diesem Salat nicht 
mehr erkennen.

Ich habe den Code mal aufgedröselt.
Das hier:

    led[i].r = 0;
    led[i].g = 20;
    led[i].b = 0;
    led[i].w = 0;

    if (i > 0)
    {
        led[(i - 1)].r = 0;
        led[(i - 1)].g = 0;
        led[(i - 1)].b = 0;
        led[(i - 1)].w = 0;
    }

    led[(i + 18)].r = 0;
    led[(i + 18)].g = 20;
    led[(i + 18)].b = 0;
    led[(i + 18)].w = 0;

    led[(i + 17)].r = 0;
    led[(i + 17)].g = 0;
    led[(i + 17)].b = 0;
    led[(i + 17)].w = 0;

    ws2812_setleds_rgbw(led, 36);

ist da wesentlich "wartungsfreundlicher".

[Malte H. (avr_alvarr)]

@Jim Meba

hab ich gestern Abend noch gekauft ;)
Sie hatten bei uns, wie es der Zufall so will, "AVR Mikrocontroller - 
Programmierung in C von Heimo Gaicher" auf Lager gehabt. Und da habe ich 
es gleich mal mitgenommen...


@Frank M

Vielen Dank fuer deinen Hindweis und den wartungsfreundlicheren Code :)
Das werde ich mir dann gleich so angewoehnen.
Klar, gerade wenn das Projekt erst mal richtig los geht, blickt man da 
sonst nicht mehr durch. Verstehe ich voll und ganz.


Wuensche euch allen ein schoenes Wochenende.

Gruss,

Malte


PS: Kann das Thema hier auch irgendwie geschlossen werden?
Ich kann naemlich verstehen, dass sich bei dem Betreff in Kombination 
mit meinem "Fehler" einige Leute zurecht getriggert fuehlen...