Einrichtung von Eclipse für AVR-Programmierung unter Linux

Hallo,

ich habe die avr tools unter /usr/local/avr also:

/usr/local/avr/avr8-gnu-toolchain-linux_x86
(für gcc tool chain download von atmel)

und
/usr/local/avr/bin
(für avrdude, avarice, avr-gdb)

Bei mir wurden die Pfade automatisch gefunden:

Window -> Preferences -> AVR -> Paths:

/usr/local/avr/avr8-gnu-toolchain-linux_x86/bin
/usr/local/avr/avr8-gnu-toolchain-linux_x86/avr/include

(die Source ist bei mir auf "System")

Mit einer Installation unter Home habe ich leider keine Erfahrung.

(Ubuntu 12.04, 32 bit :-) )

Hallo!

Habe die Toolchain nun auch mal unter /usr/local/avr gepackt. Nun findet 
eclipse den Pfad auch von alleine.

Die Bibliotheken werden trotzdem nicht eingebunden. Das Einbinden unter 
Verwendung des ganzen Pfades funktioniert augenscheinlich (es gibt aber 
noch mehr Probleme - dazu später, sonst gibt es hier ein Durcheinander).

Die Source steht bei mir ebenfalls auf "System". Die weiteren Pfade:
AVR-GCC: /usr/bin
GNU make: /usr/bin
AVRDude: /usb/local/bin

Eigentlich wollte ich drum herum kommen mit dem Atmel Studio in der 
virtuellen Maschine arbeiten zu müssen :(

Gruß Max

wenn ich einen build ausführe, kommt auf meiner console:

make all
Building file: ../main.c
Invoking: AVR Compiler
avr-gcc -Wall -g2 -O0 -fpack-struct -fshort-enums -ffunction-sections 
-fdata-sections -std=gnu99 -funsigned-char -funsigned-bitfields 
-mmcu=attiny261a -DF_CPU=1000000UL -MMD -MP -MF"main.d" -MT"main.d" -c 
-o "main.o" "../main.c"

Building target: test.elf
Invoking: AVR C Linker
avr-gcc -Wl,-Map,StepUp.map -mmcu=attiny261a -o "test.elf"  ./main.o
Finished building target: test.elf
          ^

Invoking: AVR Create Extended Listing
avr-objdump -h -S test.elf  >"test.lss"
Finished building: test.lss

Invoking: Print Size
avr-size --format=avr --mcu=attiny261a test.elf
AVR Memory Usage
----------------
Device: attiny261a

Program:    1142 bytes (55.8% Full)
(.text + .data + .bootloader)

Data:          1 bytes (0.8% Full)
(.data + .bss + .noinit)


Finished building: sizedummy


19:20:34 Build Finished (took 223ms)

Was kommt bei Dir?
Welche Libs findet er bei Dir nicht?

P.S.: je nach Prozessor kann 6.1 auch keine Lösung sein ;-)

Einbinden möchte ich:

1

#include <avr/io.h>

2

#include <avr/interrupt.h>

3

#include <stdlib.h>

4

#include <inttypes.h>

Die werden alle nicht gefunden. Mit dem ganzen Pfad klappt es:

1

#include </usr/local/avr/avr8-gnu-toolchain-linux_x86_64/avr/include/inttypes.h>

Ein Build wirft erst einmal folgende Fehlermeldungen aus:

1

make: *** [main.o] Error 1         C/C++ Problem

2

make: *** [test.elf] Error 1         C/C++ Problem

3

Symbol 'PortA' could not be resolved  main.c  /KondiTester  line 65  Semantic Error

4

Symbol 'DDRA' could not be resolved  main.c  /KondiTester  line 53  Semantic Error

Und die Konsolenausgabe ist ganz traurig:

1

**** Build of configuration Release for project KondiTester ****

2

3

Nothing to build for project KondiTester

