Hallo, für eine Anpassung in einem Altprojekt muss ich die alte Entwicklungumgebung wieder herstellen - Zulassungsbedingt. Der alte Rechner ist allerdings längst hinüber. Ich habe soweit aber die genutzten Tools wieder zusammen bis auf den Compiler und die Bibliotheken (siehe Überschrift). Wo bekomme ich SourceryG++ Lite-arm-non-eabi 2008q3-66 oder -72 her? (Vorzugsweise für Win32, Linux ginge aber auch) Auf der Mentor-Webseite habe ich als älteste Version 2011 gefunden. Hat jemand noch einen Link oder gar das Archiv? Ahoi, Martin
Gast
#5290866
Keine Ahnung ob das nur ein Update oder komplett ist, aber wenn du bei MG registriert bist, versuch mal das: https://sourcery.mentor.com/GNUToolchain/release642?
Scheint es noch zu geben: https://sourcery.mentor.com/GNUToolchain/release642? Ich habe allerdings meinen Mentor Accout verschlampt. Ohne Login sieht man nur PDFs.
Mit meinen (alten) Logindaten bleibt es leider bei den PDF-Dateien. Ahoi, Martin
Gast
#5290913
Ach wenn du von hier startest? https://sourcery.mentor.com/sgpp/lite/arm/portal/subscription3053
von jetzt an wirst Du sicherlich dazu übergehen komplett eingerichtete VMs zu archivieren, oder?
Hallo pegel schrieb: > Ach wenn du von hier startest? > > https://sourcery.mentor.com/sgpp/lite/arm/portal/subscription3053 Wenn ich eingeloggt bin, kriege ich "not permitted"... Wenn ich ausgeloggt bin, kommt die gewünschte Übersicht, der 2008q3-Link führt mich aber zur bekannten Seite und dort steht unter Software: "You must log in to view the packages associated with this release." Logge ich mich dann ein, steht unter Software nix... Heute abend werde ich mir einen neuen Account anlegen, vielleicht liegt es ja daran. Bernd K. schrieb: > von jetzt an wirst Du sicherlich dazu übergehen komplett eingerichtete > VMs zu archivieren, oder? ;-) Du hast es erfasst... Ahoi, Martin
Gast
#5291027
Ich habe mal etwas "erweitert" gesucht und die 2008q3-72 für Linux gefunden: https://sourcery.mentor.com/public/gnu_toolchain/arm-none-linux-gnueabi/arm-2008q3-72-arm-none-linux-gnueabi.bin
Aaaah, vielen Dank. pegel schrieb: > Ich habe mal etwas "erweitert" gesucht und die 2008q3-72 für Linux > gefunden: > > https://sourcery.mentor.com/public/gnu_toolchain/arm-none-linux-gnueabi/arm-2008q3-72-arm-none-linux-gnueabi.bin Nachdem ich die Linuxvariante geladen hatte, habe ich nach dem Linux-Muster einen Namen für arm-2008q3-66-arm-none-eabi.exe zusammengestellt - und es lädt!! Prima, das hat mir sehr geholfen! Danke nochmal, Ahoi, Martin
Gast
#5291079
Lade doch mal aus Spaß eine aktuelle Version vom GCC-ARM-Embedded und vergleiche die Kompilate, vielleicht ist's ja schneller aber erkennbar dass es immer noch korrekt ist.
Gast
#5291085
Martin S. schrieb: > habe ich nach dem Linux-Muster Die win Variante habe ich jetzt auch gefunden. Die war mit entgangen, da ich immer ein win oder win32 im Namen vermutet habe. ;)
Ich hatte schonmal mit 2011q?? und 2014q?? übersetzt. Das Binary wird ca. 25% kleiner(?!) und hat im Schnelldurchlauf funktioniert wie erwartet. Zeitverhalten ist völlig unkritisch, daher kann ich zu "schneller" nix sagen. In der Anwendung will ich aber nicht nochmal eine Zertifizierung anleiern, deshalb muß ich die alte Toolchain verwenden (Änderung war minimal: der Pullup eines Pins ist in der Initialisierung weggefallen... - Ich war schon drauf und dran, das Hex-File zu patchen.) Ahoi, Martin
Gast
#5291108
Martin S. schrieb: > In der Anwendung will ich aber nicht nochmal eine Zertifizierung > anleiern, Aus Neugier, wie wird denn ein Open-Source-Compiler wie G++ zertifiziert? Martin S. schrieb: > Ich war schon drauf und dran, das Hex-File zu patchen. Heh, das wäre nach meinem Geschmack... Früher™ hat man das oft so gemacht ;-)
Martin S. schrieb: > - Ich war schon drauf und dran, das Hex-File zu patchen.) Nur mal rein interessehalber: Wie würde denn so ein Patch „zertifiziert“? Oliver
Naja, das war damals wohl schon ein rechter Aufwand und lief auf Dauertests und viel Augenzudrücken raus... (das war GottSeiDank nicht meine Spielwiese) Der Iststand ist als "funktionierend nach Spec" anerkannt, incl. der dafür genutzten Toolschain. Das die fehlerfrei ist, steht ja nirgendwo, nur das das damit erzeugte Binärfile auf der Zielhardware gemäß der Spec funktioniert. Patchen ist natürlich "bäh", die Argumentiererei liefe auf "Änderung eines simplen Parameters" (des Initwertes für die Pullupkonfiguration eines einzelnen Inputs) raus, in der Annahme eines stark verringerten Testumfanges. Das Compilat wurde ja von der ursprünglichen und damit genehmigten Toolchain generiert. Ob das geklappt hätte, weiß ich nicht. Der jetzige Ansatz ist ja durchaus ähnlich, es wird nur eben tatsächlich nochmal übersetzt. Ahoi, Martin
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.