Hallo,
Ich versuche derzeit eine Library aus einer Sammlung von Funktionen zu
erstellen. Dazu habe ich versucht nach dem Tutorial dieser Website
vorzugehen (http://www.mikrocontroller.net/articles/Libraries).
Ich scheitere allerdings daran die Library zu kompilieren, da ich nicht
weiß, was ein "Compileraufruf" und ein "Kommandozeilenschalter" ist oder
wie ich das Programm "ar" verwenden soll.
Ich finde einfach keine Website, wo steht an welcher stelle ich die
Befehle eingeben soll.
Ich benutze Eclipse mit dem AVR Plugin und programmiere einen Atmega128.
mfg Richard
Richard schrieb:> Ich scheitere allerdings daran die Library zu kompilieren, da ich nicht> weiß, was ein "Compileraufruf"
Weiß du denn, was ein Compiler ist?
Dann wäre der Weg zum Compileraufruft nicht mehr weit: Das ist, wenn du
den Compiler startest. Auf den Compileraufruf folgt der Compilerlauf,
der dir deinen Code compiliert.
Werner schrieb:> Richard schrieb:>> Ich scheitere allerdings daran die Library zu kompilieren, da ich nicht>> weiß, was ein "Compileraufruf">> Weiß du denn, was ein Compiler ist?> Dann wäre der Weg zum Compileraufruft nicht mehr weit: Das ist, wenn du> den Compiler startest. Auf den Compileraufruf folgt der Compilerlauf,> der dir deinen Code compiliert.
... und dieser wird mittels "Schalter" konfiguriert.
Ok, danke erstmal soweit!
ich bin jetzt in der Console in das Verzeichniss gegangen, wo meine .c
liegt (im meinem Fall motor.c).
Wenn ich nun den Befehl:
1
$ gcc -c -ggdb -O2 -o motor.o motor.c
eingebe sagt mir die Console:
1
Der Befehl "$" ist entweder falsch geschrieben oder konnte nicht gefunden werden.
>Vielleicht solltest du dir erstmal im klaren werden
Und wie wird er sich klar ?
Der Compiler nennt sich "Gnu C Compiler".
Das Programm liegt irgendwo auf deinem Rechner und die Datei heißt
"gcc.exe"
Wenn Du eingibst:
1
gcc.exe
wird es gestartet. Dein Rechner findet es automatisch.
Wenn er es nicht findet, kommt die Meldung:
Der Befehl "gcc" ist entweder falsch geschrieben oder konnte nicht
gefunden werden.
Du kannst das .exe auch weglassen:
1
gcc
Probier das mal.
Nach dem Start wird Dir der Compiler aber mitteilen, dass ihm noch
zusätzliche Information fehlt ... welche Datei er übersetzen muss ..
usw.
Die zusätzliche Information gibst du dem gcc mit, indem Du sie einfach
hinten dran schreibst.
Vielen dank für deine ausführliche Erklärung ggg!
Also ich habe versucht gcc.exe in der Console zu starten - die Datei
findet er aber nicht.
Also habe ich mal im WinAVR Verzeichniss nach "gcc.exe" gesucht. Da hat
er dann zwei verschiedene gefunden:
1
C:\Programme\WinAVR-20100110\avr32\bin
und
1
C:\Programme\WinAVR-20100110\avr\bin
Wie kann ich der Console nun beibringen, dass es die Datei gibt und wo
sie liegt? Welche der beiden Dateien ist ide richtige (oder keine von
beiden)?
Ich finde das bescheuert, wenn man versucht Threads als "Gedrolle" zu
markieren.
Wenn Du mit Anfängern nicht klar kommst, dann sei doch einfach still.
Und geh mal an die frische Luft.
Nicht alle sind so Superhelden wie Du.
Dann tipp die Fehlermeldung halt mal in Google ein. Das hat nichts mit
motor.c zu tun.
Dein Compiler ist schlicht nicht benutzbar installiert. Richte ihn also
erstmal ordentlich ein, setze die korrekten PATH-EInträge, und zwar so,
daß du gcc auch ohne absoluten Pfad (also "gcc ...") aufrufen kannst.
ggg schrieb:> @ Richard.>> Du kannst den Pfad direkt eingeben,> also>> C:\Programme\WinAVR-20100110\avr32\bin\gcc.exe
Nein, auf keinen Fall so. Das aufzurufende Programm ist nicht gcc,
sondern avr-gcc oder avr32-gcc oder was auch immer.
avr-gcc steht in
> C:\Programme\WinAVR-20100110\bin
Das Programm soll ja für einen ATmega128 übersetzt werden und nicht für
den PC...
Cool, das mit dem avr32-gcc.exe scheint zu funktionieren!!!
Ich muss bloß noch den Code anpassen - mir wurden einige Fehler in der
Console angezeigt. Ich hoffe dann funktioniert es...
In sofern ich keine weiteren Probleme finde verabschiede ich mich
vorerst und danke euch allen für eure Hilfsbereitschaft!!!
mfg Richard
Richard schrieb:> Ich benutze Eclipse mit dem AVR Plugin und programmiere einen Atmega128.
File->New->C project->AVR cross static library->empty project
Alles andere macht das plugin für dich.
Oliver
Das uralte Problem dass die IDE mit der Programmiersprache mit dem
Compiler verwechselt wird. Kann man keinem wirklich verübeln, führt aber
bei erfahrenen Programmierern zu hohem Blutdruck und entsprechender
Ausdrucksweise wenn sie es erklären müssen.
ggg schrieb:> Wenn Du mit Anfängern nicht klar kommst, dann sei doch einfach still.> Und geh mal an die frische Luft.
Naja du musst doch zugeben es ist mehr als seltsam wenn jemand hier
kommt, anscheinend C programmieren kann, weiss was eine Library ist,
schon so viele Funktionen programmiert hat dass er sie in eine Library
tun will, selbständig dem Tutorial hier folgen kann, ABER noch nie im
Leben die Kommandozeile gesehen hat.
Ausserdem ist heute Samstag und am Wochenende kommen sie alle aus ihren
Löchern gekrochen.
@gutenberg Andersherum fragt man sich als Informatiker auch manchmal
warum ein Programmierer so etwas unbedingt wissen MUSS heutzutage. Für
so manchen Fall reicht das Weltbild "Warum heisst das
Programmierprogramm C jetzt Eclipse?" ja tatsächlich aus.
Ich denke das kommt am ehesten da her, dass hier vorwiegend
uC-Programmierer unterwegs sind, und wir arbeiten alle so ziemlich auf
der tiefsten Schicht der Softwareentwicklung wo man halt wirklich noch
wissen muss was im Prozessor wie passiert (v.a. wenn man Assembler
programmiert)
Für jemanden, der objektorientiert (C++, Java, C#, VB(.NET) oder
sonstige höhere Sprachen) programmiert und wirklich nur auf größeren
Rechnern arbeitet, sind Dinge wie Stack, Programmcounter, kleine Zahlen
als (unsigned) char zu speichern etc. genauso Fremdwörter wie der genaue
Erstellungsprozess von Software. Präprozessoren verlieren in höheren
Sprachen sowieso fast völlig an Bedeutung weil sie keinerlei Validierung
des Codes durchführen können sondern nur stupide Textersetzung. Deswegen
is Präprozessor eh verpönt und der Linker kommt teilweise erst mit late
binding zum Einsatz (siehe DLL usw.). Sind schon zwei für
ASM-/C-Programmierer essentielle Teile der Erstellungskette die jemand
anders aus gutem Grund schonmal nicht interessieren.
Ganz abgesehen davon, dass Java und C# ja eh in einer virtuellen
Maschine laufen und daher vom Erstellungsprozess wieder ganz anders
sind.
Is doch nix schlechtes wenn sich Anfänger oder Programmierer aus anderen
Gebieten mit uC beschäftigen. Dass man da vieles nicht wissen wird bzw.
oft gar nicht so weit denkt kann ich durchaus verstehen und sollten wir
hier auch unterstützen denke ich... Ich glaub nicht dass alle die hier
große Töne spucken selbst nie eine blöde Frage (abgesehen davon, dass es
blöde Fragen bekanntlich nicht gibt) gestellt haben, die man sich nicht
auch selbst hätte ergooglen können.
@ Richard: Solltest du noch Hilfe benötigen, kannst mich gerne mal
kontaktieren, bin selbst gerade beim Bibliotheken erstellen und hab mich
auch schon mit dem einen oder anderen trivialen Problem ewig rumgeärgert
;)
Auch oder gerade auf grossen Kisten ist eine genaue Kenntnis der
unterliegenden Schichten essentiell oder soll die Größe des Computers
die Unkenntnis des Programmierers ausgleichen?
Die Größe der Kiste nicht aber das Betriebssystem das darauf läuft...
Da ist es vorranging, dass du weißt wie das Betriebssystem auf dein
Programm reagiert, da es sowieso in einer Laufzeitumgebung, die vom
Betriebssystem zur Verfügung gestellt wird, ausgeführt wird.
Wie der Prozessor das auf Busbausteine rausschickt, wie die Grafikkarte
byteweise dein Bild verarbeitet oder wie die Messages am Systembus
codiert sind interessiert dich herzlich wenig wenn du irgendeine
Applikation (beispiel Buchhaltungssoftware, Servlet oder sonst
irgendwas) schreibst.
Das ist auch der Sinn hinter dem ganzen Betriebssystem; Irgendwann ist
die Komplexität so groß, dass es einfach nicht möglich ist, über jedes
kleinste Detail Bescheid zu wissen und auch zeitlich nicht machbar sein
wird.
Ich lehn mich jetzt mal so weit aus dem Fenster zu sagen, dass du nicht
exakt weißt wie der Bytecode eines simplen Bash-Hello-World-Programms
(in C) tatsächlich auf deinem Prozessor Schritt für Schritt abgearbeitet
wird... Am Mikroprozessor kannst im besten Fall den Bytecode wirklich
lesen (zumindest wenn du wie ich mal händisch assemblieren gelernt
hast...) und weißt einigermaßen genau was da abgeht, wobei in den Chip
reinschaun kann von den hier Anwesenden wahrscheinlich sowieso keiner,
sodass er weiß welcher Transistor wie schaltet - und das ist dann die
wirklich zuunterst liegende Schicht, alles andere (Register usw.) ist eh
schon Abstraktion - warum also nicht noch mehr Abstrahieren und dem
Betriebssystem die Arbeit überlassen?
Nicht umsonst sind Objektorientierte Programmiersprachen durch
Abstraktion und Kapselung so erfolgreich und verhältnismäßig einfach zu
warten...
Sorry, aber das Argument, dass man alles wissen muss um gute Software
schreiben zu können, zählt für mich einfach nicht...
Ist vl. das falsche Forum hier um über den Sinn und Vorteile/Nachteile
von Blackboxmodellen zu diskutieren, weil die Leute hier großteils gerne
alles verstehen (und welche, die das (noch) nicht machen gleich mal als
Troll bezeichnen..) wollen (was ich persönlich auch gut heiße), aber ich
finde die Einstellung dass man auf einem PC jeden Vorgang verstehen muss
einfach nicht mehr zeitgemäß, da ist jeder Vorgang zu komplex um mit
dieser Einstellung effektiv arbeiten zu können...