Servus! Unter http://distribute.atmel.no/tools/opensource/Atmel-AVR-GNU-Toolchain/3.4.4/ ist ja mit der Datei http://distribute.atmel.no/tools/opensource/Atmel-AVR-GNU-Toolchain/3.4.4/avr-libc-1.8.0.tar.bz2 der Sourcecode der libc erhältlich. Beim Studio 5 & 6 bzw. gibt es ja durch Visualstudio per Alt+G bzw. Rechtsklick "Goto Implementation" die Möglichkeit sich den Source einer Funktion anzeigen zu lassen. Ich habe jetzt den Inhalt des Ordners libc\avr-libc\ in dieser Datei nach C:\Program Files (x86)\Atmel\Atmel Toolchain\AVR8 GCC\Native\3.4.1056\avr8-gnu-toolchain\avr entpackt, weil ich da jeweils identische Dateien gefunden habe. (die Header) Der Ordner gilt jetzt fürs Studio 6, ist aber beim 5er ähnlich. Kennt ihr eine Möglichkeit dem Studio nun mitzuteilen, dass es dort nach den Sources suchen soll? (wenn es unter Code::Blocks irgendwie möglich wäre, würde ich mich auch sehr freuen) lG, Daniel
Daniel A. Maierhofer schrieb: > Kennt ihr eine Möglichkeit dem Studio nun mitzuteilen, dass es dort nach > den Sources suchen soll? Da wirst du wohl die ganze avr-libc mit Debuginformationen compilieren und installieren müssen.
Danke für die rasche Antwort Jörg! Ich hab zwar schon mit MinGW32 und dem Compilieren einiger Libraries (welche ohne MSYS installierbar waren, wie z.B. die Allegro Game Programming Library) Erfahrung, aber leider weiß ich da nicht ganz, wie ich da ansetzen soll das in einer Debug-Version zu compilieren? ./configure kann ich ja unter Windows nicht so leicht ausführen. ;) Wobei, es geht mir gar nicht darum Beim Debuggen bis in die niedrigste Implementierungsstufe zu kommen, mir würde es völlig reichen mit "Goto Implementation" da bequem hinzufinden. Ich habe wie unter Beitrag "Arduino Library unter Atmel Studio 6.2" beschrieben z.B. die komplette Arduino-Library als statisch linkbare Library compiliert und kann bei dem Beispielprogramm ohne Probleme mit Alt+G bzw. Goto Implementation bis ins kleinste Detail nachverfolgen, was unter der Haube der Library vor sich geht. Genau so hätte ich es gern mit der avr-libc, wobei ich mich nicht ganz herantrau, die im AVRStudio komplett einbinden zu können. :) Oder ist das die einzige Möglichkeit diese Informationen der IDE mitzuteilen? Soweit ich das verstehe können in den .o Files "Symbole" enthalten sein, welche die Namen der Variablen & Funktionen widerspiegeln. In diesem Fall interessier ich mich aber ja gar nicht für die bereits kompilierten Sachen sondern ich will gern im Source herumspringen können.
Daniel A. Maierhofer schrieb: > ./configure kann ich ja unter Windows nicht so leicht ausführen. ;) Doch, MinGW32 liefert eine Bash mit. Anders kann die avr-libc, die Atmel mitliefert, ja auch nicht entstanden sein (sofern sie sie nicht gerade auf Unix compilieren, danach strip -g, das würde auch gehen ;-). > Soweit ich das verstehe können in den .o Files "Symbole" > enthalten sein, welche die Namen der Variablen & Funktionen > widerspiegeln. Es sind lediglich die Symbole noch vorhanden, die der Linker unbedingt braucht. Also schon interne Funktionen wirst du nicht mehr finden. Allerdings enthalten halt die Debugsymbole den Hinweis auf den Dateinamen, der ohne diese logischerweise fehlt. Keine Ahnung, ob das Atmel Studio auch ohne diese Info in der Lage ist, dass du ihm mitteilen kannst, welche Quelldatei zu welchem Objektmodul gehört.
Daniel A. Maierhofer schrieb: > ./configure kann ich ja unter Windows nicht so leicht ausführen. ;) Brauchst du auch nicht. Die avr-libc enthält ja code für AVR, nicht für Windwos :-) Du kannst die Lib also auch unter Linux erzeugen und unter Windows verwenden.
Johann L. schrieb: > Du kannst die Lib also auch unter Linux erzeugen und unter Windows > verwenden. Allerdings stimmen dann die Pfadnamen im DWARF-2 nicht mehr. Gerade die sind ja hier aber wichtig.
Jörg Wunsch schrieb: > Da wirst du wohl die ganze avr-libc mit Debuginformationen compilieren > und installieren müssen. Jörg Wunsch schrieb: > Allerdings stimmen dann die Pfadnamen im DWARF-2 nicht mehr. Gerade > die sind ja hier aber wichtig. Sorry Jörg, aber ich bezweifle stark, dass das dem OP weiterhilft. Es geht hier ja nicht um den Debugger, sondern um den Source-Code-Editor der IDE. Der sucht einfach in dem ihm zur Verfügung stehenden Source-Code nach der Funktionsdefinition. Für das, was der OP möchte, müsste man den Source-Code der Lib dem Projekt als eine Art externe Referenz/Abhängigkeit hinzufügen, so dass er zwar bei der Source-Code-Analyse mit berücksichtigt wird, aber nicht mit kompiliert/gelinkt wird. Ich weiß aber auch nicht, ob und wie das beim Studio geht.
Stefan Ernst schrieb: > Es geht hier ja nicht um den Debugger, sondern um den Source-Code-Editor > der IDE. Der sucht einfach in dem ihm zur Verfügung stehenden > Source-Code nach der Funktionsdefinition. Zumindest im alten AVR Studio hat er aber Dateien, die keine Dateinamensinformationen in den Debug-Infos hatten, komplett ignoriert und kam nie auf die Idee, dafür irgendwo nach dem Sourcecode zu suchen. (Wurde die Datei nicht an der in den Debug-Infos hinterlegten Stelle gefunden, wurde explizit nach dem Standort gefragt.) Keine Ahnung, ob das mit dem Visual-Kram jetzt tatsächlich völlig anders ist. Ich benutze das Zeug nur, wenn mich jemand mit Geld dafür bedroht. ;-)
Stefan Ernst schrieb: > Für das, was der OP möchte, > müsste man den Source-Code der Lib dem Projekt als eine Art externe > Referenz/Abhängigkeit hinzufügen, so dass er zwar bei der > Source-Code-Analyse mit berücksichtigt wird, aber nicht mit > kompiliert/gelinkt wird. Ich hab grad gesehn, dass ich mir die Lösung des "Problems" heut schon vorweggenommen habe! siehe Beitrag "Arduino Library unter Atmel Studio 6.2" Vorgehensweise: Neues GCC C Static Library Project erstellen, die Startdatei rauslöschen und alle .c .h sowie .S und .inc Files aus folgenden Verzeichnissen als Vorhandenes Element als Link hinzugefügen Ihr müsst halt den Pfad bei Verwendung einer anderen Version der Toolchain anpassen.
1 | C:\Program Files (x86)\Atmel\Atmel Toolchain\AVR8 GCC\Native\3.4.1056\avr8-gnu-toolchain\avr\libc\misc |
2 | C:\Program Files (x86)\Atmel\Atmel Toolchain\AVR8 GCC\Native\3.4.1056\avr8-gnu-toolchain\avr\libc\pmstring |
3 | C:\Program Files (x86)\Atmel\Atmel Toolchain\AVR8 GCC\Native\3.4.1056\avr8-gnu-toolchain\avr\libc\stdio |
4 | C:\Program Files (x86)\Atmel\Atmel Toolchain\AVR8 GCC\Native\3.4.1056\avr8-gnu-toolchain\avr\libc\stdlib |
5 | C:\Program Files (x86)\Atmel\Atmel Toolchain\AVR8 GCC\Native\3.4.1056\avr8-gnu-toolchain\avr\common |
Dann noch bei den Projekteigenschaften für alle Konfigurationen unter Toolchain dem AVR/GNU C Compiler sowie Assembler mitgeteilt, dass er auch im Verzeichnis (kein Relativer Pfad!)
1 | C:\Program Files (x86)\Atmel\Atmel Toolchain\AVR8 GCC\Native\3.4.1056\avr8-gnu-toolchain\avr\common |
nach Includes, in dem Fall asmdef.h suchen soll. Bis auf ein einziges Warning für \avr\libc\stdlib\dtostre.c kompiliert das dann einwandfrei unter dem Atmel Studio 6.2 bei der Vorgehensweise! Wobei das Kompilieren eigentlich gar nicht notwendig ist. -> Im Konfigurationsmanager das Häkchen beim Erstellen weggeben. Voillà! Das Projekt kann man dann bei einer zu untersuchenden Projektmappe *als vorhandenes Projekt hinzufügen* und den ganzen Source durchstöbern! Anbei das "Projekt". Daniel A. Maierhofer
Du weißt aber, dass die avr-libc in vielen Variationen compiliert wird für die einzelnen AVRs, ja? Nicht alle werden dabei den gleichen Objektcode haben (sonst wären die Variationen nicht nötig). Wenn du dir die Implementierungsdateien nur ansehen willst, ist das sicher ziemlich egal, aber sowas wie Single-Step wird auf diese Weise sicher nicht gelingen.
Hab gerade gemerkt, dass ich auf die AVR-spezifischen Includes vergessen habe, also die Sources aus folgenden Orndern müssen ebenfalls hinzugefügt werden:
1 | C:\Program Files (x86)\Atmel\Atmel Toolchain\AVR8 GCC\Native\3.4.1056\avr8-gnu-toolchain\avr\include |
2 | C:\Program Files (x86)\Atmel\Atmel Toolchain\AVR8 GCC\Native\3.4.1056\avr8-gnu-toolchain\avr\include\avr |
3 | C:\Program Files (x86)\Atmel\Atmel Toolchain\AVR8 GCC\Native\3.4.1056\avr8-gnu-toolchain\avr\include\compat |
4 | C:\Program Files (x86)\Atmel\Atmel Toolchain\AVR8 GCC\Native\3.4.1056\avr8-gnu-toolchain\avr\include\util |
5 | C:\Program Files (x86)\Atmel\Atmel Toolchain\AVR8 GCC\Native\3.4.1056\avr8-gnu-toolchain\avr\libm\fplib |
Wobei ich von dem include/avr nur folgende ioxx.h Dateien eingebunden habe sonst wurde es zu unübersichtlich:
1 | "iotnx5.h" "iom8.h" "iom8a.h" "iom16u4.h" "iom32.h" "iom32a.h" "iom32u4.h" "iom88pa.h" "iom168pa.h" "iom328.h" "iom328p.h" "iomx8.h" "iotn4.h" "iotn5.h" "iotn9.h" "iotn13a.h" "iotn45.h" "iotn85.h" "iotn2313a.h" |
Außerdem waren das leider alles relative Pfade, sodass es nur in einer bestimmten Verzeichnisebene funktionierte. Jetzt sollte es überall funktionieren wo die jetzt gerade aktuelle Toolchain 3.4.1056 installiert ist. Ansonsten einfach per Texteditor ersetzen. Anbei das aktualisierte File. Kompilieren dauert bei dem, wenn man es spaßeshalber probiert, schon eine halbe Ewigkeit, dafür aber eine vollkommen klaglose.
Jörg Wunsch schrieb: > Du weißt aber, dass die avr-libc in vielen Variationen compiliert > wird für die einzelnen AVRs, ja? Nicht alle werden dabei den gleichen > Objektcode haben (sonst wären die Variationen nicht nötig). Ja genau, das hab ich eben auch gemerkt, weil ich die ganzen io-Files noch gar nicht inkludiert hatte. > Wenn du dir die Implementierungsdateien nur ansehen willst, ist das > sicher ziemlich egal, aber sowas wie Single-Step wird auf diese Weise > sicher nicht gelingen. Denk mir auch, dass das nicht einfach sein kann, aber mir reichts auf C-Sourcecodeebene. In speziellen Fällen kann ich mir ja eh das Assemblerlisting anschaun.
Bitteschön ein Update zur Verwendung mit dem Atmel Studio 6.2 Build 1502 und der Atmel-AVR-GNU-Toolchain 3.4.5 http://distribute.atmel.no/tools/opensource/Atmel-AVR-GNU-Toolchain/3.4.5/ https://github.com/damadmai/studio_6_libc Viel Erfolg damit,
Thread beobachten
Seitenaufteilung abschaltenBitte 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.