C-Code mit AVR-Studio-Simulator debuggen möglich?

Wie schreibst du die leere Endlosschleife?

  while(1);

Schreib das mal um

  while(1)
    ;

Manche Debugger arbeiten zu sehr Zeilenorientiert. Die streiken
dann, wenn sie für Schleifenkopf und Schleifenrumpf (der leer ist)
keine eigene Zeilen haben.

Wie das beim gdb ist, hab ich nie ausprobiert. Ich schreibe
grundsätzlich die Dinge immer in eigene Zeilen. (Mit Microsoft
Debuggern) gebranntes Kind scheut das Feuer.

Beninho wrote:
> Hallo Karl Heinz,
>
> meine Endlosschleife sieht folgendermaßen aus:
>
> Funktioniert nicht:
> for(;;)
>   {
>   }
>
> Funktioniert:
> for(;;)
>   {
>   DDRE = 0xFF;
>   }
>
> Dasselbe mit while(1) probiert, sogar einen Strickpunkt hinter der
> geschlossenen geschweiften Klammer hab ich ausprobiert (nach Deinem Tip
> auch in einer eigenen Zeile), jedoch bleibt der Cycle-Counter trotzdem
> hängen.

Das ist eigenartig. Sowas hab ich im AVR-Studio Emulator noch
nie beobachtet.

Naja, die Endlosschleife wird ja wohl nur aus einem rjmp .-2
bestehen.  Das ist ziemlich schwierig, sowas zeilenweise
abzuarbeiten -- selbst im Assembler ist es ja nur eine Zeile. ;-)

Schreib da mal was ,,richtiges'' rein, und es sollte sich besser
debuggen lassen.  Wenn du gerade nichts besseres weißt, dann
taugt allemal sowas wie

1

PORTB = 42;

als ,,richtiger'' Code.

Jörg Wunsch wrote:
> Naja, die Endlosschleife wird ja wohl nur aus einem rjmp .-2
> bestehen.  Das ist ziemlich schwierig, sowas zeilenweise
> abzuarbeiten -- selbst im Assembler ist es ja nur eine Zeile. ;-)

Schon.
Aber eigentlich sollte der Debugger schon bei einem Druck auf F10
den rjpm einmal ausführen und dann wieder stehen bleiben. Mit
Erhöhung des cycle counter natürlich.

Keine Ahnung, ich nehme kein AVR Studio...  Ich weiß auch gerade nicht,
wie sich GDB da verhält.  Ich habe eher selten komplett leere
Schleifen (und wenn, dann setze ich mir den Brechpunkt lieber in eine
ISR oder sowas).

Raphael wrote:
>
> for(q=0;q<=880;q++)
>       {
>
>         r++;
>
>       }
>
> hab da extra noch das r++; in die schleife geschrieben geht aber immer
> noch nicht. die optimierung hatte ich auch schon auf 1 und 2
> umgeschalten.
> geht auch nicht. was kann das dann noch sein?
> bin froh um jede hilfe?

Zeig mal das komplette Programm.

Machst du was mit dem r nach der Schleife?
So dämlich ist der COmpiler auch wieder nicht, dass er sich so einfach
austricksen lässt. Wenn du mit einer Variablen nichts machst, dann
kann die Variable auch wegfallen. Damit steht aber wieder nichts
in der Schleife, was eine Schleife erfordern würde.

Somit ist ...

> for(q=0;q<=880;q++)
> {
> }
>

... wieder gleichbedeutend mit ...

  q = 880;

nur das Letzteres um einiges weniger Zeit beansprucht und daher
vom Optimizer favourisiert werden wird.

Genaueres kann man aber nur sagen, wenn man das komplette Programm
sieht.

Karl heinz Buchegger wrote:

> Das ist eigenartig. Sowas hab ich im AVR-Studio Emulator noch
> nie beobachtet.

Hmm.
Nachdem ich mir vor einiger Zeit eine neuere Version geholt
habe, sieht es jetzt bei mir ebenfalls so aus:

1

#include <avr/io.h>

2

3

main()

4

{

5

  DDRA = 0xFF;

6

  PORTA =0xFF;

7

8

  while( 1 )

9

    ;

10

}

Compiliert mit -Os. Der Debugger kommt ausser Tritt. Single
Step geht noch bis zur Port Zuweisung, danach ist Schluss.

Mach ich den Single Step jedoch im Disassembler Window läuft
der Debugger brav auf den
    rjmp   PC-0x0000
auf, stept auch weiter und erhöht auch brav den Cycle Counter

>Mach ich den Single Step jedoch im Disassembler Window läuft
>der Debugger brav auf den
>    rjmp   PC-0x0000
>auf, stept auch weiter und erhöht auch brav den Cycle Counter

Wollt ich gerade fragen... hätte sonst vermutet, dass das als SLEEP 
übersetzt wird.

Funktioniert das Zählen im nicht-single-step-Modus? Also einfach mal 
laufen lassen und dann wieder anhalten?

Kai Giebeler wrote:
>>Mach ich den Single Step jedoch im Disassembler Window läuft
>>der Debugger brav auf den
>>    rjmp   PC-0x0000
>>auf, stept auch weiter und erhöht auch brav den Cycle Counter
>
> Wollt ich gerade fragen... hätte sonst vermutet, dass das als SLEEP
> übersetzt wird.
>
> Funktioniert das Zählen im nicht-single-step-Modus? Also einfach mal
> laufen lassen und dann wieder anhalten?

Habs gerade probiert.
Disassembler Window zu.
Debugger auf  - "Run"
Nach einiger Zeit auf "Break"

Der Debugger braucht interessanterweise 1 bis 2 Sekunden
bis er sich wieder meldet. Danach steht der Cycle Count
auf 650390 (ist aber jedesmal eine andere Zahl in der
Größenordnung).

So ganz koscher dürfte dasGanze also nicht sein :-)

>So ganz koscher dürfte dasGanze also nicht sein :-)
ACK - Plädiere auf Bug im Debugger ;)

>Kann ich nicht bestätigen. Bei mir läuft der Simulator ohne Probleme.

Evtl. andere Version?

Raphael wrote:
> lehre schlaufe ist? übrigens wenn ich das auf mein atmega32 schmeisse
> ändert sich die zeit auch nicht. das heisst ja das es am Compiler liegen
> sollte.

Grundsätzlich musst du zwischen Simulator und realer Hardware
unterscheiden. Der Simulator hat auch so seine Fehler.

Wenn der reale Prozessor auch nicht wartet, dann hast du
aller Wahrscheinlichkeit nach den Optimizer eingeschaltet
und ja, der optimiert die Schleifen weg.

1

#include <avr/io.h>

2

#include <util/delay.h>

3

4

int main(void)

5

{

6

  int ms;

7

8

  DDRC = 0xFF;

9

  DDRA = 0xFF;

10

11

  PORTA = 0xFF;

12

13

  for( ms = 0; ms < 100; ms++ )

14

    _delay_ms( 10 );   // 100 mal 10 Millisekunden ergeben eine Sekunde

15

16

  PORTA = 0x00;

17

18

  while(1);

19

}