Das sind Fehlermeldungen, die ich mit meiner ersten Installation auch 
schon hatte. Weil ich diese mit googeln nicht lösen konnte, oft aber den 
Hinweis gefunden habe die Paketquellen hierfür nicht zu nutzen, habe ich 
alles per Hand noch einmal gemacht.

Programmieren möchte ich den ATMega 8.

Gruß Max

#include <avr/io.h>
#include <avr/interrupt.h>
#include <stdlib.h>
#include <inttypes.h>

sind  aber Header, keine libs :-).

OK, hast Du ein C Projekt für "AVR Cross Target" erzeugt (project type)?
Oder ein "normales"?

P.S.: zum Test habe ich gerade mal die scanf_min library hinzugelinkt.
Invoking: AVR C Linker
avr-gcc -Wl,-Map,StepUp.map -mmcu=attiny261a -o "test.elf"  ./main.o 
-lscanf_min
Finished building target: test.elf

Sollte also tun.

Haha das war das Wort, welches ich gesucht hatte! :) Beim Schreiben bin 
ich in mich gegangen aber dann bei meiner ENtscheidung geblieben. Danke 
für die Korrektur!

Das Projekt habe ich als "C Project" und "AVR Cross Target Application" 
angelegt.

Gruß Max

Hallo,

habe deinen Beitrag gefunden. Hier der Link für alle anderen: 
Beitrag "AVR eclipse error message problem!!"

Meintest du diesen Lösungsvorschlag:

1

Project -> Properties -> C/C++ General -> Paths and Symbols -> Tab 

2

Includes -> GNU C -> Add... -> /usr/liv/avr/include

3

Tab Symbols -> Add... -> Name:__AVR_ATmega16__

?

Habe das mal übernommen und wie folgt geändert:

1

Project -> Properties -> C/C++ General -> Paths and Symbols -> Tab 

2

Includes -> GNU C -> Add... -> /usr/local/avr/avr8-gnu-toolchain-linux_x86_64/avr/include

3

Tab Symbols -> Add... -> Name:__AVR_ATmega8__

Hat sich leider nichts getan.

Gruß Max

Lösch mal das Symbol und versuche mit Project -> Properties -> AVR -> 
Target Hardware den MCU Type einzustellen. Wieso man da die Symbole 
manuell einstellen soll, ist mir schleierhaft.

Was gibt ein Build auf deiner Console aus?

Hallo,

Auslesen klappt wunderbar! Die Kommunikation mit dem STK500 klappt also.

Die Ausgabe ist sehr dürftig.

1

**** Build of configuration Release for project KondiTester ****

2

3

Nothing to build for project KondiTester

Ich habe nun mal ein Standard C Projekt erstellt und den Code dorthin 
kopiert. Dem Projekt habe ich dann noch den Pfad für die Bibliotheken 
mitgegeben. Diese werden damit gefunden.

Folgende Fehler bekomme ich:

1

Symbol 'DDRA' could not be resolved  main.c  /Konditester  line 53  Semantic Error

2

Symbol 'PortA' could not be resolved  main.c  /Konditester  line 65  Semantic Error

3

make: *** [test.elf] Error 1         C/C++ Problem

4

make: *** [main.o] Error 1         C/C++ Problem

5

make: *** [main.o] Error 1  Konditester       C/C++ Problem

6

‘DDRA’ undeclared (first use in this function)  main.c  /Konditester  line 53  C/C++ Problem

7

‘PortA’ undeclared (first use in this function)  main.c  /Konditester  line 65  C/C++ Problem

Dafür gibt die Konsole mehr aus:

1

20:08:33 **** Incremental Build of configuration Debug for project Konditester ****

2

make all 

3

Building file: ../main.c

4

Invoking: GCC C Compiler

5

gcc -I/usr/local/avr/avr8-gnu-toolchain-linux_x86_64/avr/include -O0 -g3 -Wall -c -fmessage-length=0 -MMD -MP -MF"main.d" -MT"main.d" -o "main.o" "../main.c"

6

