Seit einer Woche gibt es die neue GCC Release v14
Änderungen: https://gcc.gnu.org/gcc-14/changes.html
AVR-spezifisch: https://gcc.gnu.org/gcc-14/changes.html#avr
Hallo Johann,
Danke für dein stetiges Engagement. Und natürlich all die anderen Heinzelmännchen rund um avr-gcc mit Tools wie avrdude usw..
Hallo,
nur mal zur Info was der avr-gcc 14 leistet im Vergleich mit AVR128DB64.
1 |
|
2 |
|
3 |
|
4 |
|
5 |
|
6 |
|
Trotz 1k weniger "RAM Belegung" funktioniert meine Modelleisenbahn noch. :-) Man mag es kaum glauben.
(Formatierungs-Tags ergänzt, damit es auch mobil lesbar ist. - Mod.)
Da es wohl einiges an const Daten geben, die du vorher manuell ins Flash hättest schieben können. Jetzt macht’s der Compiler von sich aus.
Oliver
Hallo,
das mag sein, hier arbeitet vermutlich "rohdata_flash" ordentlich was ab. Für serielle Debugausgaben verwende ich überall das F Makro ansonsten auch constexpr/constinit. Der Compiler sieht da wohl noch viel viel mehr. Ich kann kaum glauben das ich 1kB als nicht konstante Variablen liegen gelassen habe. Aber erstmal egal, ich finde das gut. Ist ein Zeichen das es funktioniert. :-)
Trotz 1k weniger "RAM Belegung"
Zumindest teilweise entfällt das wohl auf Vtables? Aber 1k wär dann doch recht viel. Blick ins Map-File bringt Aufschluss.
Interessant wäre auch ein Vergleich mit v8, der dürfte kleineren Code produzieren als alle v9+.
Hallo,
Ich benutze MPLAB-X mit der Gcc Toolchain von Microchip. Von denen gibt es ja nur einen avr-gcc mit Version 7.3.0.
Ich würde gern Mal was neueres probieren. Deshalb ein paar Fragen.
Gibt es für den GCC 14 ein .deb package für Ubuntu oder Debian?
Wenn nein, wie kann man den sonst in MPLAB X einbinden?
Ich habe bis jetzt nur die Quellen gefunden, muss man den dann selber übersetzen? Wird da die Toolchain dann auch mit erzeugt?
Ich würde das auch selber übersetzen, aber am Ende suche ich dann wieder irgendwelche fehlenden Libraries, die ich dann doch nicht benutzen kann, weil 22.04LTS noch eine alte Version benutzt, und die neue nicht mehr kompatibel ist. Das ist mir so oder so ähnlich schon mehrfach passiert. Also verplempere ich meine Zeit auf irgendwelchen Nebenkriegsschauplätzen anstatt mit meinen eigentlichen Projekten voranzukommen,
P.S. MPLAB-X benutze ich nur weil man damit debuggen kann. Ich würde auch lieber eine andere IDE benutzten, aber nur, wenn das debuggen über UPDI und mit den Adaptern von Microchip (snap) damit geht. So etwas wie Geany würde mir als IDE reichen.
Danke schon Mal,
VG
Auf gcc.gnu.org gibt's nur Quellen. Builds gibt's zum Beispiel bei Zak Kemble
https://github.com/ZakKemble/avr-gcc-build?tab=readme-ov-file#avr-gcc
Die AVR-LibC Dokumentation beschreibt wie man die Tools generieren kann.
https://www.nongnu.org/avr-libc/user-manual/install_tools.html
Diese Version v2.1 der Anleitung müsste allerdings mal überarbeitet werden.
Ich würde gern Mal was neueres probieren. Deshalb ein paar Fragen.
Gibt es für den GCC 14 ein .deb package für Ubuntu oder Debian?
Wenn du generell an neuen Dingen interessiert bist, könntest du mal Arch Linux ausprobieren. Hab's gerade upgedatet und siehe da:
1 |
|
2 |
|
3 |
|
4 |
|
5 |
|
Cortex-M4 Projekt (Modellbahn-Decoder): GCC13 - 156kB GCC14 - 150kB
Gast
#7664352
Die neue Version gibt es bestimmt bald bei Zak https://blog.zakkemble.net/avr-gcc-builds/
Hallo,
@ Johann: Mit gcc 8 kann ich das nicht mehr kompilieren.
Wonach muss man in den .map Dateien suchen?
@ Georg: Den avr-gcc 14.1.0 kann ich dir geben, dass ist nicht das Problem. Außer du möchtest das selbst bauen. Die eigentliche Frage lautet jedoch wie man das in MPLAB-X einbindet. Da wird auch keine Installation auf OS Ebene helfen, nehme ich stark an, weil die IDE ihre Toolchain mitbringt. In Microchip Studio ist es relativ einfach. Man muss einen neuen Eintrag anlegen und den Pfad bis zum 1. bin Verzeichnis konfigurieren. Ob das in MPLAB-X ähnlich einfach ist weiß ich nicht. Kannst das auch mit der 13.2.0 von Zak Kemble ausprobieren.
Mit gcc 8 kann ich das nicht mehr kompilieren.
Verwendest du bleeding edge C++, oder was geht da schief?
Wonach muss man in den .map Dateien suchen?
In v14 schauen was in Output Section .rodata landet. Evtl. funktioniert auch diff gegen v13.
@Veit
Danke, aber im Moment habe ich keine Zeit mehr.
Selber kompilieren habe ich probiert, er findet aber 3 Libraries nicht. Alle drei sind aber installiert, 2 davon viel neuer als gefordert und eine älter.
Vom Zak habe ich vor längerem schon Mal eine neuere Version probiert. Sie ließ sich ähnlich einfach wie im Microchip Studio einbinden, brachte aber dann beim Übersetzen Fehler. Dem Compiler fehlte die passende glibc. Die gabs aber wieder Mal nur als Source...
Ich warte Mal, bis es Ubuntu 24.04.1 LTS gibt. Eventuell gibt es dann auch den avr-gcc 14.1 vom Zak. Dann probiere ich es nochmal.
Vielen Dank euch allen.
Hallo,
ich bin wahrscheinlich ein hundsmiserabler Programmierer. Ich versuche schon C++ zu schreiben mit "moderaten" Vorteilen neuer Sprachfeatures die ich verstehe. Der 8er hat Probleme mit dem Datentyp 'auto' so wie ich es verwende. Template Objekte mittels 'auto' Referenz an Funktionen übergeben. Habe nochmal andere Programme probiert mit dem avr-gcc 8.5.0 zu kompilieren. Jedoch bricht die Kompilierung auch hier immer ab. Entweder mit:
1 |
|
2 |
|
oder kombiniert mit:
1 |
|
Nur wenn mir mit neueren Toolchains ab 9+ nicht einmal eine Warnung angezeigt wird, kann es so falsch nicht sein was ich schreibe. Es kann natürlich sein das es generell nicht optimal ist, gebe ich gern zu. Hatte mir Wilhelm schon einmal gesagt. Das soll aber jetzt kein Programmierthread werden. ;-) Ich arbeite daran.
Bin auf 2 ältere Programme für den ATmega2560 ausgewichen. Nur hier kann der 14er nicht punkten mit rohdata_flash. Die Ergebnisse sind durchwachsen. Mit Prog 2 ist der 13er sogar vorn. Also es kommt darauf an. Es kommt bestimmt auch darauf an wie gut man programmiert, also was man dem Compiler überhaupt serviert. Da will ich mal gar nicht meckern. :-)
1 |
|
2 |
|
3 |
|
4 |
|
5 |
|
6 |
|
7 |
|
8 |
|
9 |
|
.map Files schau ich mir an ...
Gibt es für den GCC 14 ein .deb package für Ubuntu oder Debian?
gcc-avr ist bei Debian leider schon lange verwaist (orphaned), d.h. es gibt keinen Betreuer (maintainer) für das Paket. Siehe gcc-avr: Package version severely outdated compared to main gcc-toolchain https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=932989
Gast
#7664446
gcc-avr ist bei Debian leider schon lange verwaist (orphaned), d.h. es gibt keinen Betreuer (maintainer) für das Paket.
Alles halb so wild, der avr-gcc in der XC8 Toolchain von Microchip ist genau so alt.
Hallo,
das diff File wäre 2MB groß, weil fast alles verschieden ist. Nur nach .rohdata suchen lassen:
1 |
|
2 |
|
3 |
|
4 |
|
5 |
|
6 |
|
7 |
|
8 |
|
9 |
|
10 |
|
11 |
|
12 |
|
13 |
|
14 |
|
15 |
|
16 |
|
led10mA ist ein constexpr unsigned int Array mit 134 Werte, macht 268 Bytes. Der Rest sind Funktionen der Arduino IDE. rohdata belegt im Flash Adressen von 0xA08000 bis 0xA08493 was in Summe 493 Bytes sind. Das wäre die Hälfte vom wegoptimierten 1k RAM.
.rodata belegt 0x493 = 1171 Bytes.
Moin,
ähm ja, ich versinke gerade im Stuhl. :-) Danke.
Du vergleichst hier auch Äpfel mit Birnen: einmal ein AVR128 und dann einen AtMega 2650. Denn der AVR128 kann rodata-flash-mapping:
https://gist.github.com/sprintersb/7e538928f5b481961d31458d2e5a402d
Und wenn Du das benutzt:
das mag sein, hier arbeitet vermutlich "rohdata_flash" ordentlich was ab.
sehen die Ergebnisse eben so wahrscheinlich aus.
Hallo,
ich habe noch ein Programm auf der Platte gefunden was auch mit dem avr-gcc 7 kompiliert. Aber wieder nicht mit dem 8er. Der 8er hat einen Bug. Und die Option rohdata abschalten funktioniert auch nicht wie ich festgestellt habe. Dann dachte ich vielleicht wurde in der Doku die Optionen der Devices verwechselt, aber es spielt keine Rolle. rohdata wird nicht abgeschalten.
1 |
|
2 |
|
3 |
|
4 |
|
5 |
|
6 |
|
7 |
|
8 |
|
9 |
|
10 |
|
11 |
|
8er Version: Problem des Linkers. Egal ob mit oder ohne -mrelax Option.
1 |
|
2 |
|
3 |
|
4 |
|
5 |
|
6 |
|
Gibt es dafür einen Patch?
D.h. mit v14.1 macht -m[no-]rodata-in-ram macht keinen Unterschied?
Bei v8 hilft evtl. die entsprechende Spec im Specs-File zu patchen? Sowas wie
1 |
|
Hallo,
D.h. mit v14.1 macht -m[no-]rodata-in-ram macht keinen Unterschied?
Richtig, soweit ich das feststellen konnte.
1 |
|
2 |
|
3 |
|
Laut meiner Ansicht ist es unwahrscheinlich das die Codegröße gleich bleibt und es dürfte im .map File keine rohdata Section geben.
Bei v8 hilft evtl. die entsprechende Spec im Specs-File zu patchen? Sowas wie
1 |
|
Danke, ich versuche es.
Hallo,
D.h. mit v14.1 macht -m[no-]rodata-in-ram macht keinen Unterschied?
Die section rodata im map-file / assembler-file ist immer da, jedoch wird unterschiedlich platziert. Bei Verwendung der flash-Einblendung liegt sie viel weiter oben, z.B. bei 0x00a08000 statt bei 0x00804000
P.S.: Die setion heisst rodata (read-only) und nicht rohdata ;-)
Wenn das nicht der Fall ist bei Dir, dann zeige mal Dein Programm und den Compiler-Aufruf.
Die section rodata im map-file / assembler-file ist immer da,
Auf Assembler-Ebene gibt es nur Input Sections, und die werden nicht lokatiert.
Lokatiert werden nur Output Sections. Eine .rodata Output Section gibt es nur für Emulations avrtiny, avrxmega3, avrxmega2_flmap und avrxmega4_flmap. Die beiden letzten werden angewählt mit -mno-rodata-in-ram (default).
Die section rodata im map-file / assembler-file ist immer da,
Auf Assembler-Ebene gibt es nur Input Sections, und die werden nicht lokatiert.
Genau: wie gesagt, im Assembler-file ist die .rodata-section (input) immer da (bei den entsprechenden Architekturen).
Lokatiert werden nur Output Sections. Eine .rodata Output Section gibt es nur für Emulations avrtiny, avrxmega3, avrxmega2_flmap und avrxmega4_flmap. Die beiden letzten werden angewählt mit -mno-rodata-in-ram (default).
Im map-file ist diese auch immer da, liegt natürlich jeweils woanders bzw. wird nicht benutzt.
Und ich denke, dass ist das, was er hier feststellt (zumindest, wenn er einfach nach .rodata grep-ed und einen match erhält):
14.1.0 ... 20503 / 1247 // " --- " und 'mrodata-in-ram' (im .map existiert eine rohdata Section) 14.1.0 ... 20503 / 1247 // " --- " und 'mno-rodata-in-ram' (im .map existiert eine rohdata Section)
Beispiel mit rodata im RAM:
.rodata 0x00804000 0xc8 /tmp/ccFWXQb4.o
Beispiel mit rodata gemapped:
.rodata 0x00a08000 0xc8 load address 0x00018000
Hallo,
Bei v8 hilft evtl. die entsprechende Spec im Specs-File zu patchen? Sowas wie
1 |
|
Habe mir das Spec-File vom AVR128DB64 angeschaut. Es gibt 2 Einträge.
1 |
|
2 |
|
3 |
|
4 |
|
5 |
|
Ich weiß nicht was ich ändern muss. Internetsuche blieb auch erfolglos.
Kompiliert wird mit:
1 |
|
24335 / 2158 Bytes // ohne weitere Option 24335 / 2158 // zusätzlich -mno-rodata-in-ram
.map Dateien sind gleich.
Kompiliert wird mit:-c -g -Os -Wall -Wextra -std=gnu++20 -fno-exceptions -fpermissive -ffunction-sections -fdata-sections -fno-threadsafe-statics -Wno-error=narrowing -MMD -flto -Wno-volatile
24335 / 2158 Bytes // ohne weitere Option 24335 / 2158 // zusätzlich -mno-rodata-in-ram
.map Dateien sind gleich.
Dann solltest Du kontrollieren, ob das Flag -mrodata-in-ram tatsächlich verwendet wird, oder ob Du mit den map-files durcheinander gekommen bist.
Ach, jetzt sehe ich es: Du musst -mrodata-in-ram angeben. Die Wirkung des Flags ist andersherum, als Du denkst.
Wenn du generell an neuen Dingen interessiert bist, könntest du mal Arch Linux ausprobieren. Hab's gerade upgedatet und siehe da:
1 |
|
2 |
|
Arch Linux ist ohnehin in vielerlei Hinsicht eine feine Sache, allerdings befürchte ich, daß nicht jeder seine gut eingefahrene Linux-Installation ersetzen möchte oder kann.
Deswegen habe ich im Anhang eine kleine Demo zusammengestellt, mit deren Hilfe Arch Linux mit den Paketen avr-gcc, avr-libc und make einfach mit Hilfe eines Docker-Image nutzen läßt. Mit dem Skript build.sh wird automatisch ein Image mit den genannten Paketen aus dem Dockerfile erstellt. Die Skripte run*.sh zeigen, wie das Image benutzt werden kann.
Ein Sonderfall ist das Skript "run.sh", dem das gewünschte Kommando einfach auf der CLI übergeben werden kann, wie im Folgenden gezeigt. Dieses Skript kümmert sich dann darum, das Unterverzeichnis src/ ins Verzeichnis /build des Containers zu mounten, das Kommando interaktiv im Vordergrund auszuführen ("-it") und den Container nach dem Aufruf automatisch löschen ("--rm").
1 |
|
Im Unterverzeichnis gibt es ein kleines C-Programm aus dieser [1] Quelle.
Kleiner Wermutstropfen: die Kommandos im Container laufen als Benutzer root und deswegen gehört auch die erzeugte "main.elf" natürlich root. Das kann der geneigte Benutzer aber recht einfach ändern, indem er im Here-Dokument von "RUN" mit useradd(8) einen neuen Benutzer mit der eigenen UID anlegt und dem Dockerfile am Ende die Direktive "USER" hinzufügt, hier den Benutzer "build" mit (meiner) UID 1000:
1 |
|
2 |
|
3 |
|
4 |
|
5 |
|
6 |
|
7 |
|
8 |
|
9 |
|
Nebenbei bemerkt, lassen sich auf diese Weise beliebige Linuxdistributionen mit den darin enthaltenen Paketen und Paketversionen nutzen. Mit ein wenig mehr Arbeit ist es sogar möglich, GUI-Programme (wie bei mir Google Chrome) mit Docker zu benutzen. Dazu sei auf das Github-Repository der bezaubernden Jessica Frazzelle unter [2] verwiesen. Deren Dockerfiles laufen zwar unter irgendetwas RedHat-igem, sind aber leicht für Debian-basierte anpaßbar.
Für Fragen und Ideen stehe ich gerne zur Verfügung, HTH und viel Spaß! :-)
[1] https://www.micahcarrick.com/getting-started.html [2] https://github.com/jessfraz/dockerfiles
Hallo,
es ist egal welche Option oder keine Option man verwendet. Man erhält immer das gleiche Ergebnis. Den Rest nennt man Plausibilitätsprüfung. 3 Möglichkeiten liefern das gleiche Ergebnis. Das kann nicht sein.
Habe es nochmal kompilieren lassen. Erneut gleiche Ergebnisse.
1 |
|
Die Option hat keine Wirkung aufs Compilieren oder Assemblieren, sondern nur aufs Linken. Wenn die erzeugen Dateien nicht vom Makefile abhängen, braucht's vorm Linken ein make clean.
es ist egal welche Option oder keine Option man verwendet
Nö, irgendetwas machst Du falsch. Wie oben schon geschrieben:
-
Du hast die Wirkung der Optionen vertauscht
-
Ggf. hast Du das Compilieren bzw. Linken vergessen.
1 |
|
2 |
|
Das Problem kann ich jetzt nicht nachvollziehen; etwa Linken mit -mrelax -flto und alles funktioniert problemlos mit v8.
Verwendest Du Arduino, oder wo kommt das -r her?
Hallo Johann,
ich verwende aktuell die Arduino IDE. Mir fiel bis zu diesen Vergleichstests hier noch nie auf das die 8er Probleme machen würde. Vielleicht wiederhole ich die Vergleichstest nochmal mit dem Microchip-Studio. Abgesehen davon, wenn die 7er und die 9er+ funktionieren, warum dann ausgerechnet die 8er nicht.
Abgesehen davon, wenn die 7er und die 9er+ funktionieren, warum dann ausgerechnet die 8er nicht.
Mit -r -mrelax zu Linken funktioniert bei keiner Complerversion. Evtl. ist das ein Arduino Problem, dass beim Bauen von Libs (Arduino macht ja alles mit Static Linbs) -r -mrelax (oder -r Wl,--relax) angegeben wurde.
Die Frage bleibt aber: Wer setzt das -r ? Das brauch man für normale, statische gelinkte Programme nämlich nicht.
...eine Möglichkeit das zu umgehen ist im Specs-File:
1 |
|
2 |
|
Hallo,
habe mit der 8er nochmal rumprobiert. Für den AVR128DB64 verwende ich den DxCore, also dessen Core Package. Hier kann ich mit dem 8er komischerweise nichts kompilieren. Warum auch immer.
Dann habe ich Programme mittels Arduino IDE für einen ATmega2560 (alles Arduino Standard) mit dem 8er kompilieren lassen. Hier funktioniert bisher alles. Also scheint es eine Einstellung vom DxCore zu sein, vermutlich, womit der 8er ein Problem hat. Der DxCore wird nur mit dem Arduino Standard avr-gcc 7.3.0 getestet und "ausgeliefert".
Dann habe ich ein Programm was für einen ATmega2560 kompiliert auf den AVRxDB umgezogen. Alle Hardwareabhängigkeiten natürlich entfernt. Kompiliert wieder nicht wegen "avr/bin/ld.exe: --relax and -r may not be used together". Also Core Package abhängig.
Wo das -r herkommen soll sehe ich jedoch nicht. Ich sehe:
1 |
|
also nur -mrelax und kein -r alleine.
Die 2 Zeilen von 18:07 Uhr habe ich im device-specs File "specs-avr128db64" wie folgt eingefügt, zeigt jedoch keine Wirkung. Gleiche Fehlermeldung.
1 |
|
2 |
|
3 |
|
4 |
|
5 |
|
6 |
|
7 |
|
8 |
|
9 |
|
10 |
|
11 |
|
12 |
|
13 |
|
14 |
|
15 |
|
16 |
|
17 |
|
18 |
|
19 |
|
20 |
|
21 |
|
22 |
|
23 |
|
Nochmal die Arduino typische platform.txt Datei angeschaut und durchsuchen lassen. Darin werden alle Parameter für die Kompilierung zusammengebaut. Es gibt kein einziges '-r' in der gesamten Datei, wenn dann '-mrelax', also genauso wie ich es in der vollständigen Ausgabe sehe.
Rudi Ratlos.
1 |
|
2 |
|
3 |
|
4 |
|
5 |
|
6 |
|
7 |
|
Das definiert die link_relax Spec 2x. Nimm die erste Definition raus und ersetze sie durch die zweite.
Das wirks aber nur, wenn -r angegeben wird: Die Spec bedeutet: Wenn kein -r angegeben ist /und/ wenn -mrelax angegeben ist, dann linke mit --relax.
Versuch mal -v und -Wl,-v anzugeben um rauszufunden, wo das -r herkommt.
Hallo,
Danke. Spec File korrigiert.
1 |
|
2 |
|
3 |
|
4 |
|
5 |
|
6 |
|
7 |
|
8 |
|
9 |
|
10 |
|
11 |
|
12 |
|
13 |
|
14 |
|
15 |
|
16 |
|
17 |
|
18 |
|
19 |
|
20 |
|
Immer noch Fehler. avr/bin/ld.exe: --relax and -r may not be used together
Mit Optionen siehe Anhängen. Ich kann beim besten Willen kein -r finden.
Ich kann beim besten Willen kein -r finden.
Weil der Build mit abgebrochen wurde mit:
1 |
|
Hallo,
das muss ein falscher Fehler sein. Die Wire.h ist vorhanden und ohne Option -v funktioniert das mit den Libs. Das ist eine Standard Lib von Arduino, die muss funktionieren. Ich verstehe das so, dass mit Option -v nur in den angezeigten 6 Pfaden gesucht wird. Ohne Option -v in mehr Pfaden.
Hallo,
ich mach das nochmal mit einem anderen Bsp. um Unklarheiten auszuräumen.
Hallo,
ohne bewusst von mir extra inkludierte Arduino Libs. Nur
1 |
|
2 |
|
3 |
|
Das Programm enthält nur direkte Register Programmierung.
Beitrag #7666433 wurde von einem Moderator gelöscht.
Beitrag #7666442 wurde von einem Moderator gelöscht.
Hallo,
ich schreibe morgen nochmal in Ruhe einen Text was ich soeben mit Microchip Studio getestet habe. Sorry.
Kleiner Wermutstropfen: die Kommandos im Container laufen als Benutzer root und deswegen gehört auch die erzeugte "main.elf" natürlich root.
Um die Userid nicht hardcoded ins Dockerfile zu schreiben kann man sie beim Aufruf von docker mitgeben:
1 |
|
damit gehören alle erzeugten Dateien dem aufrufenden User.
Michael
Hallo,
Ich verstehe das so, dass mit Option -v nur in den angezeigten 6 Pfaden gesucht wird. Ohne Option -v in mehr Pfaden.
Natürlich ist das wie es geschrieben steht Blödsinn. -v erzeugt nur die Debugausgaben unabhängig von allen anderen. Nur warum kommt die Fehlermeldung mit der nicht gefundenen Wire.h erst mit der Debugausgabe? Zudem der Fehler wie gesagt nicht sein kann. Der Fehler ist wirklich Blödsinn. Die Wire.h muss wie alles andere gefunden werden. Wenn die 8.5.0 Toolchain plötzlich keine fremden Libs mehr findet wäre das komischer als angenommen.
Ich habe mittlerweile 3 verschiedene Toolchains gebaut. a) avr-gcc-8.5.0_mingw32_binutils2.40_avrLibc2.1GitHub b) avr-gcc-8.5.0_mingw32_binutils2.42_avrLibc2.1GitHub c) avr-gcc-8.5.0_mingw32_binutils2.42_avrLibc2.2GitHub Die Unterschiede erkennt man im Namen. Letztere hat das geänderte Spec File für den AVR128DB64, wegen mrelax.
Ich verwende jetzt ein ganz simples Programm, siehe main.cpp und das Microchip Studio.
a) cannot find LINK_RELAX_SPEC: No such file or directory
b) kein Fehler, nur andere binutils Version
c) kein Fehler, andere avrLibC Version + Spec File Patch
Dann habe ich noch ein anderes Programm mit eigenen Libs mit Microchip Studio getestet. Beackert die USARTs. Der Lib Pfad ist in den Projekeinstellungen angegeben. Das kompiliert überraschenderweise mit allen 3 Varianten fehlerfrei.
Ich fasse einmal zusammen. Die 8er verhält sich anderes als Andere. Irgendwie zickig. Der Relax-Fehler ist Umgebungsabhängig und Programmabhängig.
LINK_RELAX_SPEC ist nur ein Macro in den Compiler QUELLEN. Im Specs-File steht natürlich nur der Wert des Macros.
1 |
|
2 |
|
Stattdessen
1 |
|
2 |
|
zu verwenden würde IMO aber nur einen Anwenderfehler verdecken. Ich sehe immer noch nicht, wo -r --relax herkommt.
Weder in a) noch in b) oder c) taucht "relax" auf.
Hallo Johann,
so wie es aussieht kann ich verschiedene Testbedingungen schaffen und komme immer auf unterschiedliche Ergebnisse. Es kristallisiert sich leider nicht die eine Toolchain der 8er heraus. Womit man dann ganz gezielt "arbeiten" könnte.
Die Option -r wird wohl niemand irgendwo angeben. Da bin ich mir ziemlich sicher. Die kommt scheinbar aus dem Nichts. ;-)
Aktuell kommen wir hier nicht weiter wie es aussieht. Wir lassen erstmal das Wochenende und Feiertag vergehen. Dann sehen wir vielleicht weiter. Ich wünsche dir erstmal ein ruhiges Wochenende. Haste dir verdient.
Die 8er verhält sich anderes als Andere. Irgendwie zickig.
Das habe ich auch schon festgestellt, siehe meine Anmerkung in Down-Under: https://www.eevblog.com/forum/testgear/$20-lcr-esr-transistor-checker-project/msg5495680/#msg5495680
Die 8er verhält sich anderes als Andere. Irgendwie zickig.
Das habe ich auch schon festgestellt, siehe meine Anmerkung in Down-Under: https://www.eevblog.com/forum/testgear/$20-lcr-esr-transistor-checker-project/msg5495680/#msg5495680
Gute Güte, warum macht Ihr so ein Ding aus so einem alten Compiler? Lasst ihn in Frieden sterben ...
Hallo Martin,
das ist Detailwissen wo ich nicht mitreden kann.
Hallo Johann,
ich habe mit der Arduino IDE und dem DxCore noch eins probiert. Ich habe die Option -mrelax entfernt, die in der platform.txt drin ist. Siehe da, es kompiliert. Das heißt die Fehlermeldung --relax / -r hängt mit der Option -mrelax zusammen. Damit wäre klar das nirgends eine einzelne Option -r gesetzt wird. Hilft das weiter? Du sollst dennoch dein Wochenende genießen. ;-)
Gute Güte, warum macht Ihr so ein Ding aus so einem alten Compiler? Lasst ihn in Frieden sterben ...
Der 8er baut halt kleinere Binaries als die folgenden, erst der 13er kam wieder in diese Dimensionen zurück. Und das zählt z.B. für den Transistortester, dessen Flash immer mehr aus allen Nähten platzt.
https://www.eevblog.com/forum/testgear/$20-lcr-esr-transistor-checker-project/msg5054215/#msg5054215
https://www.eevblog.com/forum/testgear/$20-lcr-esr-transistor-checker-project/msg5150607/#msg5150607
Außerdem ist selbst der 8er deutlich „moderner“ als das, was es bei Debian (incl. SID) gibt :(
Gute Güte, warum macht Ihr so ein Ding aus so einem alten Compiler? Lasst ihn in Frieden sterben ...
Der 8er baut halt kleinere Binaries als die folgenden, erst der 13er kam wieder in diese Dimensionen zurück. Und das zählt z.B. für den Transistortester, dessen Flash immer mehr aus allen Nähten platzt.
https://www.eevblog.com/forum/testgear/$20-lcr-esr-transistor-checker-project/msg5054215/#msg5054215
https://www.eevblog.com/forum/testgear/$20-lcr-esr-transistor-checker-project/msg5150607/#msg5150607
Außerdem ist selbst der 8er deutlich „moderner“ als das, was es bei Debian (incl. SID) gibt :(
Ja, klar, es gibt immer wieder alte Projekte, wo das dann durch immer mehr features zum Problem wird. Allerdings ist dieses Komponententesterprojekt auch für größere atmegas wie z.B. m1284. Ich habe mir das Projekt nicht genau angeschaut, aber da würde ich einfach daran gehen, einpaar Sachen als Compiletime-Option abschaltbar machen.
Allerdings: dieser Fehler im ISR-Vector ist schon krass bei 8.3.
Naja, Debian als Entwicklerplattform ist schon recht ... konservativ ;-)
Ich habe die Option -mrelax entfernt, die in der platform.txt drin ist. Siehe da, es kompiliert. Das heißt die Fehlermeldung --relax / -r hängt mit der Option -mrelax zusammen. Damit wäre klar das nirgends eine einzelne Option -r gesetzt wird.
Aber /irgendwo/ wird doch -r gesetzt? Oder ist das ein Linkler-Bug? Das -r kommt doch vermutlich von der Arduino IDE beim Bauen von Libs?
Hilft das weiter?
Nicht wirklich. Ich verstehe immer noch nicht ob das ein Bug in den Tools ist (und wie der zu fixen wäre), ein Bug in Arduino oder ein Anwenderfehler.
Die Option -r wird wohl niemand irgendwo angeben. Da bin ich mir ziemlich sicher. Die kommt scheinbar aus dem Nichts. ;-)
würde ja bedeuten, dass es ein Bug in den Tools ist, etwa beim Verarbeiten der Linker-Optionen oder in den LTO Specs.
Gute Güte, warum macht Ihr so ein Ding aus so einem alten Compiler?
Weil die v8 besser ist als alles, was danach kommt. Sie ist gut genut, dass ich meine eigene v8.5.1 maintaine, wo paar Probleme die erst später gefixt wurden rückportiert wurden, wie PR92606, PR101188. Und Probleme wie mit PR90706 und PR110093 hat man mit v8 eben nicht.
Weil die v8 besser ist als alles, was danach kommt.
Das kommt immer auf die Anforderungen an. Für C mag das ausreichen, für modernes C++ nicht.
Und Probleme wie mit PR90706 und PR110093 hat man mit v8 eben nicht.
PR90706 kann ich im GB CE nicht nachvollziehen für >8.5
Wenn man PR110093 als template-code schreibt, wird es optimal wie in 8.5
Hallo,
Ich habe die Option -mrelax entfernt, die in der platform.txt drin ist. Siehe da, es kompiliert. Das heißt die Fehlermeldung --relax / -r hängt mit der Option -mrelax zusammen. Damit wäre klar das nirgends eine einzelne Option -r gesetzt wird.
Aber /irgendwo/ wird doch -r gesetzt? Oder ist das ein Linkler-Bug? Das -r kommt doch vermutlich von der Arduino IDE beim Bauen von Libs?
Ich gebe mein Bestes den Ursprung zu finden. Was ich wohl sicher behaupten kann ist, dass es auch ein Problem mit der Option -v gibt. Egal für welchen Controller ich mit der Arduino IDE kompiliere. Ob für Standard ATmega2560 oder den ATmega4809. Beim ATmega4809 ist auch egal ob ich dafür das megaavr Arduino Core Package oder das MegaCoreX Core Package von mcudude verwende. Ist in allen Umgebungen die -v Option aktiv werden Libs nicht gefunden. Nehme ich die Option -v raus, kompiliert alles. Das kann ja eigentlich auch nicht sein. Entweder können sie gefunden werden oder nicht, völlig unabgängig der Option -v.
Hilft das weiter?
Nicht wirklich. Ich verstehe immer noch nicht ob das ein Bug in den Tools ist (und wie der zu fixen wäre), ein Bug in Arduino oder ein Anwenderfehler.
Die Option -r wird wohl niemand irgendwo angeben. Da bin ich mir ziemlich sicher. Die kommt scheinbar aus dem Nichts. ;-)
würde ja bedeuten, dass es ein Bug in den Tools ist, etwa beim Verarbeiten der Linker-Optionen oder in den LTO Specs.
Das Problem ist für mich auch noch zu vielfältig. Unter bestimmten Umständen findet er keine Libs. Könnte man behaupten das ist ein Arduino Problem. Auf der anderen Seite gibt es einen Umstand mit Microchip Studio wo der relax Fehler auftritt. Da ist nun weit und breit nichts von Arduino im Spiel. Für mein Gefühl sind da mehrere Probleme vorhanden.
Ich bau im Moment Toolchains mit allen avr-gcc 8 Versionen. Mal sehen ob das Problem ab einer bestimmten Version beginnt. Vielleicht kann man sich so dem Problem nähern.
Ansonsten, wenn ich nichts mehr dazu beitragen kann, außer vielleicht testen, könntest du dich vielleicht mit mcudude auf Entwickler Niveau unterhalten. Ihr müßtest euch ja kennen. Er verwendet Arduino und seinen MegaCoreX.
Das Einzigste was ich mache um andere Toolchains zu verwenden ist eine platform.local.txt erstellen und darin nur die Änderungen einzutragen. Alles andere steht in der platform.txt wie oben gezeigt und bleibt wie sie ist. Darin sehe ich keine außergewöhnlichen Optionen.
1 |
|
2 |
|
3 |
|
Das wird auch mcudude wissen wie das geht.
Ich teste nachher die Toolchains durch berichte.
behaupten kann ist, dass es auch ein Problem mit der Option -v gibt.
-v kann ein Problem sein wenn man die Ausgabe ovn avr-gcc selbst braucht, etwa mit -print-multi-directory oder --version. Da bringt das zusätzliche Geplapper von -v die Ausgabe durcheinander.
Wenn man XXX als YYY-code schreibt, wird es optimal wie in ZZZ
Es ist und bleibt aber ein Compilerproblem.
Wenn man seine Quellen verhunzen will und abhängig vom Compilerversion und -problem(ch)en macht, dann wird der Code ziemlich schnell unwartbar. Und um zu vewrifizieren, dass das Verhunzen wie gewünscht wirkt, muss man ständig das (Dis)assembly durchforsten.
Ich bevorzuge da die besseren Tools.
Wilhelm M. schrieb:
Wenn man XXX als YYY-code schreibt, wird es optimal wie in ZZZ
Es ist und bleibt aber ein Compilerproblem.
Klaro. Das war auch als Hinweis gedacht.
Wenn man seine Quellen verhunzen will und abhängig vom Compilerversion und -problem(ch)en macht, dann wird der Code ziemlich schnell unwartbar.
Wo ein solches Functionstemplate den Code verhunzt, solltest Du erklären. Die C++-Standardbib. verhunzt also den Code ...
Im übrigen bitte richtig zitieren.
Und um zu vewrifizieren, dass das Verhunzen wie gewünscht wirkt, muss man ständig das (Dis)assembly durchforsten.
Das glaubst Du doch selbst nicht.
behaupten kann ist, dass es auch ein Problem mit der Option -v gibt.
-v kann ein Problem sein wenn man die Ausgabe ovn avr-gcc selbst braucht, etwa mit -print-multi-directory oder --version. Da bringt das zusätzliche Geplapper von -v die Ausgabe durcheinander.
Hallo,
das lies mir keine Ruhe. Das liegt demnach wirklich mit der Arduino Umgebung zusammen. Egal welche Toolchain ich verwende, sobald ich die Option -v verwende bricht die Kompilierung ab wegen nicht gefundener Lib, egal welche. Gut, dann wäre wenigstens das geklärt. Danke.
Egal welche Toolchain ich verwende, sobald ich die Option -v verwende bricht die Kompilierung ab wegen nicht gefundener Lib, egal welche.
Ok, dann geht -v nicht um an den problematischen Linker-Aufruf zu kommen. Aber Arduino hat doch bestimmt einen adäquaten Ersatz, mit dem man die ausgeführten Befehle anzeigen lassen kann? In den Logs die bislang zu sehen waren wird das ja unterschlagen.
Evtl. besser mal in nem Arduino Forum nachfragen, wie man die Fehlerursache eingrenzen kann?
Hallo,
habe die Toolchains auch mit Microchip Studio getestet, mit dem gleichen Programm wie hier Beitrag "Re: GCC v14 Release"
Ich kann heute mit keiner Toolchain diesen Fehler provozieren. Der ist einfach weg. Device Spec File ist bei allen nicht gepatcht. a) cannot find LINK_RELAX_SPEC: No such file or directory
Damit ist die reine AVR bzw. Microchip Studio aus dem Rennen.
Jetzt bin ich wirklich mit meinem Latein am Ende wo die -r Option herkommen soll im Zusammenhang mit Arduino. Der Betrachtungszustand hat sich damit geändert. Man sieht die -r Option nirgends, könnte dennoch irgendwo vorhanden sein oder irgendwo ist Voodoo im Spiel. :-) Da muss ich bei dem avr-gcc 8 den Spec File Patch verwenden.
Ich würde sagen wollen das WE und Feiertag ist erstmal Ruhezustand. :-)
Grüße und bis später ...
PS: wegen -v und Arduino, da frage ich nach
cannot find LINK_RELAX_SPEC: No such file or directory
Da hast du irgendwo noch einen falschen Fehler reingebastelt.
Weil die v8 besser ist als alles, was danach kommt.
Bis zur 12.x bin ich bei Dir, aber was ist mit Ver. 13, wo siehst Du die Schwächen? Die 14 ist vielleicht noch zu neu, um sie mit den anderen zu vergleichen.
sobald ich die Option -v verwende bricht die Kompilierung ab wegen nicht gefundener Lib, egal welche.
Hier wäre es hilfreich, wenn zwischen /Library/ und /Headerdatei/ differenziert werden würde.
Denn das hast Du weiter oben schon durcheinandergebracht:
das muss ein falscher Fehler sein. Die Wire.h ist vorhanden und ohne Option -v funktioniert das mit den Libs. Das ist eine Standard Lib von Arduino, die muss funktionieren.
"wire.h" ist keine Library. Das ist eine Headerdatei, oder eine Include-Datei (wie auch immer man sie nennen will), aber eben keine Library. Eine Library hieße im Falle des gcc "libwire.a" -- und wird beim Programmbau an einer völlig anderen Stelle verwendet als beim simplen Compilieren einzelener Sourcefiles. Mit Libraries beschäftigt sich der Linker.
Ja, in "C++-Sprech" und vor allem in "Arduino-Sprech" werden gerne Include-Dateien auch als "Library" bezeichnet, aber /funktional/ aus Sicht eines Toolchainbauers ist das etwas komplett unterschiedliches.
Um auf Dein Problem mit -v zurückzukommen: Das versaut Dir aus irgendeinem Grund den Include-Pfad.
Hast Du Dir mal das von CMake erzeugte tatsächliche Makefile angesehen?
Ja, in "C++-Sprech" und vor allem in "Arduino-Sprech" werden gerne Include-Dateien auch als "Library" bezeichnet
Nur letzteres. C++ kennt allerdings header-only- „Libraries“, für die sich da keine andere Bezeichnung gefunden hat.
Oliver
Hallo,
ruhig sitzen konnte ich nun doch nicht. Kleines Update. Das nicht finden einer Lib mit Option -v betrifft nicht allein die 8er Toolchain. Das betrifft alles was mit der Arduino IDE 1.8.19 zu tun hat, egal welche Toolchain, auch die Default Toolchain der IDE. Man muss nur eine Lib zusätzlich inkludieren und die Option -v mitgeben und die Kompilierung bricht ab. Den -relax Fehler betrifft aber nur die 8er Toolchain. Muss man ganz schön aufpassen das getrennt zu halten.
Ein Arduino Forum User konnte das bei sich bestäigen und gab mir den Tipp das Flag -v nicht für .cpp sondern für .c Files zu setzen. Damit läuft die Kompilierung durch, auch mit -Wl,-v. In der Debugausgabe sehe ich nun mehrfach die gesetzte Option --mlink-relax. Ist das das Problem?
Nur letzteres. C++ kennt allerdings header-only- „Libraries“, für die sich da keine andere Bezeichnung gefunden hat.
Ja, richtig, nur eine sehr unglückliche Namenswahl, wenn man Linkerfehler und Fehler des Compilers auseinanderhalten will.
Man muss nur eine Lib zusätzlich inkludieren und die Option -v mitgeben und die Kompilierung bricht ab.
Seufz. Worauf habe ich gerade herumgeritten, und warum?
Man muss nur eine Lib zusätzlich inkludieren und die Option -v mitgeben und die Kompilierung bricht ab.
Seufz. Worauf habe ich gerade herumgeritten, und warum?
Weil jeder außer du weiß worum es geht. Ein Headerfile ist Bestandteil einer Lib. Ob die nun kompiliert ist oder nicht. Mit Nebenkriegsschauplätzen egal welcher Art gebe ich mich hier nicht ab. Das stört hier nur den Threadverlauf.
Folgender Work-Around für v8 sollte gehen:
Statt -mrelax nimmt man -Wl,--relax -Wa,--mlink-relax
Was auch geht ist -g wegzulassen.
Ist also kein Arduino Problem sondern ein Bug im Compiler (lto-wrapper).
Hätte mir eigentlich schon auffallen können, aber ich verwende normal nie -g.
Weil jeder außer du weiß worum es geht. Ein Headerfile ist Bestandteil einer Lib. Ob die nun kompiliert ist oder nicht.
Das ist Dummquatsch, denn es macht einen ganz erheblichen Unterschied aus, ob der Compiler irgendwas mit einer Headerdatei macht oder ob der Linker (das ist ein anderes Programm!) etwas mit einer Library macht.
Und wenn hier darüber diskutiert wird, daß irgendeine Option dafür sorgt, daß "Libs" nicht gefunden werden, dann ist dieser Unterschied verdammt wichtig.
Du argumentierst auf der Ebene, daß es nicht wichtig ist, ob das Auto nicht fährt, weil der Tank leer ist oder der Zündschlüssel fehlt.
Du argumentierst auf der Ebene, daß es nicht wichtig ist, ob das Auto nicht fährt, weil der Tank leer ist oder der Zündschlüssel fehlt.
Nein. Ich argumentiere das der Motor keinen Sprit bekommt. Das ist der offensichtliche Fehler. Völlig egal ob der Tank leer oder die Benzinpumpe defekt ist. Hat nichts mit dem Zündschlüssel zu tun, was eine völlig andere Fehlerursache wäre. Weil ohne Schlüssel würdest du erst gar nicht ins Auto kommen. ;-) Vergiss dein Thema nicht, können wir immer noch ganz am Ende klären. Aber nicht jetzt.
Das ist Dummquatsch
Hüstel.....
Weshalb ist eine Headerdatei keine Library? Library darf und kann in unterschiedlicher Form vorliegen. Z.B Objektcode aber auch Quelltext wie in einer Headerdatei.
Diejenigen, die noch etwas Nachhilfe brauchen, vielleicht hier auch nochmal nachlesen: https://de.m.wikipedia.org/wiki/Programmbibliothek
Eigentlich ist das hier OT.
Folgender Work-Around für v8 sollte gehen:
Statt -mrelax nimmt man -Wl,--relax -Wa,--mlink-relax
Was auch geht ist -g wegzulassen.
Ist also kein Arduino Problem sondern ein Bug im Compiler (lto-wrapper).
Hätte mir eigentlich schon auffallen können, aber ich verwende normal nie -g.
Hallo Johann,
du bist der Beste. :-)
Habe beide Optionen ausprobiert. Was soll ich sagen. Der relax Fehler ist weg. Was bleibt ist mit Option -v mit Arduino das er die Lib nicht findet.
Ähm, ich meine er das Headerfile nicht findet. Bevor Harald noch Bluthochdruck bekommt. :-)
Ich weiß jetzt nicht, ob wir das Problem weiter verfolgen? Oder ob wir zum noch ungeklärten Problem übergeben avr-gcc 14 und fehlendem mrodata-in-ram Effekt?
Eigentlich ist das hier OT.
Danke. Das ist meine Rede. Das Thema kann gern näher erörtert werden. Aber hier in dem Thread gibt es wichtigere Dinge als diesen Nebenkriegsschauplatz. Das hat schon viel zu viel Platz eingenommen. Harald kann dazu gern einen eigenen Thread eröffnen, worin es erschöpfend geklärt werden kann.
Oder ob wir zum noch ungeklärten Problem übergeben avr-gcc 14 und fehlendem mrodata-in-ram Effekt?
Dann schau Dir erstmal meinen Beitrag oben an:
Ich weiß jetzt nicht, ob wir das Problem weiter verfolgen?
Das Problem mit der Fehlermeldung vom Linker trat auf, als du Benchmarks für verschiedene avr-gcc Versionen gemacht hast.
Dieses Problem kann man mit -g0 (bzw. Option -g entfernen) umschiffen. Alternativ gibt's diesen v8 Fork: https://github.com/sprintersb/avr-gcc-8
avr-gcc 14 und fehlendem mrodata-in-ram Effekt?
Der Vergleich von -mno-rodata-in-ram (default) mit -mrodata-in-ram sollte Unterschiede im RAM-Verbrauch zeigen, wenn
-
Device ist AVR128* oder AVR64*, und
-
Es befinden sich Daten in .rodata wie zum Beispiel vtables, und
-
Es wird avr-gcc v14+ mit Binutils v2.42+ verwendet,
was bei dir ja alles zutrifft.
Übrigens gibt es noch nen Bug in Binutils: avr-objdump -P mem-usage berücksichtigt keine Daten in Output Section .rodata: https://sourceware.org/PR31687
avr-size hingegen arbeitet korrekt, d.h. .rodata wird in der Größe von text berücksichtigt.
Was bleibt ist mit Option -v mit Arduino das er die Lib nicht findet.
Das muss ein Arduino-Ding sein.
Was bleibt ist mit Option -v mit Arduino das er die Lib nicht findet.
Das muss ein Arduino-Ding sein.
...spielt aber keine Rolle mehr, weil das -v nur dazu da war, den bösen Aufruf zu finden, der zum Fehler führt. Und da ist ja jetzt klar, das es ein Problem im LTO Wrapper war.
Hallo Johann,
habe mich nochmal mit avr-gcc 14.1 und rodata befasst und vorher paar avr-gcc Vergleiche angestellt, siehe .pdf
Ih denke deine letzte Aussage zu verstehen. Nur wenn ich meine Werte betrachte bin ich immer noch der Meinung das entweder der Schalter -mrodata-in-ram nicht funktioniert oder gar avr-size.exe fehlerhaft ist.
Habe mich durch die Kommandozeile gequält. Die Werte der beiden Ausgaben sind untereinander im Vergleich ähnlich zu den Werten die das Microchip Studio ermittelt. Mit dem Schalter -mrodata-in-ram wird nie das RAM belegt. Soll das wirklich so sein? Ich hatte ähnliche Werte wie beim avr-gcc-13.2 erwartet. Wohin ist das Array verschwunden?
Die Datei main.cpp ist das letzte Testprogramm alias "rodataTest_avr-gcc-14" im .pdf
1 |
|
2 |
|
3 |
|
4 |
|
5 |
|
6 |
|
7 |
|
8 |
|
9 |
|
10 |
|
11 |
|
12 |
|
13 |
|
14 |
|
15 |
|
16 |
|
17 |
|
18 |
|
19 |
|
20 |
|
21 |
|
22 |
|
23 |
|
24 |
|
25 |
|
26 |
|
1 |
|
2 |
|
3 |
|
4 |
|
5 |
|
6 |
|
7 |
|
8 |
|
9 |
|
10 |
|
11 |
|
12 |
|
13 |
|
14 |
|
15 |
|
16 |
|
17 |
|
18 |
|
19 |
|
20 |
|
21 |
|
22 |
|
23 |
|
24 |
|
25 |
|
26 |
|
Du linkst doch nicht etwa mit -c ?
Hallo,
Nicht das ich wüsste. Microchip Studio hat Defaults wie -ffunction-sections usw. und ich stelle zusätzlich für den Compiler "-Os -std=c++20 -flto -v" ein. Das Projekt ist als Cpp Projekt eingerichtet.
Hallo Johann,
habe es versucht auf der Kommandozeile zu kompilieren. Von Microchip Studio abgeschaut und bewusst Option -c rausgenommen. Scheint zu funktionieren. Ohne -mrodata-in-ram, also default, stimmt das mit Microchip Studio überein. Mit -mrodata-in-ram sehe ich eine Reaktion das RAM belegt wird. Soweit so gut. :-)
Jetzt frage ich mich natürlich warum Microchip Studio die Option -c setzt? Ist Microchip Studio schon zu alt dafür?
OHNE Flag -mrodata-in-ram kompiliert avr-size.exe -d -A main.elf
1 |
|
2 |
|
3 |
|
4 |
|
5 |
|
6 |
|
7 |
|
8 |
|
9 |
|
10 |
|
11 |
|
12 |
|
13 |
|
14 |
|
MIT Flag -mrodata-in-ram kompiliert avr-size.exe -d -A main.elf
1 |
|
2 |
|
3 |
|
4 |
|
5 |
|
6 |
|
7 |
|
8 |
|
9 |
|
10 |
|
11 |
|
12 |
|
13 |
|
Beitrag #7668952 wurde von einem Moderator gelöscht.
Nur wenn ich meine Werte betrachte bin ich immer noch der Meinung das entweder der Schalter -mrodata-in-ram nicht funktioniert oder gar avr-size.exe fehlerhaft ist.
Du hast in Deinen Compiler-Optionen "-c" drin. D.h. es wird kein executable .elf erzeugt, sondern nur eine Object-Datei (die Du wahrscheinlich fälschlicherweise in die Datei main.elf schreibst - statt main.o).
Daher siehst Du auch ein .text segment der Größe 0. Das sollte Dir schon mal auffallen ...
warum Microchip Studio die Option -c setzt?
Weil das die übliche Vorgehensweise ist, ein C/C++ Projekt zu erzeugen:
Zunächst werden alle Module mit -c zu Object-Dateien *.o übersetzt. Hier endet der Vorgang nach dem Aufruf des Assemblers.
Dann werden alle erzeugten *.o Dateien zum *.elf Executable zusammengelinkt.
Wenn du sowas siehst wie:
1 |
|
2 |
|
3 |
|
4 |
|
5 |
|
6 |
|
dann handelt es sich dabei um ein NICHT GELINKTES Objectfile, egal welcher Name der Datei verpasst wurde. Im finalen ELF haben LTO Sections nämlich nix mehr zu suchen. Und dass alle Code+Data Sections leer sind, ist für ein fertiges ELF auch nicht der Fall.
OHNE Flag -mrodata-in-ram kompiliert avr-size.exe -d -A main.elf
1 |
|
2 |
|
3 |
|
4 |
|
MIT Flag -mrodata-in-ram kompiliert
1 |
|
2 |
|
3 |
|
Das ist plausibel:
Mit -mrodata-in-ram sind die 278 Bytes an .rodata im RAM, ansonsten im Flash.
Ohne .rodata ist .text um 26 Bytes länger, was der Größe von __do_copy_data entspricht. Dieses wird mit .rodata nicht gebraucht, weil .data im Beispiel leer ist.
Außerdem sieht man daran, dass im .rodata Fall nicht gegen __do_flmap_init gelinkt wurde, das 18 Bytes groß ist und erst in AVR-LibC v2.2 enthalten ist. (Dann wäre .text nur 8 Bytes größer, nicht 26 Bytes).
Hallo,
diesmal hatte Wilhelm den richtigen Riecher. Danke Johann mal wieder für die Erklärung. Ich denke ich habe meinen Fehler erkannt. Ich hatte versucht die Kommandozeile nachzubauen und mit '-c' ein main.elf erzeugt statt main.o. Wenn ich die Option '-c' richtig verstehe wird mit '-c' nur kompiliert aber nicht gelinkt. Ohne '-c' wird kompiliert und gelinkt weshalb das gestern am Ende mit main.elf als Ausgabedatei funktionierte.
Noch eine Frage. Man verwendet doch eigentlich avr-g++.exe zum kompilieren. Ich habe gestern die Kommandozeile mit avr-gcc.exe begonnen. Scheint dennoch zu funktionieren. Was macht das für einen Unterschied? Oder ruft avr-g++.exe sowieso avr-gcc.exe auf?
Microchip Studio: - GCC GCC 14.1.0-x64 - erzeugt mit zak script
Microchip Studio7 compiliert mit NATIVE Compiler und installierten Device-Packs die modernen AVR8-uC Dx, Ex,..
Microchip Studio7 compiliert mit ZAK-AVR-GCC 14.1.0-x64-windows und installierten Device-Packs die modernen AVR8-uC Dx, Ex,.. NICHT.
Im Compiler-Aufruf FEHLT -B "$(PackRepoDir)..", obwohl in |Project|AVR/GNU|common| der Eintrag -B "$(PackRepoDir).." vorhanden ist.
..\device-specs\specs-avr128db48 *cpp: .. -D__AVR_DEV_LIB_NAME__=avr128db48 ist deshalb NICHT definiert.
resultierende Fehlermeldungen :
- #warning "device type not defined" [-Wcpp]
C:\Atmel-Toolchain\AVR8\avr-gcc-14.1.0-x64-windows\avr\include\avr\io.h 633 - cannot find crtavr128db48.o: No such file or directory
Workaround: Nachtragen von B "$(PackRepoDir).. in |Compiler|Miscellaneus| UND in |Linker |Miscellaneus|
Weshalb -B "$(PackRepoDir).." mit avr-gcc-14.1.0 fehlt weiss ich nicht.
Man verwendet doch eigentlich avr-g++.exe zum kompilieren. Ich habe gestern die Kommandozeile mit avr-gcc.exe begonnen. Scheint dennoch zu funktionieren. Was macht das für einen Unterschied? Oder ruft avr-g++.exe sowieso avr-gcc.exe auf?
Nein. avr-gcc und avr-g++ rufen Sub-Programme auf anhand der übergebeen Dateinamen und Optionen. Aufgerufene Programme sind zum Beispiel C-Compiler cc1, C++ Compiler cc1plus, LTO Compiler lto1, oder Assembler as.
Falls die Sprache nicht mit -x <lang> explizit angegeben wurde, werden folgende Datei Extensions als C++ compiliert: .cc, .cpp, .c++, .cxx, .C, .CPP, .cp. Als C wird .c compiliert, und als Assembler+C-Präprozessor wird .S und .sx behandelt.
Unterschied zwischen avr-gcc und avr-g++ ist bei den Optionen (Libs), die dem Linker mitgegeben werden, aber da es keine C++ Libs gibt, macht das kein Unterschied.
Die aufgerufenen Programme kann man mit -v anzeigen lassen, wobei die angezeigten Programme ihrerseits wieder andere Programme aufrufen können, etwa bei LTO Builds. Allerdings zeigt -v noch mehr Informationen an, etwa verwendete Include-Pfade.
Ein einfaches
1 |
|
etwa zeigt folgende Programmaufrufe:
1 |
|
2 |
|
3 |
|
4 |
|
5 |
|
6 |
|
7 |
|
8 |
|
Wobei
1 |
|
2 |
|
3 |
|
Der erste Assembler-Aufruf übersetzt lediglich LTO Bytecode von ASCII nach Binär, weil der C-Compiler nur LTO-Bytecode erzeugt. Der LTO-Code wird erst später von lto1 zum eigentlichen Assembler-Code compiliert, der vom 2ten Assembler-Aufruf assembliert wird.
Hallo Johann,
Danke wieder. Ich weiß schon warum ich das einer IDE überlasse. Spätestens wenn zusätzliche Libs dazu kommen wird es schnell kompliziert. Ich werde mich damit nochmal mit einfachen Bsp. näher befassen müssen.
Ich weiß schon warum ich das einer IDE überlasse. Spätestens wenn zusätzliche Libs dazu kommen wird es schnell kompliziert.
Ich denke, Du solltest Dir ein einfaches Makefile schreiben. Denn dort hast Du alles direkt übersichtlich an einer Stelle und kannst Dir die Aufrufe der Tools auch direkt ansehen.
Hallo,
Ich musste beim avr-gcc 14.1.0 für Microchip Studio diesmal nicht wie sonst fehlende Dateien ergänzen. Es ist alles enthalten. Fremde/meine Toolchains verweisen immer auf das erste \bin Verzeichnis der Toolchain.
Hast du in Microchip Studio die Device Packs installiert? Tools > Device Pack Manager
Verwendest du zum Toolchain bauen die aktuellen binutils 2.42?
Hallo Veit,
es ist alles aktuell und funktioniert auch.
mit -B "$(PackRepoDir)\atmel\AVR-Dx_DFP\1.10.114\gcc\dev\avr128db48" werden die device-spezifischen Dateien ins Projekt eingefügt.
Das funktioniert bei Toolchain="NATIVE" auch out of the box. Anders bei Toolchain="avr-gcc-14.1.0-x64-windows". Da fehlt der entsprechende Eintrag im Makefile, obwohl -B"$(PackRepoDir)\atmel\AVR-Dx_DFP\1.10.114\gcc\dev\avr128db48" unter |Toolchain|AVR/GNU Common|General| automatisch korrekt eingetragen wird.
Workaround siehe oben. Patch weiss ich nicht. Makefile wird immer neu generiert.
Angehängte Dateien:
-
Makefile-comparison.jpg
(230 KB)
Hallo,
wie hast du die Toolchain eingebunden? Der schnellste Weg ist irgendein Projekt öffnen. Projekt > Properties > Advanced > Flavour > Add Flavour Name ausdenken und Pfad inkl. \bin angeben. Danach steht es alle Projekten zur Verfügung.
Angehängte Dateien:
-
Screenshot.png
(84 KB)
Hallo,
ich habe eine Vermutung. Die AVR-Dx Device Pack Version 1.10.114 wird es nicht mehr geben. Wenn das Zak Script das live runterladen möchte, könnte das übersprungen werden und fehlt am Ende. Aktuell ist 2.5.294. http://packs.download.atmel.com/ Sieht man auch im Device Pack Manager.
Hallo,
habe mich aufs Linux Eis bewegt. :-) Dabei befinde ich mich in einem Ordner worin die Toolchain direkt mit ihren 6 Unterordner ist und meine main.cpp liegt.
1 |
|
2 |
|
3 |
|
4 |
|
Mit den Aufrufen sollte doch als Basis alles stimmen? Das Ergebnis von avr-size sieht stimmig aus. Warum baut man sich am Ende ein makefile und kein Bash File? Was ist das besondere am makefile was ein Bashfile nicht kann?
Hallo,
habe mich aufs Linux Eis bewegt. :-)
Na prima, da ist alles einfacher. Schön, dass Du meiner Empfehlung gefolgt bist ;-)
Dabei befinde ich mich in einem Ordner worin die Toolchain direkt mit ihren 6 Unterordner ist und meine main.cpp liegt.
1 |
|
2 |
|
3 |
|
4 |
|
5 |
|
6 |
|
7 |
|
Mit den Aufrufen sollte doch als Basis alles stimmen?
Du brauchst für dieses einfache Programm aus nur einer Quelldatei keine zwei Schritte für Compilation und Linken. Geht in einem Aufruf des Frontends.
Das Ergebnis von avr-size sieht stimmig aus.
Perfekt. Hast Du beide Varianten getestet?
Warum baut man sich am Ende ein makefile und kein Bash File? Was ist das besondere am makefile was ein Bashfile nicht kann?
Wenn es größere Projekt sind, wir nur das gebaut, was tatsächlich sich geändert hat. Make ist ein regelbasiertes tool - es lohnt sich, sich damit bzw. anderen build-tools auseinander zu setzen.
Selber kompilieren habe ich probiert, er findet aber 3 Libraries nicht.
Am einfachste geht das, indem man GCC die Libs mitgenerieren lässt.
Dazu führt man VOR configure ein
1 |
|
im GCC Quellverzeichnis aus.
Das lädt die Quellen der benötigten Host-Libs (GMP, MPFR, MPC, ISL) ins GCC Quellverzeichnis. Mit GCC configure und make werden die Libs dann automatisch mitgeneriert, unabhängig von im System installierten oder eben nicht-installierten Libs.
Der GCC Build dauert dann zwar etwas länger, aber dafür hat man allen GCC-Abhängigkeitsärger vom Hals.
Vom Zak habe ich vor längerem schon Mal eine neuere Version probiert. [...] Dem Compiler fehlte die passende glibc.
avr-gcc verwendet keine glibc sondern AVR-LibC als Target LibC.
Falls die entsprechende Version einer Host glibc fehlt, da kann ich leider nicht weiterhelfen. Aber auf einem Linux-System ist avr-gcc ja flott generiert.
1 |
|
Mit -flto zu compilieren bring nix, wenn man nicht auch mit -flto linkt. Außerdem hat man gerne -mrelax als Compile- und Linkoption, und linkt mit -Wl,--gc-sections (was dann compile mit -fdata-sections -ffunction-sections wünschenswert macht).
1 |
|
Das Programm sollte mit avr-gcc v14 crashen, weil Output Section .rodata fehlt, siehe https://gcc.gnu.org/gcc-14/changes.html#avr
Das Ergebnis von avr-size sieht stimmig aus.
Das stimmt aber nicht mir deinem HEX überein.
Warum baut man sich am Ende ein makefile und kein Bash File?
Weil Make keine Skriptsprache ist, sondern es beschreibt Abhängigkeiten von Dateien, und wann und wie (Binär)Dateien neu generiert werden müssen.
Wenn man z.B. ein großes Projekt hat mit zig Quellen, dann würde ein Bash Script immer alles neu generieren auch wenn man nur eine einzige C/C++ Quelle geändert hat.
Georg P. schrieb:
Vom Zak habe ich vor längerem schon Mal eine neuere Version probiert. [...] Dem Compiler fehlte die passende glibc.
Aktuelles zak script verwenden. AFAIR fehlt den älteren das libmpfr-dev
script: https://blog.zakkemble.net/avr-gcc-builds/
modifizierte avr-libc: https://github.com/ZakKemble/avr-libc3
Quellen anpassen:
NAME_BINUTILS="binutils-${VER_BINUTILS:-2.42}"
NAME_GCC="gcc-${VER_GCC:-14.1.0}"
NAME_GDB="gdb-${VER_GDB:-14.2}"
NAME_GMP="gmp-6.3.0"
NAME_MPFR="mpfr-4.2.1"
NAME_LIBC="avr-libc3.git"
COMMIT_LIBC="d09c2a61764aced3274b6dde4399e11b0aee4a87"
@Veit
In meinen Augen ist das ein Studio7-Bug beim generieren des Makefiles.
Die All-Options Felder von Compiler und Linker zeigen den -B "pfad", im Makefile fehlt er jedoch.
Wenn der -B "pfad" händisch im Compiler- und im Linker-Feld eingetragen wird, dann wird alles korrekt eingebunden.
@Georg P.
Nachtrag: Zielverzeichnis ändern. Weg von /root
. Output locations for built toolchains
. target dir - modify to keep results
BASE=${BASE:-/media/ab/Linux-HDD/avr-toolchain__/}
Georg P. schrieb:
Vom Zak habe ich vor längerem schon Mal eine neuere Version probiert. [...] Dem Compiler fehlte die passende glibc. Aktuelles zak script verwenden. AFAIR fehlt den älteren das libmpfr-dev
Hat aber nix mit glibc zu tun?
modifizierte avr-libc: https://github.com/ZakKemble/avr-libc3
Veraltet. Besser HEAD der originalen AVR-LibC verwenden.
Quellen anpassen: NAME_GMP="gmp-6.3.0" NAME_MPFR="mpfr-4.2.1"
Braucht man nicht wenn wie oben beschrieben die Host-Libs gleich mitgeneriert werden.
@Veit
In meinen Augen ist das ein Studio7-Bug beim generieren des Makefiles.
Ich denke nicht.
Hat aber nix mit glibc zu tun?
Die Windows Toolchain wird nicht korrekt erstellt, wenn was mit libmpfr-dev falsch läuft..
Braucht man nicht wenn wie oben beschrieben die Host-Libs gleich mitgeneriert werden.
Deine Bemerkungen helfen nur jenen. die dieses Toolchain-Geschäft schon beherrschen. Ich brauche einfach nur ein Script das ohne Fehler durchläuft. Das zak-skript tut genau das.
Ich schaue mir gerne ein funktionierendes Script von dir mit den oben beschriebenen Eigenschaften an, das dann auch die neuesten Libs enthält. Ich werde nie mit den Hinweisen von GNU und deinen Insider-Tips ein eigenes funktionierendes Script schreiben können.
Hier sind nicht alle Compilerentwickler oder Hochschulprofessoren. Die Mehrheit sucht ein brauchbares Werkzeug. AtmelStudio war ein Schritt in diese Richtung und mit aktuellem c++20 für mich immer noch interessant.
@Veit: ich denke schon.
Hallo,
gut, Vorteil von make verstanden, spart erneute Kompilezeit. Mal sehen ob ich eine Blink Programm kompiliert bekomme was am Ende auch praktisch funktioniert. Nur den Einwand mit "output section .rodata" verstehe ich nicht. Das muss ich selbst doch nicht angeben?
Nur den Einwand mit "output section .rodata" verstehe ich nicht. Das muss ich selbst doch nicht angeben?
Ausprobieren :-)
Bzw. warum gibst du .data an in
1 |
|
wenn man es nicht angeben muss?
Hallo,
das hatte ich wo gelesen. ;-) Wenn ich alle Optionen selbst setzen muss erschlägt es mich. Ich hoffe das zu ändern.
Die Windows Toolchain wird nicht korrekt erstellt, wenn was mit libmpfr-dev falsch läuft..
Gut, ist jetzt nicht so überrachend. Wenn was falsch läuft, funktioniert es nicht.
Es ist nun mal eben nicht ganz so einfach ein Cross Build der Host-Libs zu machen; aber wenn du auf diesem holprigen Weg unterwegs sein magst, wird dich hier niemand aufhalten.
Wie's einfacher geht hab ich ja erklärt.
Braucht man nicht wenn wie oben beschrieben die Host-Libs gleich mitgeneriert werden.
Deine Bemerkungen helfen nur jenen. die dieses Toolchain-Geschäft schon beherrschen.
Man muss eben vor configure ein bestimmtes Kommando ausführen. Mehr nicht. Zu erklären, wie man bestimmte Kommantos ausführt würde jetzt uuch zu weit führen.
Ich brauche einfach nur ein Script das ohne Fehler durchläuft. Das zak-skript tut genau das.
Dann ist ja alles gut.
Wenn ich alle Optionen selbst setzen muss erschlägt es mich.
Wenn du avrdude verwendest: Der kann auch ELF Dateien flashen; es braucht also überhaupt kein HEX File. Den alten Zopf kannst du also getrost abschneiden :-)
@Veit: ich denke schon.
Meine Empfehlung. Bau in das Zak Script -x und -e ein und schau wann es abbricht/stoppt. Wenn du dir ein Bauscript selbst bauen möchtest wäre es besser dafür einen eigenen Thread zu eröffnen. Bin mir sicher das auch du dabei Hilfe bekommst. Als Basis verwende ich Ubuntu 22.04LTS in einer VM und bereite es vor mit
1 |
|
2 |
|
3 |
|
4 |
|
5 |
|
6 |
|
7 |
|
8 |
|
9 |
|
10 |
|
@ Johann: alles klar :-)
Die Windows Toolchain wird nicht korrekt erstellt, wenn was mit libmpfr-dev falsch läuft..
Hab mir Zak's Skript mal angeschaut. Für die GCC-Libs wird bereits download_prerequisites verwendet; da gibt's also keine Probleme mit GMP, MPFR etc.
MPFR wird jedoch für GDB gebraucht. Wenn kein GDB benötigt wird, sollte also BUILD_GDB=0 das Problem vermeiden. (Ob es einen zu GCC verglichbaren Mechanismus für die GDB Host-Libs gibt hab ich mir noch nicht angeschaut:)
Inzwischen wurde auch v13.3 released.
Der einzig nennenswerte Unterschied zu v13.2 (aus AVR-Sicht) ist, dass mehr Devices unterstützt werden, nämlich alle die auch v14.1 unterstützt.
Hallo,
diese schon wichtige Info fehlt leider im "Change" Text.
Was unterscheidet überhaupt den avr-gcc-13 vom avr-gcc-14 konkret? Abgesehen vom rodata Flash Feature. Was macht er im Untergrund anders bzw. besser?
Was unterscheidet überhaupt den avr-gcc-13 vom avr-gcc-14 konkret?
https://en.cppreference.com/w/cpp/compiler_support
Etwas nettes habe ich schon entdeckt ...
Hallo,
dort werden Sprachfeatures aufgelistet. Das meinte ich nicht. Das "rodata Flash" ist ja kein Sprachfeature. Das wurde speziell für den AVR eingebaut. Ich meinte die Frage so, was er intern vielleicht anders macht. Irgendwelche neuen Optimierungen. Ich meine wenn alles gleich bleiben würde, dann würde ich Laienhaft behaupten, dann dürfte die erzeugte Codegröße nicht atmen. Da sie atmet müssen ja intern immer irgendwelche Änderungen stattfinden. Vielleicht kann da jemand aus dem Nähkästchen plaudern.
Hallo,
noch eine Frage zum avr-gcc 13.3. In "Change" wird AVR nicht erwähnt. Bedeutet das, dass die Patches PR105532 und PR109476 nicht im 13.3 enthalten sind? Gibt es ggf. noch weitere Patches die man besser einbauen sollte?
diese schon wichtige Info fehlt leider im "Change" Text.
Rückportiert werden eigentlich nur relevante Bugfixes und Typos in der Dokumentation. Neue Devices gehören nicht dazu; wurden aber rückportiert weil als unkritisch erachtet.
Solche Backports führen aber mitunter zu Überrachungen beim Anwender. Wenn zum Beispiel Device-Support vom aktuellen Entwicklungszweig zu v13.3 und v12.4 rückportiert wird, dann wird ein Anwender, der von v12.4 auf v13.2 upgraded feststellen, dass bestimmte Devices "verschwunden" sind. Das passiert weil immer mehrere GCC Major Versionen unterstützt werden, und v13.2 älter ist als zum Beispiel v12.4.
Was unterscheidet überhaupt den avr-gcc-13 vom avr-gcc-14 konkret?
Allein in 2024 gab es bis zur v14 Release Anfang Mai über 50 Commits, das willste nicht alles in den Release-Notes sehen. Relevante Änderungen sind .rodata-in-Flash für AVR64 und AVR128 Devices und ein neuer Optimierungs-Pass für Reduced Tiny.
Ob dieser Pass wirklich wichtig ist kann ich nicht beurteilen; viele Entwickler programmieren die Dinger vermutlich in Assembler. Was aber evtl. auch daran liegt, dass der Code vom Compiler zu mies ist / war. Die Dinger in C/C++ zu programmieren ist bei 4k Flash wie beim ATtiny40 ja auch nicht abwegeg.
Für Reduced Tiny wird dann der Support in der AVR-LibC auch etwas besser (pgm_read_xxx und string_P Funktionsn).
Das "rodata Flash" ist ja kein Sprachfeature. Das wurde speziell für den AVR eingebaut. [...] Irgendwelche neuen Optimierungen.
Wie gesagt bessere indirekte RAM-Zugriffe bei Reduced Tiny (PR114100)
eine Frage zum avr-gcc 13.3. In "Change" wird AVR nicht erwähnt.
Die Release Notes beziehen sich auf eine neue Major Release, also seit v5 die erste Zahl in der Versionsnummer.
Bedeutet das, dass die Patches PR105532 und PR109476 nicht im 13.3 enthalten sind?
Du meinst vermutlich PR105523. Der wurde rückportiert.
PR109476 wurde nicht rückportiert weil es nur eine Optimierung ist.
Gibt es ggf. noch weitere Patches die man besser einbauen sollte?
Da fällt mir nur PR101188 ein, der in v14 gefixt ist (und auch in der oben gelinkten v8.5.1), aber noch nicht auf v13 portiert wurde, vermutlich weil Jeff noch keine Zeit dafür hatte.
Hallo,
die Infos muss man erstmal verdauen. Vielen Dank.
Du meinst vermutlich PR105523
Ja, meinerseits ein Zahlendreher. Im Patch steht PR105523 drin, was damit übereinstimmt.
Ich fasse einmal zusammen. PR105523 ... für avr-gcc 13.2.0 noch notwendig " -- " ... im avr-gcc 13.3.0 enthalten PR101188 ... gibt es getrennt für avr-gcc 8 bzw. avr-gcc 13.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.