Guten Tag, Ich habe gerade AVR-GCC Installiert und verstehe dieses System nicht ganz! Ich habe jetzt die Datei prel.c, diese möchte ich kompilieren (zu eine *.a90 oder *.hex datei) um sie aud en µC zu programmen. ... Doch welche exe ist dafür zuständig und welche Parameter muss ich dabei angeben? ich finde einfach keine halbwegs gescheite Anleitung. Mit freundlichen Grüßen Jochen
Welchen avr-gcc? Ich hoffe, Deiner kommt aus dem WinAVR-Paket. Ansonsten ist er viel zu alt (> 1 Jahr, in dem sehr viel passiert ist, vor allem hinsichtlich Dokumentation), deinstalliere ihn wieder und installiere ein aktuelles WinAVR. Lies mal hier durch das Forum, aus dem Beispielmakefile der letzten Version mußt Du eine der LDFLAGS Zeilen auskommentieren, insbesondere wenn Du einen kleinen Controller hast. WinAVR kommt mit einigem an Doku, fang' mit dem README an.
Ich habe viele verschiedene AVRs ich wollte aber den90S2313 einsetzen Ich benutze WinAVR 20030424 April 23, 2003 von wann die prell.c datei ist weiß ich nicht aber daraus willich nur eine hex datei machen ...
kann man nicht alles was man mit WinAVR ( 20030424 April 23, 2003) machen kann auch mit IAR EWB machen ? oder kann das NUR der GCC
Im Prinzip kann man das sicher auch mit IAR machen (so man das Geld für diesen ausgegeben hat ;-), im konkreten Fall ist das Programm selbst für den aktuellen avr-gcc/avr-libc schon mächtig angestaubt. Statt <io.h> bitte <avr/io.h> benutzen. Includenamen ohne Verzeichnis haben wir mittlerweile den vom C-Standard definierten Headerdateien überlassen, alles AVR-Spezifischen hat ein avr/ davor. outp() war früher beim avr-gcc nötig, ist mittlerweile dort veraltet und nicht mehr empfohlen. Erstens hat es eine verwirrende Syntax (erst den Wert, dann die Portadresse), zweitens ist man damit inkompatibel zu den anderen AVR-C-Compilern (z. B. IAR). Wenn Du statt outp (v, p); p = v; schreibst, müßte der Code wirklich einigermaßen portabel sein (kann aber sein, daß man beim IAR statt avr/io.h explizit io2313.h einbinden muß). Ansonsten das Beispiel-Makefile ins Arbeitsverzeichnis mit der prell.c kopieren, dort die LDFLAGS-Zeilen auskommentieren (braucht man für dieses Beispiel alle nicht), MCU setzen (at90s2313), TARGET setzen (auf "prell"), in der Zeile mit SRC den Backslash entfernen sowie foo.c und bar.c in der folgenden Zeile löschen. Danach "make" aufrufen, von der Kommandozeile (cmd.exe) am einfachsten, oder von jedem beliebigen Programm aus, mit dem man ein Kommando ausführen kann.
im anhang hab ich mal das projekt gepackt und es an den aktuellen avr-gcc standard angepasst und direkt das passende makefile beigefügt. viel spass, BAB
Also ich kann ja ein kleines bißchen C und das C-Tutorial unter Artikel finde ich auch ziemlich verständlich aber... Bis man aus dem C-Code erstmal ne Surce-File hat, die man in den AVR braten kann .. SEUFTZ ... was ist denn eine MAKEFILE ? ich kenne von AVRStudio nur *.hex Dateien ... also der Maschinencode der *.asm -+-+-+-+- Beispiel-Makefile ins Arbeitsverzeichnis mit der prell.c kopieren, dort die LDFLAGS-Zeilen auskommentieren (braucht man für dieses Beispiel alle nicht), MCU setzen (at90s2313), TARGET setzen (auf "prell"), in der Zeile mit SRC den Backslash entfernen sowie foo.c und bar.c in der folgenden Zeile löschen. Danach "make" aufrufen, von der Kommandozeile (cmd.exe) am einfachsten, oder von jedem beliebigen Programm aus, mit dem man ein Kommando ausführen kann. -+-+-+-+- WAS IST DENN DAS ?! Davonhabe ich gerade echt NICHTS verstanden ... ich will euch auch nicht auf die nerven gehen aber ich habe nirgendswo eine halbswegs gescheite Anleitung! was davon ist eigentlich reines "C" und was davon ist AVR bzw AVR-GCC - zpezifisch ??!!
LDFLAGS-Zeilen, MCU setzen,TARGET setzen, SRC den Backslash entfernen, foo.c und bar.c in der folgenden Zeile löschen, make" aufrufen, ->> BAHNHOF ! Gibt es nicht ein schönes kompaktes buch oder tutorial wo drin steht was das bedeutet und wie ich ganz einfach aus dem C-Surce ne datei mache , die ich über das AVR STUDIO mit dem STK 500 in den AVR braten kann
Warum siehst Du Dir denn nicht wenigstens Kais Projekt an? Er hat Dir doch nun die Arbeit schon abgenommen... Reines C ist der Quellcode. Alles andere ist Tool-spezifisch. Klar ist ein Makefile kein C, aber auch eine ``Projektwizard'' oder sowas hat mit C überhaupt nichts zu tun. Beides sind Mittel zum Zweck. Ansonsten: avr-gcc -mmcu=at90s2313 -Os -o prell.out prell.c avr-objcopy -O ihex -j .text -j .data prell.out prell.hex Das wäre die einfachste Variante. Kürzer als zwei Zeilen kann man es wohl nicht ausdrücken... Hast Du Dir denn eigentlich mal die mitgelieferte Doku durchgelesen? http://savannah.nongnu.org/download/avr-libc/doc/avr-libc-user-manual/demo_project.html
ES GEHT ! FEIIIN! -> ES GEHT ! VIELEN DANK ! naja mein englisch is nichtbesonders gut... aber z.B. diese befehle z.B.: inp(<register>); bit_is_set (<port>, <pin>); bit_is_clear (<port>, <pin>); outp (<wert>, <register>); sbi (<register>, <bitnummer>); cbi (<register>, <bitnummer>); loop_until_bit_is_set(<register>, <bitnummer>); loop_until_bit_is_clear(<register>, <bitnummer>); .. sind die NUR un AVR-GCC verfügbar ? gibt es keien io.h in man in jedem compiler nutzen kann ? .. danke nocmal !
Ja.
Ja.
inp/outp/sbi/cbi sind mittlerweile auch »deprecated«, oder wie
heißt das so schön im Deutschen: »Nicht für Neuentwicklungen
vorgesehen.« :-) Stattdessen wird direkte port-IO bevorzugt,
sbi und cbi schreiben sich dann so:
PORTx |= (1 << n);
PORTy &= ~(1 << m);
Sofern n und m konstant sind und PORTx im zulässigen Bereich für
die sbi/cbi-Befehle liegen, setzt der Optimierer automatisch
diese Befehle ein.
Die kommerziellen Compiler haben wohl kein großes Interesse
an gegenseitiger Kompatibilität. avr-gcc dagegen konnte früher
die direkte Angabe das Portnamens nicht, daher der Umweg mit
outp/inp/sbi/cbi, die dann per Makro direkt auf die entsprechenden
Controller-Befehle gebogen worden sind (inline asm).
Dinge wie bit_is_{set,clear} usw. sind avr-gcc (bzw. avr-libc )
Erweiterungen, aber wenn man portabel bleiben will, kann man
gut auf die verzichten -- es sind simple Makros, die man auch
mit Standard-C-Konstrukten erreichen kann. Im Gegenzu, wenn
man keine Portabilität zu anderen Compilern braucht, verbessern
sie die Lesbarkeit des Programms.
mein ziel ist es eigentlich Compiler-unabhängig zu programmieren also ein c-surce der soviw in "IAR Embedded Workbench for Atmel AVR" als auch in "Imagecraft ICCAVR" aber auch in WinAVR ... also müsste man ja wissen welche funktionen den selben namen haben und parameter verwenden ?? oder könnte man nicht einfach bei jedem compiler die selbe io.h datei nehmen ? dann würden die funktionen die man verwenden will sei es nun it_is_{set,clear} oder inp/outp/sbi/cbi... aus seiner persönlichen io.h entnommen oder ist gerade das was den Compiler ausmacht ... EIGENE mehr oder weniger effektive funktionen ??!! in assembler ist es eindeutiger .. stellt atmel sowas nicht bereit ? wodran sich dann alle compiler hersteller halten ?
Atmel stellt dazu nichts bereit. Warum auch? Die produzieren Chips, keine C-Compiler. Vergleiche einfach die Compiler (Du kannst es -- wir können es nicht bzw. kaum: ich gebe kein Geld für einen Windows-Compiler aus, den ich nicht brauche, noch dazu, da ich gar kein Windows habe). Die Grundfunktionen sind doch gleich. Den Rest kann man mit #ifdef kapseln. Für Vorschläge, wie man die Interoperabilität der C-Quellen zwischen den Compilern verbessern kann, sind wir aufgeschlossen (dann aber bitte an die avr-libc-devel Mailingliste). Einzig, <avr/io.h> werden wir nicht wieder in <io.h> zurückbenennen. Die klare Trennung von Funktionen, die zum Standard-Umfang von C gehören und solchen, die AVR-spezifisch sind, ist uns wichtiger als die Portabilität zu anderen Compilern.
Da haben Sie recht ! "avr-libc-devel"... ist eine Opensurce Community die AVR-Spezifische C-funktionen entwickelt??? Sehe ich das richtig? Gibt es dafür eine übersichtliche auflistung AVR-Spezifischer funktionen, die die <avr/io.h> bereitstellt? Ich meine die, die weiterentwickelt werden und im moment verwendet werden. WUnd diese <avr/io.h> ist nur für AVR-GCC ? Im grunde ist dieses Opensurce effektiver als ein kommerzieller Compiler, jeder kann Funktionen verbessern und veröffentlichen.
Die Heimat des avr-libc Projektes ist http://savannah.nongnu.org/projects/avr-libc/ Aus verschiedenerlei Gründen werden bei der Opensource AVR Toolchain die Komponenten an verschiedenen Stellen entwickelt. GCC und GNU Binutils (assembler, linker, objcopy, ...) haben historisch jeweils ihre eigene Heimat. Die avr-libc stellt dann den Rahmen bereit, damit man mit dem C-Compiler auch was vernünftiges anfangen kann: Headerfiles, die eigentliche libc eben, aber auch Dokumentation, wobei wir uns hier auch den AVR-spezifischen Details von gcc und binutils verpflichtet fühlen. Zwar haben sowohl gcc als auch binutils ihre eigene umfangreiche Dokumentation, aber die AVR-Details gehen dort schon auch mal unter. Von der Projektseite gelangt man sowohl zur Dokumentation (die übrigens auch von WinAVR komplett mit installiert wird -- einfach nur mal lesen) als auch zur Seite mit der Mailingliste.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.