In file included from ../main.c:44:0:

7

/usr/local/avr/avr8-gnu-toolchain-linux_x86_64/avr/include/avr/io.h:602:6: warning: #warning "device type not defined" [-Wcpp]

8

 #    warning "device type not defined"

9

      ^

10

../main.c: In function ‘initial’:

11

../main.c:53:2: error: ‘DDRA’ undeclared (first use in this function)

12

  DDRA = 0xff; // PortA Ausgänge

13

  ^

14

../main.c:53:2: note: each undeclared identifier is reported only once for each function it appears in

15

../main.c: In function ‘main’:

16

../main.c:65:3: error: ‘PortA’ undeclared (first use in this function)

17

   PortA = 0b00000001; //Port Bit A0 wird gesetzt

18

   ^

19

make: *** [main.o] Error 1

20

21

20:08:33 Build Finished (took 58ms)

Aber ein C Projekt ist vermutlich eh nicht richtig oder? Wir müssen ja 
nun nicht versuchen hier an zwei Fronten zu kämpfen.

Gruß Max

Bei mir kommt

"Invoking: AVR Compiler"

bei Dir nicht ;-).

Wenn Du den GNU C für Dein x86 Linux benutzt, wird da kein AVR Exec raus 
kommen. Bitte den richtigen C-Projekt Typ nehmen,

Das mit den Editor Problemen nach einem MCU Type wechsel habe ich 
inzwischen auch verstanden. Wenn man zuerst in "Project -> Properties -> 
AVR -> Target Hardware" auf "Restore Defaults" auswählt und applied und 
anschließend den Prozessor Typ auswählt, verschwinden meine roten 
Kreuze.
Compilieren tat aber auch mit den roten Dingern.

Wenn Du also ein AVR Cross Target Application Projekt nimmst, den 
Prozessor Type auf ATMega8 einstellst, dann sollten andere Meldungen bei 
einem Build kommen.

Das liegt daran, dass ich testweise gerade auch ein C Projekt angelegt 
habe. Aus diesem stammt die Konsolenausgabe, daher der C Kompiler.

Habe erst im Anschluss überlegt dass das Quatsch war.

Gruß Max

Achim K. schrieb:
> Lösch mal das Symbol und versuche mit Project -> Properties -> AVR ->
> Target Hardware den MCU Type einzustellen. Wieso man da die Symbole
> manuell einstellen soll, ist mir schleierhaft.
>
Ja, den Beitrag meinte ich. Warum es so ist weiss ich nicht, aber meine 
Umgebung (Hatte es beim tiny2313 jetzt wieder)akzeptiert kein manuelles 
setzen oder auslesen ueber avrdude fuer ein device das vom Standard bei 
Generierung des Projects angegeben ist. Gilt auch bei einem neuen 
Projekt, bei mir zieht es immer den mega8 der irgendwo als init fuer ein 
neues Projekt hinterlegt ist.

Was sagt <f2> auf den portnamen, kommt das richtige device.h durch die 
io.h oder nicht?
Bei mir kommt die iom8.h und die ist ggf. falsch. Sseltsam ist 
allerdings ein device ohne porta keine ahnung ob es so eine ioxxx..h 
gaebe.

//hufnala

Ich befürchte, dass hier erst einmal der richtige Projekt Typ ausgewählt 
werden muss. Dann der MCU Typ. Und ob dann die roten Kreuze kommen wird 
man sehen.

Ein ATmega 8 hat kein PORTA, zumindest steht das so in der Doku. Daher 
gibt es den PORTA auch nicht in den zugehörigen Headern.

Achim K. schrieb:

>
> Ein ATmega 8 hat kein PORTA, zumindest steht das so in der Doku. Daher
> gibt es den PORTA auch nicht in den zugehörigen Headern.
Hm, gut das ich immer das datenblatt daneben liegen habe, auswendig 
merke ich mir das nicht :-)) war ja ein perfektes beispiel...

//hufnala

