AVR-Studio 6 kompiliert fehlerhaft

Ja, dann sind deine Programme nicht sauber programmiert!
Zeig doch mal eins deiner nicht funktionierenden Programme!

Das hier war nur ein Testprojekt worauf später ein Programm mit einem 
ADC aufbauen sollte und wo erst mal nur eine LED blinken sollte ... 
macht sie aber nicht ...

In der Simulation rennt er über alles drüber was mit Variablen zu tun 
hat. einen Breakpoint kann ich an der Stelle auch nicht setzten. Die 
Schleifen werden einfach übergangen ...

1

#define F_CPU 8000000

2

3

#include <avr/io.h>

4

#include <stdint.h>

5

#include <util/delay.h>

6

7

8

#define LED_PORT    PORTB

9

#define LED_DDR     DDRB

10

#define LED_PIN     PB1

11

12

int main(void){

13

  int16_t t,i;

14

  int8_t j;

15

16

  t = 5600;

17

  LED_DDR |= 1 << LED_PIN;

18

  LED_PORT ^= 1 << LED_PIN;

19

  while (1)

20

  {

21

    for(i=0; i< t;i++){

22

      j=0;

23

      for(j=0;j<10;j++){

24

        _delay_ms(10);

25

      }        

26

    }

27

    LED_PORT ^= 1 << LED_PIN;

28

  }

29

  return 0;

30

}

> sollte und wo erst mal nur eine LED blinken sollte

..alle gut 9 Minuten..

> macht sie aber nicht

wie lange hast Du denn auf eine Reatkion  gewartet? Brav knapp 
eineinhalb Stunden?

Mach mal die Warterei kürzer. Und packs auf einen richtigen µC.

Japp alle 9,33 Minuten ... eigentlich sollten es 10 Min sein, ich war 
aber irgendwie in Gedanken und so sind es dann 9,33 geworden ...
Das Programm lief auf einem STK500 ca. 4 Stunden ohne das sich was 
sichtbares getan hatte ... es stand so neben mir rum als ich noch was 
anderes gemacht hatte ...

Wenn du immer 560s wartest blinkt die LED natürlich etwas lahm...

Net_Hans schrieb:
> Japp alle 9,33 Minuten ... eigentlich sollten es 10 Min sein, ich
> war
> aber irgendwie in Gedanken und so sind es dann 9,33 geworden ...
> Das Programm lief auf einem STK500 ca. 4 Stunden ohne das sich was
> sichtbares getan hatte ... es stand so neben mir rum als ich noch was
> anderes gemacht hatte ...

Du hast eine merkwürdige Art und Weise etwas zu testen...

Ich wollte es einfach mit realen Zahlen machen ... hat mich in dem 
Moment nicht gestört ,da ich ja eh noch was anderes nebenbei machen 
musste ...

Bei den Delay Funktionen muss man aufpassen, dass die Optimierung 
eingeschaltet ist - sonst gibt das viel zu lange Wartezeiten.
Mit Optimierung kann es passieren das einige variablen ganz wegoptimiert 
werden und mit den Debug Funktionen schwer zu fassen sind. So ähnlich 
kann es passieren, dass Teile ganz wegoptimiert werden und daher da auch 
kein Berakpoint gesetzt werden kann.

Bei einem so einfachen Programm könnte man sich noch das erzeugte ASM 
File anzeigen und sehen was da etwa bei raus kommt.

beim Debuggen immer Optimierungen ausschalten!
Und wenn ein Breakpoint nicht greift, dann hat GCC ganz einfach die 
Zeile wegoptimiert.
Wenn Du in ein Projekt reinschreibst:

unsigned char counter;

counter = 1;

counter = 2;

counter = 3;

und versuchst einen Breakpoint auf die Zeile counter=2 zu sezten,dann 
stoppt der Debugger auch nicht an dieser Zeile da diese im Assembler gar 
nicht existiert! Will man alle "Raw" Daten beibehalten, muß man die 
Optimierung komplett abschalten.

A. K. schrieb:
> Um beim Debuggen nicht über Optimierungseffekte
> wie wegoptimierte Zeilen und völlig verkorkste Reihenfolge zu stolpern,
> sollte man eigentlich das Debugging ausschalten. Nur funktionieren die
> Delays dann nicht wirklich gut.

Deswegen gibt es extra Timer mit Interruptfähigkeit. Das 
Prozessorleistung verbratende delay() ist dann überflüssig ;-)

Hallo,

danke für eure Erklärungen. Das Ausschalten der Optimierung würde ich 
jetzt mal probieren. Hoffen wir mal, das es funkt ... wenn nicht, lesen 
wir uns hier wieder ;-)