Announcement: there is an English version of this forum on Hallo, ich habe mir das ucos-ii für verschiedene Controller portiert. Momentan teste ich das mit dem ATMega2560. Da ich schon seit Jahren mit winavr bestens klar komme, habe ich bei mir das immer noch installiert. Da die Software auf dem Atmega2560 erst nicht lief, habe ich das auch mit ATmel-Studio compiliert. Mittlerweile läuft sie einwandfrei wenn ich das mit dem avr-gcc 4.3.3 compiliere und dann ins STK600 überspiele. Compiliere ich das mit dem avr-gcc aus dem Atmel-Studio, läuft die Software nicht im STK600. Es ist nicht nur exakt derselbe Quellcode sondern auch dieselben Dateien. Um auszuschliessen, dass es an Atmel-Studio liegt, habe ich mir eine Batch-Datei geschrieben, wo die einzelnen Dateien separat compiliert und gelinkt werden. Dies jeweis für den avr-gcc 4.3.3 als auch 4.8.1. Es ist in den Batch-Dateien alles identisch. Nur der jeweilige Compiler wird aus unterschiedlichen Pfaden aufgerufen. Aber die Compiler- und Linkeroptionen sind zu 100% identisch. Hat jemande eine Idee, woran das liegen könnte? Oder habe ich sonst eine Möglichkeit herauszufinden, wo die erzeugten Dateien unterschiedlich sind. Ich habe das schon über die "lss"-Datei versucht. Aber da komme ich nicht weiter. Von beiden Compilern habe ich mal die Versionen anzeigen lassen und das Ergebnis unten eingefügt. Vorab schon mal Danke für eine Antwort. Viele Grüße avr-gcc.exe (AVR_8_bit_GNU_Toolchain_3.4.5_1522) 4.8.1 Copyright (C) 2013 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. avr-gcc (WinAVR 20100110) 4.3.3 Copyright (C) 2008 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
In den unzähligen Versionen von AVR-gcc gibts tatsächlich welche, die Macken haben. Ob jetzt 4.8.1 dazugehört, ist unklar. Auf AVRfreaks gibt es zumindest Hinweise, das es so sein könnte. Aktuell ist allerdings ja Version 14, da sollte es ausreichend viele andere außer 4.8.1 zur Auswahl geben. Allerdings hat sich das Optimierungsverhalten der Compiler über die Zeit schon stark verändert, und mancher eigentlich fehlerhafter Code, der mit alten Compilern trotzdem lief, läuft mit neueren nicht mehr. Also zeig mal den Code. Andreas schrieb: > Aber die Compiler- und > Linkeroptionen sind zu 100% identisch. Die zeig auch mal. Oliver
:
Bearbeitet durch User
> der mit alten Compilern trotzdem lief, läuft mit neueren nicht mehr.
DAs ist das Problem! WEnn man glaubt einen Fehler zu haben dann sollte
man seinen Debugger anwerfen und die genaue Stelle finden. In 99% der
Faelle wird man dann sehen das man selber Unsinn programmiert hat und im
restlichen 1% hat man dann wirklich einen Bug im Compiler gefunden an
dessen Behebung man mitwirken kann.
Vanye
Danke erstmal für Eure Antworten. Oliver S. schrieb: > Aktuell ist allerdings ja Version 14 Meinst Du von dieser Webseite: https://blog.zakkemble.net/avr-gcc-builds/ ? Da habe ich irgendwo im Internet gelesen, dass der Compiler von dieser Webseite ziemlich aufgeblähten Code liefert. Ich weiss aber im Moment nicht mehr wo ich das gelesen habe. Oliver S. schrieb: > mancher eigentlich fehlerhafter Code, der mit > alten Compilern trotzdem lief, läuft mit neueren nicht mehr. Das kann ich mir nur schwer vorstellen, bzw. ist für mich nicht nachvollziehbar. Der eigentliche ucos-source wurde auf zahlreichen Controllern portiert und ist in ANSI-C geschrieben. Die Portierung für den avr-gcc wurde bereits 2001 von Ole Saether und 2003 von Julius Luukko vorgenommen und ist auch bei mehreren Projekten im Internet zu finden. Ich habe lediglich die Timerinitialisierung für den AT90CAN128, ATMega162 und AT90S8515 geändert. Bei allen drei Controllern läuft es einwandfrei. Sowohl auf einem STK500 als auch STK200. Beim STK200 aber mit zusätzlichem RAM. Ausserdem ist es nur schwer nachzuvollziehen, dass der Code fehlerhaft sein soll, dann aber doch läuft. Darüber hinaus läuft es im Simulator von AVR-Studio. Ich habe das zwar nocht nicht mit den Timeraufrufen getestet, aber zumindest ein Task wird angesprungen. Oliver S. schrieb: > Also zeig mal den Code. Das sind über 10 Dateien. Da wird sich hier wohl kaum jemand durchquälen. Wie ich bereits geschrieben hatte, existiert der auch an zahlreichen Stellen im Internet. Oliver S. schrieb: >> Aber die Compiler- und >> Linkeroptionen sind zu 100% identisch. > > Die zeig auch mal. Hier mal der Compileraufruf für eine Datei:
1 | avr-gcc.exe -Wall -g2 -gstabs -Os -fpack-struct -fshort-enums -ffunction-sections -fdata-sections -std=gnu99 -funsigned-char -funsigned-bitfields -mmcu=atmega2560 -DF_CPU=8000000UL -MMD -MP -MF"ucossource/os_core.d" -MT"ucossource/os_core.o" -c -o "ucossource/os_core.o" "../ucossource/os_core.c" |
und hier der Linkeraufruf:
1 | avr-gcc.exe -Wl,--gc-sections -Wl,-Map,Multitasking.map -Wl,--gc-sections -mrelax -mmcu=atmega2560 -o "Multitasking.elf" ./ucossource/os_core.o ./ucossource/os_flag.o ./ucossource/os_mbox.o ./ucossource/os_mem.o ./ucossource/os_mutex.o ./ucossource/os_q.o ./ucossource/os_sem.o ./ucossource/os_task.o ./ucossource/os_time.o ./MTuart.o ./Main.o ./os_cpu_a.o ./os_cpu_c.o -lm -lm |
Die Batch-Datei für den Compiler von AVR-Studio ist identisch. Dort ist nur das avr-gcc.exe ersetzt durch:
1 | "C:\Program Files (x86)\Atmel\Atmel Toolchain\AVR8 GCC\Native\3.4.1061\avr8-gnu-toolchain\bin\avr-gcc.exe" |
Vanye R. schrieb: > WEnn man glaubt einen Fehler zu haben dann sollte > man seinen Debugger anwerfen und die genaue Stelle finden. Habe ich gemacht. Und zwar lange bevor ich den Thread erstellt hatte. Wie ich bereits geschrieben habe, im AVR-Studio läuft es. Zumindest kommt die Software weiter als in der Hardware auf dem STK600. Vanye R. schrieb: > In 99% der > Faelle wird man dann sehen das man selber Unsinn programmiert Das kann wohl kaum sein, wenn die Software auf 4 Controllern mit dem avr-gcc 4.3.3 läuft. Dazu auch noch im Simulator von AVR-Studio. Vanye R. schrieb: > im > restlichen 1% hat man dann wirklich einen Bug im Compiler gefunden an > dessen Behebung man mitwirken kann. Momentan gehe ich noch nicht einmal von einem Bug im Compiler aus sondern glaube eher, dass da irgendwas wegoptimiert oder anders umgesetzt wird. Dies würde ich gerne finden, wäre auch bereit mir den erzeugen Assemblercode anzusehen. Aber ich hatte das bereits über die lss-Datei versucht. Die ist aber von der Strukturierung dermassen anders bei beiden Compilern, dass mir das nicht möglich war. Daher hatte ich gehofft hier einen Tipp zu finden, wie ich das einfacher herausfinden kann. Ich werde am Wochenende nochmal versuchen die Software für den AT90CAN128, den ATMega162 und AT90S8515 mit dem Compiler von AVR-Studio zu compilieren und gucken was dann rauskommt. Wenn noch jemand eine andere Idee hat, wie ich die Unterschiede der erzeugen Hex-Dateien finden kann, wäre ich dankbar. Viele Grüße
Es ist nicht ausgeschlossen, dass ucos nen Bug hat. Es ist nicht ausgeschlossen, dass die gcc Version nen Bug hat. Da will man dann natürlich wissen, wo das Problem ist. Wenn das Problem im eigenen Code / der eigenen Portierung ist, und man nimmt zur "Lösung" eine andere Compilerversion, dann hat man nix gewonnen, weil man früher oder später vom selben Artefakt wieder ins Hinterteil gezwickt wird. Was ich nicht verstehe ist v4.8.1. Die v4.8 Release Serie endet mit v4.8.5, warum also nicht diese nehmen, die im Vergleich zur ersteren ausschließlich Bugfixes enthält? Die Problembeschreibung ist viel zu allgemein, um konkret Tipps geben zu können. Also wie immer: Problem eingrenzen mit den üblichen mittels wie Debugging, Logging, Statische Analyse (z.B. generierten Code anschauen, mehr Warnings aktivieren), Code verkleineren / vereinfachen. etc. Letzteres ist natürlich nur dann praktikabel, wenn die Unterschiede im erzeugten Code überschaubar sind -- was, wie du schreibst, nicht der Fall ist. Also Problem weiter eingrenzen. Und ist das Problem sporadisch? Tritt immer zur gleichen Zeit auf? Software stürzt sofort ab? etc Einen großen Beitrag zum Delta zwischen lst Dateien sind unterschiedliche Code-Adressen: Eine Instruktion mehr oder weniger, und alle folgenden Adressen sind anders. Hier kann es helfen, die lst vorher zu filtern, zB mit sed.
Das Argument mit 4.8.5 vs. 4.8.1 kann ich nachvollziehen. Anderer Punkt: Was passiert denn bei -O0 anstelle -Os? Wenn es dann funktioniert, dann kannst Du das Problem schon auf eine Datei eingrenzen. fchk
Beitrag #7761260 wurde von einem Moderator gelöscht.
Andreas schrieb: >> Aktuell ist allerdings ja Version 14 > Meinst Du von dieser Webseite: > https://blog.zakkemble.net/avr-gcc-builds/ ? > Da habe ich irgendwo im Internet gelesen, dass der Compiler von dieser > Webseite ziemlich aufgeblähten Code liefert. Ich weiss aber im Moment > nicht mehr wo ich das gelesen habe. Das ist wohl auch der Grund, warum Microchip selber bei 5.4.0 stehen geblieben ist. Neuere Versionen erzeugen weniger kompakten Code. Klar, gcc ist nicht für 8-Bit Architekturen designt, und das Hauptaugenmerk liegt auf x86, arm, mips, risc-v, also alles 32/64 Bit Architekturen. fchk
Andreas schrieb: > Da habe ich irgendwo im Internet gelesen, dass der Compiler von dieser > Webseite ziemlich aufgeblähten Code liefert. Kann ich bestätigen. Hier ist noch eine Alternative zur Seite von ZAK: https://gnutoolchains.com/avr/ Die Version 5.3.0 (ab Windows XP) erzeugt den gewohnt kompakten Code. Bei der 7.3.0 (ab Windows 7) weiß ich es nicht. Debian Linux ist bei Version 5.4.0 hängen geblieben.
:
Bearbeitet durch User
Johann L. schrieb: > Was ich nicht verstehe ist v4.8.1. Weil ich den Compiler von AVR-Studio 6.2 genommen habe und dachte, der würde funktionieren. Frank K. schrieb: > Das Argument mit 4.8.5 vs. 4.8.1 kann ich nachvollziehen. War mir nicht bekannt. Ich habe hier noch einen Compiler von Sysprogs installiert, aber bisher nicht getestet. Am Wochenende werde ich mal ausprobieren, was dabei rauskommt. Frank K. schrieb: > Was passiert denn bei -O0 anstelle -Os? Wenn es dann funktioniert, dann > kannst Du das Problem schon auf eine Datei eingrenzen. Werde ich am Wochenende auch mal ausprobieren. Danke für den Tipp. Sherlock 🕵🏽♂️ schrieb: > Hier ist noch eine Alternative zur Seite von ZAK: > https://gnutoolchains.com/avr/ Danke, den habe ich installiert. Da ich aber mit Eclipse und dem Plugin programmiere, war mir das bisher zu umständlich alles anzupassen. Aber am Wochenende werde ich das über die Batch-Datei testen. Johann L. schrieb: > Und ist das Problem sporadisch? Tritt immer zur gleichen Zeit auf? > Software stürzt sofort ab? etc Nein. Software läuft gar nicht an. Ich habe mir zum debuggen in der Interruptroutine 2 LEDs anzeigen lassen. Da sehe ich, dass da reingesprungen wird. Johann L. schrieb: > Letzteres ist natürlich nur dann praktikabel, wenn die Unterschiede im > erzeugten Code überschaubar sind -- was, wie du schreibst, nicht der > Fall ist. Also Problem weiter eingrenzen. Ich habe das über die lss-Datei versucht. Das war Wahnsinn und für mich unmöglich. Daher hatte ich mir erhofft hier einen Tipp tz bekommen, wie das einfacher geht. Sofern in der Version, die ich bzw. das Atmel Studio verwendet, tatsächlich ein Bug ist, bringen auch alle Versuche damit nichts. Daher werde ich das am Wochenende mit anderen Versionen bzw. mit den Einstellungen O0 versuchen. Das Ergebnis werde ich berichten. Bis dahin erstmal danke an alle.
Andreas schrieb: > Ich habe das über die lss-Datei versucht. Kannst du mal die beiden fertig compilieren elf-Dateien hier hochladen? Und bitte auch den Sourcecode, zusammen gezippt. Oder auch das ganze Eclipse-Projektverzeichnis. Oliver
Um das Problem näher einzugrenzen, habe ich die Software für den AT90CAN128 mit den Versionen avr-gcc 7.3.0 und 5.4.0 compiliert. Da läuft sie einwandfrei. Mit der Version 4.8.1 habe ich es noch nicht getestet. Da ich das jetzt zum Anlass nehmen wollte mal auf die Version 7.3 umzusteigen, habe ich versucht die Software für den ATMega162 zu compilieren. Dabei habe ich aber erhebliche Schwierigkeiten. Damit das Ganze nicht zu unübersichtlich wird, habe ich dafür einen neuen Thread aufgemacht. Sobald es hier was neues gibt, werde ich berichten. Viele Grüße Andreas
So, ich habe das Ganze in den letzen Tagen getestet und, wie meistens, sitzt der Fehler wohl vor dem Bildschirm. Aber der Reihe nach. Um den Fehler einzugrenzen habe ich mir die avr-Versionen 7.3.0, die avr-Version 5.4 und die Version von Sysprogs heruntergeladen. Wobei ich festgestellt hatte, dass die 7.3.0 identisch ist mit der von Sysprogs. Ich hatte die Software schon seit längerem durch eine bedingte Compilierung auch für den AT90CAN128, den AT90S8515 und den ATMega162 geändert. Dort liefen die auch einwandfrei. Daher wollte ich zunächst testen, ob das auf allen drei Controllern noch funktioniert. Während ich die Software für den ATMega2560 geändert hatte, fielen mir diverse Dinge bei den anderen Controllern auf, wo ich dachte, das könnte man verschönern. Natürlich ungetestet, wodurch sich das Ganze erstmal als eine Verschlimmbesserung herausstellte. Daher hatte ich erstmal einiges an der Software wieder gerade biegen müssen, was mehrere Tage an Zeit in Anspruch genommen hatte. Dabei gab es auch diverse Probleme, wozu es auch einen separaten Thread Beitrag "section `.data' is not within region `data'" gibt. Nachdem das dann auf den anderen Controllern lief, habe ich das auch für den ATMega2560 getestet. Auch dort läuft es jetzt einwandfrei. Auch mit dem Compiler des Atmel-Studios (4.8.0) läuft es (bedingt) einwandfrei. Ich weiss definitiv, dass es, als der Thread von mir erstellt wurde, nicht lief. Es war exakt dieselbe Software. Wo der Fehler in der Software war, lässt sich jetzt nicht mehr nachvollziehen, da ich mir den Stand blöderweise nicht gesichert habe. Allerdings bekomme ich bei der Version 4.8.0 immer eine Fehlermeldung in einer Interrupt-Routine: "Error 5 local frame unavailable (naked function?)" Wenn ich den Funktionsaufruf in der Interrupt-Routine auskommentiere, kommt der Fehler nicht. Diese Fehlermeldung bekomme ich weder bei der Version 5.4.0 noch bei 7.3.0. Dort funktioniert die Interrupt-Routine auch einwandfrei. Oliver S. schrieb: > Und bitte auch den Sourcecode, zusammen gezippt. Oder auch das ganze > Eclipse-Projektverzeichnis. Hätte ich gemacht. Aber wie ich geschrieben hatte, mussten ich meine ganzen Änderungen wieder erstmal auf einen vernünftigen Stand bringen, so dass es auf den anderen Controllern lief. Das wollte ich niemandem zumuten. Danke an alle für den Aufwand und die Bemühungen. Ich werde das jetzt als Anlass nehmen und auf 7.3.0 umstellen.
Andreas schrieb: > So, ich habe das Ganze in den letzen Tagen getestet und, wie meistens, > sitzt der Fehler wohl vor dem Bildschirm. Hut ab für das öffentliche Eingeständnis. Menschen, die Fehler nicht nur machen, sondern auch dazu stehen, verdienen Respekt.
Andreas schrieb: > Um das Problem näher einzugrenzen, habe ich die Software für den > AT90CAN128 mit den Versionen avr-gcc 7.3.0 und 5.4.0 compiliert. Da > läuft sie einwandfrei. Na dann ist doch alles in Butter. Atmel Studio 7 bzw. Microchip Studio verwenden die 5.4.0. Laß also die 4.8.1 in Frieden ruhen.
1 | C:\Program Files (x86)\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\bin>avr-gcc --version |
2 | avr-gcc (AVR_8_bit_GNU_Toolchain_3.6.2_1778) 5.4.0 |
3 | Copyright (C) 2015 Free Software Foundation, Inc. |
4 | This is free software; see the source for copying conditions. There is NO |
5 | warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. |
Harald K. schrieb: > Hut ab für das öffentliche Eingeständnis. Menschen, die Fehler nicht nur > machen, sondern auch dazu stehen, verdienen Respekt. Danke Peter D. schrieb: > Atmel Studio 7 bzw. Microchip Studio verwenden die 5.4.0. > Laß also die 4.8.1 in Frieden ruhen. Wäre schön, wenn Atmel Studio 7 bei mir laufen würde. Ich habe bestimmt schon 3 oder 4 mal versucht das bei mir zu installieren. Aber es wird immer abgebrochen mit irgendwelchen nicht näher bezeichneten Fehlermeldungungen. Als ich den avr-gcc 7.3.0 installiert hatte, habe ich auch Atmel Studio 7 nochmal installiert. In der Hoffnung, dass zumindest der aktuelle Compiler installiert wird und ich den von Hand aufrufen kann. War natürlich nichts. Der einzige Grund, warum ich die 4.8.1 installiert habe, war der, dass sich Atmel Studio 6.2 (oder 6.1, das weiss ich gerade nicht, weil PC aus) installieren liess und die 4 8.1 dazu gehören. Studio 6 kann ohne Fehler installiert und aufgerufen werden.
Wenn es nur um die Tools geht (avr-gcc + binutils + avr-libc), die hatte ich vor einiger Zeit mal für MinGW32 generiert: https://sourceforge.net/projects/mobilechessboar/files/avr-gcc%20snapshots%20%28Win32%29/ Das neueste ist eine v8.0.1 (v10 würde ich nicht empfehlen). Wenn die v8.0.1 bei die läuft, könnte ich auch eine v8.5 generieren und hochladen. Die Tools gibt's aber auch bei Microchip zum Download; weiß aber nicht welche Versionen es da gibt.
Johann L. schrieb: > Wenn es nur um die Tools geht (avr-gcc + binutils + avr-libc), die hatte > ich vor einiger Zeit mal für MinGW32 generiert: Sind das die: https://sourceforge.net/projects/mobilechessboar/files/avr-gcc%20snapshots%20%28Win32%29/avr-gcc-10.0.0_2019-12-16_-mingw32.zip/download ? Falls ja, würde ich die in den nächsten Tagen mal installieren und das Ergebnis hier mitteilen. Johann L. schrieb: > Die Tools gibt's aber auch bei Microchip zum Download; weiß aber nicht > welche Versionen es da gibt. Meinst Du das hier: https://ww1.microchip.com/downloads/aemDocuments/documents/DEV/ProductDocuments/SoftwareTools/avr8-gnu-toolchain-3.7.0.1796-win32.any.x86_64.zip Da meldet sich bei mir der Compiler mit 7.3.0. Aber dazu schrieb Jörg: Jörg W. schrieb: > Vermutlich Microchips mit privaten Patches zusammen gefrickelte > Toolchain.
Andreas schrieb: > Wäre schön, wenn Atmel Studio 7 bei mir laufen würde. Ich habe bestimmt > schon 3 oder 4 mal versucht das bei mir zu installieren. Aber es wird > immer abgebrochen mit irgendwelchen nicht näher bezeichneten > Fehlermeldungungen. Was unter einem handelsüblichen Windows 10 schon seltsam ist. Oliver
Andreas schrieb: > Johann L. schrieb: >> Wenn es nur um die Tools geht (avr-gcc + binutils + avr-libc), die hatte >> ich vor einiger Zeit mal für MinGW32 generiert: > Sind das die: > https://sourceforge.net/projects/mobilechessboar/files/avr-gcc%20snapshots%20%28Win32%29/avr-gcc-10.0.0_2019-12-16_-mingw32.zip/download > ? > Falls ja, würde ich die in den nächsten Tagen mal installieren und das > Ergebnis hier mitteilen. Von der v10 würde ich abraten wegen Codequalität, dito für alle v9-v12. v13 hat mindestens einen (selten auftretenden) Bug, der für v14 gefixt ist aber noch nicht rückportiert. Die v14 wiederum erzeugt suboptimalen Code for floats. Meine aktuelle Version ist die v8.5. Zum Testen ob die Tools überhaupt laufen wäre dann die "avr-gcc-8.0.1_2018-04-23_mingw32.zip" vom 2018-04-23 / 57.4 MB. Das lief damals auf W2K, sollte also auch auf neueren Windows Versionen laufen. > Da meldet sich bei mir der Compiler mit 7.3.0. Aber dazu schrieb Jörg: > Jörg W. schrieb: >> Vermutlich Microchips mit privaten Patches zusammen gefrickelte >> Toolchain. Die "eigenen Patches" sind wohl vor allem der Support für neuere Devices. Evtl. unterscheiden sich auch die Device-Header / SFRs.
Eine gute Quelle für avr-gccs für Windows ist Zak Kemble, inzwischen auf github zu finden https://github.com/ZakKemble/avr-gcc-build/releases Oliver
:
Bearbeitet durch User
Johann L. schrieb: > Meine aktuelle Version ist die v8.5. Zum Testen ob die Tools überhaupt > laufen wäre dann die "avr-gcc-8.0.1_2018-04-23_mingw32.zip" vom > 2018-04-23 / 57.4 MB. Das lief damals auf W2K, sollte also auch auf > neueren Windows Versionen laufen. Werde ich irgendwann in den nächsten Tagen ausprobieren und dann berichten. Danke erstmal. Oliver S. schrieb: > Eine gute Quelle für avr-gccs für Windows ist Zak Kemble, inzwischen auf > github zu finden Dazu hatte ich schon mal was geschrieben: Andreas schrieb: > Da habe ich irgendwo im Internet gelesen, dass der Compiler von dieser > Webseite ziemlich aufgeblähten Code liefert. Ich weiss aber im Moment > nicht mehr wo ich das gelesen habe. Die Erfahrung haben auch andere gemacht: Sherlock 🕵🏽♂️ schrieb: > Kann ich bestätigen.
Andreas schrieb: >> Da habe ich irgendwo im Internet gelesen, dass der Compiler von dieser >> Webseite ziemlich aufgeblähten Code liefert. Ich weiss aber im Moment >> nicht mehr wo ich das gelesen habe. > Die Erfahrung haben auch andere gemacht: > Sherlock 🕵🏽♂️ schrieb: >> Kann ich bestätigen. Erst lesen, dann denken, dann posten… Auf der von mir verlinkten github -Seite von Zak Kemble (nicht seiner Homepage) findet man nicht nur den aktuellen AVR-gcc 14, sondern auch alle von ihm früher veröffentlichen Versionen, bis zurück zu 8.3 (oder so). Oliver
:
Bearbeitet durch User
Johann L. schrieb: > Meine aktuelle Version ist die v8.5. Zum Testen ob die Tools überhaupt > laufen wäre dann die "avr-gcc-8.0.1_2018-04-23_mingw32.zip" vom > 2018-04-23 / 57.4 MB. Das lief damals auf W2K, sollte also auch auf > neueren Windows Versionen laufen. Aufgrund anderer Dinge hat es noch einige Zeit gedauert, aber habe es eben installiert und funktioniert einwandfrei. Vielen Dank Oliver S. schrieb: > Was unter einem handelsüblichen Windows 10 schon seltsam ist. Wer sagt Dir Denn, dass bei mir Windows 10 installiert ist? Mein Rechner läuft mit Windows 8.1 und da ich damit bisher gut gefahren bin, gilt bei mir: "Never touch a running system". Insbesondere vor dem Hintergrund, dass ich, als ich den Rechner neu gekauft hatte, Windows 10 installiert hatte. Danach lief der dermassen langsam, das war nicht normal. Ich habe dann herausgefunden, dass es an irgendeinam Grafiktreiber lag und ganz schnell wieder zurück auf Windows 8.1 installiert. Da ich den Rechner momentan dringend brauche, werde ich auch keine neuen Tests mit einer neueren Windows-Version machen. Vielen Dank nochmal an alle für die Unterstützung und Hinweise.
Andreas schrieb: > Johann L. schrieb: >> Meine aktuelle Version ist die v8.5. Zum Testen ob die Tools überhaupt >> laufen wäre dann die "avr-gcc-8.0.1_2018-04-23_mingw32.zip" vom >> 2018-04-23 / 57.4 MB. Das lief damals auf W2K, sollte also auch auf >> neueren Windows Versionen laufen. > Aufgrund anderer Dinge hat es noch einige Zeit gedauert, aber habe es > eben installiert und funktioniert einwandfrei. Vielen Dank Wie angekündigt hab ich mal eine v8.5.1 generiert und hochgeladen: https://sourceforge.net/projects/mobilechessboar/files/avr-gcc%20snapshots%20%28Win32%29/ avr-gcc-8.5.1_2024-11-23_mingw32.zip Enthalten sind sind lediglich GCC (v8.5.1), Binutils (v2.43), AVR-LibC (v2.2.0). Dokumentation zur AVR-LibC: https://avrdudes.github.io/avr-libc/avr-libc-user-manual-2.2.0/index.html Dokumentation zu GCC: https://gcc.gnu.org/onlinedocs/gcc-8.5.0/gcc/ wobei alle Devices unterstützt werden, die auch die v14 kann: https://gcc.gnu.org/onlinedocs/gcc-14.2.0/gcc/AVR-Options.html avr-gcc-8.5.1 unterscheidet sich von stock v8.5 durch: https://github.com/sprintersb/avr-gcc-8#what-is-it
Johann L. schrieb: > avr-gcc-8.5.1_2024-11-23_mingw32.zip Hab ich installiert. Software lässt sich einwandfrei compilieren und läuft auch auf dem STK600. Vielen Dank erstmal. Beim ersten Compilieren hatte ich natürlich prompt eine "Fehlermeldung":
1 | c:/gcc-8-avr-mingw32/bin/../lib/gcc/avr/8.5.1/../../../../avr/bin/ld.exe: address 0x801402 of Multitasking.elf section `.bss' is not within region `data' |
2 | c:/gcc-8-avr-mingw32/bin/../lib/gcc/avr/8.5.1/../../../../avr/bin/ld.exe: address 0x801402 of Multitasking.elf section `.bss' is not within region `data' |
3 | c:/gcc-8-avr-mingw32/bin/../lib/gcc/avr/8.5.1/../../../../avr/bin/ld.exe: address 0x801402 of Multitasking.elf section `.bss' is not within region `data' |
Nach kurzem Nachdenken fiel mir auf, dass ich als Parameter beim Compiler und Linker "-mmcu=at90can128" angegeben hatte, die Software aber mittlerweile für den AT90CAN128 zu gross ist, was den Ram betrifft. Beim Compilieren für den ATMega2560 war die Meldung nicht. Das Ganze nochmal getestet für den ATMega162 mit folgender Ergänzung beim Linker:
1 | -Wl,-Tdata=0x800500 -Wl,--defsym,__DATA_REGION_ORIGIN__=0x800500 |
2 | -Wl,--defsym=__DATA_REGION_LENGTH__=32k |
ohne diese Ergänzungen denselben "Fehler" wie für den AT90Can128. Mit den obigen Parametern beim Linken kam die Meldung nicht. Von daher gefällt mir die "Fehlermeldung" gut. Denn bei der Version 4.3.3 wurde die Software ohne irgendeine Meldung compiliert. Da hatte ich erst mit avr-size gesehen, dass der Ram nicht ausreicht. Nochmals vielen Dank für Deine Bemühungen und Aufwand.
Andreas schrieb: > c:/gcc-8-avr-mingw32/ Die "Installation" dieser v8.5.1 besteht nur im Auspacken des ZIP. Der Ordner kann dort ausgepackt werden, wo es einem am besten passt; es braucht nicht an der C: Wurzel zu sein.
Johann L. schrieb: > Die "Installation" dieser v8.5.1 besteht nur im Auspacken des ZIP. Der > Ordner kann dort ausgepackt werden, wo es einem am besten passt; es > braucht nicht an der C: Wurzel zu sein. Ok, danke. Das wusste ich nicht. Ich meine ich hätte hier irgendwo im Forum gelesen, dass Winavr2010 im Verzeichnis C:\ installiert sein muss. Daher habei ich das so beibehalten. Werde ich aber bei Gelegenheit verschieben.
Andreas schrieb: > Ich meine ich hätte hier irgendwo im Forum gelesen, dass > Winavr2010 im Verzeichnis C:\ installiert sein muss. WinAVR kam mit einem kleinen Installer, der es optional erlaubte, den Pfad zum bin/ Verzeichnis in PATH aufzunehmen. Wenn man danach WinAVR verschiebt, dann wird die Compiler natürlich nicht mehr per PATH gefunden. Bei meinem ZIP handelt er sich nicht um einen Installer, und es ist auch kein WinAVR enthalten sondern AVR Tools für Windows / MinGW32. Man kann die Tools direkt per absoluten Pfad aufrufen, uns / oder man kann den Pfad des bin/ Verzeichnisses in PATH aufnehmen, so dass man ienfach avr-gcc etc. verwenden kann.
Johann L. schrieb: > Man kann die Tools direkt per absoluten Pfad aufrufen, uns / oder man > kann den Pfad des bin/ Verzeichnisses in PATH aufnehmen, so dass man > ienfach avr-gcc etc. verwenden kann. Danke für die Erklärung. Path muss ich noch ändern. Da ich ein Fan von eclipse bin, habe ich bisher nur dort die entsprechenden Variablen geändert.
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.