Oh mein Gott! Wie peinlich! Ich hatte einfach blind port A verwendet, 
bzw. verwenden wollen...

Werde ich später mal testen.

Das löst allerdings nicht das Problem mit den header Dateien!

Gruß Max

Ich habe gerade ein neues C-Project "AVR Cross Target Application" 
"Empty Project" angelegt. Bei "weiter" kann man im letzten Dialog den 
"MCU Type" auf "ATmega8" setzen. Danach habe ich ein "main.c" mit 
folgendem Inhalt erzeugt:

#include <avr/io.h>
#include <avr/interrupt.h>
#include <stdlib.h>
#include <inttypes.h>

int main()
{
  PORTB = 0;
}

Das Compiliert ohne Fehlermeldungen.

make all
Building file: ../main.c
Invoking: AVR Compiler
avr-gcc -Wall -g2 -gstabs -O0 -fpack-struct -fshort-enums 
-ffunction-sections -fdata-sections -std=gnu99 -funsigned-char 
-funsigned-bitfields -mmcu=atmega8 -DF_CPU=1000000UL -MMD -MP 
-MF"main.d" -MT"main.d" -c -o "main.o" "../main.c"
Finished building: ../main.c

Building target: test.elf
Invoking: AVR C Linker
avr-gcc -Wl,-Map,test.map -mmcu=atmega8 -o "test.elf"  ./main.o
Finished building target: test.elf

Invoking: AVR Create Extended Listing
avr-objdump -h -S test.elf  >"test.lss"
Finished building: test.lss

Invoking: Print Size
avr-size --format=avr --mcu=atmega8 test.elf
AVR Memory Usage
----------------
Device: atmega8

Program:      86 bytes (1.0% Full)
(.text + .data + .bootloader)

Data:          0 bytes (0.0% Full)
(.data + .bss + .noinit)


Finished building: sizedummy


08:08:25 Build Finished (took 619ms)

Es gibt auch keine roten Kreuze.

Ich benutze
----------------------------------
Eclipse IDE for C/C++ Developers

Version: Kepler Service Release 1
Build id: 20130919-0819
----------------------------------
AVR Eclipse Plugin 2.4.1
------------------------------
avr8-gnu-toolchain-3.4.3.1072-linux.any.x86.tar.gz
----------------------------------

Wenn das in Deiner Eclipse / AVR Plugin Installation nicht tut, wäre es 
gut, die Fehlermeldungen zu haben. Leider habe ich keine Möglichkeit,
"kurz mal die 64Bit Version zu testen".

Na dann kann Max jetzt ja an drei Fronten kämpfen ;-).

Mit roten Kreuzen, die man aber nur vielleicht bekommt,
mit Arduino (komplett veraltete Tool Chain und deren 
Installationsanleitung),
und mit PORTs, die sein Chip nicht hat :-).

Also Max, Du darfst jeden Unsinn machen. Wenn Du aber unter Verwendung 
der richtigen Tool Chain (AVR Cross Target Application) und der passend 
MCU (ATmega8) weiter Probleme hast, dann bitte mit nur den 
Fehlermeldungen :-).

Und ich habe einfach die Atmel GNU-AVR toolchain, AVRdude, Eclipse 
Kepler CDT und das AVR Plugin installiert. Und es tat auch, wenn man es 
richtig bedient (eben AVR Cross Toolchain Projekt, MCU Type).
Wenn man aber die konkreten Fehlermeldungen oben sieht (falsche Tool 
Chain (x86 statt AVR) und falsche PORTs), dann hat das wohl eher nichts 
damit zu tun, ob man die Arduino Dinge benutzt oder nicht.
Und welche Fehler aktuell "übrig" geblieben sind hat Max bis jetzt noch 
nicht geschrieben. Wir werden ja sehen, ob der Ansatz "teste 
unterschiedliche Toolchains aus, bis ein tut" oder "arbeite dich durch 
die Fehlermeldungen durch" zur Lösung führt.
Wie aber Arduino nicht vorhandene PORTs oder die Verwendung der x86 Tool 
Chain behebt, weiß ich nicht.

