Hallo.
Seit ein paar Tagen kann ich unter avr eclipse bei den Project
Properties keinen MCU Type mehr auswählen. Der Auswahl-Button ist
ausgegraut, das "load from MCU" schlägt fehl. Zur Umgehung habe ich die
Target Architektur von Hand eingestellt, was natürlich andere Nachteile
hat.
Ich weiß nicht, was zu dem merkwürdigen Verhalten geführt hat (update?).
Was mich jetzt aber echt Nerven kostet, ist die Fehlermeldung, die das
Build meiner C-Programme liefert:
Invoking: AVR Compiler
as: unrecognized option '-mmcu=attiny85'
avr-gcc -D__AVR_TINY__=1 -U__AVR_ATmega16__ -U__AVR_MEGA__ -Wall -g2
-gstabs -O0 -fpack-struct -fshort-enums -std=gnu99 -funsigned-char
-funsigned-bitfields -mmcu=attiny85 -DF_CPU=20000000UL -MMD -MP
-MF"src/pwm.d" -MT"src/pwm.d" -c -o "src/pwm.o" "../src/pwm.c"
make: *** [src/pwm.o] Fehler 1
Building file: ../src/timer.c
as: unrecognized option '-mmcu=attiny85'
Invoking: AVR Compiler
make: *** [src/timer.o] Fehler 1
avr-gcc -D__AVR_TINY__=1 -U__AVR_ATmega16__ -U__AVR_MEGA__ -Wall -g2
-gstabs -O0 -fpack-struct -fshort-enums -std=gnu99 -funsigned-char
-funsigned-bitfields -mmcu=attiny85 -DF_CPU=20000000UL -MMD -MP
-MF"src/timer.d" -MT"src/timer.d" -c -o "src/timer.o" "../src/timer.c"
avr-size: 'LED_Controller_ATTiny85.elf': No such file
Invoking: Print Size
make: [sizedummy] Fehler 1 (ignoriert)
avr-size --format=berkeley -t LED_Controller_ATTiny85.elf
make: Das Target »all« wurde wegen Fehlern nicht aktualisiert.
0 0 0 0 0 (TOTALS)
Finished building: sizedummy
Ich vermute, dass das falsche Assemblerprogramm aufgerufen wird (as
statt avr-as). Ich bin mit meinem Latein echt am Ende.
Das Problem trat auch mit eclipse Helios und Indigo auf, und ich habe
die avr-gcc Versionen 436, 453, 462, 47 durchprobiert, ohne Erfolg.
System-Info:
Opensuse 12.1 X86_64, (Gnome)
eclipse Juno (Build 20120614-1722),
AVR Eclipse Plugin 2.4.0.201203041437
cross-avr-gcc 4.3.3
cross-avr-binutils 2.22-19.5
avr-libc 1.7.1-2.2
avrdude 5.11-4.1
Hat jemand eine Idee, was ich sonst noch probieren könnte?
Du könntest den Compiler mal in einer Shell aufrufen
(einfach z.B.
avr-gcc -D__AVR_TINY__=1 -U__AVR_ATmega16__ -U__AVR_MEGA__ -Wall -g2
-gstabs -O0 -fpack-struct -fshort-enums -std=gnu99 -funsigned-char
-funsigned-bitfields -mmcu=attiny85 -DF_CPU=20000000UL -MMD -MP
-MF"src/timer.d" -MT"src/timer.d" -c -o "src/timer.o" "../src/timer.c"
pasten - natürlich im richtigen Directory) und schauen, ob das
funktioniert.
Oder dem avr-gcc von der eclipse aus die "-v" Option mitgeben,
dann siehst Du, welche Teilprogramme das Compiler-Frontend (avr-gcc)
aufruft.
Vielen Dank für den Tipp. Es ist, wie vermutet. Da wird der falsche
Assembler aufgerufen. Es sollte avr-as aufgerufen werden.
**** Incremental Build of configuration Debug for project
LED_Controller_ATTiny85 ****
make -k all
[... compiler-Aufruf avr-gcc gelöscht ...]
Compiler executable checksum: f0ea7bb03ac8fc333bb567155412f408
COLLECT_GCC_OPTIONS='-D__AVR_TINY__=1' '-U__AVR_ATmega16__'
'-U__AVR_MEGA__' '-Wall' '-g2' '-gstabs' '-O0' '-fpack-struct'
'-fshort-enums' '-std=gnu99' '-funsigned-char' '-funsigned-bitfields'
'-v' '-mmcu=attiny85' '-DF_CPU=20000000UL' '-MMD' '-MP' '-MFsrc/adc.d'
'-MTsrc/adc.d' '-c' '-o' 'src/adc.o'
as -v -mmcu=attiny85 -o src/adc.o /tmp/cczd9Jmd.s
GNU assembler version 2.21.1 (x86_64-suse-linux) using BFD version (GNU
Binutils; openSUSE 12.1) 2.21.1
as: unrecognized option '-mmcu=attiny85'
make: *** [src/adc.o] Fehler 1
Using built-in specs.
[... Rest gelöscht ...]
Ich frage mich jetzt nur noch, warum das passiert. In der Toolchain kann
ich AVR Assembler oder Cross GCC Assembler auswählen, es ergibt sich
kein Unterschied.
Die avr Tools sind alle unter /usr/bin verfügbar.
Da wird doch vermutlich ein Makefile verwendet?
1. Dann kontrolliere doch mal, ob da drin AS definiert wird (also in der
Art AS =...irgendwas...).
2. Dann setz doch da mal rein:
AS = avr-as
oder:
AS = gcc
Ja, und das Makefile definiert drei Targets, das .elf, das .lss
(disassembly listing) und sizedummy, um die Größen der Segmente
anzuzeigen. Die beiden letzt genannten fallen aus, da ihre Dependency
nicht erzeugt wird (das .elf). Der Assembler ist, soweit ich das sehen
kann, weder im makefile noch sonst wo im Eclipse-Projekt definiert
(File-Search auf String "as").
Ich glaube schon fast, dass mein avr-gcc eine Macke hat. Das build log
sagt u.a.:
Was mich stutzig macht, ist --with-gnu-as, eine configuration option,
die beim Bauen des Compilers gesetzt wird. Bedeutung lt.
http://gcc.gnu.org/install/configure.html:
1
--with-gnu-as
2
Specify that the compiler should assume that the assembler it finds is
3
the GNU assembler. However, this does not modify the rules to find an
4
assembler and will result in confusion if the assembler found is not
5
actually the GNU assembler. (Confusion may also result if the compiler
6
finds the GNU assembler but has not been configured with --with-gnu-as.)
7
If you have more than one assembler installed on your system, you may want
8
to use this option in connection with --with-as=pathname or --with-build-
9
time-tools=pathname.
10
11
The following systems are the only ones where it makes a difference
12
whether you use the GNU assembler. On any other system, --with-gnu-as has
13
no effect.
14
15
'hppa1.0-any-any'
16
'hppa1.1-any-any'
17
'sparc-sun-solaris2.any'
18
'sparc64-any-solaris2.any'
Habe ich zurecht gestutzt? Hat das beim cross-Kompilieren keine
Auswirkungen? Kann es sein, dass der avr-gcc wegen dieser Option den as
statt des avr-as aufruft?
Ich finde allerdings im gesamten /opt/cross/avr Verzeichnisbaum kein
Programm namens avr-as. (ich habe jetzt zum n+1. male alles komplett neu
installiert, einschließlich des eclipse avr plugins).Vielleicht sucht
avr-gcc ja den avr-as, findet ihn nicht und nimmt dann ersatzweise as,
der ja im exec-Pfad liegt.
Kennt sich damit jemand aus? Ich hoffe, dass ich auf der falschen Fährte
bin; ansonsten müsste ich mir den Compiler selbst komplett neu bauen
(Haufen Doku lesen). Weil ich nichts außergewöhnliches gemacht habe,
wundert's mich auch, dass niemand sonst das Problem hat. Oder ist meine
Konfig sooo selten?
Heinrich Seebauer schrieb:> Ich finde allerdings im gesamten /opt/cross/avr Verzeichnisbaum kein> Programm namens avr-as. (ich habe jetzt zum n+1. male alles komplett neu> installiert, einschließlich des eclipse avr plugins).Vielleicht sucht> avr-gcc ja den avr-as, findet ihn nicht und nimmt dann ersatzweise as,> der ja im exec-Pfad liegt.
Hast du denn überhaupt die avr-binutils (wo der avr-as drin sein sollte)
installiert?
Der Assembler wohnt hier: /usr/avr/bin/as ist ein Link auf
/usr/bin/avr-as.
Aber das bestärkt mich in der Auffassung, dass der falsche as aufgerufen
wird, denn das Build liefert:
1
...
2
as -v -mmcu=attiny85 -o src/timer.o /tmp/cc5DvSGe.s
3
GNU assembler version 2.21.1 (x86_64-suse-linux) using BFD version (GNU Binutils; openSUSE 12.1) 2.21.1
Was zeigt which avr-as denn an?
Wenn der nicht gefunden wird, in PATH aufnehmen.
Wenn PATH nicht verändert werden soll, die binutils in dir toolchain
installieren, d.h. mit gleichem --prefix oder von dort verlinken: Im
./bin Verzeichnis der Toolchain, wo auch avr-gcc steht, ist dann auch
ein avr-as, avr-ld, etc.
Johann L. schrieb:> Was zeigt which avr-as denn an?>> Wenn der nicht gefunden wird, in PATH aufnehmen.>
1
which avr-gcc avr-as avr-ld
2
/usr/bin/avr-gcc
3
/usr/bin/avr-as
4
/usr/bin/avr-ld
Sind alle da. Eclipse nimmt auch den avr-gcc aus dem korrekten
Verzeichnis /usr/bin.
> Wenn PATH nicht verändert werden soll, die binutils in dir toolchain> installieren, d.h. mit gleichem --prefix oder von dort verlinken: Im> ./bin Verzeichnis der Toolchain, wo auch avr-gcc steht, ist dann auch> ein avr-as, avr-ld, etc.
Wenn ich das richtig sehe, müsste ich das Paket cross-avr-binutils lokal
compilieren, oder habe ich mit yast oder zypper ein Chance, das install
prefix zu setzen? Aus /usr/avr/bin zu verlinken, würde, glaube ich,
nicht helfen, da er in diesem Verzeichnis nicht sucht, sondern in
/usr/bin. Oder ich müsste das Eclipse-Directory für die Toolchain
anpassen. Wenn alle Stricke reißen sollten, werde ich das in's Auge
fassen. Im Moment kann ich da die Folgen nicht abschätzen. Trotzdem,
danke für den Tipp!
Heinrich Seebauer schrieb:> Johann L. schrieb:>> Was zeigt which avr-as denn an?>>>> Wenn der nicht gefunden wird, in PATH aufnehmen.>>>> which avr-gcc avr-as avr-ld> /usr/bin/avr-gcc> /usr/bin/avr-as> /usr/bin/avr-ld>> Sind alle da. Eclipse nimmt auch den avr-gcc aus dem korrekten> Verzeichnis /usr/bin.
Das hasst doch überhaupt nicht zu
Heinrich Seebauer schrieb:> Das build log sagt u.a.:>> Configured with: ... --prefix=/opt/cross/avr
Scheint mir mal wieder ein Beispiel dafür zu sein, warum man die
AVR-Pakete der Distributionen besser links liegen lässt.
Nimm dir ein Paket von hier
http://www.wrightflyer.co.uk/avr-gcc/
und du hast eine funktionierende Toolchain in /usr/local/avr.
Stefan Ernst schrieb:> Scheint mir mal wieder ein Beispiel dafür zu sein, warum man die> AVR-Pakete der Distributionen besser links liegen lässt.>
Seit opensuse 11.3 (oder so) ist der AVR Toolchain nicht mehr in der
Distro enthalten. Vorher habe ich eigentlich nie Probleme gehabt.
> Nimm dir ein Paket von hier> http://www.wrightflyer.co.uk/avr-gcc/> und du hast eine funktionierende Toolchain in /usr/local/avr.
Würde ich gerne machen, wenn ich die Dinger bei mir installieren könnte.
Meine letzten Versuche, auf Ubuntu oder Debian umzusteigen, waren totale
Fehlschläge - ich habe die Distros bei mir nicht zum Laufen gebracht.Und
derzeit sieht es so aus, als wäre suse das einzige, was auf meiner HW
läuft.
Gibt es eine Möglichkeit, die .deb Pakete unter Suse zu installieren?
Alien habe ich schon mal angetestet, sieht aber nicht sehr Erfolg
versprechend aus.
Johann L. schrieb:> Heinrich Seebauer schrieb:
[...]
>>>> Sind alle da. Eclipse nimmt auch den avr-gcc aus dem korrekten>> Verzeichnis /usr/bin.>> Das hasst doch überhaupt nicht zu>> Heinrich Seebauer schrieb:>>> Das build log sagt u.a.:>>>> Configured with: ... --prefix=/opt/cross/avr
Ja, da hast Du Recht. Aber was folgt daraus?
Heinrich Seebauer schrieb:> Gibt es eine Möglichkeit, die .deb Pakete unter Suse zu installieren?
Du brauchst da nichts zu "installieren", schließlich verteilt das Paket
seinen Inhalt nicht über das ganze System, sondern es landet alles unter
/usr/local/avr. Und irgendwelche Veränderungen an anderen Dateien sind
auch nicht nötig. Einfaches "Auspacken" reicht da völlig.
Alles klar, ganz herzlichen Dank, Stefan!
Das mit dem ar hat bei mir zwar nicht funktioniert -- ich habe das Paket
von Hand ausgepackt und an die korrekte Stelle geschoben. Jetzt sehe ich
nur noch meine eigenen Fehler im Build log!
Und das target lässt sich auch wieder einstellen.
Noch einen Vorteil hat das Ganze: das Paket wird nicht mehr automatisch
aktualisiert ;)
Hallo zusammen,
so, ein ähnliches Problem habe ich nun auch.
Seit dem ich Anfang des Monats auf SUSE 12.2 mein System aktualisiert
habe,
bekomme ich eine ähnliche Fehlermeldung.
Wenn ich unter Netbeans versuche per "make program" mein ATMEGA8 zu
flashen, bekomme ich als Meldung :
COLLECT_GCC_OPTIONS='-v' '-c' '-mmcu=atmega8' '-I.' '-g' '-Os'
'-funsigned-char' '-funsigned-bitfields' '-fpack-struct' '-fshort-enums'
'-Wall' '-Wstrict-prototypes' '-std=gnu99' '-o' 'netzteil.o'
as -v -I. -mmcu=atmega8 -adhlns=netzteil.lst -o netzteil.o
/tmp/cc7eA9Fp.s
GNU assembler version 2.22 (i586-suse-linux) using BFD version (GNU
Binutils; openSUSE 12.2) 2.22
as: unrecognized option '-mmcu=atmega8'
Hier wird also der "normale" as aufgerufen, obwohl in den Einstellungen
hier explizit der avr-as angegeben ist.
Rufe ich allerdings "make program" von der Konsole auf, passt es.
COLLECT_GCC_OPTIONS='-v' '-c' '-mmcu=atmega8' '-I.' '-g' '-Os'
'-funsigned-char' '-funsigned-bitfields' '-fpack-struct' '-fshort-enums'
'-Wall' '-Wstrict-prototypes' '-std=gnu99' '-o' 'netzteil.o'
as -v -I. -mmcu=atmega8 -adhlns=netzteil.lst -o netzteil.o
/tmp/ccReQnKt.s
GNU assembler version 2.22 (avr) using BFD version (GNU Binutils;
openSUSE 12.2) 2.22
Die Pfade setze ich explizit im "netbeans" StartScript auch nochmal ...
Hmmmh, vorher, SUSE 11.4 klappte es ...
Hat jemand eine Idee ?
Gruß Ingo / DH1AAD
Thread beobachten
Seitenaufteilung abschalten