Fehlermeldung beim Compilieren

[SprinterSB]

Ich hab jetzt also meine Datei "main.c" per

avr-gcc -02 -mmcu=atmega32 main.c -o main.elf

in eine *.elf - Datei gewandelt, die dann weiter mit

avr-objcopy -O ihex -j .text -j .data main.elf main.hex

in eine hex-Datei umgewandelt wird.

Ist das nun die "richtige" Vorgehensweise, also das Endprodukt eine "echte" hex-Datei? Per Kommandozeile kann ich dem Compiler ja den Chiptyp übergeben, die Taktfrequenz kann ja im Code auch angegeben werden.

Ja, das funktioniert. Die Taktfrequenz kann im Code (oder im Makefile oder wo auch immer) angegeben werden, aber verändert wird sie nur durch Umsetzen der Fuses. Die Angaben haben also nur informativen Character für das Programm, das daraus Zeitwerte berechnen kann.

Es wäre halt praktisch, wenn ich den Compiler mit make all direkt aus dem Programmer's Notepad aufrufen könnte, und nicht immer die ganzen Parameter etc. in die Kommandozeile eingeben müsste. Dafür wäre dann ja aber wieder das Makefile nötig?

Nicht unbedingt. Es geht wie gesagt auch ein Skript aus PN aufzurufen oder andere Build-Tools wie Ant zu verwenden. Aber das nur am Rande...

Gibt es eigentlich sowas wie eine "Mindestanforderung", was alles im Makefile stehen muss, dass sich der Compiler auskennt? Das, was ich ihm auch so schon über die Kommandozeile sage?

Die Mindestanforderung an ein Makefile ist, daß es mindestens eine Regel enthält. Im einfachsten Falle sieht ein Makefile also so aus:

rule:

Die Compiler hat mit Makefiles überhaupt nix zu tun (wenn man mal davon absieht, daß zur Generierung von GCC auch Makefiles verwendet werden). Makefiles sind Steuerdateien, die festlegen, wann warum was wie gemacht werden soll.

Ebenfalls hat make überhaupt nix mit GCC zu tun (wenn man mal davon absieht, daß make mit GCC generiert wurde). Makefiles beinhalten lediglich Regeln, die Strings wie "avr-gcc" enthalten können. Es geht aber auch sowas:

.PHONY: all
all:
	(explorer)

Die Erzeugung eines Projekts aus Quelle besteht idR aus mehreren Schritten, die in einem Makefile verwaltet werden können. Aber wie gesagt: make ist keine Sprache im eigentlichen Sinne, und ein Makefile wird nicht von oben nach unten abgearbeitet! (Vielleicht beim Einlesen durch make, aber die Aktionen, die erfolgen, haben mit der Reihenfolge wie sie dastehen nix zu tun!)

Im Falle eines AVR-C-Projekten könnten sie Schritte zB sein

• Kompiliere C-Quellen nach Assembler (c -> s)
• Assembliere Assembler zu Object (S -> o, s -> o)
• Linke Objekte zu elf (o -> elf)
• Erstelle ein Map-File (elf -> map)
• Erstelle ein Listfile (elf -> lst)
• Erstelle Intel-HEX-Datei (elf -> hex)
• Flashe das IHEX in den µC
• Zeige Resourcenverbrauch
• Setze Fuses
• ...

Dass das Makfile unbedingt so lang sein muss, wie von mFile vorgeschlagen, kann ich mir nur schwer vorstellen...

So ist das mit den eierlegenden Wollmilchborstentieren nun mal...

Je weniger Aufgaben es erledigen muss und je weniger allgemeingültig es ist, je simpler das Projekt ist, desto einfacher kann ein Makefile sein. Da mfile versucht, ein möglichst allumfassendes Makefile zu erstellen, ist es entsprechend komplex.

Ich muss gestehen, daß mir das zuviel des Guten ist. Ich benutze nicht gerne Sachen, die schwer zu durchsteigen sind. Ausserdem würde es viele Aufgaben, die ich in meinen Projekten brauche, nicht lösen. Das müsste dann alles reingefrickelt werden. Die Fehlermeldung von oben liest man öfter in Foren, aber ich hab mich nie damit beschäftigt wie man es behebt, da ich kein mfile verwende. Evtl. ein "make clean" oder das Verzeichnis .dep löschen oder ein leeres anlegen...keine Ahnung.

Ich hab also irgendwann mal nen Tag investiert und make-Manuals gelesen, und seither komm ich mit make ganz gut zurande.

Klar, wenn man ein Projekt machen will, möchte man natürlich Ergebnisse auf dem AVR sehen, und nicht mit Zeugs wie make Zeit verschwenden. Allerdings ist es mit make wie mit vielen anderen Tools aus der Unix-Welt auch: ohne Einarbeitung bringt es Frust. Der Ich-Click-Einfach-Mal-Rum-Und-Guck-Was-Passiert-Und-Versteh-Dann-Schon-Was-Abgeht-Ansatz ist eben zu 95% zum Scheitern verurteilt. Standardbeispiel ist TeX bzw. LaTeX, sed oder awk und auch GCC. Aber wenn man sich damit auseinandersetzt, dann hat mehr sehr mächtige Werkzeuge an der Hand.

Ich hab mal ein kleines, ungetestetes Projekt angehängt, das eine LED blinkt. Es macht nicht viel, aber trotzdem sind es schon einige Zeilen. Du kannst es natürlich noch weiter abspecken. Ich hab ein paar Module reingemacht, damit man sieht, die ein C-Projekt aus mehreren Modulen ausgebaut wird. Wenn du von der Console aus make startest, wiest du sehen, daß es nicht immer das gleiche tut, auch wenn der Aufruf der gleiche ist. Gib einfach mal nacheinander ein

make all
make all
make clean
make clean
make timer2.o
make timer2.o
make

Die Abhängigkeiten der kannst du übrigens nachlesen in .depend