Hallo!

Ich freue mich über die vielen Hilfestellungen!

Nun noch einmal ganz strukturiert:

1. Ich habe die 64 bit Toolchain mal gegen die "normale" 32 bit 
Toolchain getauscht. Nicht, dass es nur deswegen Probleme gibt. Eclipse 
hat direkt den richtigen Pfad 
(/usr/local/avr/avr8-gnu-toolchain-linux_x86/avr/include) für die Header 
Dateien gefunden
2. Neues C Projekt "AVR Cross Target Application" "Empty Project" 
angelegt. (als Toolchain wird hier "AVR-GCC Toolchain angezeigt!)
3. Im letzten Schritt wurde "ATmega8" als "MCU Type" eingestellt.
4. "main.c" mit dem selben Inhalt, wie aks erstellt:

1

#include <avr/io.h>

2

#include <avr/interrupt.h>

3

#include <stdlib.h>

4

#include <inttypes.h>

5

6

int main()

7

{

8

  PORTB = 0;

9

}

5. Gelbe Fragezeichen bei den include's. Fehlermeldungen nach dem Muster 
"Unresolved inclusion: <avr/io.h>".
6. Meldung bei PortB "Symbol 'PORTB' could not be resolved."
@ hufnala: Bei <f2> auf den Portnamen passiert gar nichts.
7. Trotzdem versucht zu bauen
8. Folgende Fehlermeldungen:

1

make: *** [test.elf] Error 1         C/C++ Problem

2

make: *** [main.o] Error 1         C/C++ Problem

3

Symbol 'PORTB' could not be resolved  main.c  /einrichtungTest  line 8  Semantic Error

4

fatal error: avr/io.h: No such file or directory  main.c  /einrichtungTest  line 1  C/C++ Problem

9. Konsolenausgabe:

1

11:48:44 **** Build of configuration Debug for project einrichtungTest ****

2

make all 

3

Building file: ../main.c

4

Invoking: AVR Compiler

5

avr-gcc -Wall -g2 -gstabs -O0 -fpack-struct -fshort-enums -ffunction-sections -fdata-sections -std=gnu99 -funsigned-char -funsigned-bitfields -mmcu=atmega8 -DF_CPU=1000000UL -MMD -MP -MF"main.d" -MT"main.d" -c -o "main.o" "../main.c"

6

../main.c:1:20: fatal error: avr/io.h: No such file or directory

7

compilation terminated.

8

make: *** [main.o] Error 1

9

10

11:48:44 Build Finished (took 61ms)

So, wie ich das sehe, wird wegen der fehlenden io.h abgebrochen.

Wenn ich nun den ganzen Pfad bei den includes angebe, werden die Header 
Dateien gefunden. PORTB bleibt weiterhin unbekannt. Fehlermeldungen:

1

make: *** [test.elf] Error 1         C/C++ Problem

2

make: *** [main.o] Error 1         C/C++ Problem

3

Symbol 'PORTB' could not be resolved  main.c  /einrichtungTest  line 8  Semantic Error

4

fatal error: avr/sfr_defs.h: No such file or directory  einrichtungTest    line 99, external location: /usr/local/avr/avr8-gnu-toolchain-linux_x86/avr/include/avr/io.h  C/C++ Problem

Konsolenausgabe:

1

11:50:56 **** Incremental Build of configuration Debug for project einrichtungTest ****

2

make all 

3

Building file: ../main.c

4

Invoking: AVR Compiler

5

avr-gcc -Wall -g2 -gstabs -O0 -fpack-struct -fshort-enums -ffunction-sections -fdata-sections -std=gnu99 -funsigned-char -funsigned-bitfields -mmcu=atmega8 -DF_CPU=1000000UL -MMD -MP -MF"main.d" -MT"main.d" -c -o "main.o" "../main.c"

6

In file included from ../main.c:1:0:

7

/usr/local/avr/avr8-gnu-toolchain-linux_x86/avr/include/avr/io.h:99:26: fatal error: avr/sfr_defs.h: No such file or directory

8

compilation terminated.

9

make: *** [main.o] Error 1

10

11

11:50:56 Build Finished (took 60ms)

Es gibt also weiterhin offene Fragen:
1. Warum wird der eingestellte Pfad nicht genutzt, um dort nach den 
Header Dateien zu suchen?
2. Was ist das Problem bzgl. avr/sfr_defs.h?
3. Das PORTB Problem.

Gruß Max

In meinen avr includes steht die "sfr_defs.h" im Verzeichnis 
"include/avr" neben der/ genauso wie die "io.h".
Stehen bei dir auch beide Dateien dort? Hast Du lese Berechtigungen?
Bei mir wird diese Datei gefunden, ohne dass ich die include 
Verzeichnisse ändere. Was hast Du den für die include Verzeichnisse 
genommen?

Bei mir ist es (project -> preferences -> C/C++ General -> Paths and 
Symbols -> includes -> GNU C)
... /lib/gcc/avr/4.8.1/include
... /lib/gcc/avr/4.8.1/include-fixed
... /avr/include


Was steht bei Dir und was hast Du ergänzt?

Hallo,

"sfr_defs.h" befindet sich im selben Verzeichnis wie auch io.h. 
Leseberechtigungen sind vorhanden.

Unter project -> properties -> C/C++ General -> Paths and
Symbols -> includes -> GNU C standen offensichtlich noch Pfade aus der 
alten Installation:

1

/usr/lib/gcc/avr/4.7.2/include

2

/usr/lib/gcc/avr/4.7.2/include-fixed

Folgende Eingetragen habe ich ergänzt (die vorhandenen kann ich nicht 
entfernen?!):

1

/usr/lib/gcc/x86_64-linux-gnu/4.8/include

2

/usr/lib/gcc/x86_64-linux-gnu/4.8/include-fixed

3

/usr/local/avr/avr8-gnu-toolchain-linux_x86/avr/include

Nun werden alle Header Dateien gefunden!
PORTB ist auch bekannt!

Leider klappt das alles noch nicht ohne Fehler.
Fehlermeldungen:

1

make: *** [test.elf] Error 1         C/C++ Problem

2

make: *** [main.o] Error 1         C/C++ Problem

3

make: *** [einrichtungTest.elf] Error 1         C/C++ Problem

4

crtm8.o: No such file: No such file or directory  einrichtungTest       C/C++ Problem

Konsolenausgabe:

1

12:40:27 **** Incremental Build of configuration Debug for project einrichtungTest ****

2

make all 

3

Building target: einrichtungTest.elf

4

/usr/lib/gcc/avr/4.7.2/../../../avr/bin/ld: crtm8.o: No such file: No such file or directory

5

collect2: error: ld returned 1 exit status

6

Invoking: AVR C Linker

7

avr-gcc -Wl,-Map,einrichtungTest.map -mmcu=atmega8 -o "einrichtungTest.elf"  ./main.o   

8

make: *** [einrichtungTest.elf] Error 1

9

10

12:40:27 Build Finished (took 73ms)

Die "crtm8.o" zcheint das Problem zu sein. Ich habe mein System 
durchsucht und finde sie an zwei Orten:
1. /home/max/Downloads/avr8-gnu-toolchain-linux_x86/avr/lib/avr4 (hier 
habe ich den Download entpackt, das eclipse diese Datei nicht findet ist 
klar)
2. /usr/local/avr/avr8-gnu-toolchain-linux_x86/avr/lib/avr4 (das ist 
wohl der Pfad, der eigentlich zum Ziel führen sollte) - Warum sucht 
eclipse nicht selbstständig tiefer?

Gruß Max

Ohne auf ein spezielles Problem einzugehen hier mal mein Vorgehen, mit 
dem ich meine Entwicklungsumgebung unter Debian-basierenden Systemen 
jetzt schon mehrfach ohne Verrenkungen eingerichtet habe:

1. Eclipse IDE for C/C++ Developers von eclipse.org runterladen und 
entpacken, OpenJDK per Paketverwaltung installieren (openjdk-7-jdk)

2. GCC, AVR-Libs und avrdude installieren (gcc-avr avr-libc avrdude)

3. Eclipse starten, http://avr-eclipse.sourceforge.net/updatesite zu den 
Quellen hinzufügen und Plugin installieren, Eclipse neustarten

4. Projekt anlegen (New Project > C Project > AVR Cross Target 
Application), MCU und Taktfrequenz auswählen.

So purzeln schonmal funktionierende Hexfiles raus. Vor dem Flashen aus 
Eclipse muss noch eine avrdude-Konfiguration angelegt werden, beim 
ersten Versuch kommt ein Hinweis darauf, wie man das macht.
Je nach Programmer müssen evtl. noch die Berechtigungen auf das Device 
angepasst werden.

Hallo cyprius,

danke für deinen Beitrag!

Das hilft mir allerdings leider nicht weiter. Vielleicht hilft es einem 
anderen bei der Suche nach einem möglichen Vorgehen.

Gruß Max

Nunja, es sieht ein bisschen so aus, als würdest du dich da in Details 
verrennen. Das dürfte inzwischen auch so speziell sein, dass da niemand 
mehr per Erfahrung aushelfen kann.

Hast du mal versucht, in einer virtuellen Maschine einen frischen, 
geordneten Installationsprozess durchzuführen? Wenn du auf die extern 
beschafften Libraries bestehst, würde es auch Sinn machen, den ganzen 
Vorgang zu dokumentieren. Dann kannst du das auf "deinem" System 
jederzeit wieder reproduzieren.

Nein, an Installationen gab es bisher die über Paketquellen und aufgrund 
der vielen Warnhinweise eine manuelle.

Dokumentieren macht sicherlich Sinn, nur würde ich gerne etwas 
funktionierendes aufschreiben :)

