Hallo, durch verschiedene Fenster-Verschiebereien habe ich mit wohl mein AVR Studio verhagelt. Obwohl sonst (nahezu) alles funktioniert, wird im Editor-Fenster kein Source-Code mehr angezeigt, sodaß ich auch nicht mehr durch Doppelklick auf Meldungen im Build-Fenster auf die entsprechende Zeile springen kann (zum Editieren verwende ich einen externen Editor). Das Editor-Fenster erscheint einfach grau; unten im Registerkarten-Reiter steht der Name des Source-Files, aber der Inhalt ist nicht zu sehen. Normalerweise konnte ich mit F7 einen Build auslösen; das geht jetzt nicht mehr, und im Menü/Build wird kein F7 angezeigt (erst wenn ich Build aus dem Menü auswähle und der Build erfolgt ist, zeigt das Menü den Tesxt "F7" mit an). Durch bestimmte Mausklicke erscheinen blaue Navigationspfeile auf dem Schirm, deren Funktion ich auch noch nicht ergründet habe. Kann mir jemand einen Tip geben, wie ich AVR Studio wieder in den Grundzustand bekomme? Das ganze verhält sich nur bei einem bestimmten Projekt so; bei anderen ist alles ganz normal. Vielen Dank für eure Hilfe. Günter
Hallo, Jörg, danke für den Hinweis. Das ist aber die Notlösung. Gibt es kein Ini-File, das man löschen könnte und durch dessen Fehlen AVR Studio Default-Werte nimmt? (So mache ich es bei meinen Delphi-Programmen). Gruß, Günter
Keine Ahnung, musst du in Trondheim nachfragen. Ich nehm kein AVR Studio... (Ich wollte eigentlich oben auch ein Fragezeichen statt eines Punktes schreiben, hatte ich nur vergessen.) Kann ja genauso gut sein, dass sie allen Krempel irgendwo in die allseits beliebte Registry stopfen.
Hallo, Jörg, hast recht, werde AVR Studio neu installieren (finde es halt doch recht gut). Unabhängig davon: heute hatte ich den Eindruck, daß C-Programme (mit AVR-GCC bzw. WinAVR compiliert) sich unterschiedlich verhalten, je nachdem, ob sie ohne Optimierung (-O0) oder mit Optimierung (-O2 oder -Os) compiliert werden (natürlich abgesehen von der Code-Größe bzw. geringfügigen Laufzeit-Unterschieden). Ist so etwas denkbar? Günter
> Ist so etwas denkbar?
Ja, mit -O0 debuggst du einen völlig anderen Code. Mit anderen
Worten: du debuggst es zweimal.
Ich ziehe es daher vor, lieber mit den Effekten des Optimizers
(Hin- und Herspringen im Code, Wegoptimieren nicht benötigter
Variablen) klarzukommen und gleich den optmierten Code zu
debuggen.
Okay! Was mich dabei aber auch immer wundert, ist die große Zahl von "Out of scope"-Variablen, m.a.W.: sehr viele Variablen lassen sich im Watch oder durch "Berühren mit der Maus" nicht anzeigen, auch nicht größere Arrays, die niemals als Register abgebildet sein können. Wie ist das möglich? Ich dachte, daß zwar Register-Variablen nicht angezeigt werden könnten (so ist es z.B. bei dem anderen Prozessor-System, mit dem ich arbeite - Toshiba TLCS900-16/32-Bit-Prozessoren), aber immer doch solche, die im realen RAM liegen, im Datensegment (also globale Variablen). Nebenbei: wie debuggst Du denn, wenn Du ohne AVR Studio arbeitest? Gibt es einen (Fremd-)Debugger, der mit dem AVR-JTAG-ICE funktioniert?
Warum AVR Studio das Zeug als "Out of scope" bezeichnet, weiß ich nicht. Der GDB kennt diesen Ausdruck nicht, und ich kann mich (einigermaßen) beliebig zwischen den Call-Scopes durchhangeln und mir damit auch die lokalen Variablen der Aufrufer ansehen. Ggf. hilft halt einfach der Blick in den generierten Assemblercode (oder zur Not ins Disassemblerlisting) um zu sehen, was der Compiler aus bestimmten Ausdrücken gemacht hat. > Nebenbei: wie debuggst Du denn, wenn Du ohne AVR Studio > arbeitest? Gibt es einen (Fremd-)Debugger, der mit dem > AVR-JTAG-ICE funktioniert? GDB mit AVaRICE. Zugegebenerweise nicht alles optimal. Größter Nachteil von AVaRICE derzeit ist die fehlende Unterstützung für Software-Breakpoints (also solche, die als BREAK-Befehle in den Flash geschrieben werden), damit ist man auf die 3 [+ 1 für den Einzelschrittbetrieb] Breakpoints der JTAG-Engine beschränkt, aber diese sind ohnehin die zu bevorzugenden. Software-BPs werde ich aber über kurz oder lang mal einbauen müssen, schon deshalb, weil der debugWire-Support ansonsten bissel nutzlos ist. Die oben genannte Verfolgung des Callstacks funktioniert manchmal nicht ganz zuverlässig, weil sie auf internem Wissen über die Stackframes des Compilers basiert, aber naja, besser als gar nichts. Was mir an GDB gefällt: . ein Debugger für alles (ich arbeite seit 15 Jahren damit, egal auf welchem Prozessor oder Betriebssystem) . die Möglichkeit, x-beliebige C-Ausdrücke ,live' zu berechnen; wenn ich also eine Speicheradresse 0x800245 habe, von der ich weiß, dass sie eigentlich eine x-fach verkettete Liste vom Typ struct foo * ist, so kann ich mich durch die Liste hangeln mit »print (struct foo *)0x800245->next->next->next« usw.
Hallo Günter >Kann mir jemand einen Tip geben, wie ich AVR Studio wieder in >den Grundzustand bekomme? Das ganze verhält sich nur bei einem >bestimmten Projekt so; bei anderen ist alles ganz normal. Wenn es bei anderen Projekten "normal" ist, dann hast Du diese eine Projekt-Datei verschossen und nicht die AVR-Studio Installation! Eine Neuinstallation wird Dir diese Projekt-Datei nicht reparieren. Lösche einfach die entsprechende AvrStudio Projekt-Datei [*.aps] und eröffne ein neues Projekt, mit den noch vorhandenen Source-Dateien! Peter
Die Projektdateien sind übrigens XML-Dateien, die kann man auch angucken und mit einem normalen Texteditor editieren.
Hallo, Peter, sorry, muß zurückrudern - es sind alle Projekte betroffen, nicht nur das eine; die Idee, einfach das Projekt neu zu erstekllen, hatte ich bald schon auch, und auch getestet - hat sich nichts verbessert. Werde nun also doch AVR Studio neu installieren. Hallo, Jörg, richtig, das sind XML-Dateien. Habe mit XML noch nicht viel gemacht, werde mich aber jetzt mal damit befassen. Danke für den Hinweis. Günter
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.