Studio 6.2 Simulator

[Turmburger (Gast)]

Habe Probleme mit Simulator. Habe das Programm mit zahlreichen 
Breakpoints durchlaufen lassen. Beim ersten Programmdurchlauf wird die 
erste und dritte for-schleife durchlaufen, die Zweite wird übersprungen:

#define   F_CPU 8000000
#include  <avr\io.h>
#include  <stdio.h>
#include   <limits.h>
#include   <stdlib.h>
#include   <util\delay.h>

int ZeilenVektor[8];
int co;
int z1;
int z2;
int z0;
int i;
double BRENNDAUER;


int main ()
{

   DDRB  = 0xFF;
   PORTB = 0xFF;

   DDRD  = 0xFF;
   PORTD = 0x00;
   BRENNDAUER = 50;


   for (z0=0;z0<=7;z0++)      // wird durchlaufen
   ZeilenVektor[z0] = 0;

   while(1)
   {

      for (z1=0;z1<=7;z1++)  // wird übersprungen
      {
  PORTD = ZeilenVektor[z1];
  PORTB &=~(1<<z1);              void _delay_ms(double BRENNDAUER);
  PORTB |= (1<<z1);
  PORTD = 0x00;
      };

      co = 1; // wird übersprungen
      for (z2=0;z2<=7;z2++)// wird durchlaufen
      {
         ZeilenVektor[z2]=ZeilenVektor[z2]+co;
         if (ZeilenVektor[z2]==256)
            ZeilenVektor[z2]=0;
         else
      co=0;
       };
   };
};

[Betatester (Gast)]

Wollen wir hoffen, dass der Bug in der finalen Version gefixt ist!

[Turmburger (Gast)]

Was soll mir das sagen?

[Wolfgang (Gast)]

Turmburger schrieb:
> Was soll mir das sagen?

Dass der µC, in diesem Fall der Simulator, genau das macht, was ihm der 
Programmierer gesagt hat, aber nicht das, was der Programmierer von im 
will. Der µC kann schließlich nicht hellsehen.

[Turmburger (Gast)]

Irre komisch

[Turmburger (Gast)]

und nicht wirklich hilfreich

[lesender (Gast)]

Semikolon am Ende ALLER Blockklammern! Irgendwie seltsam!

[Walter Tarpan (Gast)]

Und schau Dir nochmal die Doku zu _delay_ms() an. Das mag nämlich nur 
Konstanten.

[Kaj (Gast)]

Turmburger schrieb:
> for (z0=0;z0<=7;z0++)      // wird durchlaufen
>    ZeilenVektor[z0] = 0;
ok, ein array das mit nullen gefuellt wird...