Gruß Max

"/usr/lib/gcc/avr/4.7.2/../../../avr/bin/ld"

und

"/usr/local/avr/avr8-gnu-toolchain-linux_x86/avr/lib/avr4"

Ich denke, jetzt weiß ich, was der Unterschied ist. Du hast die 
debian/ubuntu Pakete installiert (siehe oben "alles aus den 
Paketquellen) und dann die Tool Chain von Atmel. Jetzt hast Du zwei :-).

Entferne mal die überflüssigen Pakete!

Lasse das AVR Plugin die Pfade neu suchen (Window -> Preferences -> AVR 
-> Paths), sollten dann alle auf 
"/usr/local/avr/avr8-gnu-toolchain-linux_x86/..." zeigen. Dann neues 
C-Projekt ..., c-file kopieren und nach weiteren Fehlern Ausschau halten 
:-).

Hallo,

habe gcc-avr etc. gelöscht (aus den Paketquellen).

Nun findet eclipse AVR-GCC auch unter dem selben Pfad, wie die Header 
Dateien. Hier alle Pfade:

1

AVR GCC /usr/local/avr/avr8-gnu-toolchain-linux_x86/bin

2

GNU make /usr/bin

3

AVR Header Files /usr/local/avr/avr8-gnu-toolchain-linux_x86/avr/include

