mikrocontroller.net

Forum: Compiler & IDEs Eclipse und WinAVR


Autor: MSE (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich arbeite zur Zeit im WinAVR unter Eclipse. Es ist mir (jetztm nachdem
es das CDT3.0 gibt) endlich gelungen, ein C++-Projekt so zu
konfigurieren (als managed-Make), dass der Build-Prozess so
stattfindet, wie ich es will (nämlich bis zur Erstellung eines
.hex-Files).

Leider muß ich bislang für jedes neue Projekt alles wieder von Hand so
hinbiegen. Ich wüßte gerne, ob und wie man eine Voreinstellung treffen
kann, so dass die AVR-Toolchain samt gewisser vernünftiger
Voreinstellungen als Default gelten (und nicht irgend ein gcc, der
versuchen soll, ein Lauffähiges Windows Programm zu erstellen).

Ich würde am liebsten nur jeweils den Controllertyp auswählen müssen.

Hat das irgendwer zufällig im Griff?


Gruß, Michael

Autor: Peter Winter (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Versuchs mal damit. Ist eine frühe Beta-Version. Einfach ins
Plug-Ins-Verzeichnis kopieren und los gehts. Die Hex-File-Erzeugung hab
ich über einen Post-Build step implementiert.

Gruß
Peter

Autor: MSE (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Peter

Ich hab Dein Plugin mal auspprobiert. Hast Du bisher nur die Assembler
Unterstützung implementiert oder übersehe ich etwas?

Gruß, Michael

Autor: Peter Winter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Michael,
eigentlich kann man mit dem Plugin Managed-Make Projekte in C, C++???
und Assembler verwalten. Zum testen verwende ich ein Projekt, das
mehreren Bibliotheken erzeugt. Diese Libs werden dann von weiteren
Sourcefiles verwendet und gemeinsam zu einem ausführbaren Programm
gelinkt.
Erzeuge mal ein neues "Managed Make C Projekt" und wähle als Project
Type Executable(AVR) aus.
Was wird Dir unter "Properties|C/C++ Build|Tool Settings" alles
angezeigt?
Gruß
Peter

Autor: MSE (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Aha, jetzt habe ich einmal ein c- statt eines c++-Projekts angelegt und
sehe nun, was Du alles für Compiler- und Linkereinstellungen eingebaut
hast.
Was mich jetzt noch davon abhält, mein Projekt zu builden ist die
Device-Einstellung für den Compiler: '-mmcu=avrn' müßte in
'-mmcu=atmega128' oder der gleichen geändert werden.

Wie funktioniert es denn bei Dir bisher?

Ich lege momentan all meine neuen Projekte immer wieder von Hand und
beim Urschleim beginnend an:
 Überall 'g++' in 'avr-g++' umwandeln, 'mmcu=atmega128' einfügen
etc.

Gruß, Michael

Autor: Peter Winter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mit der Option -mmcu=AVRx wird die Architektur eingestellt. Wenn Du den
Prozessor angeben möchtest kannst Du unter "Properties|C/C++
Build|Tool Settings|Symbols" ein neues Symbol für den Prozessor
anlegen (z.B. _AVR_ATmega128_).
Natürlich müssen die entsprechenden Einstellungen für Deine
gegebenheiten vorgenommen werden. Änderungen wie g++ -> avr-g++ sind
aber nicht nötig. Wie ich bereits anfangs geschrieben habe ist das
ganze eine Beta-Version und ich habe noch nicht alle Einstellungen
getestet bzw. es fehlen vielleicht auch noch Optionen.
Gruß
Peter

Autor: MSE (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
OK, hab ich jetzt nachvollzogen, das mit dem Symbol
'__AVR_ATmega128__' klappt, ich kann's compilieren.
Leider funktioniert das bisher nur mit c-Files und nicht mit c++-Files,
oder?
Sehr interessant ansonsten.

Wie hast Du das gemacht?
Mit dem 'Managed Build System Extensibility Document'?
Anhand des Beispiels 'Tutorial: An Example Tool Integration'?

Ich habe das probiert, kam aber nicht zurecht damit. Ist mir auf die
Schnelle zu kompliziert (ich stand und stehe unter einem gewissen
Zeitdruck, d.h. ich kann mich nicht beliebig lange mit der Technik der
Werkzeuge beschäftigen sondern muss irgendwie damit arbeiten).

Gruß, Michael

Autor: Peter Winter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Leider habe ich noch keinen Test mit c++-Files gemacht. Vielleicht
kannst Du mal beschreiben was geht bzw. nicht geht.
Die Basis für das Plugin bildet das von Dir o.g. Dokument. Ich habe
noch keine Beschreibung für die 3.0 Version gefunden, daher musste ich
vieles durch probieren herausfinden (und ständig neue Updates des CDK
ziehen). Eigentlich habe ich auch keine Zeit mir die Werkzeuge
anzupassen. Aber mit den frei verfügbaren Editoren war ich nicht
zufrieden und Eclipse bietet sehr viele Möglichkeiten. Falls Du (oder
sonst jemand) Vorschläge zur Verbesserung hast werde ich versuchen
diese bei Gelegenheit umzusetzen.
Gruß
Peter

Autor: MSE (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nun, es werden einfach keine Compilationsregeln für *.cpp-Files
erstellt, so dass diese völlig ignoriert werden.
Der Versuch, dem Compiler in *.c-Files irgendwelche c++-typischen
Sachen unterzujubeln, scheitert daran, dass der Compiler nur reines c
erwartet und z.B. das Schlüsselwort 'class' als Fehler erkennt.

Verbesserungsvorschlag: Einfach auch noch den Punkt 'C++-Projekt'
entsprechend ausbauen.

Du hast ja schon einiges geleistet, Respekt!
(Wie gesagt, ich habe mich zu dumm dabei angestellt. Ich habe es gar
nicht geschafft, den Compiler überhaupt aufrufen zu lassen, irgendwas
ging immer völlig schief.)

Gruß, Michael

Autor: MSE (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe mir erlaubt, einen tieferen Blick in Dein Werk zu tun und bin
guter Hoffnung, dass ich daraus genug lernen kann, um (gernügend Zeit
vorausgesetzt :) ) doch noch selber einige Anpassungen vorzunehmen.

Heute (und wahrscheinlich den Rest dieser Woche) wird es wohl nix mehr
aber schaun wir mal...

Auf jeden Fall erstmal Danke für Deine Antworten und Deine Hilfe. Wenn
ich irgendwas hinbekommen sollte, melde ich mich wieder.


Gruß,
Michael

Autor: Peter Winter (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Habe mal die fehlenden C++ Compiler-Optionen ergänzt.

Gruß
Peter

Autor: MSE (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Halla Peter,

vielen Dank dafür, ich hab's mir sofort heruntergeladen. Bis ich Zeit
finde, es mir anzuschauen wird es aber noch etwas dauern.

Gruß, Michael

Autor: Fabian Thiele (ape)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
Respekt damit wollt ich mich auch schon immer beschäftigen habs bisher
aber immer so gelöst das ich ein Standard Make C Project gemacht habe
und das Makefile selber gemacht habe, Managed Make ist aber schon
komfortabler.
Aber wo sage ich ihm wo mein Include Path liegt? Ich bekomm jetzt immer
Warnings wie z.B.: C/C++ Indexer Problem: Preprocessor Inclusion not
found: avr/io.h in file: ...
Bei Standard Make C Projects konnte man den Include Path direkt in den
Project Properties angeben, bei Managed Make existiert dieser Punkt
nich ...

Autor: Peter Winter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dabei handelt es sich um ein Problem des Indexers. Bis mir was besseres
einfällt, unter "Properties|C/C++ Build|Tool Settings|AVR-GCC C
Compiler|General|Include paths (-I)" einen Pfad auf das Verzeichnis
mit den Standard-Includes (z.B. bei mir
C:\Programme\WinAVR\avr\include) und schon sind die Fehler
verschwunden.

Gruß
Peter

Autor: Claus Mayer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Peter Winter,

ich habe Ihr plugin erfolgreich in eclipse zu Laufen bekommen. Es
funktioniert sehr gut und ich muß nun auch nicht mehr bei jedem neuen
Projekt die makefile-Arie durchsingen.
Leider schaffe ich es nicht, ein hilfreiches Target generisch
hinzuzufügen, nämlich das Starten des ISP mit avrdude.

dieses Target hatte ich bislang in meinen Makefiles enthalten, so daß
ein Wechsel auf eine anderes ISP-Programm nicht nötig war.

Bei Bedarf schicke ich das Target zu, wenn Sie es in eine neue Version
integrieren.

Gruß,

Claus

Autor: Peter Winter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Claus,
bisher habe ich avrdude nicht verwendet. Schick mir doch bitte das
Target und ich versuch mal, was ich damit machen kann. Das Plugin ist
noch nicht fertig! Es wird noch einige Erweiterungen bzw. Änderungen
geben. Ich arbeite gerade an der Hex-File Erstellung und denke über die
Integration eines Debuggers nach. Falls Du weitere Vorschläge/Wünsche
hast, einfach melden.

Gruß
Peter

Autor: Claus Mayer (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Peter,

danke für die schnelle Antwort.
Anbei der Teil des makefiles, der avrdude-Anteile enthält.

Ich habe dort drei Targets,
- Nur eeprom neu beschreiben
- Nur Flash-RAM neu beschreiben
- Beides neu beschreiben.

Ganz wesentlich fehlt in Deinem bisherigen makefile wohl die Variable
$TARGET (Im Bespiel "pstore"). Der Rest ist ziemlich generisch.

Ich freue mich auf Deine Antwort,

viele Grüße,

Claus

Autor: Sascha (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!
Ich habe folgendes Problem:
Ich muss möglichst schnell mein Eclipse 3.1.1 c/c++ fähig machen.

Das cdt 3.0 habe ich bereits "installiert".
Was benötige ich denn noch um meine Programme unter Eclipse laufen zu
lassen?
Man sagte mir ich solle gcc3.3.1 verwenden. leider weiß ich beim besten
willen nicht was ich damit anfagen soll.

Könnt ihr mir weiter helfen?

Grüße
Sascha

Autor: Hubert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>>Was benötige ich denn noch um meine Programme unter Eclipse laufen zu
lassen?

Vorallem sehr viel Zeit...

Autor: Peter Winter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Sascha,
Deine Frage passt zwar nicht hier her, aber was Dir nocht fehlt ist die
Toolchain (Compiler, Linker ...). Such mal nach MinGW oder Cygwin.
Dann kann es los gehen.
Warum man mehr Zeit brauchen soll, als mit anderen IDEs ist mir nicht
ganz klar. Wahrscheinlich liegts aber an der persönlichen Einstellung
und den Randbedingungen. Darum gibt es ja auch eine große Auswahl an
Tools aus denen jeder das für sich passende auswählen kann. Gell
Hubert!

Gruß
Peter

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!

Wie schaut es eigentlich mit dem Debugging in
Eclipse mittels simulavr und avr-gdb aus?

Gruß
Stefan

Autor: Jonas Diemer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!

Das ist mal n cooles Plugin! Danke! Gibt es dazu auch ne Website oder
ist das bisher nur hier im Forum bekannt? Könnte ja durch aush noch
andere interessieren.

Ich habe auch gleich ein Problem: Beim Managed Make scheint er die
Assembler Dateien nicht mitzubauen.. Mag das an der
Groß-/Kleinschreibung der Datei liegen? (Ich arbeite unter Windows)

Gruß

Autor: Peter Winter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe noch keinen Test mit Assembler Dateien gemacht. Vielleicht gibt
es da noch Fehler. Groß-/Kleinschreibung sollte kein Problem sein.
Leider habe ich momentan nicht genug Zeit um am Plugin weiter zu
arbeiten. Auf meiner ToDo-Liste sind noch einige Punkte. Danach werde
ich mich um eine Website usw. kümmern.

Gruß
Peter

Autor: Jonas Diemer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Habs selber herausgefunden: In einer der neueren eclipse-Versionen ist
*.S (groß S) nicht mehr als Assembler-Datei definiert. Dies führt dazu,
dass das Plugin die *.S Dateien ignoriert. *.s Dateien bekommt der gcc
nicht assembliert, daher muss man

 In den Project-Properties einen neuen File Type .S definieren.

Außerdem waren bei mir noch folgende Dinge nötig (unter Project
Properties -> C/C++ Build -> Tool Settings -> AVR-GCC Assembler):

* unter command  oder unter general->Assembler Flags folgende
Optionen:
** -nostdlib -D__AVR_ATmega8__
* den MCU type auf Avr4 setzen

Vielleicht kannst du diese Optionen bei der nächsten Version
übernehmen. Gut wäre auch, wenn man die mcu type und das device type
nur einmal setzen müsste (für asm und c)

Gruß

Autor: Jonas Diemer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dazu fällt mir nochwas ein: Momentan zeigt mir eclipse an, dass der C
Indexer #includes wie <avr/interrupt.h> nicht findet. Irgendwo müsste
man ihm doch sagen können, dass er im WinAVR-Verzeichnis suchen soll.
Nur wo?

Gruß

Autor: Andreas Kielkopf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich bin gerade selbst dabei mit Eclipse und AVR anzufangen. Mit Java
arbeite ich schon lang, mit Eclipse seit es Eclipse gibt. Mit dem Avr
aber bin ich ganz neu.

Das oben angeführte Plugin hab ich noch nicht probiert, aber ich hab
meine eigenen Erfahrungen hier im Wiki unter AVR Eclipse abgelegt.

Wenn ihr eure Erfahrung mit einbringen würdet, wär das für viele Leser
sicher übersichtlicher, als hier jede Mail lesen zu müssen.

Übrigens hat ich das Problem mit dem Indexer auch, bis ich seine
Optionen verändert hab. (steht im Wiki)

Wenn einige meiner Einstellungen falsch oder überholt sind, freue ich
mich über jede Änderung auf der Seite.

Gruß AndreasK

Autor: Jonas Diemer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi!

Ich habe neulich 5h geopfert, herauszufinden, dass das eclipse plugin
irgendwie die interruptvektoren nicht korrekt setzt (oder irgendeine
gcc option vergisst oder zuviel setzt, die dies bewirkt).

Konkreter: Ich habe bei meinem mega8 einen timer0ovf interrupt
konfiguriert. Leider löst der timer0irq nicht aus, jedenfalls nicht
wenn man das eclipse plugin verwendet. Mit dem Makefile aus der WinAVR
distro war alles kein Problem.

Ich habe meinen Code auf das wesentliche reduziert, hier der
Problematische code:

SIGNAL(SIG_OVERFLOW0){
  PORTD = 0x00:
}

int main(void){
  DDRD = 0xff;
  TCCR0 = _BV(CS02);
  TIMSK = _BV(TOIE0);
  sei();

  while(1){ PORTD=0xff; }
}

Vielleicht weiß jemand, welche option im Plugin fehlt. Ich werde wohl
erstmal wieder auf Makefiles umsteigen, bin aber gern bereit, neue
Versionen des Plugins zu testen. Ich poste auch mal eine Warnung im
Wiki (damit anderen die 5h Sucherei erspart bleibt :-)) )

Gruß

Autor: Peter Winter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Jonas,
schick doch mal das List-File von beiden Varianten. Damit sollte es
einfach sein den Fehler zu lokalisieren und die entsprechende
Compiler-Option zu finden.

Gruß
Peter

Autor: Jonas Diemer (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
So, anbei die listings. Ich hab auf anhieb nicht gesehen, worans liegt,
habs aber auch nur kurz überflogen.

Gruß

Autor: Patrick Dohmen (oldbug) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Was mich jetzt noch davon abhält, mein Projekt zu builden ist die
>Device-Einstellung für den Compiler: '-mmcu=avrn' müßte in
>'-mmcu=atmega128' oder der gleichen geändert werden.

Hast Du das beachtet?
Scheinbar nämlich nicht:

aus main-gut.lst:
   1                   .file  "main.c"
   2                   .arch atmega16

aus main-schlecht.lst:
   1                   .file  "main.c"
   2                   .arch avr4

Du musst also nicht -mmcu=avr4, sondern -mmcu=atmega16 einstellen!

Autor: Peter Winter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie Patrick richtig erkannt hat ist die -mmcu Option der einzige
relevante Unterschied zwischen den beiden Files. Im funktionierenden
Programm gibt es noch einige zusätzliche Labels die aber keinen Einfluß
haben sollten. Daher vermute ich das Problem beim Linken. Kannst Du mir
noch die Hex-Files schicken?

Autor: Patrick Dohmen (oldbug) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das wird allerdings nicht sehr viel nützen.
Viel wichtiger wäre die Kommandozeile, die den gcc aufruft.

Autor: Jonas Diemer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, die mmcu option hatte ich so gelassen, wie das plugin das vorschlug,
mämlich avr4 und dann als Symbol _AVR_ATmega16_ angelegt. Reicht das
nicht?

Ich versuche das evtl. heute abend alles nochmal und poste dann ggf
compiler flags etc.

Gruß

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> ... mämlich avr4 und dann als Symbol _AVR_ATmega16_ angelegt.
> Reicht das nicht?

Ja, das reicht nicht.

_AVR_ATmega16_ beginnt mit einem doppelten Unterstrich, damit ist
das für dich tabu es sei denn, die Doku (von Compiler oder Bibltiothek
-- die beiden haben die Autorität über derartige Symbole) würde von
dir irgendwo verlangen, dass du ein derartiges Symbol anlegst.

Die Doku verlangt aber stattdessen von dir, nach -mmcu= den Typ des
Controllers anzugeben.

Autor: Peter Winter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Genau das wollte ich aber vermeiden. Denn damit ist man gezwungen für
jeden neuen Controller-Typ das Plugin zu erweitern. Über die Auswahl
der Prozessor Architektur (-mmcu= avr1 bis avr5) und der Angabe des
genauen Typs durch den Benutzer sollte das vermieden werden.

@Jörg
Du bist auch in allen Foren zu finden. Kannst Du bitte etwas genauer
auf die technischen Hintergründe eingehen. Dann kann ich das in der
nächsten Version anpassen.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Genau das wollte ich aber vermeiden. Denn damit ist man gezwungen für
> jeden neuen Controller-Typ das Plugin zu erweitern.

Sorry, lässt sich nicht ernsthaft vermeiden.  Wir müssen auch für
jeden neuen Controllertyp den GCC und die binutils erweitern --
bislang ist uns da noch nichts Besseres eingefallen.

Wenn dir's Spaß macht, kannst du ja (z. B. einmal pro Sitzung beim
Start) eine leere C-Dummy-Datei anlegen und den avr-gcc mit -mmcu=foo
auf diese Datei ansetzen.  In der Fehlermeldung bekommst du dann die
Liste aller unterstütztere MCU-Typen.  Blende avr[1-5] aus, und du
hast deine Liste.

> Kannst Du bitte etwas genauer auf die technischen Hintergründe
> eingehen.

Das -mmcu= ist insbesondere dafür vonnöten, dass der Compiler beim
Start des Linkers das korrekte crt*.o-File auswählt (und ggf. andere
Optionen wie einen geänderten RAM-Bereich).  Theoretisch würde deine
Variante vielleicht für den reinen Compiler sogar funktionieren, aber
für den Linker tut's sowieso nicht, und aus unserer Sicht (Hersteller
von Compiler und Bibliothek) ist sie auch nicht supportet, d.h. falls
wir mal was ändern wollen, würden wir das -mmcu=-Interface
beibehalten, aber nicht notwendigerweise die Abstraktion für avr1 bis
avr5.

Autor: Jonas Diemer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gut, dann wird's wohl am falschen -mmcu gelegen haben. Kann man das
Plugin nicht so erweitern, dass alle heutigen mcus drin sind und man
aber stattdessen auch einen string angeben kann? Dann hätte man den
komfort, dass mans auswählen kann und die flexibilität, zukünftige mcus
zu unterstützen. Jörgs vorschlag wäre natürlich noch komfortabler, aber
sieht n bisserl gehäckt aus :-)

Autor: Peter Winter (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
In den nächsten Tagen habe ich leider noch weniger Zeit (Firma zieht um
und da war noch irgend was...). Daher hier der aktuelle Stand. Die
-mmcu Option, die Hex- und List-File Erzeugung ist geändert. Alles aber
nicht besonders gut getestet! Viel Spass beim Probieren.

Autor: Marcel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich hab das mal ausprobiert, das C-Projekt scheint zu funktionieren.
beim C++ Projekt werden bei den Einstellungen anstatt der
Linkereinstellung nochmal die Compilereinstellungen angezeigt. Und dort
wird immer ein falscher mmcu-Wert angezeigt. Wenn ich den Eintrag ändere
steht das zwar so im Auswahlfeld, aber die Kommandline, die dann später
ausgeführt wird enthält wieder den falschen Wert.

Viele Grüße

Autor: Peter Winter (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Diesen Fehler habe ich bereits korrigiert. Folgende Erweiterungen sind
in dieser Version enthalten:
- Debug-Informationen für den Assembler einstellbar
- Weitere Parameter beim Hex-File erstellen hinzugefügt
- Linux-Variante freigeschaltet

Gruß Peter

Autor: Marcel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Peter,

ich hatte immernoch das Problem, dass mein Programm mit Timerinterrupt
nicht funktioniert hat.Ich habe dann mal die Compiler und
Linkeroptionen mit denen des AVRStudio verglichen. Dort wurde beim
Linken auch noch der Typ mit -mmcu=xxx angegeben. Als ich das in den
Properties direkt der Kommandline hinzugefügt habe, hat es
funktioniert. Vielleicht kann man dafür auch noch ein Dropdownfeld
einfügen.

Nochmal Danke für das Plugin, Eclipse ist einfach die beste IDE :-)

Gruß
Marcel

o. t. Wo hast du das Knowhow über Eclipse her? Kannst du ein paar gute
Links empfehlen?

Autor: AndreasH (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich habe mir Eclipse runtergeladen und das Plugin von Peter.

Nach einigem Kampf ist es mir gelungen ein Projekt mit mehreren Dateien
(auch Assembler) zu compilieren.
Für die Assembler-Dateien musste ich in den Projekteinstellungen noch
mehrere Flags setzen weil ansonsten mehrere Fehler ausgegeben wurden.

Jetzt bekomme ich noch folgenden Fehler:
Generating Extended Listing-File
Usage: c:\WinAVR\bin\avr-objdump.exe <option(s)> <file(s)>
 Display information from object <file(s)>.
 At least one of the following switches must be given:
Dann werden die ganzen Optionen aufgezählt.

Mir ist im Moment nicht klar wie ich den wegbekomme.
Kann mir hier jemand einen Tip geben.

>o. t. Wo hast du das Knowhow über Eclipse her? Kannst du ein paar
>gute Links empfehlen?
Das würde mich auch interessieren.

Ausserdem würde ich die zusätzlichen Flags gerne für das nächste
Projekt voreinstellen. Wie kann ich das machen?

Danke im Voraus
Andreas

Autor: Peter Winter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Andreas,
welche Flags hast Du zusätzlich gesetzt? Vielleicht kann ich die ins
Plugin einbauen.
Die Fehlermeldung deutet darauf hin, daß Du irgend welche Einstellungen
vergessen oder falsch eingestellt hast. Bei mir funktioniert es mit -h
-S, sonst hab ich nichts aktiviert.
Eine Voreinstellung (bzw. Übernahme) der Flags für/in ein neues Projekt
ist derzeit nicht möglich.
Zum Thema Links: Leider gibt es bisher nichts brauchbares bis auf das
Managed Build System Extensibility Document. Wer was anderes findet
bitte mir mitteilen.
@Marcel
Ich versuche gerade die -mmcu=xxx Option in eine globale Einstellung
für das gesamte Projekt zu ändern. Funktioniert leider noch nicht
richtig. Dann sollte das Problem behoben sein und die Auswahl muß nur
noch ein mal vorgenommen werden.

Gruß Peter

Autor: AndreasH (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Peter,

ich hatte beim assemblieren von Assembler-Dateien Schwierigkeiten.
Daher habe ich folgende Änderungen vorgenommen:

ALT                          NEU
avr-gcc -S                   avr-gcc -c

bei miscellaneous:
ALT                          NEU
                             -x assembler-with-cpp -Wa

Ohne diese beiden Änderungen habe ich meine Assembler-Datei nicht
compiliert bekommen.
Dafür habe ich mir die Flags im Make-File von Jörg, d.h. das man  mit
mfile erstellen kann, angesehen.
Danach ging es.

Mit den Flags für "avr-objdump.exe" hast Du recht. Da habe ich den
Wald vor lauter Bäumen nicht gesehen. Wusste nicht wo ich dem welche
Flags einstellen konnte.
Läuft jetzt einwandfrei

Vorab schon mal Danke
Andreas

Autor: Karsten Schmidt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich habe das Plugin installiert, die erste Übung alte File mit uart und
lcd liefen nach einigen Versuchen problemlos. Danke Peter!

Einige "Problemchen" sind mir aber noch aufgefallen:
+ Den Prozessortyp muss ich an zwei Stellen einstellen. Hier sehe ich
ein hohes Fehlerpotenzial.
+ Includes. Bei mir werden in der Projektansicht die Includes von minGW
"importiert" und leider nicht die Includes der avr-library. Kann man
das irgendwo einstellen?
+ Kann man das "Makefile" auch als normales Makefile exportieren.
Wahrscheinlich habe ich da wieder mal etwas übersehen.

Gruß und vielen Dank

Karsten

Autor: Peter Winter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Karsten,
ich arbeite schon einige Zeit daran, den Prozessortyp nur einmal
einstellen zu müssen. Leider verhält sich das CDT hier etwas
unkooperativ. Ich gebe aber nicht so schnell auf.
Die Pfade kann man über "Properties|C/C++ Build|Environment"
einstellen bzw. verändern. Wähle dort mal "New" und setze den Pfad
(PATH, Replace)ausschließlich auf das AVR Verzeichnis. Hab ich aber
nicht ausprobiert.
Die Makefiles liegen im Projektverzeichnis (bestehen aus mehreren
Teilen). Also solltest Du die auch extern verwenden können. Hab ich
auch noch nicht probiert.

Gruß
Peter

Autor: Alexander Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

bin gerade mal wieder auf dieses Forum gestossen. Irgendwie führen
viele Wege zu www.mikrocontroller.net :-)))

Ich mache gerade meine ersten Gehversuche mit Eclipse. Habe mit dazu
die letzte Version von Eclipse (3.1.2) und CDT (3.0.2) runtergeladen
und in ein passendes Verzeichnis installiert/entpackt.
Dann habe ich das oben genannte Plugin (Version 1.0.16) gefunden und
ebenfalls installieren wollen.
Und hier beginnt mein Problem:
Ich lege ein neues "managed make c" Projekt an und möchte über
Project/Properties C/C++ Build den Project Type wie oben beschrieben
einstellen. Leider ist die zugehörige ComboBox verriegelt (grau) ich
kann nichts auswählen :-(
Ich bekomme als letzten Hinweis unter "Problems":
"Error launching external scanner info generator (gcc -E -P -v -dD
PfadzuWorkspace/.metadatei/.plugins/org.eclipse.cdt.make.core/specs.c"

Bin jetzt etwas irritiert. Setzt Eclipse einen gcc voraus / muss ein
"normaler" gcc ebenfalls installiert sein? Was habe ich vergessen,
oder übersehe ich?

Alexander

Autor: Peter Winter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Alexander,
da fallen mir zwei mögliche Ursachen ein:
- Eclipse hat das Plug-in nicht richtig erkannt. Starte Eclipse mit der
Option "-clean". Überprüfe über "Help|About Eclipse SDK|Plug-in
Details" ob das Plug-in aktiviert wurde.
- beim Erstellen des Projekts hast Du nicht den richtigen Projekttyp
ausgewählt.
Grundsätzlich muß kein gcc installiert sein, um Eclipse + Plug-in zu
aktivieren. Du kannst aber ohne eine Toolchain nichts damit anfangen.

Gruß
Peter

Autor: Alexander Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Peter,

der erste Versuch mit /clean brachte nichts. Ich habe dann mal meinen
Eclipse Ordner in die oberste Ebene geschoben, Meinen Workspace Ordner
ebenfalls. Dann habe ich das Projekt nochmal neu angelegt.

Jetzt erscheint's zumindest beim Anlegen eines neuen Projekts in der
Auswahl :-)

Hatte so den Eindruck, dass Eclipse Probleme mit langen Dateinamen,
bzw. Leerzeichen darin hat?!
Ausserdem konnte ich mich dann dunkel erinnern, dass ich mal Cygwin uf
dem Rechner hatte, und habe dann mal ein gcc Projekt probiert. Das
machte dann auch prompt Stress, wegen Versionskonflikten der
cygwin1.dll (WinAVR hat ja ne eigene dabei). Muss also wohl noch etwas
"basteln"(tm).

Andere Frage: den Projekttyp kann man demnach nur beim Anlegen des
Projekts festlegen? Das Feld ist nämlich immer noch grau, wenn ich
nachträglich in die Porperties schaue...

Gruss&Merci

Alexander, der sich jetzt die Ärmel hochkrempelt ;-)

Autor: Patrick Dohmen (oldbug) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe da ein ähnliches Problem wie Karsten.
Es werden ausschliesslich die Cygwin-Includes angezeigt. Ein Editieren
der Environment-Variablen bringt keine Abhilfe. Ausserdem bekomme ich
beim Anlegen eines Projektes immer die Fehlermeldung:

Severity  Description  Resource  In Folder
1  Error launching 'cygpath' command  blablubb      24. Februar 2006
11:20:21

Ich kann aber auch nicht Kompilieren, es wird kein einziges Headerfile
gefunden.

Autor: Torsten (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe das Eclipse Plugin avrgcc_1.0.16 installiert, verwende
AVR-Managed-Make und habe das gleiche Problem wie Marcel (weiter
oben):

Sobald ich im Programm Funktionen oder ISR verwende, dann funktioniert
der Controller AT90S2333 nicht mehr.

Ich habe die beiden Werte -mmcu=at90s2333 beim Assembler und beim
Compiler gesetzt.

Bei der Suche nach den Ursachen bin ich fündig geworden.
Beim Linken wird aber das File crts8515.o anstelle von crts2333.o
geladen.

Hier ein Auszug aus dem Map-File
---
Linker script and memory map

LOAD d:/WinAVR/bin/../lib/gcc/avr/3.4.5/../../../../avr/lib/crts8515.o
LOAD ./src/vqc10ctrl.o
LOAD d:/WinAVR/bin/../lib/gcc/avr/3.4.5/../../../../avr/lib\libm.a
LOAD d:/WinAVR/lib/gcc/avr/3.4.5\libgcc.a
LOAD d:/WinAVR/bin/../lib/gcc/avr/3.4.5/../../../../avr/lib\libc.a
LOAD d:/WinAVR/lib/gcc/avr/3.4.5\libgcc.a
---

Das Setzen des Wertes -mmcu=at90s2333 bei den Linker
Einstellungen/Command line pattern hat nichts gebracht, denn der Linker
verwendet diesen Wert offenbar gar nicht.
Offenbar wird durch die crts8515.o der Stack-pointer falsch gesetzt und
bei einem Funktionsaufruf oder ISR stürzt der Controller ab.

Wie bringt man den Compiler/Linker dazu, die korrekten Werte zu
verwenden?

Viele Grüße
Torsten

Autor: Stefan Lehminger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich versuche mich auch gerade daran, mir eine Entwicklungsumgebung für
Atmega16 aufzusetzen. Eclipse habe ich allerdings noch nie benutzt.
Aber soweit (Dank diesem geilen PlugIn) funktioniert schon alles. Aber
eine Sache stört mich noch:
Wie kann ich die compilierten Dateien sortiert ausgeben? Also z.B. die
.o - Dateien in einen Ordner objects, die .hex und .elf -Dateien in
einen Ordner binary?
Außerdem möchte ich gerne noch das Doxygen-PlugIn benutzen. Wie kann
ich das in den automatisierten Ablauf mit einbinden?

Autor: Steffen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi!

Für ein Projekt muss ich einen Atmega16 mit C programmieren. In diesem
Forum bin auch auf das Eclipse Plugin von WinAVR gestoßen, welches mir
sehr gut gefällt! --> Gute Arbeit ;)

Nun versuche ich mich gerade daran, Beispielcode aus dem WinAVR Ordner
zu kompilieren (klappt auch sehr gut), und anschließend möchte ich die
erzeugte Datei debuggen können. Dazu möchte ich auch das Eclpise PlugIn
verwenden. Ich starte den simulavr durch den folgenden Aufruf:
"simulavr -g -p 10000 -d atmega16 -P simulavr-disp".
Wenn ich nun den Debugger starte, wird folgende Fehlermeldung
angezeigt: "Execution is suspended because of error."

Woran liegt das? Welche Eintsellungen habe ich vergessen?

Danke für eure Hilfe,
Gruß Steffen

Autor: MSE (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hei Peter Winter,

Ich habe gerade Deine letzte Version des Plugins heruntergeladen und
ausprobiert. Das sieht ja richtig toll aus! Vielen Dank für die Arbeit,
die Du Dir gemacht hast und deren Ergebnis Du mit uns allen teilst.

Ich selbst mußte leider erkennen, dass ich zu blöd bin, soetwas selber
zu machen (bzw. es hätte mich erheblichen Einarbeitungsaufwand
gekostet, den ich einfach nicht aufbringen konnte.)

Gruß, Michael  :)

Autor: Steffen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi!

Vor ca. 2 Wochen hatte ich ein Problem meinerseits mit simulavr
geschildert (2 Posts oberhalb).

Ich habe das Problem trotz hohem Aufwand leider immer noch nicht lösen
können... Kann mir wirklich keiner helfen???

Steffen

Autor: eumh (Gast)
Datum:
Angehängte Dateien:
  • gdbinit (55 Bytes, 780 Downloads)

Bewertung
0 lesenswert
nicht lesenswert
Hi Steffen

Mit den folgenden Einstellungen läufts bei mir.

1.) simulavr von Konsole starten:
     >> simulavr -g -p 1212 -d atmega8 -P simulavr-disp

2.) Eclipse
     Debug-->C/C++ Local Application
       Main:
         Projekt: AVR-Test (oder wie auch immer)
         C/C++ Application: Debug/AVR-Test.elf
       Debugger:
         Debugger: gdbserver Debugger
         Main:
           GDB debugger: avr-gdb
           GDB command file: gdbinit (ist angehängt)
         Connection:
           Type: TCP
           Hostname or IP: localhost
           Portnumber: 1212

Und das wars auch schon:)

Autor: Nikias Klohr (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Ich bin echt am verzweifeln. Ich versuche die ganze Zeit die
Proycon-Libraries in mein Projekt unter Eclipse einzubinden. Der Linker
beschwert sich mangels objekt-Dateien aber das er die Funktionen nicht
finden kann! Wie bekomme ich den GCC dazu die Libs von Procyon
mitzukompilieren !?
Hat jemand eine Idee, wie man Procyon + eclipse verwenden kann?

Gruß,
Nikias

Autor: max.p (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo

ICh hab ein problem mit dem Plugin festgestellt. Und zwar mit den Timer
beim ATMega 16. Die Pluginversion ist 1.0.16. Wie von Torsten beschriben
wird auch bei mir die crts8515.o automatisch geladen.
Hat inzwischen jemand eine möglichkeig gefunden das problem zu lösen?

mfg
Max

Autor: Wilfried (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Ich habe gerade versucht das Plugin zu installieren, aber bekomme es
einfach zum Laufen.

Ich habe das Eclipse-SDK 3.1.2 und das Plugin (unter Linux) in
"/opt/eclipse/plugins" kopiert. Ein Versuch es in
"~/.eclipse/plugins/" zu installieren ging auch nicht.

Gibts eine Möglichkeit in irgendeinem Logfile zu schaun, warum das
Plugin nicht geladen wird?

Danke für Hilfe.

Wilfried

Autor: Wilfried (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sorry, im ersten Satz fehlt ein "nicht".

Autor: Wilfried (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hab das Plugin jetzt auch am laufen. Habs aus den Verzeichnissen
noch mal gelöscht und noch mal neu kopiert. Warum es vorher nicht ging
ist mir noch ein Rätsel.

Um ein Assembler-File übersetzten zu können musste ich aber auch ein
paar Änderungen machen:

AVR-GCC Assembler:
-Command von "avr-gcc -S" nach "avr-as" geändert, sonst werden
Include-Files nicht gefunden (-I).

AVR-GCC Linker:
-Command von "avr-gcc ..." nach "avr-ld" geändert, sonst gibts
immer eine Fehlermeldung das die "8515crt..?" nicht
gefunden/verarbeitet werden kann. "Generate Mapfile" hab ich auch
ausgeschaltet, die Option kennt der linker wohl nicht.

Ansonsten läuft alles wunderbar, danke für das Plugin =).

Autor: nex0foo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Peter,

erstmal danke, dass ich meine bevorzugte IDE nun auch komfortabel für
die AVR's benutzen kann. Da meine bevorzugte Plattform aber MacOSX
ist, wäre es super, wenn Du mir helfen könntest MacOSX als Target zu
integrieren.
Hab noch nie Plugins für eclipse programmiert, XML ist jedoch kein
Problem :)

Howdy

Autor: nex0foo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Peter,

also es funktioniert auch mit der Linux Version, meldet aber vorher,
das es keine Build Configuration für MacOSX gibt. Ich muss nur die
envirement Variable neu setzen. Kurzum, ich bin begeistert.
(Falls Du die Zeit hast und es nicht viel Arbeit ist die Anpassung an
MacOSX noch zu machen, wäre Dir die Zuneigung der Mac Gemeinde gewiss
:)
Ich benutze übrigens die compilierten Tools von diesem Link
http://www.avrfreaks.org/index.php?module=FreaksFi...


Howdy

Autor: N. K. (bennjo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Auch wenn ich diesen Beitrag jetzt 2x Poste ... hier gehört er Definitiv
auch rein...:

Also nachdem mich dieses Problem jetzt 2 Tage meines Lebens gekostet,
und fast um den Verstand gebracht hat, will ich es anderen ersparen:

Wenn man für den Atmega168 compiliert MUSS man undbedingt dem Linker
mit dem Parameter "-mmcu=atmega168" mitteilen, dass man selbiges
tut.

Ansonsten laufen kleine Test-Programme...sobald es etwas komplizierter
wird oder sobald man char* Konstanten also Strings verwendet bekommt
man ein absolut nicht-deterministisches Verhalten...nach jedem flashen
verhält es sich anders!


Ich hoffe man wird diesen Eintrag mit der Suche finden.

Autor: Martin #### (martin-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Nikias
Das ist keine Linker-Option sondern des Assemblers avr-as

Autor: N. K. (bennjo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Martin:
Dachte ich auch...habs auch nur spaßeshalber einfach mal
ausprobiert...als ich nicht mehr weiterwusste.

Meine Parameter für den Linker im Eclipse-Plugin sehen jetzt
folgendermaßen aus:

-lm -Wl,-Map=$(@:%.elf=%.map) --cref --oformat=elf32-avr
-mmcu=atmega168


und so - UND NUR SO - gehts !

Ich denke der Linker muss wohl wissen für welches Zielsystem gelinked
wird !?

Autor: Philip Mulrane (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi an Peter Winter,
hab Eclipse (WinXP/WinAvr/Eclipse 3.1.2/CTD/MyAVR usw) am laufen mit
der 1.0.16 Version der Plugin. Top Sache!
Aaaabbbbeeeerrrrr........
Eine frage hat ich noch:
ich benutze avrdude vom WinAvr um Eeprom und Flash zu schreiben.
Kein Problem, dachte ich, einfach in der Eclipse PostBuild Step die
richtige Befehl einfügen. Leider wird mein PostBuild Step vor der
"Generating Program Flash-Hex-File" und "Generating Data
EEPROM-Hex-File" ausgeführt. Also zu früh. Gibt es ein Trick um die
von Eclipse als PostBuild Step nach alle andere auszuführen?
,Philip

Autor: Odo Maletzki (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

ich habe ein Projekt, das unter WinAVR mit dem Programmers Notepad
einwandfrei compiliert und linkt (und auf dem ATMega auch läuft;-)
versucht unter Eclipse ans Laufen zu bringen.

leider erhalte ich folgenden Fehler:

Severity and Description  Path  Resource  Location  Creation Time  Id
ld: region text is full (avrtest1.elf section .text)    avrtest1  line
0  1156900583455  2526



Meine Einstellungen:

1) Assembler:
-mmcu=atmega8515 -gstabs

2) Compiler:
-fmessage-length=0 -Wall -Wstrict-prototypes -Wmissing-prototypes
-I"C:\Programme\Atmel\WinAVR\avr\include" -mmcu=atmega8515
-minit-stack=__stack -O0 -fshort-enums -fpack-struct -funsigned-char
-funsigned-bitfields -std=gnu99 -g2

3) Linker:
-lm -Wl,-Map=$(@:%.elf=%.map) --cref --oformat=elf32-avr

4) Object Copy Flash:
-O ihex avrtest1.elf avrtest1.hex

5) Object Copy EEPROM
-O ihex avrtest1.elf avrtest1.eep

6) Object Dump:
-h -S avrtest1.elf >avrtest1.lss

Hat da jemand eine Idee?

Gruß

Odo

Autor: Philip Mulrane (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,
"region text is full" heißt sowas wie Programme zu groß, galub ich.
FWIW,
hier sind meine compiler/linker einstellungen (ich versuce es mit C++)
, alle andere Settings sind bei mir gleich:

Compiler:
-fmessage-length=0
-Wall
-Wstrict-prototypes
-IC:/WinAVR/avr/include
-mmcu=atmega8
-minit-stack=__stack
-D__AVR_ATmega8__
-O0
-fshort-enums
-fpack-struct
-funsigned-char
-funsigned-bitfields
-std=gnu99
-gstabs


Linker:
-lm -Wl,-Map=$(@:%.elf=%.map) --cref --oformat=elf32-avr

Und es gibt kein Quelltext unterschiede zum 'Programmers Notepad'
compilierte version? 'Programmers Notepad' kenn ich nicht aber wann
er auch avr-gcc benutz dann kann mann leicht die Optionen vergleichen.
,Philip

Autor: Michael Z. (incunabulum)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kennt eigentlich jemand eine Doku, wie so ein Plugin konfiguriert wird?


Ähnlich wie bei AvrStudio würde ich gerne beim Compilieren gezeigt
bekommen, wie viel Speicherplatz (Flash etc.) verbraucht ist.

cu, Michael

Autor: Odo Maletzki (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Philip,
danke für die Info.
Es war ein Platzproblem.
Gelöst habe ich das, indem ich den Linkerswitch -lm weggelassen habe


Gruß
Odo

Autor: Daniel Bremenkamp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen.

Ich benutze jetzt auch Eclipse und das AVR-GCC-Plugin. Finde ich super.
Allerdings habe ich noch Probleme beim Einbinden der LCD-Funktionen
(2x16 Zeichen LCD, lcd.c von P. Fleury). Wenn ich per lcd_putc ein
Zeichen ausgebe kommt es korrekt an, wenn ich aber lcd_puts für einen
String benutze steht nur Mist auf dem Display. Ich habe bei jedem
Aufruf des avr-gcc noch ein -DF_CPU=7327800UL angheängt, außerdem habe
ich zur Sicherheit F_CPU in meinem Header definiert (und das sollte mit
dem -D gar nicht mehr nötig sein). Gibt es da evtl. noch andere Stellen,
an denen was zu ändern ist?

Gruß,
Daniel

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Gelöst habe ich das, indem ich den Linkerswitch -lm weggelassen habe

Das ist falsch.

Autor: Markus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Daniel!

Du schreibst

-DF_CPU=7327800UL

Der Quarz hat aber bestimmt 7,372800 MHz(zahlendreher?).

Nur so auf die schnelle...

Und ja, ich bin der Markus, den du meinst... ~|

Gruß
Markus

Autor: Daniel Bremenkamp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ah, automatic! Hallo Markus!

Ja, war ein Zahlendreher. Das hab ich in meinem Projekt auch
ausprobiert, hat aber nichts ausgemacht. Was ich sehr seltsam finde
ist, daß lcd_putc und lcd_command funktioniert, lcd_puts aber nicht.
Ich habe da irgendwie den verdacht, daß der String, den ich an die
Funktion übergebe falsch interpretiert wird.

Gruß, Daniel

Autor: Daniel Bremenkamp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo nochmal zusammen.

Wie oben schonmal beschrieben benutze ich das AVR-GGC-Plugin für
Eclipse in der Version 1.0.16. Nun ist mir beim kompilieren eines
Projektes für einen ATmega64 der folgenden Fehler aufgefallen:

Invoking: AVR-GCC C Linker
avr-gcc -o  "DSP5_Ctrl.elf"  ./DSP5_Control.o ./circular_eeprom.o
./digipoti.o ./effekt_bloecke.o ./init.o ./lcd.o ./uart.o ./userinput.o
   -lm -L"C:\Programme\WinAVR\avr\lib" -Wl,-Map=DSP5_Ctrl.map
--cref --oformat=elf32-avr -DF_CPU=7273800UL
c:\programme\WinAVR\bin\..\lib\gcc\avr\3.4.5\..\..\..\..\avr\bin\ld.exe:
region text is full (DSP5_Ctrl.elf section .text)
avr-make: *** [DSP5_Ctrl.elf] Error 1

d.h., die Text-Region ist anscheinend zu klein.
Wenn ich die Map-Files aus Eclipse und dem AVR-Studio vergleiche ist
die Text-Region bei Eclipse um den Faktor 10 zu klein, im AVR-Studio
jedoch nicht.

MAP-File, AVR-Studio:
Name             Origin             Length             Attributes
text             0x00000000         0x00020000         xr

MAP-File Eclipse:
Name             Origin             Length             Attributes
text             0x00000000         0x00002000         xr

Ist sonst noch jemandem dieser Fehler aufgefallen? Wenn ja, gibt es
schon eine Lösung dafür?

Gruß,
Daniel

Autor: Daniel Bremenkamp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hm, Blödsinn, Faktor 10. Die Region .text ist natürlich um den Faktor 16
zu klein.

Autor: Jaons Dong (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi All,

About the problem "region text is full", I have found the problem:

Add a linker option to:

      AVR-GCC C Linker --> Miscellaneous --> -mmcu=xxxxxxxx

Try it now!



:)

Autor: Peter Winter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Daniel,
wie Jaons Dong richtig festgestellt hat liegt es an der fehlenden
Linker-Option -mmcu=XXX. Der Linker verwendet ohne diese Option ein
Script für einen anderen AVR Controller (vermutlich das
Default-Script). Leider kann ich Parameter nicht global für alle Tools
verwenden, was eigentlich nach der Beschreibung des CDT gehen sollte.
Momentan habe ich aber wenig Zeit um mich darum zu kümmern. Daher
bleibt nur die Möglichkeit diese Option von Hand einzutragen.

Gruß
Peter

Autor: Daniel Bremenkamp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo.

Vielen Dank für die Hilfe, genau das war das Problem.
Und da ich sowieso nicht jeden Tag ein neues Projekt anfange ist es
auch gar kein Problem, kurz diese Zeile in die Projektoptionen
einzufügen.

Jetzt hab ich aber noch eine Frage, das betrifft das Programm
avr-size.
Wenn ich den Befehl über die Windows-Console aufrufe kriege ich genau
das was ich haben will. Dann habe ich die Zeile

avr-size -C -mmcu=atmega64 Projekt.elf

als Post-Build step eingetragen. Das berechnet zwar die Größe das
Programmes, aber nicht die prozentuale Größe im uC. Fehlermeldung:

avr-size -C -mmcu=atmega64 Projekt.elf
AVR Memory Usage
----------------
Device: Unknown

Program:   32150 bytes
(.text + .data + .bootloader)

Data:        419 bytes
(.data + .bss + .noinit)


avr-size: '-mmcu=atmega64': No such file

Gibt's da auch schon einen Hinweis zu? Das ist z.Z. noch nicht
essentiell wichtig, wäre aber schön, wenn ich das auch Eclipse
integriegen könnte.

Gruß,
Daniel

Autor: Michael Z. (incunabulum)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also ich verwendd folgende Option im Post-Build-Step:

avr-size -t -C -o --mcu=atmega32 dogDisplayCpp-I.elf

Damit wird auch entsprechend die Größe in Prozent etc. dargestellt.

cu,mz

Autor: Odo Maletzki (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hmmm.

Leider bekomme ich immer noch den Fehler "Region text is full"

--->
Building target: Application.elf
Invoking: AVR-GCC C++ Linker
avr-g++ -o  "Application.elf"  ./Application.o ./Dcf77.o ./Hardware.o
./SigCounter.o ./Stopwatch.o    -lm -Wl,-Map=Application.map --cref
--oformat=elf32-avr -mmcu=atmega8515 -funsigned-char
-funsigned-bitfields -fshort-enums -Wall  -std=gnu++98 -Os -gstabs
c:\Programme\Atmel\WinAVR\bin\..\lib\gcc\avr\3.4.6\..\..\..\..\avr\bin\l 
d.exe:
region text is full (Application.elf section .text)
make: *** [Application.elf] Error 1
make: Target `all' not remade because of errors.
Build complete for project Application
<---

Die -mmcu - Linker-Option alleine scheint es also nicht zu sein...

Gruss
Odo

Autor: Martin Schneider (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielleicht fehlt ja nur ein "-" bei der mmcu-Option??

Autor: Holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So nett wie das hier beschriebene plugin auch ist, es fehlt mir die 
Einbindung des avrdude. Als post-build-step ist es m.E. nicht sehr 
sinnvoll, will ich doch nicht unbedingt nach jedem Compiliervorgang den 
Flash- bzw. EEPROM-Speicher neu beschreiben.
Daher habe ich als Lösung 'avrdude' als ein externes Tool eingebunden.

Hierzu musste lediglich unter 
Run/ExternalTools/ExternalTools.../Location der Ort von avrdude.exe 
eingetragen werden. Arbeitsverzeichnis erhielt den Eintrag 
${workspace_loc:/test1/Release} und als Parameter wurden bei meinem 
STK500-Board
avrdude -p atmega8 -P com1 -c stk500v2 -U flash:w:${project_name}.hex

Hier müssen ggf. individuelle Anpassungen vorgenommen werden.

Von nun an lässt sich recht komfortabel mit einem Mausklick der 
Flash-Vorgang starten.


Holger

Autor: Mark Struberg (struberg)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi!

Ich hab das plugin auch mal versucht und nach einer Nacht durchdebuggen 
warum mein Program nicht geht (hab den Fehler zerst lange bei mir 
gesucht), bin ich auf folgendes Problem gestoßen:

In den Linker settings muß wohl auch noch der -mmcpu switch rein.

Ohne -mmcu swith sind zB die elf files für ATtiny26 nicht korrekt.

Autor: Julius Krebs (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

sämtliche Plugins sind installiert, unter Projet Properties -> C/C++ 
Build -> Tool Settings -> Avr-GCC C Linker -> Miscellaneous -> wurde die 
Zeile "-mmcu=atmega32" hinzufgefügt, da zuvor der "region text is full" 
Fehler angezeigt wurde.
Nun kommt es leider zu einem weiteren Fehler, den ich mir nicht erklären 
kann (letzter Abschnitt):

**** Incremental build of configuration Debug for project test3 ****

make -k all 
Building file: ../bohrer.c
Invoking: AVR-GCC C Compiler
avr-gcc -c -fmessage-length=0 -Wall -Wstrict-prototypes -mmcu=atmega32 -minit-stack=__stack -O0 -fshort-enums -fpack-struct -funsigned-char -funsigned-bitfields -std=gnu99 -g2 -obohrer.o ../bohrer.c
Finished building: ../bohrer.c
 
Building file: ../display.c
Invoking: AVR-GCC C Compiler
avr-gcc -c -fmessage-length=0 -Wall -Wstrict-prototypes -mmcu=atmega32 -minit-stack=__stack -O0 -fshort-enums -fpack-struct -funsigned-char -funsigned-bitfields -std=gnu99 -g2 -odisplay.o ../display.c
Finished building: ../display.c
 
Building file: ../main.c
Invoking: AVR-GCC C Compiler
avr-gcc -c -fmessage-length=0 -Wall -Wstrict-prototypes -mmcu=atmega32 -minit-stack=__stack -O0 -fshort-enums -fpack-struct -funsigned-char -funsigned-bitfields -std=gnu99 -g2 -omain.o ../main.c
Finished building: ../main.c
 
Building file: ../timer.c
Invoking: AVR-GCC C Compiler
avr-gcc -c -fmessage-length=0 -Wall -Wstrict-prototypes -mmcu=atmega32 -minit-stack=__stack -O0 -fshort-enums -fpack-struct -funsigned-char -funsigned-bitfields -std=gnu99 -g2 -otimer.o ../timer.c
Finished building: ../timer.c
 
Building target: test3.elf
Invoking: AVR-GCC C Linker
avr-gcc -o test3.elf ./bohrer.o ./display.o ./main.o ./timer.o -lm -Wl,-Map=test3.map --cref --oformat=elf32-avr -mmcu=atmega32
Finished building target: test3.elf
 
Generating Program Flash-Hex-File
avr-objcopy -j .text -j .data -O ihex test3.elf test3.hex
Finished building: test3.hex
 
Generating Data EEPROM-Hex-File
avr-objcopy -j .eeprom --set-section-flags=.eeprom=alloc,load --change-section-lma .eeprom=0 -O ihex test3.elf test3.eep
c:\WinAVR\bin\avr-objcopy.exe: there are no sections to be copied!
c:\WinAVR\bin\avr-objcopy.exe: --change-section-lma .eeprom=0x00000000 never used
make: *** [test3.eep] Error 1
Generating Extended Listing-File
Finished building: test3.lss
 
make: Target `all' not remade because of errors.
Build complete for project test3

Habt ihr eine Erklärung?

Gruß
Julius

Autor: Martin Schneider (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja, da steht: HEX-Teil ist fertig und ok, EEPROM-Teil nix gefunden.
HAST du denn was im EEPROM des Controllers abgelegt?
Wenn nicht: alles prima.

Martin

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Julius Krebs (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank für die Antworten.

Ich habe nun doch auf ein anderes Plugin zurückgegriffen und ein "AVR 
Cross-Target Project" erstellt.
Funktioniert tadellos, hat nur einen keinen Schönheitsfehler: Im Tab 
"Problems" wird für jede einzelne Projektdatei die Infomeldung "File not 
indexed because it was not built" rausgegeben. Stört mich weiter nicht, 
bis auf den Umstand, dass die "Rename-Funktion" nicht benutzt werden 
kann.

Könnt ihr mir weiterhelfen?

Autor: Manuel Stahl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schaut mal auf http://sf.net/projects/avr-eclipse
das ist schon etwas weiter fortgeschritten!

Autor: David F. (davidson)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo, das avr-eclipse Plugin ist echt super. Leider funktioniert das 
AVRDUDE im Plugin nicht ganz richtig. Wenn ich in den 
AVRDUDE-PREFERENCES unter "Target MCU Type" den AT90CAN128 auswähle und 
dann auf den AVR-Button klicke kommt etwas mit ... m128 ... und damit 
funktioniert mein Programmer nicht. Ich benutze folgenden Befehl:
avrdude -p at90can128 -P /dev/ttyUSB0 -b 115200 -c avr910 -e -U flash:w:./$(TRG).bin

und damit funktioniert das ohne Probleme.

Außerdem könnte man noch die Auswahl des eeprom hex-files optional 
gestalten, denn wie man an dem Kommando sieht benötigt man das nicht 
unbedingt.

Wenn der Autor diese features seinem Werk hinzufügen könnte wäre das 
echt toll.

Autor: Dude (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Wenn der Autor diese features seinem Werk hinzufügen könnte wäre das
>echt toll.

Das interessiert ihn sicherlich mächtig, was du hier von dir gibst, und 
er wird heute nacht nichts anderes tun, als zu kuschen und alles zu 
befolgen, was du ihm aufträgst.

Autor: Michael J. (jogibaer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich habe auch mal Eclipse ausprobiert.

Dabei habe ich ein Problem:

z.B.


TCCR0 = 128;

direkt in main eingegeben funktioniert.

Lagere ich dies aber in eine externe funktion in eine extra Datei aus,
die ich mit #include "datei.c" einbinde, findet
er das Register TCCR0 nicht mehr:

-> error: 'TCCR0' undeclared (first use in this function)

Weiß jemand was da falsch läuft ?

Jogibär

Autor: Frank Erdrich (erdi-soft)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
#include <avr/io.h> in dem File, in dem du den Registernamen benutzt? 
Also in deinem Fall in datei.c...

Autor: Michael J. (jogibaer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

muß das in jede zusätzliche Datei rein ??!!??

Bisher habe ich dies nicht benötigt.
Da hat es genügt, es einmal in main.c einzutragen und ich hatte von
überall Zugriff.

Da habe ich aber mit kate gearbeitet und auf der Konsole compiliert.

Jogibär

Autor: Frank Erdrich (erdi-soft)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, normalerweise in jede Datei, die das Include benötigt.

Autor: Michael J. (jogibaer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

kann ja fast gar nicht sein.

1. wenn ich 2 mal die gleiche Datei include, dann meckert der Compiler
   das an.

2. mit include setzt doch der Compiler an diese Stelle den Inhalt der 
Datei.
   Dann bin ich doch damit in main, und brauche die io.h nur einmal


Jogibär

Autor: Frank Erdrich (erdi-soft)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Compiler compiliert aber Modul (eine .c-Datei) für Modul (unabhängig 
voneinander). Und in jedem Modul muss er wissen, was jedes #define oder 
ähnliches bedeutet.
Das kann er nur, wenn der Präprozessor das #include durch das 
entsprechende File ersetzt hat.
Meckern tut er höchstens, wenn du eigene Header benutzt. In denen sollte 
dann sowas stehen:
#ifndef __HEADER_H__
#define __HEADER_H__

#endif

In den Header, die WinAVR mitbringt, ist das aber bereits geschehen.

Ich verstehe gerade nicht so ganz, wie du compilieren konntest, ohne 
diese Abhängigkeiten aufzulösen. Es sei denn, du hast das im Makefile 
berücksichtigt, ohne es vielleicht zu merken.

Autor: Michael J. (jogibaer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

bei Kate benutze ich folgendes makefile:

# makefile, written by guido socher
MCU=atmega128
CC=avr-gcc
OBJCOPY=avr-objcopy
# optimize for size:
CFLAGS= -mmcu=$(MCU) -Wall -Wstrict-prototypes -Os -mcall-prologues
#CFLAGS=-g  -mmcu=$(MCU) -Wall -Wstrict-prototypes
#-------------------
all: main.hex
#-------------------
main.hex : main.out
  $(OBJCOPY) -R .eeprom -O ihex main.out main.hex
main.out : main.o
  $(CC) $(CFLAGS) -o main.out -Wl,-Map,main.map main.o
main.o : main.c
  $(CC) $(CFLAGS) -Os -c main.c

# you need to erase first before loading the program.
# load (program) the software into the eeprom:

load:   main.hex
  uisp  -dprog=dasa2 -dserial=/dev/ttyS0 -dpart=$(MCU) --erase
  uisp  -dprog=dasa2 -dserial=/dev/ttyS0 -dpart=$(MCU) --upload 
if=main.hex

info:  main.hex
  avr-size main.out

#load: projekt.hex
#  uisp -dlpt=/dev/parport0 --erase  -dprog=dapa
#  uisp -dlpt=/dev/parport0 --upload if=projekt.hex -dprog=dapa  -v=3 
--hash=32
# here is a pre-compiled version in case you have trouble with
# your development environment

#load_pre: projekt_pre.hex
#  uisp -dlpt=/dev/parport0 --erase  -dprog=dapa
#  uisp -dlpt=/dev/parport0 --upload if=projekt_pre.hex -dprog=dapa 
-dno-poll -v=3 --hash=32
#-------------------
clean:
  rm -f *.o *.map *.out
#-------------------

Jogibär

Autor: Frank Erdrich (erdi-soft)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hmmm, wie hast du denn bisher immer deine Programme geschrieben?
Alles in main()? Oder hast du die *.c includiert?

Ich bin nicht gerade ein Makefile-Held, aber das schaut tatsächlich so 
aus, als hättest du bisher immer nur ne main.c gehabt.

Autor: Michael J. (jogibaer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
erstmal die beiden dateien:

main.c

>>>>>>>>>>>>>>>>>>>>>><<
#include <avr/io.h>
#include <avr/interrupt.h>
#include "test.c"



int main(void)

{
  funktion();
  return 0;

}

<<<<<<<<<<<<<<<<<<<<<<<<

test.c

>>>>>>>>>>>>>>>>>>>>>>>>

void funktion (void)

{
  TCCR0 = 128;

}

<<<<<<<<<<<<<<<<<<<<<<<<


Fehlermeldung:

./test.c:6: error: 'TCCR0' undeclared (first use in this function)
../test.c:6: error: (Each undeclared identifier is reported only once
../test.c:6: error: for each function it appears in.)


zusätzlich am Anfang von test.c #include <avr/io.h> eingefügt

Fehlermeldung:

Invoking: AVR-GCC C Linker
avr-gcc -o  "Test2.elf"  ./main.o ./test.o    -Wl,-Map=Test2.map --cref 
--oformat=elf32-avr
./test.o: In function `funktion':
/mnt/franzjb/home/michael/workspace/Test2/Debug/../test.c:6: multiple 
definition of `funktion'
./main.o:/mnt/franzjb/home/michael/workspace/Test2/Debug/../test.c:6: 
first defined here


Funktioniert auch nicht so richtig.

Exakt das gleiche mit Kate und Konsole -> funktioniert !

Jogibär

Autor: Michael J. (jogibaer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

z.B. so:

#include <avr/interrupt.h>
#include <avr/pgmspace.h>
#include <avr/io.h>
#include <string.h>
#include "projekt.h"
#include "ft232r.c"
#include "systimer8.c"
#include "usart1.c"
#include "pcf8583.c"
#include "i2c.c"
#include "t6963c.c"
#include "glcdausgabe.c"
#include "softwareuhr.c"
#include "error.c"
#include "zyklus.c"
#include "protokoll.c"

Jogibär

Autor: Frank Erdrich (erdi-soft)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nu ja, ich kenne deine Kate Konfiguration nicht.
Aber prinzipiell solltest du bei C nach folgendem Muster vorgehen.

Du hast eine main(). Wenn du ne Funktion in eine andere Datei 
auslagerst, dann gehört zu jeder *.c noch eine *.h, in der du 
Funktionsprototypen, #defines, structs, enumerations und dergleichen 
mehr unterbringst (nur keine globalen Variablen, abgesehen von extern 
...., und keine Funktionalität).
In deinem Fall sieht das dann so aus:
#ifndef __TEST_H__
#define __TEST_H__

//nun der Funktionsprototyp, damit der Compiler bei der main weiß, dass diese Funktion existiert

void funktion(void);

#endif

Diese Header includierst du sowohl in der test.c selbst mit ein, als 
auch in der main.c.
//dies ist deine main.c

#include <avr/io.h>
//#include ....
#include "test.h"

int main(void)
{
   funktion();

   return 0;
}

Dann sollte das auch ohne Kate und seine Voreinstellungen funktionieren.

Autor: Frank Erdrich (erdi-soft)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich brauch zu lang zum tippen :).

Ich sehe schon, du inkludierst deine *.c.
Schlechter Stil. Musste sowas mal auseinanderklabüstern. Ist nicht 
angenehm.
:)

Wie oben schon gesagt, für jede *.c eine *.h mit den 
Funktionsprototypen. Und diese Header dann dort includiert, wo du diese 
Funktionen benötigst.

Autor: Michael J. (jogibaer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

danke für deine Hilfe.

Ich binde jetzt nur dir *.h Datei ein.
Das habe ich schon mehrmals woanders gesehen.
Scheint so eine Art Standard zu sein.
Ich werde dies zukünftig übernehmen.

Noch ein paar Fragen:

Ich gebe ja nirgends die Datei test.c an.
Der Compiler nimmt also an, wenn eine datei.h existiert, gehört
eine datei.c dazu, oder ?

Jetzt wird wohl jede Datei für sich compiliert und dann alle zusammen
gelinkt.Heißt das, daß bei Änderungen an nur einer Datei nur noch diese
Datei neu compiliert wird ?




Jogibär

Autor: Michael J. (jogibaer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo nochmal,

ich benutze normalerweise auch .h Dateien.

Da stehen aber nur defines,Funktionsprototypen und anderer Kram darin.

Das includen von .c Dateien hat auch einige kleine Vorteile.
Wenn man sich dran gewöht hat, ist es eigentlich kein Problem.

Jogibär

Autor: Frank Erdrich (erdi-soft)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Ich binde jetzt nur dir *.h Datei ein.
> Das habe ich schon mehrmals woanders gesehen.
> Scheint so eine Art Standard zu sein.
> Ich werde dies zukünftig übernehmen.

Ja, kann man als Standart bezeichnen. :)

> Noch ein paar Fragen:
>
> Ich gebe ja nirgends die Datei test.c an.
> Der Compiler nimmt also an, wenn eine datei.h existiert, gehört
> eine datei.c dazu, oder ?

Du musst dem Compiler schon sagen, dass eine datei.c existiert.
Z.B.:
%.o: %.c
  $(CC) -c $(FLAGS) $<

Das solltest du aber sicherheitshalber nochmal nachlesen, da ich mir die 
makefiles immer generieren lasse.

> Jetzt wird wohl jede Datei für sich compiliert und dann alle zusammen
> gelinkt.Heißt das, daß bei Änderungen an nur einer Datei nur noch diese
> Datei neu compiliert wird ?

Exakt. Jede *.c wird als eigenständiges Modul angesehen und getrennt 
compiliert. Deshalb benötigt es auch den Linker. Und ja, wenn nur eine 
Datei verändert wird, wird auch nur diese neu compiliert. Dafür sorgt 
das make. Allerdings gibt es hier eine Besonderheit zu beachten. Änderst 
du etwas an einer Header, solltest du in der entsprechenden *.c ein 
Leerzeichen eingeben und dieses wieder löschen (also eine Änderung des 
Speicherdatums der Datei erzwingen). Sonst gibts Probleme, bzw. du 
wunderst dich evtl., warum ein #define in der Header nicht übernommen 
wurde.

Autor: Frank Erdrich (erdi-soft)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Da stehen aber nur defines,Funktionsprototypen und anderer Kram darin.

Genau so ist es.

> Das includen von .c Dateien hat auch einige kleine Vorteile.
> Wenn man sich dran gewöht hat, ist es eigentlich kein Problem.

Das mag durchaus sein. :)
Aber wenn man da als externen mal ranmuss, dann guckt man schon erst 
mal, was denn da genau passiert. Und es kann auch einiges schiefgehen. 
Aber was genau, das kann dir jemand anderes bestimmt 1000 mal besser 
erklären, als ich. :D

Autor: Klaus Falser (kfalser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Das includen von .c Dateien hat auch einige kleine Vorteile.
> Wenn man sich dran gewöht hat, ist es eigentlich kein Problem.

Es gibt keinen technischen Grund, warum man eine .h Datei includiert und 
nicht .c Dateien. Du kannst auch deine Datei mit .asm bezeichnen und 
includieren.

Aber der Unterschied zwischen .h Dateien (Header) und .c Dateien 
(Programm) ist ja gerade, daß man damit ausdrücken will :
Diese Datei ist zum includieren gedacht (Header), der gebe ich die 
Erweiterung .h.
Diese Datei enthält Programm-Code, ist direct für den Compiler gedacht, 
der gebe ich die Erweiterung .c.

Das ist eine Konvention, an die sich alle, die C/C++ programmieren 
halten sollen.

Klaus

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich finde der unterschied wird dann besonders deutlich wenn man sich 
vorstellt, man hat den Quelltext nicht (keine c-Datei) sondern nur den 
Header und die compilierte Objektdatei.

Die Objektdatei kann man dann auch nicht einfach includieren (muss der 
linker zum endgültigen Programm zusammensetzen). Die h-Datei sollte dann 
nur die Funktionen aus der lib definieren, so dass der Compiler weiss, 
dass irgendwann mal auf die Funktionen verwiesen wird.

Naja, wenn man nicht durcheinander kommen will bleibt man bei dieser 
trennung, auch wenn man die c-Datei selber hat. Ausserdem machen das 
wohl die meisten Programmierer so (Frage nach Verständlichkeit und 
Austauschbarkeit), und daran kann man sich halten oder nicht. Sieht 
jedenfalls komisch aus #include <irgendwas.c> !!!

Autor: Tobias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich arbeite jetzt zum ersten Mal mit Eclipse. Ich hab mir das Plugin 
instelliert, und es wird auch erkannt. Dann hab ich ein neues Projekt 
erstellt und gespeichert. Ich hab auch den auto-build eingeschaltet also 
solle eigentlich auch eine hex-Datei erzeugt werden. Das wird allerdings 
nicht. Ich bekomme nur die Fehlermeldung:

"**** Build of configuration Release for project test ****

Nothing to build for project test"

Woran kann das liegen, bzw. was mache ich falsch?

Tobias

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen

Ich bin ein absoluter c-neuling und versuche gerade mit eclipse einen 
atmega16 zu programmieren. ich habe auch die Plug-ins installiert, aber 
ich bekomme folgende Fehlermeldung:

Generating Data EEPROM-Hex-File
avr-objcopy -j .eeprom --set-section-flags=.eeprom="alloc,load" 
--change-section-lma .eeprom=0  -O ihex led.elf led.eep
c:\WinAVR-20070525\bin\avr-objcopy.exe: there are no sections to be 
copied!
c:\WinAVR-20070525\bin\avr-objcopy.exe: --change-section-lma 
.eeprom=0x00000000 never used
make: *** [led.eep] Error 1
Generating Extended Listing-File
avr-objdump  -h -S led.elf >led.lss
Finished building: led.lss

make: Target `all' not remade because of errors.
Build complete for project led

Kann mir hier irgendjemand weiterhelfen?

Autor: Wilfried Holzke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi, wird es von dem Plugin eine Version für CDT 4.0 geben?

Autor: Alexej (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

scheinbar gibt es bis heute noch keine nennenswerten Alternativen zu 
diesem PlugIn für Eclipse. Von dem her würde mich auch interessieren, ob 
dieses noch weiterentwickelt wird, oder hier kein Interesse mehr 
besteht? Denn das mit der globalen -mmcu=xxx ist ja immer noch nicht 
behoben, oder habe ich da was überlesen? Und das mit CDT 4.0 würde mich 
auch interessieren.

Ansonsten finde ich das PlugIn richtig cool, good work! :-)

Gruß,
Alexej

Autor: Thomas Holland (innot)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

auch ich fand, dass das Plugin etwas zu wünschen übrig gelassen hat. 
Beim Versuch 2-3 Verbesserungen einzubringen habe ich "aus versehen" ein 
mehr oder weniger komplett neues Plugin geschrieben.

Es ist noch etwas "work-in-progress", es sind noch nicht alle Ideen 
verwirklicht die ich noch habe. Aber es scheint im großen und ganzen 
stabil zu laufen. Das Plugin benötigt übrigens CDT 4.0 (und damit 
Eclipse 3.3 "Europa")

Wer es austesten möchte kann es sich entweder aus dem sourceforge SVN 
repository des alten Plugins ziehen 
(https://avr-eclipse.svn.sourceforge.net/svnroot/av...)

Alternativ auch via Eclipse Update Manager über meine frisch 
eingerichtete Update Site (http://www.innot.de/eclipse/avrplugin/).

Es ist aber, wie gesagt, noch ziemlich beta und ich übernehme auch keine 
garantie das es läuft. Nutzung daher auf eigene Gefahr:-))

über Feedback und weitere Ideen würde ich mich freuen. Entweder über die 
Sourceforge Seite des alten Plugins (s.o., Bugs, Feature Requests etc.) 
oder direkt an mich.
Auch wäre nicht schlecht, wenn es mal jemand unter Linux testen könnte. 
Ich hatte bisher noch keine Zeit das zu machen)

brgds

Thomas

Autor: Alexej (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wow, nicht schlecht!

das PlugIn funktioniert bei mir auf Anhieb! Habe jetzt einen kleinen Bug 
entdeckt. Nach dem Anlegen eines neuen Projektes, werden beim 
erstmaligen Compilieren die standard mmcu Einstellungen verwendet (also 
nicht die eigens eingestellten). Aber in Projekt->Properties->C/C++ 
Build->Settings war alles wunerbar richtig drin. Nach einem Apply hat er 
die Makefiles dann richtig geschrieben.

Aber ansonsten bin ich bis her richtig begeistert. :-) Weiter so!

Autor: Alexej (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Unter Linux gibt es noch ein kleines Problem.

Zunächst einmal mein System:
Ubuntu 7.10
JRE 1.6 u3
Aktuelles Eclipse Europa + das Plugin
AVR GCC, avrlibc ...

einfaches Testprojekt mit ATMega128 mmcu

Beim Compilieren meckert der avr-gcc, dass er keine ATMega128 kennt. Es 
wird eine Liste ausgegeben mit den möglichen mcu's, darunter auch 
"atmega128" (also das ganze klein geschrieben, da ist linux pingelich 
;-) ).

Gruß,
Alexej

Autor: Alexej (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Linux bug:

Habe jetzt festgestellt, dass der Bug mit der nicht erkannten mmcu unter 
Linux mit einem Apply bei Project->Properties->Build C/C++->Settings 
behoben wird. Scheinbar wird das makefile am Anfang irgend wo nicht 
richtig geschrieben. Nun sieht es folgender maßen aus: Compilieren 
funktioniert!

Aber es sind folgende Fehler aufgetaucht:
1) avr-size bringt beim --format flag folgenden Fehler:
Invoking: winAVR Print Size
avr-size --format=avr --mcu=atmega128 avrtest2.elf
avr-size: Ungültiges Argument für --format: avr

Nach dem Einstellen des Formats auf "berkeley" kommt folgender 
Fehlercode:
Invoking: winAVR Print Size
avr-size --format=berkeley -t --mcu=atmega128 avrtest2.elf
avr-size: unrecognized option `--mcu=atmega128'
Verwendung: avr-size [Option(en)] [Datei(en)]
 Zeigt die Größen der Sektionen innerhalb binärer Dateien an
 Wenn keine Eingabedateien angegeben werden, wird a.out angenommen
 Die Optionen lauten:
  -A|-B     --format={sysv|berkeley}  Ausgabestil wählen (Vorgabe ist berkeley)
  -o|-d|-x  --radix={8|10|16}         Nummern oktal, dezimal oder hexadezimal anzeigen
  -t        --totals                  Gesamtgrößen anzeigen (nur Berkeley)
            --target=<bfdname>        Binäres Dateiformat festlegen
            @<DATEI>                  Optionen aus <DATEI> einlesen
  -h        --help                    Diese Information anzeigen
  -v        --version                 Programmversion anzeigen

avr-size: Unterstützte Ziele: elf32-avr elf32-little elf32-big srec symbolsrec tekhex binary ihex
make: [sizedummy] Fehler 1 (ignoriert)
Finished building: sizedummy

Nun der Fehler wird zwar ignoriert, aber es kommt eben keine 
Größenangabe (und dieses Feature "avr-size" finde ich eigentlich 
ziemlich cool).

Gruß,
Alexej

Autor: mz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Leider ist meiner Info nach avr-size mit Prozentangaben nur in Winavr 
vorhanden. Dies liegt aber nicht am Plugin, sondern an avr-size direkt.

Autor: Thomas Holland (innot)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Alexej,

vielen Dank für Deinen Input.

Das Problem mit dem gross und kleingeschriebenen MCUs war schnell mit 
einer Zeile gefixt.

Das Problem mit der nicht richtigen übernahme des -mmcu Wertes aus dem 
Projekt Wizard ist dagegen deutlich schwieriger zu lösen. Beim 
ausgiebigen Testen habe ich festgestellt, dass das ganze noch massive 
Fehler hat(te).

Aber so langsam steige ich hinter das ManagedBuild System des CDT und 
ich denke, dass ich in 2-3 Tagen eine neue, richtig funktionierende 
Version hochladen kann.

brgds

Thomas

Autor: Thomas Holland (innot)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hier eine neue Testversion meines Plugins.

Die in der letzten Version vorhandenen Fehler sollten behoben sein.

Zur Installation die angehängte ZIP daten einfach in das Verzeichnis 
extrahieren, in dem auch Eclipse installiert ist.
Oder in den Eclipse Update Manager die Update Site 
http://www.innot.de/eclipse/avrplugin eintragen.

Das Plugin ist nicht kompatibel mit der letzten Version, d.h. für 
Projekte die mit der letzten Version angelegt wurden muss ein neues 
Projekt angelegt werden und die Files aus dem alten in das neue Projekt 
importiert werden. Da es sich bei dem Plugin noch um Testversionen 
handelt wird das wahrscheinlich auch für weitere Testversionen gelten.

Das Plugin beinhaltet:
- Toolchains für die Kompilierung von AVR Programmen, inkl. Erstellung 
von Flash und EEPROM Hex files

- Einen Viewer der einige Informationen zu den AVR Prozessoren anzeigt 
(Window -> Show View -> other... -> AVR -> AVR Device Explorer

- keine Dokumentation :-)

Über Feedback  Fehlerreports  Anregungen würde ich mich freuen.

brgds

Thomas

Autor: Ha Jo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Thomas,

erstmal danke für die Arbeit und für das Plugin. Habe es gerade
installiert. Ich hatte vorher noch die alte Eclipse Version mit
dem in diesem Thread beschriebenen Ursprungs-Plugin.

Jetzt habe ich Eclipse-Europa mit Deinem Plugin instaliert.
Habe einen kurzen Test gemacht und der war positiv. Hast eine
gute Arbeit gemacht, wie es scheint.

Muß später weiter testen. Im Moment aber wenig Zeit. Über 
Weihnachten.... :-)

Danke und einen schönen Sonntag noch.

Hajo

PS. Ich wollte Eclipse Artikel aufbohren mit allen Infos
die man zu dem alten Plugin brauchte, aber nun hat mich die
Zeit überholt. :-)

Autor: Alex1 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich moechte auch mal Eclipse testen, aber komme momentan mit dem Plugin 
von Thomas nicht zurecht.

Was muss ich alles einstellen, um etwas hinzubekommen?

Ich habe ein neues C-Project gemacht mit "AVR Cross Target Application".
Danach habe ich ein main.c gemacht, mit einer "For" -Schleife.

Beim Build bekomme ich folgenden Fehler:

**** Build of configuration Debug for project TestAvr1 ****


(Exec error:Das System kann die angegebene Datei nicht finden.
)


Was muss ich alles einstellen?

Danke
Alex

Autor: Thomas Holland (innot)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Alex1,

das Plugin kann bei Dir das (externe) Programm "make" nicht finden.

Kann es sein, dass Du noch keinen AVR-GCC Compiler/Toolchain installiert 
hast?

("winAVR" [http://winavr.sourceforge.net/] für Windows oder für Linux 
die Packages "gcc-avr" , "binutils-avr" und "gdb-avr" [Ubuntu. andere 
Distros evtl. andere Namen])

In der Anleitung, an der ich gerade schreibe, wird das noch explizit 
drinstehen.

brgds

Thomas

Autor: Alex1 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Thomas,

nein, das WinAvr habe ich installiert. Ich entwickele momentan mit 
anderen Editoren,..., würde aber gerne alles mit einem Tool machen. Da 
schein mir Eclipse am nähestem zu sein.
Wann hättest Du den mal eine Version zum reinschnuppern?

Alex

Autor: Alex1 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich bekomme es einfach nicht ans laufen....

Ich habe mal jetzt versucht ein anderes Projekt zu erstellen-> Mingw.

Da ist das selbe Problem.

Ich habe einfach ein C++-Project->Executable->Mingw erstellt.
Danach habe ich ein paar cpp, h files importiert.

Jetzt Buld All.

Und wieder diese Fehlermeldung.
Dann habe ich mal eine commandoZeile geöffnet und da einfach mal 
mingw32-g++ eingegeben-> das Resultat war : no input files.

Die Pfade sind scheinbar richtig...
Was habe ich noch nicht gemacht?
Danke
Alex

Autor: Thomas Holland (innot)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alex1, gib doch bitte mal "make -v" in der "Eingabeaufforderung" ein. Es 
sollte dann "GNU Make 3.81 ..." kommen. Ansonsten auch noch mal ein 
"echo %PATH%" eingeben und schauen welche Pfade darin stehen. Wenn das 
alles in Ordnung ist, dann liegt das Problem nicht an den Pfaden.

Mir fällt gerade ein: wenn die Fehlermeldung kommt, hast Du 
anschliessend in Deinem Projekt einen Ordner "Debug" und in dem Ordner 
eine Datei "makefile" die normal aussieht?

Wenn "makefile" gut aussieht, dann kannst Du auch mal zum testen 
versuchen es manuell aufzurufen, also Eingabeaufforderung ->
cd x:\Eclipse-workspace\deinprojekt\Debug 
make
und schauen was passiert.

Wenn kein makefile im Ordner Debug vorhanden ist, dann schau doch bitte 
mal unter deinProjekt -> Properties -> C/C++ Build -> Tool chain editor 
-> Current builder nach, was da gewählt ist. Testhalber kannst Du mal 
auf "CDT Internal Builder" schalten und auch das mal probieren.

Ich weiss, viele Sachen zum ausprobieren, aber ich möchte Deinem Problem 
ganz gerne auf dem Grund gehen um zu sehen ob mein Plugin noch Fehler 
hat. (ich glaube übrigens nicht, dass es an meinem Plugin liegt wenn die 
MinGW Toolchain bei Dir den selben Fehler zeigt)

Autor: Alex1 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Thomas,

ich moechte damit auch nicht sagen, dass ein PlugIn nicht richtig 
funktioniert... Es funktioniert ja (wie hijo schreibt).

Ich habe nur den internen Builder.
Muss ich denn etwas anderes einstellen?
Ein makefile wird nicht erzeugt.
Wer erzeugt denn das makefile?

Danke
Alex

Autor: Thomas Holland (innot)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alex1, probier mal folgendes:

deinProjekt -> Properties -> C/C++ Build

Im Tab "Builder Settings" dann folgende Einstellungen:

Builder Type: External Builder

Use default build command: deselektieren

Build Command: Kompletten Pfad zur Datei "make" im winAVR\utils\bin 
Verzeichnis
z.B. (bei mir) "D:\WinAVR-20070525\utils\bin\make"

Dann "Apply", "OK", und im Project Menu "Build Project"

Eine andere Sache, die Du probieren könntest, wenn Du noch keine 
ernsthaften Sachen in Eclipse gemacht hast:

Im Eclipse Workspace Verzeichnis den Ordner ".metadata" komplett löschen 
(während Eclipse nicht läuft). Darin bewahrt Eclipse alle 
Einstellungen auf und möglicherweise ist bei Dir etwas zerschossen. Beim 
nächsten Start legt Eclipse das Verzeichnis mit den Grundeinstellungen 
wieder neu an.

Autor: Alex1 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Thomas,

>Im Tab "Builder Settings" dann folgende Einstellungen:
>Builder Type: External Builder
>Use default build command: deselektieren

bei mir lässt sich das nicht ausschalten (ist ausgegraut).

Habe ioch vielleicht etwas nicht installiert?
Ich habe mir von eclipse.org 2 Dateien runtergeladen 1~70MB und 
CDT...4.0.2

Danke
Alex

Autor: Alex1 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
habe etwas vergessen: Es laesst sich auch nichts ausschalten, wenn ich 
das .metadata Verzeichniss loesche.

Alex

Autor: Ha Jo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alex1 wrote:
> habe etwas vergessen: Es laesst sich auch nichts ausschalten, wenn ich
> das .metadata Verzeichniss loesche.
>
> Alex

Hi Alex,

ich hatte auch mit der neuen Eclipse Version Merkwürdigkeiten,
die mit der alten Version so nicht auftraten.

Installieren mal nur das Eclipse-Paket neu. Die Datei muß
man ja nur entzippen in ein Verseichnis. Das CDT installiere
nicht durch entpacken Deiner Datei, sondern so:

1) In Eclipse unter Help-Software-Find and Install
   Search for new features to install aufmachen.
2) Dort den Button "New archived site" anklicken
3) Jetzt die ZIP-Datei mit dem CDT 4 auswählen.

Nun installiert er das CDT. Evtl geht es danach vernünftig.
Bei mir war das der Fall.

Viel Glück
Hajo

Autor: Ha Jo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was ich noch vergaß:
Das Plugin dann wie gehabt in das Eclipse-Verzeichnis entpacken.

Anstatt das CDT zu installieren, kannst Du Dir auch eine 
Eclipse-Variante
mit eingebautem CDT von ECLIPSE.ORG runterladen. Die funktioniert
auch so.

Hajo

Autor: Alex1 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

nun habe ich mein Eclipse ans Laufen bekommen...
Danke.
Habe dann auch gleich Das Plugin von Thomas (Avr) installiert und habe 
folgende Problemchen festgestellt:
- das avr-size funktioniert nicht richtig (hier die Ausgabe)
------------------------------------------------------
Invoking: winAVR Print Size
avr-size -A --format=avr --mcu=atmega16 TestEclipse2.elf "sizedummy"
e:\Programme\WinAVR\bin\avr-size.exe: invalid argument to --format: avr
Usage: e:\Programme\WinAVR\bin\avr-size.exe [option(s)] [file(s)]
 Displays the sizes of sections inside binary files
 If no input file(s) are specified, a.out is assumed
 The options are:
  -A|-B     --format={sysv|berkeley}  Select output style (default is 
berkeley)
  -o|-d|-x  --radix={8|10|16}         Display numbers in octal, decimal 
or hex
  -t        --totals                  Display the total sizes (Berkeley 
only)
            --target=<bfdname>        Set the binary file format
  -h        --help                    Display this information
  -v        --version                 Display the program's version

e:\Programme\WinAVR\bin\avr-size.exe: supported targets: elf32-avr 
coff-avr coff-ext-avr elf32-little elf32-big srec symbolsrec tekhex 
binary ihex
E:\Programme\WinAVR\utils\bin\make: [sizedummy] Error 1 (ignored)
Finished building: sizedummy
------------------------------------------------------
- DF_CPU wird für den Compiler nicht richtig übernommen (steht der 
DefaultWert drin).

Alex

Autor: Ha Jo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alex1 wrote:
> Hallo,
>
> nun habe ich mein Eclipse ans Laufen bekommen...
> Danke.

Für die Leute, die das gleiche Problem haben sollten ist es sicher
interessant, wie Du es nun zum Laufen bekommen hast. Ich würde
es auch gerne wissen :-)

> - das avr-size funktioniert nicht richtig (hier die Ausgabe)

Kann ich leider nicht bestätigen, bei mir funktioniert es.
Du hast da in der Kommandzeile was von "sizedummy" stehen.
Das ist wahrscheinlich das Problem. Woher kommt das.
Bei mir sieht die Kommandozeile so aus:

Invoking: winAVR Print Size
avr-size --format=avr --mcu=atmega16 Nixieclk.elf
AVR Memory Usage
----------------
Device: atmega16

Program:   14726 bytes (89.9% Full)
(.text + .data + .bootloader)

Data:        751 bytes (73.3% Full)
(.data + .bss + .noinit)

EEPROM:        1 bytes (0.2% Full)
(.eeprom)


> ------------------------------------------------------
> - DF_CPU wird für den Compiler nicht richtig übernommen (steht der
> DefaultWert drin).

Kann ich leider auch nicht bestätigen. Funktioniert bei mir.
Allerdings hatte ich auch irgendwie den Fall, dass beim ändern der
Frequenz in den Settings, diese nicht übernommen worden ist, sondern
sie brauchte eine Extraaufforderung, ich mußte sie nochmal eingeben.

Hajo

Autor: Alex1 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

hier mal meine Erkenntnisse:
- MinGW habe ich folgendermassen ans Laufen bekommen:
  (so wie Ha Jo schon oben geschrieben hat)
  1. CDT PlugIn von eclipse.org herunterladen
  2. In Eclipse unter Help-Software-Find and Install
     Search for new features to install aufmachen.
  3. Dort den Button "New archived site" anklicken
  4. Jetzt die ZIP-Datei mit dem CDT 4 auswählen.
  5. Installieren.

  das gnu make muss im Pfad sein.
  Dann sollte alles laufen...

- WinAVR neueste Version installieren (WinAVR-20070525)
  Das PlugIn von Thomas herunterladen und installieren (ins PlugIn
  Verzeichniss von Eclipse entpacken.
  WinAvr\bin und WinAvr\utils\bin müssen im Pfad sein.
  Dann sollte alles laufen...

Jetzt versuche ich mich gerade am Debuggen:
1. über JTAG ICE (nachgebautes)
2. Simulator.
Da habe ich allerdings noch nichts...

Eine Frage hätte ich allerdings noch (Schoenheitsgeschichte):
Wie kann ich bei dem Editor die Tabulatoren auf =2 stellen?
Ich habe es zwar schon etwas eingestellt, das tut es aber nicht.
Wie mache ich es richtig?
Danke
Alex

Autor: Ha Jo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alex1 wrote:

> Eine Frage hätte ich allerdings noch (Schoenheitsgeschichte):
> Wie kann ich bei dem Editor die Tabulatoren auf =2 stellen?

Window-Preferences-General-Editors-TextEditors-DisplayedTabWidth

Hajo

Autor: Thomas Holland (innot)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Alex1 und Hajo,

hab gerade im Hotel freies Internet und daher ein kurze Antwort:

Sizedummy: CDT versucht intelligent zu sein und baut in dem makefile nur 
die Tools ein, deren Outputs auch tatsächlich gebraucht werden. Daher 
habe ich für das Size Tool ein virtuelles Output Target definiert 
("sizedummy") da sonst CDT das Size Tool nie aufrufen würde.

Alex1: Das bei dir "Size" die Option "--format=avr" nicht kennt wundert 
mich. Unter Linux scheint es diese Option nicht zu geben, aber winAVR 
kennt diese Option schon mindestens seit der letzten Version (von Mai 
'07).
Aber damit nicht alle Linux User mich mit Fehlerreports zuschütten, dass 
Size nicht geht, werde ich wohl irgendeine Abfrage einbauen müssen, ob 
avr-size die option "-format=avr" kennt.

Was das Thema Übernahme der CPU Frequenz an geht, so werde ich noch mal 
ein bisschen testen. Bei mir hat es immer funktioniert, aber vielleicht 
habe ich noch irgendeinen Grenzfall beim Testen übersehen.

Die aktuellste Version (noch nicht veröffentlicht) holt sich übrigens 
die Pfade selbst, für Windows aus der Registry und für Linux (TODO...).
Damit sollte auch das Problem von Alex1, das "make" nicht im Pfad war, 
erledigen.

Ansonsten habe ich in den letzten Tagen ein bisschen Doku geschrieben. 
Ein einfaches mini-Tuturial und die ersten Teile von "Concepts" sind 
fertig.  Sobald ich wieder zu Hause bin werde ich eine neue Testversion 
veröffentlichen.

Dazu werde ich aber -pro Testversion- einen neuen Thread in diesem Forum 
machen, damit immer klar ist, auf welche Version des Plugins sich 
Feedback reports beziehen und das ganze nicht als Eintrag 5245 in diesem 
Thread rumdümpelt.

brgds (aus Kattowice)

Thomas

Autor: Ha Jo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Thomas,

bei Alex erschien das "sizedummy" in der Kommandozeile von AVR-SIZE,
bei mir nicht und bei läuft es. Am Ende von AVR-SIZE stet allerdings
auch bei mir "Finished building: sizedummy". Es taucht wie gesagt nicht
in der Kommandozeile auf.

Nun ja, dann viel Spaß noch in Polen!?

Hajo

Autor: Sven K. (skasko)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Thomas,

ich finde es ebenfalls super, dass das Plugin weiterentwickelt wird, 
Danke.

Dazu von mir eine Anmerkung.
Und zwar habe ich das folgende Problem: wenn ich dem Linker in den 
Settings ein eigenes Archiv angebe, wird die Pfadangabe mit -L in den 
Linkeraufruf übernommen, der Libname mit -l jedoch nicht.

Es scheint bei der Makefile Generierung nicht berücksichtigt zu werden.
Oder muss an anderer Stelle noch eine Einstellung vorgenommen werden?

Gruß
Sven

Autor: Thomas Holland (innot)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Sven,

da hast Du einen echten Bug gefunden, der noch aus dem original AVR 
Plugin stammt (anscheinend bist Du der erste, der eine Library einbinden 
möchte).

Bug ist gefixed. Die nächste Version mit dem fix erscheint Morgen oder 
Übermorgen - ich mache noch etwas finetuning an der Doku.

Bis dahin kannst Du natürlich einfach "-ldielib" unter Other 
Arguments bei den Linker Optionen eintragen.

brgds

Thomas

Autor: Thomas Holland (innot)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
HaJo, Du hast recht, dass bei Alex "sizedummy" in der Kommandozeile für 
avr-size erscheint habe ich übersehen. Kann eigentlich nicht sein, denn 
die Kommandozeile für avr-size ist definiert als:

commandLinePattern="${COMMAND} ${FLAGS} ${INPUTS}"

d.h. ${OUTPUT} taucht nicht auf.

Alex1, wenn Du "Project->Properties->C/C++ Build->Settings->Tool 
Settings->Print Size" auswählst, was wird dann unter "Expert Settings:" 
in dem Feld "Command Line Pattern:" angezeigt?

Thomas

P.S. ich habe gerade gesehen, dass Alex schon geschrieben hat, dass das 
Plugin bei ihm jetzt funktioniert. Also erübrigt sich dieser Post wohl.

Autor: Thomas Holland (innot)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So, die nächste Version ist zum testen fertig.

Eigentlich wollte ich sie jetzt über sourceforge veröffentlichen, aber 
der Admin des alten avr-plugins kommt nicht so richtig in die Puschen.

Daher noch mal ein "kleiner" release exclusiv auf mikrocontroller.net. 
Die Datei ist in dem neuen Thread:

Beitrag "Neues AVR Eclipse Plugin (Beta20071222)"

zu finden.

brgds
Thomas

Autor: Fesspagsargug (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hello!
Nice site ;)
Bye

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.