Hallo zusammen,
ich nutze AVR-GCC um Code für einen ATmega128RFA1 zu kompilieren.
Ursprünglich nutzte ich WinAVR-20100110, nun möchte ich aber einen
neueren Kompiler nutzen. Ich habe also nun zwei zur Verfügung: den aus
WinAVR in Version 4.3.3 und einen in Version 4.8.1 aus der Atmel
AVR-Toolchain (für 8-Bit AVR).
Die benutzten Makefiles sind stets dieselben, der Unterschied liegt nur
darin, dass ich in meiner Konsole entweder den Pfad zu WinAVR (bin,
avr/bin und utils) dem vorhandenen voranstelle oder den Pfad zur
AVR-Toolchain (bin und avr/bin, die Utilities kommen dann auch aus
Win-AVR - die spielen beim Kompilieren selbst aber keine Rolle, die
relevanten Tools (avr-gcc, avr-as, ...) liegen ja in bin oder avr/bin
(dort als gcc, as, ...). Benutzt wird Win7. Es gibt keine Fehler beim
kompilieren.
Der Build log ist absolut identisch, bis auf die Ausgabe der Größen:
WinAVR:
--------
Die erzeugte Größe des Output-Files ist im zweiten Fall viel zu klein.
Die Größe der zwischendurch erstellten Objektdateien ist aber in beiden
Fällen sinnvoll (und teilweise sehr groß).
In meinem Listing sehe ich, dass im Fall der AVR-Toolchain eine Menge
Symbole weggeworfen wird.
Beispiel "BSP_OpenLeds": Für WinAVR findet man dieses Symbol im Listing
in Sektion "Linker script and memory map", aber im Falle der
AVR-Toolchain erscheint es unter Sektion "Discarded input sections".
BSP_OpenLeds ist aber eine Funktion, die definitiv benutzt wird!
Irgendwo muss also der Linker völligen Käse machen. Als Optionen wird
-ffunction-sections dem Kompiler gegeben (um ungenutzte Funktionen
später heraustrennen zu können) und --gc-sections dem Linker (und zwar
über -Wl,--gc-sections in Form einer Kompileroption, so dass dieser sie
korrekt weitergibt).
WinAVR trennt dann auch nur wirklich unbenutztes Zeug heraus, wohingegen
die AVR-Toolchain auch genutztes heraustrennt.
(aufgerufen wird avr-gcc mit o.g. LINKER_FLAGS)
Warum in aller Welt verhält sich nun ein neuerer Kompiler/Linker so
dermaßen anders? Mit einem selbst kompilierten AVR-GCC 4.9.1 passiert
das gleiche...
Hat jemand sowas auch schon gesehen oder einen Tipp?
Vielen Dank!
Volker
Ohne Code ist es schwierig, da was zu sagen.
zb könnte ein aggressiveres Inlining da einen Unterschied machen. Wenn
dann Compiler/Linker auch noch rauskriegen, dass die Funktion (weil
überall geinlined) eigentlich nicht gebraucht wird und deshalb komplett
rausfliegt, kann das einen Unterschied ausmachen zum Fall, dass die
Funktion zwar geinlined wird, aber als Funktion selbst auch noch im
Programm beibehalten wird.
Funktioniert denn das kleinere Ergebnis?
Vielleicht wirfst du das -ffunction-sections und -gc-sections ja
erstmal raus?
Die Dinger sind doch in den allermeisten Fällen nur eine Entschuldigung
für die Faulheit des Programmierers, den Überblick darüber zu behalten,
was er in seinem Projekt von alldem, was da aufgeschrieben worden ist,
denn nun tatsächlich braucht.
Oliver S. schrieb:> Das ist bei -Os allerdings nicht zu erwarten.
Zumindest beim WINAVR 2010 wird trotz -Os ungewünscht geinlined.
Man muß es explizit mit:
-fno-inline-small-functions
ausschalten.
> Das ist bei -Os allerdings nicht zu erwarten.>
Die 'Idee' war eigentlich, dass sich unterschiedliche Compilerversionen
hier zum Beispiel unterschiedlich verhalten könnten.
Wenn also dieselbe Funktion in der einen Compilerversion übrig bleibt
und in einer anderen Version rausfällt, dann muss das nicht unbedingt
auf einen Fehler im Compiler hindeuten.
Vielen Dank erstmal für die vielen Ratschläge. Gleich kommt die Lösung,
aber zuerst dies:
@ Oliver S. (oliverso): Nein, es funktioniert nicht und wäre auch nicht
zu erwarten gewesen. Das Programm nutzt den Atmel BitCloud Stack, der
alleine schon um die 80 k hat. Aber das hatte ich nicht erwähnt, daher
ist die Nachfrage natürlich berechtigt. Danke!
@Jörg Wunsch (dl8dtl): Das ist ein naheliegender, sinnvoller Vorschlag,
danke! Aber hier wird eben ein Atmel BitCloud-Stack benutzt, plus eigene
Applikation oben drauf, und diese Optimierung wird von Atmel schon in
den Makefiles eingebaut, weil der Stack naturgemäß viel mehr Funktionen
anbietet, als eine Applikation später nutzt. Ohne das Rausschmeißen
ungenutzter Funktionen würde ich wohl den Speicherplatz sprengen (läuft
auf einem ATmega128RFA mit 128 kB Flash, braucht mit Stack und Treibern
ohne großartige App schon >103 kB bei Rausschmeißen der ungenutzten
Funktionen.
Und: Mit WinAVR klappt's ja...
@Karl Heinz (kbuchegg): Ja, genau, es muss nicht am Compiler liegen
(bzw. eher Linker hier). Das ist tatsächlich hier der Fall. Ich hatte
gehofft, dass jemand diesem Phänomen schon mal aufgesessen ist, und dann
sagen kann, schau mal hier oder mal da. Das wurde ja auch erfüllt, denn
mancher Hinweis von Dritten gibt einem oft den entscheidenden Blick auf
etwas, was man bisher nicht in Betracht zog (schon alleine das
Formulieren der Frage brachte mich dazu, selbst noch das ein oder andere
vorher auszuprobieren und auszuschließen). Aber genug Blabla, jetzt
kommt die (naheliegende) Lösung:
Im Linker-Script (nebenbei bemerkt von Atmel) haben die eine
DISCARD-Section eingebaut und schmeißen die .init9-Sektion weg. Da kommt
aber gemäß AVR-LIBC die main hin. Sehr, sehr schlau. Die Atmel-Leute
haben stattdessen eine Sektion *(.text.main) nebst KEEP (*(.text.main))
eingefügt, aber das funktioniert nicht (bei mir).
Nun habe ich dort wieder *(.init9) und den DISCARD auskommentiert, und
nun klappt's auch mit den neueren Kompilern (und es ist nicht der
Kompiler, sondern das ebenfalls neuere AVR-LIBC, das nun in V1.8.0 statt
1.6.7 (oder so) vorliegt, wobei main schon immer nach .init9 gekommen
sein dürfte...
Theoretisch müsste es nun auch mit meinem selbstkompilierten GCC 4.9.1
gegen, nebst selbst kompiliertem AVR-LIBC 1.8.0.
Jörg müsste das wohl am besten beurteilen können, ob es nun an AVR-LIBC
und dem "komischen" Atmel-Linker-Script lag, aber wie gesagt, nun geht's
ja.
Nachfrage Off-Topic an Jörg: Du hattest an AVRDUDE gearbeitet, um auch
mit aktuellen Firmwareversionen von JTAGICE3 programmieren zu können und
das gibt's als SVN-Snapshot irgendwo. Gibt es bald eine neue, offizielle
Release, die das unterstützt? So lange muss ich nämlich auf's
Firmwareupdate meines JTAGICE3 verzichten (und kann nicht vernünftig
Debuggen, weil ich es nicht ans Atmel-Studio anschließen kann, ohne dass
es meine Firmware updated). Leider gibt's ja auch noch keine
OpenSource-Debugging-Möglichkeit mit JTAGICE3, das vermisse ich sehr
(hätte halt doch einen AVR Dragon kaufen sollen, der wird wenigstens gut
unterstützt)...
funker schrieb:> @Jörg Wunsch (dl8dtl): Das ist ein naheliegender, sinnvoller Vorschlag,> danke! Aber hier wird eben ein Atmel BitCloud-Stack benutzt, plus eigene> Applikation oben drauf, und diese Optimierung wird von Atmel schon in> den Makefiles eingebaut, weil der Stack naturgemäß viel mehr Funktionen> anbietet, als eine Applikation später nutzt.
Da rächt es sich, dass sie den nicht sauber in Bibliotheken ablegen,
und gegen diese linken. Aus denen würde sich der Linker nur die
Module krallen, die wirklich referenziert werden.
> Im Linker-Script (nebenbei bemerkt von Atmel) haben die eine> DISCARD-Section eingebaut und schmeißen die .init9-Sektion weg. Da kommt> aber gemäß AVR-LIBC die main hin. Sehr, sehr schlau. Die Atmel-Leute> haben stattdessen eine Sektion *(.text.main) nebst KEEP (*(.text.main))> eingefügt, aber das funktioniert nicht (bei mir).
Grmpf. Kaputtgespielt.
Schreib ihnen einen Bugreport.
> Nachfrage Off-Topic an Jörg: Du hattest an AVRDUDE gearbeitet, um auch> mit aktuellen Firmwareversionen von JTAGICE3 programmieren zu können und> das gibt's als SVN-Snapshot irgendwo. Gibt es bald eine neue, offizielle> Release, die das unterstützt?
Ist doch schon drin (seit März 2014).
Allerdings macht es zuweilen Probleme (OSX und wohl teilweise auch
Windows), weil die libusb sich nicht gegen die OS-Treiber für das
HID durchsetzen kann. Ich erwäge, das Ganze auf libhid umzubauen,
denn damit scheint OpenOCD gut zurecht zu kommen.
Linux und FreeBSD gehen auf jeden Fall damit, auch mit dem neuen
Atmel-ICE.
Nur im AVaRICE hab' ich es immer noch nicht drin.
> Leider gibt's ja auch noch keine> OpenSource-Debugging-Möglichkeit mit JTAGICE3, das vermisse ich sehr
Doch, AVaRICE kommt mit der 2.er (nicht-CMSIS-DAP-)Firmware des
JTAGICE3 zurecht. Hab' ich gerade eben wieder benutzt hier. Bloß
die CMSIS-DAP-Erweiterung bin ich noch nicht angegangen.
Jörg Wunsch schrieb:> Grmpf. Kaputtgespielt.
Sicher? Ich vermute da doch eher einen unzulässigen MischMasch der
verschiedenen toolchain- Versionen.
Das die aktuelle Atmel-toolchain so kaputt wäre, daß sie main
"rausoptimiert", hätte sich schon rumgesprochen.
Oliver
Oliver S. schrieb:> Sicher?
Es gibt bei AVR + avr-libc keinen vernünftigen Grund, warum man für
ein 08/15-Projekt überhaupt mit custom linker scripts anfangen
müsste. (Ja, bei ARM ist das anders.)
Außerdem ist der Sprung (bzw. Aufruf) von main() aus .init9 das
dokumentierte Verhalten der avr-libc.
Wenn Atmel das besser weiß, sollen sie's bitte selbst supporten.
@ Oliver S. (oliverso):
Nee, nicht die AVR-Toolchain ist "kaputt", sondern das Linker-Script,
das im BitCloud Stack benutzt wird. In der Atmel AVR-Toolchain sind die
originalen Linkerscripts von AVR-LIBC drin. Wer also die Atmel Toolchain
mit den mitgelieferten Linker-Scripts nutzt, hat kein Problem.
Keine Ahnung, warum es im BitCloud-Stack ein eigenes Linker-Script gibt
(öhm, nun gut, in neueren Versionen haben sie extra Sektionen
eingeführt, da mag das Sinn machen, wenn man's denn richtig machte).
Jedenfalls ist es also nie ein Problem irgendeiner Toolchain gewesen,
sondern nur des mitgelieferten Linker-Scripts im BitCloud-Stack, das man
für seine BitCloud-App nutzen soll. Vermutlich wäre (zumindest in alten
Versionen) ein linken gegen die Original-Linker-Scripts aus AVR-LIBC
auch gegangen...
Jörg Wunsch schrieb:> Ist doch schon drin (seit März 2014).
Dann habe ich was verpasst oder falsch verstanden. Ich hatte mir einen
AVRDUDE 6.1 (vom 13.3.3014) für Windows kompiliert und es so verstanden,
dass dieser zwar JTAGICE3 unterstützt, aber nicht mit
CMSIS-DAP-Firmware. Ich dachte, dazu müsse man einen SVN-Snapshot holen
und den kompilieren...
> Nur im AVaRICE hab' ich es immer noch nicht drin.
Dann hält mich auch dies noch von einem Firmware-Update ab.
> Doch, AVaRICE kommt mit der 2.er (nicht-CMSIS-DAP-)Firmware des> JTAGICE3 zurecht. Hab' ich gerade eben wieder benutzt hier. Bloß> die CMSIS-DAP-Erweiterung bin ich noch nicht angegangen.
Habe Version 3.15 drauf (schon seit Kauf). Jetzt sag aber nicht, dass
das schon eine mit CMSIS-DAP-Firmware ist... Meine PID ist jedenfalls
noch 0x2110 und nicht 0x2140, wie auf den CMSIS-DAP-Geräten laut
http://savannah.nongnu.org/bugs/?40615...
Damit müsste AvaRICE dann gehen? Muss ich morgen sofort ausprobieren
(wenn ich dazu komme)...
funker schrieb:>> Nur im AVaRICE hab' ich es immer noch nicht drin.>> Dann hält mich auch dies noch von einem Firmware-Update ab.
Sagen wir mal so: wenn du nicht musst, dann solltest du dir den
Upgrade auch nicht antun. (Müssen tut man nur für Atmel Studio.)
Besser wird davon nämlich fast nichts, wenn man vielleicht davon
absieht, dass es im Prinzip dann auch noch unter USB 1.1 geht (aber
mit saumäßiger Performance), während die nicht-CMSIS-DAP-Firmware
in dieser Hinsicht kaputt war. Die geht nur auf USB 2.0.
Das Einzige, was daran aus Windows-Sicht besser ist ist, dass
Windows eben immer einen Treiber für HID mitbringt, sodass man
keinen spezifischen Treiber installieren muss. Nicht-Windows-Systeme
hatten ebendieses Problem jedoch gar nicht erst, denn die bringen für
alle USB-Geräte immer einen low-level-Treiber mit, auf dem die
libusb aufsetzen kann. (Neuere Windows-Versionen sollen sowas auch
haben, habe ich mir sagen lassen.)
Der ganze HID-Krempel verursacht ein Vielfaches an Overhead in der
Kommunikation. Da werden jedesmal volle 512 Bytes über den Draht
gefeuert, auch dann, wenn nur ein Byte gesendet werden muss. Jedes
Antwortpaket muss per Anforderung abgeholt werden (wobei die
Anforderung selbstverfreilich ihre vollen 512 Bytes einnimmt), während
es in der vorigen Firmware freiwillig ankam. Events hatten in der
vorigen Firmware einen eigenen Interrupt-Endpoint; jetzt muss die
Applikation regelmäßig nach Events pollen (und du vermutest richtig,
wenn du denkst, dass auch das Pollen selbst volle 512 Byte für die
Anforderung und weitere 512 Byte für die Antwort, auch eine leere,
braucht).
> Habe Version 3.15 drauf (schon seit Kauf). Jetzt sag aber nicht, dass> das schon eine mit CMSIS-DAP-Firmware ist... Meine PID ist jedenfalls> noch 0x2110 und nicht 0x2140, ..
OK, bei mir ist die nicht-CMSIS-DAP-Version noch eine 2.21 (dezimal),
aber wenn die PID bei dir 0x2110 ist, dann passt das schon.
Jörg, noch eine kurze Frage zum AVaRICE:
Ich habe versucht, die letzte Version mit MinGW für Windows zu
kompilieren (ähnlich der Anleitung unter
http://www.nongnu.org/avr-libc/user-manual/install_tools.html (Building
and Installing under Linux, FreeBSD, and Others)), aber es geht nicht
(u.a. make Fehler termios.h fehlt - wurde auch von configure erkannt,
aber nicht als Fehler gemeldet). Nun gut, MinGW bietet ja auch keine
volle POSIX-Unterstützung, aber wenn es schon in der Anleitung steht,
dass es mit MinGW ginge, hätte ich jetzt mehr Erfolg erwartet.
1) Siehst Du überhaupt eine Chance, das ganze mit MinGW zu kompilieren?
Zur Not müsste ich wohl den Weg über Cygwin gehen, aber ich wollte mir
das Mitführen der Cywin-DLL ersparen, daher habe ich alle anderen Tools
bisher mit MinGW erstellt.
2) Ich sehe ohnehin gerade im Quellcode, dass selbst 2.13 keinen Support
für JTAGICE3 hat. In deinem Trunk 2014-10-13 sehe ich aber diesen
Support. Muss also den runterladen, aber der wird desselbe Problem
bereiten...
Blöderweise kann ich hier kein SVN machen (sitze hinter einem Proxy, der
das verbietet - selbst bei "svn checkout
http://svn.code.sf.net/p/avarice/code/trunk avarice-code", wie im
SorceForge-Link angegeben).
3) Ist es ein großer Aufwand, Unterstützung für neue Typen einzubauen
(bspw. könnte ich mal versuchen, die ATmega256RFR2 zu beschreiben). I/O
Register sind ja in ioreg.cc beschrieben, das würde ich hinkriegen, den
Code dafür zu erstellen, aber damit wird es alleine nicht getan sein? In
devdecr.cc und jtag.h sehe ich die Strukturen für die Beschreibung eines
Devices, allerdings frage ich mich, wo ich alle die Informationen
herkriegen soll (einen ATmegaRFR256, dessen ID ich über JTAG auslesen
könnte, habe ich nicht).
funker schrieb:> Nun gut, MinGW bietet ja auch keine> volle POSIX-Unterstützung, aber wenn es schon in der Anleitung steht,> dass es mit MinGW ginge, hätte ich jetzt mehr Erfolg erwartet.
Steht doch nicht drin, sondern da steht:
1
Build the tools below in Cygwin.
AVaRICE ist ziemlich POSIX-lastig in der kompletten Implementierung,
daher geht das nur mit Cygwin.
> Zur Not müsste ich wohl den Weg über Cygwin gehen, aber ich wollte mir> das Mitführen der Cywin-DLL ersparen, daher habe ich alle anderen Tools> bisher mit MinGW erstellt.
Ich weiß, der Cygwin-DLL-Krams ist ätzend (und per selbst ernanntem
Ordnungshüter-Syndrom darf man das auch nicht statisch linken).
> 2) Ich sehe ohnehin gerade im Quellcode, dass selbst 2.13 keinen Support> für JTAGICE3 hat. In deinem Trunk 2014-10-13 sehe ich aber diesen> Support.
Stimmt. Wird wohl höchste Zeit, da mal wieder einen Release
rauszuschieben.
> bereiten...> Blöderweise kann ich hier kein SVN machen (sitze hinter einem Proxy, der> das verbietet - selbst bei "svn checkout> http://svn.code.sf.net/p/avarice/code/trunk avarice-code", wie im> SorceForge-Link angegeben).
Ja, der Proxy müsste dafür die WebDAV-HTTP-Requests durchreichen.
Ich hänge dir mal einen aktuellen Snapshot an. Der hat den
zusätzlichen Vorteil, dass da autoconf/automake schon gelaufen sind,
du hast also ein "configure" dabei.
> 3) Ist es ein großer Aufwand, Unterstützung für neue Typen einzubauen> (bspw. könnte ich mal versuchen, die ATmega256RFR2 zu beschreiben).
ATmega256RFR2 ist schon dabei, das habe ich noch unter Atmel-Flagge
gemacht damals.
> I/O> Register sind ja in ioreg.cc beschrieben, das würde ich hinkriegen, den> Code dafür zu erstellen, aber damit wird es alleine nicht getan sein?
In tools/ gibt es noch ein bisschen XSLT dafür. Geht nicht
ganz automatisch, aber vieles. (tools/ ist aber kein Bestandteil
eines Releases, daher auch nicht im angehängten Archiv mit drin.)
Jörg Wunsch schrieb:> Steht doch nicht drin, sondern da steht:> Build the tools below in Cygwin.
Ich meinte in der zitierten Anleitung "Building and Installing under
Linux, FreeBSD, and Others", nicht in Deinen Readme-Dateien. Bei Deiner
Readme steht das explizit drin, das stimmt, und dort habe ich es auch
gelesen. Ich wundere mich aber, wieso es eine (andere) Anleitung im Netz
gibt, die behauptet, es ginge mit MinGW, wenn das quasi ausgeschlossen
ist. Aber egal.
Vielen herzlichen Dank für den Snapshot, da werde ich gleich mal mein
Glück versuchen, es (mit Cygwin) zu kompilieren.
73
Jörg Wunsch schrieb:> Ja, genau aus der habe ich das zitiert. ;-)
Tja, dann habe ich das überlesen. Mein Fehler...
Nun gut, avarice ist nun kompiliert (musste ja leider auch die libusb
dann nochmal unter Cygwin kompilieren, und zwar nutze ich libusb-1.0.19
mit libusb-compat0.1.5). Nach ein paar Schwierigkeiten mit Libusb und
Cygwin-64 unter Win7 ging es dann.
Wie konnektiere ich denn nun meinen JTAGICE3 (was ist der devname)?
Ich bin mal ganz naiv rangegangen und habe gemäß manpage-Text "The AVR
Dragon and JTAGICE3 can only be connected through USB, so this option
defaults to "usb" in that case"
avarice -3 -j usb :4242
oder auch
avarice --jtag usb --jtag3 :4242
eingegeben und erhalte
1
AVaRICE version 2.13svn20141210, Dec 11 2014 12:39:49
2
3
Defaulting JTAG bitrate to 250 kHz.
4
5
cannot read serial number "No such file or directory"
oder wenn ich --jtag3 bzw. -3 weglasse, lautet die Meldung "did not find
any USB device".
AVRDUDE findet meinen JTAGICE3 aber:
I:\>avrdude -p m128rfa1 -c jtag3
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100%
0.08s
avrdude: Device signature = 0xXXXXXX (ausge-ixt)
avrdude: safemode: Fuses OK (E:FE, H:99, L:62)
avrdude done. Thank you.
Hast Du eine Idee? Kann meine 3.15er Firmware vielleicht in AVaRICE doch
Probleme machen, trotz 0x2110 VID (USB\VID_03EB&PID_2110&REV_0100)?
Oder schieße ich mir ins Knie, weil ich unter Windows den fertigen
libusb-win32-bin-1.2.6.0 benutzt habe, aber AVaRICE mit neuerer LibUSB
kompiliert habe (sollte aber eigentlich kompatibel sein)? Ein Linken
gegen die im fertigen Paket mitgelieferte Library schlug fehl, aber ggf.
habe ich auch was falsch gemacht. Ich könnte AVARICE nochmal versuchen,
gegen das "passende" Paket zu linken.
funker schrieb:> avarice -3 -j usb :4242
Korrekt
> cannot read serial number "No such file or directory"
Klingt allerdings in der Tat irgendwie nach einem libusb-Problem.
Leider habe ich keine Ahnung, wie man sowas auf Windows debuggt.
Auf meinem FreeBSD würde ich da ktrace oder dtrace anwerfen …
> AVRDUDE findet meinen JTAGICE3 aber:>> I:\>avrdude -p m128rfa1 -c jtag3
Allerdings eben nicht unter Cygwin und daher mit anderer libusb
gebaut.
Hast du mal die libusb ausprobiert, die bei Cygwin verfügbar ist?
Jörg Wunsch schrieb:> Hast du mal die libusb ausprobiert, die bei Cygwin verfügbar ist?
Vorher nein, nur die selbst erstellte. Jetzt aber ja, das Ergebnis ist
nun, dass die Meldung "did not find any USB device" nun auch bei
"avarice -3 -j usb :4242" erscheint anstelle von "No such file or
directory" (immerhin hat sich was getan). Die dritte Option, ein Linken
gegen das libusb-win32-Paket funktioniert generell nicht (Compiler
scheint mit der mitgelieferten libusb.a nichts anfangen zu können).
Übrigens habe ich meine JTAGICE-Firmware nun auf V 2.15 gebracht (mit
dem Firmware-Tool von Atmel), ändert aber auch nichts.
Ich spekuliere jetzt mal ein wenig: Mit dem unter Cygwin mitgelieferten
libusb wird eine cygusb0.dll benötigt (liegt auch vor und ist
installiert). Ich rate jetzt einfach mal, dass der libusb0.sys-Treiber
mit dieser DLL nicht zusammenarbeitet, genausowenig, wie wenn ich gegen
aktuelle libusb linke. AVaRICE hat also enwteder statisch eine aktuelle
libusb oder dynamisch die von Cygwin in Verwendung, je nachdem, wie ich
kompiliere. AVRDUDE hingegen habe ich statisch gegen die libusb.a linken
können, die im libusb-win-Paket enthalten war. Folglich kann AVRDUDE mit
der passenden libusb mit dem Windows-Treiber kommunizieren, aber keine
der Varianten von AVaRICE... Das bringt mich auf die Idee, mal exakt die
Quellen zu nutzen, die von libusb-win32 verwendet wurden. Kann aber auch
schief gehen...
Zum Verzweifeln. Jetzt habe ich schon einen aktuellen AVaRICE von Dir,
bringe ihn aber nicht zum Laufen... Wird wohl nichts aus schönem
debuggen, sehr schade...oder ich muss halt doch noch einen AVR Dragon
kaufen.
Könnte man eigentlich auch mit einem FT2232 basierte JTAG-Dongle
langfristig in AVaRICE einbinden oder fehlt dazu dann die Doku, wie
Atmel nun eigentlich die über USB empfangenen Daten letzlich in
JTAG-Signale umsetzt? Das ist ja einer der großen Vorteile von OpenOCD
bei ARM, dass man mit 10 EUR-USB-Dongle auch debuggen kann...
funker schrieb:> Zum Verzweifeln. Jetzt habe ich schon einen aktuellen AVaRICE von Dir,> bringe ihn aber nicht zum Laufen... Wird wohl nichts aus schönem> debuggen, sehr schade...oder ich muss halt doch noch einen AVR Dragon> kaufen.
Vielleicht lässt du ja ein unixoides OS in einer VM arbeiten? ;-)
Sorry, ich auch gerade keine freien Valenzen, mir den ganzen
Cygwin-Kram irgendwo in einer VM anzutun. Irgendwie muss das ja
aber mal alles funktioniert haben, sonst würde es ja auch mit einem
Dragon nicht klappen.
> Könnte man eigentlich auch mit einem FT2232 basierte JTAG-Dongle> langfristig in AVaRICE einbinden oder fehlt dazu dann die Doku
So isses: die JTAG-Kommandos zum Debuggen hat Atmel nie dokumentiert.
Es gab mal ein paar halbherzige Ansätze zum reverse engineering,
aber meines Wissens ist nichts davon so weit getrieben worden, dass
man nun bei OpenOCD ein AVR-Debug-Backend daraus gebaut hätte.
Jörg Wunsch schrieb:> Sorry, ich auch gerade keine freien Valenzen,
Das verstehe ich, wie ich selbt feststellen muss, sind schnell mal ein
paar Stunden weg, wenn man mal dies mal das ausprobiert.
Für die nächste Zeit belasse ich es also damit, dass es halt (noch)
nicht mit Cygwin geht oder vielleicht auch wegen dem sehr aktuellen
Cywin nicht geht oder weil ich einfach zu blöd dazu bin. Vlt. findet
sich ja ein Fähiger, der das AVaRICE in seiner neuesten Version auch für
JTAGICE3 unter Windoof zum Laufen kriegt...
Jedenfalls nochmal vielen Dank für den Support bis hier!
SUCCESS! ERFOLG! HURRA!
Update zum Problem mit AVaRICE: Nun läuft es (unter Vorbehalt) auch mit
JTAGICE3 unter Windows (mit Hilfe der Cygwin-DLL)!
Ich habe mir noch mal ein wenig Zeit genommen, alles genau
durchzuchecken und nun einen Weg gefunden, der geht.
Mit der libusb.a aus dem SOURCE-Package, also libusb-win-src-1.2.6.0,
ließ sich AVaRICE komplilieren UND läuft dann auch.
"Läuft dann auch" heißt dabei, dass JTAGICE3 erkannt wird und ich damit
schon mal die Fuses lesen konnte (avarice -r -3). Debugging habe ich
noch nicht probiert, aber dass das Fuses lesen nun geht und damit
JTAGICE3 prinzipiell funktioniert ist doch schon mal was!!!
Jetzt logge ich mich doch mal noch ein, damit ich auch mitbekomme, wenn
jemand interesse am fertig kompilierten Programm hat (avarice.exe). Wenn
also jemand die AVaRICE version 2.13svn20141210 mit Support für JTAGICE3
braucht, einfach bei mir melden...
Volker T. schrieb:
> Jetzt logge ich mich doch mal noch ein, damit ich auch mitbekomme, wenn> jemand interesse am fertig kompilierten Programm hat (avarice.exe). Wenn> also jemand die AVaRICE version 2.13svn20141210 mit Support für JTAGICE3> braucht, einfach bei mir melden...
Hallo Volker,
Ich versuche auch gerade das Avarice aus Svn unter Cygwin 64Bit zum
laufen zu bekommen, leider bisher erfolglos. Hierzu verwende ich derzeit
das fertige libusb-win32 Binary zip. Es gelang mir bisher nicht mit den
verschiedenen zur Verfügung stehenden gcc-varianten in cygwin entweder
die libusb.a beim configure mit einzubinden oder das avarice
durchzubauen. Mit welcher Konstallation hast du es geschafft? Ziel ist
die Verwendung des JtagIce3 mit dem gdb unter Windows7 64Bit.
Gruß
Sebastian
Hallo Sebastian,
sorry für die späte Antwort. Meine komplette Liste (den ersten Teil hast
Du ja schon erledigt, einfach ignorieren):
Vorbereitung:
- Cygwin installieren, nebst allen Tools zum Kompilieren. Die restlichen
Schritte gehen davon aus, dass unter Cygwin gearbeitet wird!
- Hinweis: MikTeX muss schon installiert und der Pfad zum Executable auf
der Pfadvariable sein. Ebenso /usr/local/bin und /bin.
libusb.a erstellen:
- libusb-win32-src-1.2.6.0 herunterladen:
http://sourceforge.net/projects/libusb-win32/files/libusb-win32-releases/1.2.6.0/
- Nach $HOME entpacken
- cd $HOME/libusb-win32-src-1.2.6.0
-
1
make
(make liefert Fehler, erstellt trotzdem libusb.a, bis dahin
funktioniert das also, alles weitere brauchen wir nicht)
Weiter mit AVaRICE:
- AVaRICE herunterladen: http://avarice.sourceforge.net/
- AVaRICE nach $HOME entpacken
- cd $HOME/avarice-2.13
- mkdir build
- cd build
- Wir sind nun also in $HOME/avarice-2.13/build. Hier heraus rufen wir
configure auf. Configure benötigt den Pfad und die Angabe der
USB-Libraries und zur Header-Datei lusb0_usb.h:
-
Abschlussarbeiten:
- Mit "cygcheck /usr/local/bin/avarice.exe" kann man testen, welche DLL
man zur Ausführung von avarice.exe braucht. Hat man mit LIBS=‘…‘ sein
make durchgeführt, so wird außer der Cywin1.dll nichts weiter gebraucht.
Hinweis: Eine ggf. unter /usr/local/include stehende usb.h-Datei kann zu
Konflikten führen, diese ggf. temporär umbenennen. Das habe ich
vorsichtshalber gemacht (denn ich hatte zunächst den Weg mit erstellen
von libusb-1.0 und libsub-compat-0.x versucht und dort dann die
entsprechenden Dateien), ob's wirklich nötig ist, habe ich aber nicht
geprüft.
Einfacher Test (lesen der Fuses über JTAGICE3):
1
avarice-r-3
Wenn das klappt, funktioniert AVaRICE prinzipiell.
Also der Knackpunkt war, nicht das Binary Package
libusb-win32-bin-1.2.6.0 zu nutzen, sodnern das Source Package
libusb-win32-1.2.6.0 und aus den dortigen Quellen dann libusb.a unter
Cygwin64 für den eigenen Windows-7-Rechner zu erstellen.
Alle anderen Wege scheiterten bei mir (Verwendung des Binary Package
libusb-win32-bin-1.2.6.0, Verwendung von libusb-1.0 und
libusb-compat-0.x, Verwendung von fertigen libusb-Libraries unter Cygwin
oder MinGW, Verwendung des letzten "echten" libusb-0.1.12).
Volker schrieb:> Also der Knackpunkt war, nicht das Binary Package> libusb-win32-bin-1.2.6.0 zu nutzen, sodnern das Source Package> libusb-win32-1.2.6.0 und aus den dortigen Quellen dann libusb.a unter> Cygwin64 für den eigenen Windows-7-Rechner zu erstellen.>> Alle anderen Wege scheiterten bei mir (Verwendung des Binary Package> libusb-win32-bin-1.2.6.0, Verwendung von libusb-1.0 und> libusb-compat-0.x, Verwendung von fertigen libusb-Libraries unter Cygwin> oder MinGW, Verwendung des letzten "echten" libusb-0.1.12).
Ich meine:
...sondern das Source Package libusb-win32-src-1.2.6.0...
Und ferner:
Mein oben in der ersten Antwort hart eingegebener Pfad
$HOME/avarice-2.13 ist natürlich zu ersetzen mit dem jeweils tatsächlich
gültigen, der ja von der Version abhängt...
Hallo Volker,
vielen Dank für deine ausführliche Anleitung.
Gestern habe ich es, auf etwas anderen Wege, auch geschafft.
Sorry, ich hätte das schon gestern abend schreiben sollen.
Im nächsten Thread möchte ich kurz meinen Weg für die Nachwelt
zusammenfassen.
Gruß
Hallo Volker, Liebe weitere Leser.
Ich wechsele den thread da das Topic nicht mehr zum aktuell besprochenen
Thema passt. Ich hoffe das ist Ok und findet sich einfacher.
> Im nächsten Thread möchte ich kurz meinen Weg für die Nachwelt> zusammenfassen.
Meine Zusammenfassung habe ich hier gepostet:
Beitrag "Avarice für Atmel AVR JTAGICE3 unter Cygwin(64Bit) bauen"
Gruß
Sebastian