Turmburger schrieb:
> for (z1=0;z1<=7;z1++)  // wird übersprungen
>       {
>   PORTD = ZeilenVektor[z1];
jetzt gehst du in das array rein, um daraus eine null zu lesen...
wie waere es einfach mit "PORTD = 0" ?

Turmburger schrieb:
> PORTD = 0x00;
ergibt keinen sinn, weil eh schon ne null drin steht

Turmburger schrieb:
> for (z2=0;z2<=7;z2++)// wird durchlaufen
>       {
>          ZeilenVektor[z2]=ZeilenVektor[z2]+co;
Ok, vom prinziep steht da: ZeilenVektor[z2] = 0 + co
Wie waere es mit ZeilenVektor[z2] = co

Turmburger schrieb:
> co = 1; // wird übersprungen
Wird wegoptimiert weil es sich nie aendert!

Turmburger schrieb:
> Habe Probleme mit Simulator. Habe das Programm mit zahlreichen
> Breakpoints durchlaufen lassen. Beim ersten Programmdurchlauf wird die
> erste und dritte for-schleife durchlaufen, die Zweite wird übersprungen:
Wenn da was nicht funktioniert, dann weil der Compiler Dinge 
wegoptimiert, und das zu recht!

An deinem Problem ist weder der Compiler, noch der Simulator, noch die 
Tatsache das es sich um eine Beta-Version handelt schuld.
Schalte die optimierung ab, oder programmiere ordentlich!

[Jay (Gast)]

Kaj schrieb:
> Turmburger schrieb:
>> for (z1=0;z1<=7;z1++)  // wird übersprungen
>>       {
>>   PORTD = ZeilenVektor[z1];
> jetzt gehst du in das array rein, um daraus eine null zu lesen...
> wie waere es einfach mit "PORTD = 0" ?
>
> Turmburger schrieb:
>> PORTD = 0x00;
> ergibt keinen sinn, weil eh schon ne null drin steht
Aber ist PORTD nicht volatile? Theoretisch könnte es einen Interrupt 
geben, welcher zwischen den beiden Zuweisungen PORTD ändert...

[Oliver S. (oliverso)]

Kaj schrieb:
> Schalte die optimierung ab, oder programmiere ordentlich!

Warum "oder"?

Und all, das, was du da schreibst, erklärt nicht, warum die Schleife 
überspungen wird. Die Ports sind alle volatile, da darf der Compiler 
nichts wegoptimieren.

Oliver

[Kaj (Gast)]

Jay schrieb:
> Theoretisch könnte es einen Interrupt
> geben, welcher zwischen den beiden Zuweisungen PORTD ändert...
Theoretisch ja, praktisch nein, da der TO keine Interrupts benutzt. 
Ausgehend von dem Stueck Code da oben, werden keine Interrupts benutzt 
und damit aendert sich der Port auch nicht.
Ansonsten hast du recht.

Gruesse

[Jay (Gast)]

Kaj schrieb:
> Jay schrieb:
>> Theoretisch könnte es einen Interrupt
>> geben, welcher zwischen den beiden Zuweisungen PORTD ändert...
> Theoretisch ja, praktisch nein, da der TO keine Interrupts benutzt.
> Ausgehend von dem Stueck Code da oben, werden keine Interrupts benutzt
> und damit aendert sich der Port auch nicht.
> Ansonsten hast du recht.
Mein theoretisch bezieht sich (wie du richtig anmerkst) eben darauf, 
dass im Quellcode des TOs keine Spuren eines Interrupts gibt.
Aber der Compiler muss doch trotzdem davon ausgehen, dass sich PORTD in 
der Zwischenzeit geändert haben könnte und kann die Zeilen nicht einfach 
wegoptimieren.


Bei genauerer Betrachtung des Codes sehe ich aber du hast unrecht:

Das ist die Initialisierung:

for (z0=0;z0<=7;z0++)      // wird durchlaufen
   ZeilenVektor[z0] = 0;

Danach kommt eine grosse while Schleife als Mainloop(neu formatiert):

while(1)
{
  for (z1=0;z1<=7;z1++)  // wird übersprungen
  {
    PORTD = ZeilenVektor[z1];
    PORTB &=~(1<<z1);
    void _delay_ms(double BRENNDAUER);
    PORTB |= (1<<z1);
    PORTD = 0x00;
  }

  co = 1; // wird übersprungen
  for (z2=0;z2<=7;z2++)// wird durchlaufen
  {
    ZeilenVektor[z2]=ZeilenVektor[z2]+co;
    if (ZeilenVektor[z2]==256)
      ZeilenVektor[z2]=0;
    else
      co=0;
  }
}

Beim ersten Durchlauf hast du recht, da sind alle Werte von ZeilenVektor 
== 0. Aber im unteren Teil wird ZeilenVektor verändert(sieht ein bischen 
aus wie ein, ziemlich schräger, 64bit Counter). Danach beginnt die while 
Schleife wieder von vorne.

Ich glaube also nicht, dass der Compiler hier grossartig etwas weg 
optimieren kann. Jedenfalls nicht so wie du es oben beschreibst.

> Gruesse
Gruesse zurueck...

[kif (Gast)]

Schalte mal die Optimierung aus und probiers nochmal