4

AVRDude /usr/loca/bin

Source ist jeweils SYstem.

GNU make und AVRDude haben sich nicht geändert!

Bei den Projekteigenschaften wurden nun auch die Pfade

1

/usr/lib/gcc/x86_64-linux-gnu/4.8/include

2

/usr/lib/gcc/x86_64-linux-gnu/4.8/include-fixed

durch das System hinzugefügt. Ich konnte meine Eintragungen entfernen, 
da sie nun doppelt waren.

Ausgabe der Fehler:

1

make: *** [test.elf] Error 1         C/C++ Problem

2

make: *** [main.o] Error 1         C/C++ Problem

3

make: *** [einrichtungTest.elf] Error 1         C/C++ Problem

Zwei Warnungen besagen, dass die nicht löschbaren Einträge aus den 
Projekteigenschaften auf die GCC Version 4.7.2 nicht zu finden sind 
(wurde ja auch gelößcht):

1

Invalid project path: Include path not found (/usr/lib/gcc/avr/4.7.2/include-fixed).  einrichtungTest    pathentry  Path Entry Problem

2

Invalid project path: Include path not found (/usr/lib/gcc/avr/4.7.2/include).  einrichtungTest    pathentry  Path Entry Problem

Konsolenausgabe sieht gut aus:

