Probleme mit GDB

Ist j denn volatile? Ich glaube, auch bei Optimierung 0 werden solche 
sinnlosen Schleifen weggemacht.

Hallo Christian,

vielen Dank für Deine Antwort.
- Ja, j ist volatile
- Die Schleife wird aber sicher benutzt, hier das gesamte Programm 
(Hauptschleife):
while (1) {
  for (j = 0; j < 500000; j++ )
  {}    // wait 500 msec
  IO0SET = 0x00000400;    // red led 1 off
  IO0CLR = 0x00000800;    // red led 2 on
  for (j = 0; j < 500000; j++ )
  {}    // wait 500 msec
  IO0CLR = 0x00000400;   // red led 1 on
  IO0SET = 0x00000800;   // red led 2 off
}
Zwei LEDs blinken im Wechsel, ich sehe ein Blinken, die Endwerte für j 
werden benutzt.
- Wenn ich volatile entferne, ist die Situation dieselbe wie vorher.
....
so, jetzt habe ich noch ein paar Sachen probiert, auf deinen Kommentar 
hin "sinnlose Schleifen".
Wenn die Schleife so aussieht:
  for (j = 0; j < 500000; j++ )
  {
    nop ();
  }
dann wechselt Insight mit jedem Singlestep zwischen der for- und der 
nop-Zeile. Allerdings hängt er da natürlich ewig fest. (aber das 
Programm Insight / GDB) hängt nicht mehr)

Und mit diesem hier:
void wait (void)
{
int j;
  for (j = 0; j < 500000; j++ )
  {
    nop ();
  }
}
kann man dann auch finish machen bzw in der Hauptschleife mit next über 
wait drüberlaufen.

Bleibt noch die Frage, was an dem leeren Schleifenkörper nicht gefällt, 
nur so, um was dazuzulernen.

Vielen Dank, falls es jemand weiß

Gruß

Martin

Äh das läuft?
Ist nicht der Wertebereich von int -32.768 bis 32.767 ?
Du zählst da aber bis 500.000 ?!?

Naja, hier gehts ganz offenbar um einen ARM, da sollte Int schon 32 Bit 
sein....

Das ist dann aber kein c Standard oder?
Bezug nehmend auf das da: 
http://homepage.univie.ac.at/Heinz.Kabelka/edv-ueb/variabl.htm

Hm oder, int ist Compiler abhängig...
Na gut, ich benutze da immer eindeutigere Typen, wie "short" wenn ich 
2Byte int's meine und "long int" wenns um 4Byte geht.
Sorry^^

Martin M. schrieb:
> Bleibt noch die Frage, was an dem leeren Schleifenkörper nicht gefällt,
> nur so, um was dazuzulernen.

Er steppt Dein Programm dann so lange, bis es eine andere 
Quellcode-Zeile erreicht.  Da der Schleifenkörper leer ist, bleibt es 
500000mal auf derselben Zeile, bevor es die nächste erreicht, und das 
dauert nun mal.

Daniel R. schrieb:
> Das ist dann aber kein c Standard oder?

Schon, doch.

> Bezug nehmend auf das da:
> http://homepage.univie.ac.at/Heinz.Kabelka/edv-ueb/variabl.htm

Und das ist Müll.  Solche Bereiche schreibt der C-Standard nicht vor, 
aber die gezeigten entsprechen dem Standard (sind eine der vielen 
Möglichkeiten).


> Hm oder, int ist Compiler abhängig...
> Na gut, ich benutze da immer eindeutigere Typen, wie "short" wenn ich
> 2Byte int's meine und "long int" wenns um 4Byte geht.

Das ist keineswegs eindeutiger, mit short und long bist Du genauso nass 
(compilerabhängig).  Willst Du genau 8 Bits haben, nimm int8_t und für 2 
Bytes int16_t.  Das hat die Evolution in ihrer unendlichen Weisheit in 
C99 extra dafür standardisiert.

Hallo,

@ Christian:
ja, ARM7, hatte ich eingangs vergessen

@ Hazeh:
Ich verstand single step so, dass er (=GDB / Insight) die Zeile einmal 
ausführt und dann wartet. Gesehen habe ich aber, dass er gar nicht mehr 
reagiert, musste manchmal mehrmals Stop klicken, bevor ich ihn resetet 
gekriegt habe.
Aber es ist natürlich schon uneindeutig, was hier einmal ausführen 
heißen soll, einmal j erhöhen oder einmal bis zum Grenzwert von j. Wenn 
letzeres, sollte er dass doch aber ohne permanenten Eingriff des 
Debuggers tun, also durch bis zur nächsten Zeile laufen (mit voller 
Controllergeschwindigkeit)?

Gruß

Martin

Das, was du willst, ist im GDB das Kommando "until".  Aber auch
hier bleibt dem GDB nichts anderes übrig, als immer wieder die
Applikation anzuhalten.

Besser kommst du, wenn du gleich einen (ggf. temporären) Breakpoint
dahinter setzt (denn im Gegensatz zum Debugger weißt du genau,
dass der nächste auszuführende Code immer direkt hinter der Schleife
kommt) und dann bis dorthin in Echtzeit laufen lässt.

> Ich verstand single step so, dass er (=GDB / Insight) die Zeile einmal
> ausführt und dann wartet.

Die interne Logik des gdb ist aber so, dass er im Single Step 
Einzelschrittausführung macht, bis sich die Zeilennummer ändert (= der 
Programmzähler die Adresse einer anderen Zeile enthält).  Das geschieht 
also nicht in Echtzeit.  Deshalb kannst Du in Deinem Fall (5000000 mal 
dieselbe Zeile) warten, bist Du (fast) schwarz bist.

Um in Echtzeit auszuführen, musst Du, wie Jörg schon schrieb, einen 
Breakpoint setzen und dann "continue" machen.

Hallo,
und vielen Dank für die Beiträge.
Ich denke mein Problem ist gelöst und ich weiß jetzt worauf ich beim 
Arbeiten mit GDB/Insight achten muß.

Gruß

Martin