Hallo,
nur mal zur Info was der avr-gcc 14 leistet im Vergleich mit AVR128DB64.
1
avr-gcc 9.5.0 - Flash 24960 / RAM 3328 Bytes
2
avr-gcc 10.5.0 - Flash 25114 / RAM 3328 Bytes
3
avr-gcc 11.4.0 - Flash 25014 / RAM 3328 Bytes
4
avr-gcc 12.3.0 - Flash 24336 / RAM 3328 Bytes
5
avr-gcc 13.2.0 - Flash 24170 / RAM 3328 Bytes
6
avr-gcc 14.1.0 - Flash 24335 / RAM 2158 Bytes
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.)
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. :-)
Veit D. schrieb:> 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
Georg P. schrieb:> 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
$ avr-gcc --version
2
avr-gcc (GCC) 14.1.0
3
Copyright (C) 2024 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.
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.
Veit D. schrieb:> 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:
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.
:-)
Georg P. schrieb:> 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
Alexander S. schrieb:> 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
errno |0080486c| B | OBJECT|00000002| |.bss
2
__bss_end |0080486e| B | NOTYPE| | |.bss
3
_end |0080486e| B | NOTYPE| | |.bss
4
__eeprom_end |00810000| R | NOTYPE| | |.rodata
5
__RODATA_VMA__ |00a00000| A | NOTYPE| | |*ABS*
6
.LC76 |00a08000| r | NOTYPE| | |.rodata
7
__RODATA_ORIGIN__ |00a08000| A | NOTYPE| | |*ABS*
8
__rodata_start |00a08000| A | NOTYPE| | |*ABS*
9
.LC84 |00a08010| r | NOTYPE| | |.rodata
10
vtable for HardwareSerial|00a0803a| r | OBJECT|00000012| |.rodata
11
vtable for TwoWire |00a0804c| r | OBJECT|00000012| |.rodata
12
digital_pin_to_bit_mask|00a0805e| r | OBJECT|00000037| |.rodata
13
digital_pin_to_port |00a08095| r | OBJECT|00000037| |.rodata
14
digital_pin_to_bit_position|00a080cc| r | OBJECT|00000037| |.rodata
15
LED_HELLIGKEIT::led10mA|00a08103| r | OBJECT|0000010c| |.rodata
16
__rodata_end |00a08493| A | NOTYPE| | |*ABS*
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.
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:
Veit D. schrieb:> 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.
14.1.0 ... 20503 / 1247 // " --- " und 'mrodata-in-ram' (im .map existiert eine rohdata Section)
11
14.1.0 ... 20503 / 1247 // " --- " und 'mno-rodata-in-ram' (im .map existiert eine rohdata Section)
8er Version: Problem des Linkers. Egal ob mit oder ohne -mrelax Option.
1
c:/avrtoolchain/avr-gcc-8.5.0_mingw32_binutils2.40_avrlibc2.1github/bin/../lib/gcc/avr/8.5.0/../../../../avr/bin/ld.exe: --relax and -r may not be used together
2
collect2.exe: error: ld returned 1 exit status
3
lto-wrapper.exe: fatal error: C:\avrToolchain\avr-gcc-8.5.0_mingw32_binutils2.40_avrLibc2.1GitHub/bin/avr-gcc returned 1 exit status
Hallo,
Johann L. schrieb:> D.h. mit v14.1 macht -m[no-]rodata-in-ram macht keinen Unterschied?
Richtig, soweit ich das feststellen konnte.
1
14.1.0 ... 20503 / 1247 // ohne diese Option
2
14.1.0 ... 20503 / 1247 // -mno-rodata-in-ram
3
14.1.0 ... 20503 / 1247 // -mrodata-in-ram
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>
Veit D. schrieb:> Hallo,>> Johann L. schrieb:>> 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.
Wilhelm M. schrieb:> 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).
Johann L. schrieb:> Wilhelm M. schrieb:>> 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):
Veit D. schrieb:> 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
Habe mir das Spec-File vom AVR128DB64 angeschaut. Es gibt 2 Einträge.
1
*asm_relax:
2
%{mrelax:--mlink-relax}
3
4
*link_relax:
5
%{mrelax:--relax}
Ich weiß nicht was ich ändern muss. Internetsuche blieb auch erfolglos.
----------------------------------------------------------
Kompiliert wird mit:
Veit D. schrieb:> 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.
Yalu X. schrieb:> Wenn du generell an neuen Dingen interessiert bist, könntest du mal Arch> Linux ausprobieren. Hab's gerade upgedatet und siehe da:>>
1
> $ avr-gcc --version
2
> avr-gcc (GCC) 14.1.0>
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
./run.sh make compile
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:
pacman --sync --refresh --noconfirm avr-gcc avr-libc make
5
mkdir /build
6
EOS
7
WORKDIR /build
8
VOLUME /build
9
USER build
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.
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.
Veit D. schrieb:> es ist egal welche Option oder keine Option man verwendet
Nö, irgendetwas machst Du falsch. Wie oben schon geschrieben:
1) Du hast die Wirkung der Optionen vertauscht
2) Ggf. hast Du das Compilieren bzw. Linken vergessen.
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.
Veit D. schrieb:> 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.
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:
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
*asm_errata_skip:
2
%{!mskip-bug: -mno-skip-bug}
3
4
*link_pmem_wrap:
5
6
7
*link_relax:
8
%{mrelax:--relax}
9
10
*link_relax:
11
%{!r: %{mrelax:--relax}}
12
13
*link_arch:
14
%{mmcu=*:-m%*}
15
16
*link_data_start:
17
%{!Tdata:-Tdata 0x804000}
18
19
*link_text_start:
20
21
22
*self_spec:
23
%<mmcu=* -mmcu=avrxmega4 %<mshort-calls %<msp8
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.
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,
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.
Ein T. schrieb:> 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
dockerrun-u"$(id -u):$(id -g)"...
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
#define LINK_RELAX_SPEC \
2
"%{mrelax:--relax} "
Stattdessen
1
#define LINK_RELAX_SPEC \
2
"%{!r: %{mrelax:--relax}} "
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.
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. ;-)
Martin H. schrieb:> Wilhelm M. schrieb:>> 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 :(>> Beitrag "Re: GCC v14 Release"
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 ;-)
Veit D. schrieb:> 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.
Wilhelm M. schrieb:> 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.
Johann L. schrieb:> 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.
Johann L. schrieb:> 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,
Johann L. schrieb:> Veit D. schrieb:>> 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.
Veit D. schrieb:> 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.
Wilhelm M. schrieb:> 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.
Johann L. schrieb:> 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.
Johann L. schrieb:> Veit D. schrieb:>> 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.
Veit D. schrieb:> 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
Johann L. schrieb:> 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.
Veit D. schrieb:> 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:
Veit D. schrieb:> 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?
Harald K. schrieb:> 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?
Oliver S. schrieb:> 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.
Veit D. schrieb:> 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?
Harald K. schrieb:> Veit D. schrieb:>> 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.
Veit D. schrieb:> 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.
Harald K. schrieb:> 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.
Harald K. schrieb:> 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.
Johann L. schrieb:> 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?
900ss schrieb:> 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.
Veit D. schrieb:> 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:
Beitrag "Re: GCC v14 Release"
Veit D. schrieb:> 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
1) Device ist AVR128* oder AVR64*, und
2) Es befinden sich Daten in .rodata wie zum Beispiel vtables, und
3) 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.
Veit D. schrieb:> Was bleibt ist mit Option -v mit Arduino das er die Lib nicht> findet.
Das muss ein Arduino-Ding sein.
Johann L. schrieb:> Veit D. schrieb:>> 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
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
main.elf :
2
section size addr
3
.data 0 8404992
4
.text 1912 0
5
.rodata 278 10518528
6
.comment 18 0
7
.note.gnu.avr.deviceinfo 64 0
8
.debug_aranges 32 0
9
.debug_info 14718 0
10
.debug_abbrev 13926 0
11
.debug_line 110 0
12
.debug_str 6471 0
13
.debug_line_str 123 0
14
Total 37652
MIT Flag -mrodata-in-ram kompiliert
avr-size.exe -d -A main.elf
Veit D. schrieb:> 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 ...
Veit D. schrieb:> 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:
Veit D. schrieb:
1
> main.elf :
2
> section size addr
3
> .text 0 0
4
> .data 0 0
5
> .bss 0 0
6
> .gnu.lto_.profile.978610d3 11 0
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.
Veit D. schrieb:> OHNE Flag -mrodata-in-ram kompiliert> avr-size.exe -d -A main.elf
1
> section size addr
2
> .data 0 8404992
3
> .text 1912 0
4
> .rodata 278 10518528
> MIT Flag -mrodata-in-ram kompiliert
1
> section size addr
2
> .data 278 8404992
3
> .text 1938 0
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.
Veit D. schrieb:> 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
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.
Veit D. schrieb:> 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.
A. B. schrieb:
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.
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.
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.
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?
Veit D. schrieb:> 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.>
>> 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.
Georg P. schrieb:> 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
./contrib/download_prerequisites
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.
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).
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__/}
A. B. schrieb:> 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.
Johann L. schrieb:> 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?
Veit D. schrieb:> 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
A. B. schrieb:> 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.
Veit D. schrieb:> 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 :-)
A. B. schrieb:> @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
A. B. schrieb:> 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?
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?
Veit D. schrieb:> 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).
Veit D. schrieb:> 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)
Veit D. schrieb:> 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.
Thread beobachten
Seitenaufteilung abschalten