1

13:42:42 **** Incremental Build of configuration Debug for project einrichtungTest ****

2

make all 

3

Building file: ../main.c

4

Invoking: AVR Compiler

5

avr-gcc -I/usr/local/avr/avr8-gnu-toolchain-linux_x86/avr/include -Wall -g2 -gstabs -O0 -fpack-struct -fshort-enums -ffunction-sections -fdata-sections -std=gnu99 -funsigned-char -funsigned-bitfields -mmcu=atmega8 -DF_CPU=1000000UL -MMD -MP -MF"main.d" -MT"main.d" -c -o "main.o" "../main.c"

6

Finished building: ../main.c

7

8

Building target: einrichtungTest.elf

9

Invoking: AVR C Linker

10

avr-gcc -Wl,-Map,einrichtungTest.map -mmcu=atmega8 -o "einrichtungTest.elf"  ./main.o   

11

Finished building target: einrichtungTest.elf

12

13

Invoking: AVR Create Extended Listing

14

avr-objdump -h -S einrichtungTest.elf  >"einrichtungTest.lss"

15

Finished building: einrichtungTest.lss

16

17

Invoking: Print Size

18

avr-size --format=avr --mcu=atmega8 einrichtungTest.elf

19

AVR Memory Usage

20

----------------

21

Device: atmega8

22

23

Program:      86 bytes (1.0% Full)

24

(.text + .data + .bootloader)

25

26

Data:          0 bytes (0.0% Full)

27

(.data + .bss + .noinit)

28

29

30

Finished building: sizedummy

31

32

33

13:42:42 Build Finished (took 112ms)

Ein hex-File scheint es leider noch nicht zu geben.

Gruß Max

Aber ein .elf file wird erzeugt. Und avrdude sollte in 6.01 mit den 
entsprechende configure switches compiliert .elf direkt lesen können.
Dazu muss man dann "${CWD}/${BuildArtifactFileName}" unter "Project -> 
Properties -> AVR -> AVR Dude -> Flash / EEPROM -> from flash memory 
image file" "${CWD}/${BuildArtifactFileName}" eingeben.

Es gibt sicher auch Alternativen, die hex aus elf files erzeugen 
(avrdude älter oder ohne elf Unterstützung compiliert), aber da habe ich 
leider keine Erfahrung.

Es läuft!!!

Tausend Dank Achim! Für deine sehr kompetente Hilfe und dafür, dass du 
nicht aufgegeben hast ;-)

Jetzt kann ich mich endlich mal wieder der Entwicklung widmen. Toll!

Gruß Max

Gern geschehen!

Ich habe erst vor ein paar Wochen auch auf Eclipse gewechselt, da in AS 
6.1 die debugWire und AVRDragon Unterstützung für den ATTiny861A sehr 
problematisch war. Bei mir dauerte es 3 Tage, bis ich endlich den 
AVRDragon mit debugWire einsetzen konnte. Aber immerhin noch besser wie 
beim AS 6.1; da habe ich nach 2 Monaten aufgegeben. Für andere 
Prozessoren soll es aber gehen.

Gruß
Achim