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
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
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
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
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
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
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
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
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
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
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 ...
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
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
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
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
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
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
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ß
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
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ß
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ß
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
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ß
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
>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!
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?
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ß
> ... 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.
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.
> 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.
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 :-)
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.
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
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
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?
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
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
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
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
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
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
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
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 ;-)
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.
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
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?
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
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 :)
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
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
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
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
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 =).
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
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=FreaksFiles&func=viewFile&id=1905&showinfo=1
Howdy
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.
@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 !?
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
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
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
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
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
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
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
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
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!
:)
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
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
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
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
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
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.
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):
1
**** Incremental build of configuration Debug for project test3 ****
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
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?
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:
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.
>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.
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
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
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
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:
1
#ifndef __HEADER_H__
2
#define __HEADER_H__
3
4
#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.
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.
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
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:
1
#ifndef __TEST_H__
2
#define __TEST_H__
3
4
//nun der Funktionsprototyp, damit der Compiler bei der main weiß, dass diese Funktion existiert
5
6
voidfunktion(void);
7
8
#endif
Diese Header includierst du sowohl in der test.c selbst mit ein, als
auch in der main.c.
1
//dies ist deine main.c
2
3
#include<avr/io.h>
4
//#include ....
5
#include"test.h"
6
7
intmain(void)
8
{
9
funktion();
10
11
return0;
12
}
Dann sollte das auch ohne Kate und seine Voreinstellungen funktionieren.
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.
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
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
> 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.:
1
%.o:%.c
2
$(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.
> 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
> 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
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> !!!
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
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?
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
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/avr-eclipse/avr_eclipse_plugin_2.0/trunk/)
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
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!
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
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:
1
Invoking:winAVRPrintSize
2
avr-size--format=avr--mcu=atmega128avrtest2.elf
3
avr-size:UngültigesArgumentfür--format:avr
Nach dem Einstellen des Formats auf "berkeley" kommt folgender
Fehlercode:
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
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
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
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. :-)
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
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
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
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
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 ->
1
cdx:\Eclipse-workspace\deinprojekt\Debug
2
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)
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
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.
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
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
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
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
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
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
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
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
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
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
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 OtherArguments bei den Linker Optionen eintragen.
brgds
Thomas
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:
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.
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
Thread beobachten
Seitenaufteilung abschalten