Hallo zusammen, habe bereits etwas die Suchfunktion in Anspruch genommen, bin aber aufgrund der Komplexität der Anforderung an die Formulierung gescheitert bzw. schlichtweg nicht fündig geworden. Vielleicht kann mir jemand einen Link auf einen bestehenden Beitrag für eine Lösung nennen, ansonsten bitte ich so um Hilfe: Konfiguration: - Atmel Studio 4.18 - JTAG ICE MKII original (kein Nachbau) - WinAVR-20100110 (die letzte mir bekannte Version) - Prozessor z.B. ATMega644 oder ATxMega128 - benutze das JTAG Interface Das Problem: Beim Durchsteppen mit dem Debugger findet Atmel Studio nicht alle Sourcen, zeigt also dann ggf. nichts an, man sieht dann plötzlich nicht an welcher Stelle man im Code steht. Erst wenn man einen im Code bekannten (und noch sichtbaren) Breakpoint setzt und dann den Code bis dorthin laufen lässt (F5) findet man wieder eine hervorgehobene Code-Zeile wo man sich befindet. Insbesondere auffällig ist das bei _delay_ms(...) aber auch anderen Low-Level Routinen. Gibt es irgendwelche Anforderungen der Kombination Atmel Studio und WinAVR, oder muss man den beteiligten Programme durch Settings noch etwas mitteilen was ich nicht weiss? Oder gibt es spezielle Compiler Flags für eine Debug-Version? Reihenfolge der Installation von Studio und WinAVR (die beiden Beteiligten sind auf ihre vorgeschlagenen Default-Verzeichnisse instelliert)? Gruß loocee
Gast
#3854169
>Beim Durchsteppen mit dem Debugger findet Atmel Studio nicht alle >Sourcen, Die Sourcen von Librarys sind meist nicht vorhanden. Über Library Funktionen machst du halt ein StepOver. Also sowas wie (s)printf, itoa, strcpy, _delay_ms. Im Prinzip alles was im Projekt nicht als C-Code vorhanden ist.
holger schrieb: > Die Sourcen von Librarys sind meist nicht vorhanden. Diesr Code ist normalerweise "von Hand" zu finden, so z.B ist _delay_ms () in der Header Datei delay.h (irgendwo im WinAVR-20100110) auscodiert. Einleuchtend wäre es wenn der Compiler nur vohandene Objects einbindet, so compiliert er aber die Source mit ein .....
Gast
#3854254
>Diesr Code ist normalerweise "von Hand" zu finden, so z.B ist >_delay_ms () in der Header Datei delay.h (irgendwo im WinAVR-20100110) >auscodiert. _delay_ms ist jetzt aber ein schlechtes Beispiel. Ohne Optimierung ist _delay_ms quasi unbrauchbar. Siehe die Warnung in delay.h. Da fängst du dir Floating Point Funktionen ein. Mit Optimierung brauchst du deinen Debugger gar nicht erst anwerfen. Da darf der Compiler alles so umbauen wie er möchte. Da gehen durchaus ganze Codeteile oder Variablen flöten weil er sie nicht braucht. Oder kurz zusammengefasst: Willst du _delay_ms verwenden? Dann debugge nicht. Wenn du debuggen willst verwende _delay_ms nicht;)
holger schrieb: > _delay_ms ist jetzt aber ein schlechtes Beispiel. > Ohne Optimierung ist _delay_ms quasi unbrauchbar. > Siehe die Warnung in delay.h. Da fängst du dir > Floating Point Funktionen ein. Die Warnings kenne ich .... Ein Aufruf von _delay_ms(...) mit Konstante als Übergabe ergibt festverdrahteten Inline-Code und keine Floating Point Operationen. Das würde man sehr schnell merken da sonst FP Code (Grösse!) dazugelinkt wird ..... Klar kann man sich die Delays für den Debug-Fall mit ifdefs ausblenden, aber ich hatte mir aus Erfahrung mit anderen Debuggern erwartet dass so etwas einwandfrei unterstützt wird.