Ich wollte ein älteres C-Programm erweitern und neu compilieren. Seit Tagen versuche ich mich daran - vergeblich. Ob mir hier vielleicht jemand helfen kann? Ich benutze die aktuelle WinAVR-Version 20070122, die aber die alten C-Programme nicht mehr recht übersetzten kann: Da ist das Problem mit den multiplen Definitionen, die seitenweise moniert werden. Bei Lektüre der FAQ's fand ich den Hinweis, in mfile das Zielsystem anders zu benennen als die Source.c . Ist zwar unübersichtlicher, hat aber viel gebracht: meine eigenen Funktionsdefinitionen werden nun nicht mehr als multiple definitions beanstandet! Dafür tauchen aber jetzt viel häßlichere auf: In function '__vectors': ....multiple definition of '__vectors'. Und __bad_interrupts ist auch mehrfach definiert. Kommen die aus den include-Dateien? Die sollten sich aber doch miteinander vertragen? Kriegt man das in den Griff? In den FAQ's schrieb jemand, er hätte das in der makefile korrigiert, aber wenn ich mir die mit ihren zahllosen Definitionen ansehe, graust es mir (allerdings habe ich das Manual noch nicht gelesen). Zum Schluß noch eine Frage: das o.g. C-Programm ist mit eifriger Benutzung des gcc-avr-libc-Reference-Manuals (das mit den vielen deprecated's) entstanden. Wie stellt man jetzt den C-Standard-Level im makefile ein: C86, gnu86, c99, gnu99? Es wäre nett, wenn mir jemand helfen könnte. Vielen Dank schon mal mfg Egon
Wenn es KEIN geheimes Projekt ist, wäre es hilfreich das Projekt als Archiv zusammenzupacken und hier in den Anhang zu stellen. Wenn es ein geheimes Projekt ist, könntest du die Source so bearbeiten, dass nicht mehr erkenntlich ist, wofür sie eigentlich gedacht war. Dann Tipps einholen (mit angehängtem Archiv) und dann die Tipps in das richtige Projekt einarbeiten. Welche WinAVR Version hattest du vorher benutzt?
Gast
#558792
>Ich benutze die aktuelle WinAVR-Version 20070122,
Besorg dir doch eine der älteren Versionen. Vielleicht geht es damit
einfacher.
Den C-Standard definierst du mit -std=c99 in den Compileroptionen
Oliver
Oliver wrote: >>Ich benutze die aktuelle WinAVR-Version 20070122, > > Besorg dir doch eine der älteren Versionen. Vielleicht geht es damit > einfacher. @Egon Die langfristig einfachste Lösung ist sicherlich das Programm richtig zu stellen. Lass dich nicht von der Menge der Fehlermeldungen beeindrucken. Wenn das schon mal compilierte, dann sind da meist nur eine Handvoll Fehler im Programm, alles andere sind Folgefehler. Korrigierst du einen Fehler, dann verschwinden auch 10 andere. Korrigier einfach immer nur den ersten Fehler und denk über die anderen noch gar nicht nach. Neu compilieren und wieder den ersten Fehler korrigieren. Du wirst sehen, dass die Fehlerzahl schnell sinkt.
Egon Müller wrote: > Ich benutze die aktuelle WinAVR-Version 20070122, die aber die alten > C-Programme nicht mehr recht übersetzten kann: Zwischen AVR-GCC 3.4.6. und 4.1.1 wurden sehr gravierende Änderungen vorgenommen. Wenn das Programm mit der älteren Version lief, würde ich dringend davon abraten, es mit der neuen Version weiter zu bearbeiten. Es sei denn, Du willst es Zeile für Zeile überprüfen, ob da kritische Stellen drin sind. Sämtliche Stellen, wo ein bestimmtes Timing benötigt wird, können erhebliche Überraschungen bereiten (Code-Reordering) und müssen daher überprüft werden. Ich habe daher in sämtliche alten Programme folgenden Header eingefügt:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
Mit ner Batchdatei schalte ich dann zwischen den Versionen um (WINAVR-Verzeichnis umbenennen). Peter
Peter Dannegger wrote: > Zwischen AVR-GCC 3.4.6. und 4.1.1 wurden sehr gravierende Änderungen > vorgenommen. Was der OP hier aber geschrieben hat, hat damit gar nichts zu tun und lässt sich in der Tat nur mit Kenntnis seines Sourcecodes (bzw. seiner Build-Umgebung, Kommandos etc.) analysieren. > Wenn das Programm mit der älteren Version lief, würde ich dringend > davon abraten, es mit der neuen Version weiter zu bearbeiten. Deine Abneigung gegen GCC 4.x kennen wir, die musst du nun nicht bei jeder unpassenden Gelegenheit anderen, die damit gar nichts zu tun haben, aufs Butterbrot schmieren. Peter, deine Kenntnisse in allen Ehren (die leider aber langsam verstauben, bei der Compilertechnologie bspw. auf dem Niveau von Anfang der 1990er Jahre), aber du nervst damit langsam. Einen fundierten GCC-Bugreport zu schreiben (und ihn dann auch mit den GCC-Entwicklern auszudiskutieren, wenn nötig), bist du zu faul, das überlässt du anderen. Dann sorry, bitte behalt aber auch den Rest für dich, denn es ist mittlerweile alles andere als konstruktiv. Insbesondere möchte ich dich drum bitten, dass du nicht -- wie jetzt gerade -- bei jedem Problem, das irgendwo irgendeiner mit dem AVR-GCC hat, die große Verschwörungstheorie über den abgrundtiefen GCC 4.x hervorkramst, ohne dich auch nur ansatzweise mit dem Problem überhaupt befasst zu haben, das derjenige hat. Danke.
Gast
#558895
>Die langfristig einfachste Lösung ist sicherlich das >Programm richtig zu stellen. Ich würde Aufwand und Nutzen abwägen. Geht es nur um eine kleine Erweiterung eines an sich fertigen Programms, welches danach nie wieder :-) angefasst wird, lohnt der Aufwand der Umstellung auf den aktuellen Compiler und die akzuelle avr-libc nicht. Denn die erforderlichen Änderungen erfordern nachfolgendes Debugging und Test, nur um am Ende den "gleichen" Stand zu erreichen, der jetzt schon da ist. Soll dagegen das vorliegende Programm grundlegend geändert werden, lohnt sich die Umstellung. Da gebe ich Karl heinz Buchegger uneingeschränkt recht. Oliver
Gast
#558978
Hallo, Vielen Ddank für Eure Antworten. Ich füge das fragliche Programm bei und es wäre nett, wenn Ihr mit viel mehr Kenntnissen mal schauen könntet, wo die Fehlermeldungen herkommen. Nein, geheim ist es nicht, allerdings mir etwas peinlich, weil es doch ziemlich handgestrickt ist (aber die damals daraus abgeleitete Endversion tut schon seit Jahren ihren Dienst bei der Überwachung eines Koiteiches). Ich neige übrigens dazu, das ziemlich kleine Programm an gcc 4.x anzupassen, ganz nach meinem (Aber-)Glauben "neuer ist besser". Und außerdem: die Leute geben sich dankenswerterweise so viel Mühe mit Programmweiterentwicklung, das sollte man doch nutzen. Viele Grüße aus Karlsruhe Egon
Gast
#558980
Zweiter Versuch, das Programm beizugügen mfg Egon
Gast
#558982
Ist das das Original, oder schon mit Code-Änderungen für den "neuen" gcc? Oliver
Hmm, verrätselst du uns noch den Controllertyp? Wie schon geschrieben, vermute ich den Fehler in deiner Build-Umgebung (Makefile oder so), die hast du uns leider nicht mitgegeben. Nachdem ich <avr/twi.h> in <util/twi.h> geändert habe, compiliert es, aber es linkt nicht: % avr-gcc -mmcu=atmega16 -Os -o foo.elf AVRTel20.c /tmp/ccGMsAry.o: In function `texte': AVRTel20.c:(.text+0x466): undefined reference to `Zulauf'
Gast
#558994
Jein, es das "abgewandelte Original". Ich habe die vormals enthalteten // für Kommentare ersetzt durch /* ... */, denn das war aus den Fehlermeldungen zu erkennen. Aber am Code selbst habe ich noch nichts geändert. Ich vermute, es sind einige inzwischen abgeschaffte Bitmanipulationen enthalten. Andersnkann ich mir das eigentümliche Verhalten des LCD nicht erklären: Die Texte werden dargesstellt, aber das Display läßt sich nicht löschen. mfg Egon
Gast
#558999
Der Controller ist ein ATmega16, zur Build-Umgebung habe ich die makefile beigefügt (ich hoffe, diesmal funktioniert die Übertragung gleich)
Gast
#559003
Das hatte ich übersehen: die Aufrufe der auszugebenden Texte kannst beliebig ändern, wo "aussen" augegeben werden sollte, steht Venus oder Zulauf oder sonstwas drüber. Das wollte ich gerade anpassen: mfg Egon
Jörg Wunsch wrote: > Hmm, verrätselst du uns noch den Controllertyp? > > Wie schon geschrieben, vermute ich den Fehler in deiner Build-Umgebung > (Makefile oder so), die hast du uns leider nicht mitgegeben. > > Nachdem ich <avr/twi.h> in <util/twi.h> geändert habe, compiliert es, > aber es linkt nicht: > > % avr-gcc -mmcu=atmega16 -Os -o foo.elf AVRTel20.c > /tmp/ccGMsAry.o: In function `texte': > AVRTel20.c:(.text+0x466): undefined reference to `Zulauf' Zulauf ist eine Funktion In der Funktionsdefinition ist es allerdings als 'zulauf' (mit kleinem Z) geschrieben, beim Aufruf als 'Zulauf' (mit grossem Z). Muss schon ein sehr alter Compiler gewesen sein, wenn er das durchgehen lies :-)
@Jörg Wenn du schon dabei bist: Baust du ihm bitte auch noch gleich eine lcdtxt_string Funktion ein? Sowas:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
ist nicht wirklich wartungsfreundlich :-)
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
Gast
#559012
Ich muß den Compiler in Schutz nehmen, ich habe vorhin etwas an den Texten gebastelt, da könnte das geschehen sein. E.
Karl heinz Buchegger wrote: > Zulauf ist eine Funktion > In der Funktionsdefinition ist es allerdings als 'zulauf' (mit > kleinem Z) geschrieben, beim Aufruf als 'Zulauf' (mit > grossem Z). Außerdem noch mit einem Argument 0 aufgerufen obwohl als void deklariert... > Muss schon ein sehr alter Compiler gewesen sein, wenn er > das durchgehen lies :-) -fno-syntax-check oder sowas :.) Wenn ich den Aufruf von Zulauf(0) in zulauf() ändere, lässt es sich zumindest anstandslos compilieren. Egon Müller wrote: > Anders kann ich mir das eigentümliche Verhalten des LCD nicht > erklären: Die Texte werden dargesstellt, aber das Display läßt sich > nicht löschen. Nun, das ist zumindest erstmal was völlig anderes als deine multiple definition errors von ganz am Anfang.
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
Hier hat natürlich Peter Danneger dann wohl eher Recht... Probier doch mal
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
Allerdings solltest du dir unbedingt mal angucken, wofür Atmel in deinen AVR gleich 3 Timer eingebaut hat...
Karl heinz Buchegger wrote:
>1 | |
2 | |
3 | |
4 | |
5 | |
Nicht ganz.
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
entspricht eher dem Original. Keine Ahnung, warum er 0xa0 statt 0x20 für das Leerzeichen nimmt.
Gast
#559074
Nachdem ich Eure Beiträge gelesen habe, und gesehen habe, daß da schon die Neben-Kriegsschauplätze betrachtet werden können(LCD_STRING, delay usw, was ich später verdauen werde), und dann gar noch lesen konnte ..."Wenn ich den Aufruf von Zulauf(0) in zulauf() ändere, lässt es sich zumindest anstandslos compilieren." war ich voller Hoffnung, daß es irgendwie funktionieren wird. Nach der kurzen Phase der Euphorie sollten wir uns wieder dem realen Leben zuwenden: Ich habe die Textgeschichten begradigt, einen handfesten Fehler eingebaut als Kontrolle für den Compiler und dann make gestartet. Das Ergebnis ist schlimmer als zuvor: nicht mal der Compiler lebt. Ich habe makefile durchsucht, da müßte doch der Pfad zu WinAVR/bin usw. stehen? Das Ergebis des Laufes füge ich als jpg bei (ich weiß nicht, wie man das cmd-Fenster auf die Schnelle als Text extrahieren kann) mfg Egon
Gast
#559075
hier das Bild
Angehängte Dateien:
-
Compiler.jpg
(30 KB)
Gast
#559085
Die Fehlermeldung besagt, daß make mit der Datei AVRTel20 nichts anzufangen weiss, da die keinen bekannten Typ hat. Da fehlt die Extension (.c?) Lösch das makefile, und mach es mit mfile neu. Die Pfade sind anscheinend richtig, der avr-gcc wird auf jeden Fall gefunden.
Gast
#559086
Nachtrag: Das .c fehlte schon bei der Datei, die du weiter oben angehängt hattest. Oliver
> ich weiß nicht, wie man das > cmd-Fenster auf die Schnelle als Text extrahieren kann
1 | |
Danach log.txt anhängen.
Oliver wrote:
> Lösch das makefile, und mach es mit mfile neu.
Kann ich auch empfehlen.
Aber nicht radikal Löschen, sondern umbenennen, damit du die alten
Optionen/Programmereinstellungen mit den neuen Optionen vergleichen und
anpassen kannst.
Das gepostete Makefile hat bei mir drei Probleme
1/ Es geht noch von AVRTel15.c aus, während die Source jetzt AVRTel20.c
heisst (heissen soll).
2/ Obwohl MCU = atmega16 definiert ist, wird die Definition nicht
beachtet. Ausserdem werden in den Kommandozeilen (aus $(CC)...) Flags
doppelt aufgeführt. Letztlich führt das zur Warnung
In file included from AVRTel20.c:82:
e:/temp/winavr/bin/../avr/include/avr/io.h:332:6: warning: #warning
"device type not defined"
3/ Die Datei AVRTel20.c wird aufgrund von 2/ bei einem erfolgreichen
Compilerlauf mit dem Listing überschrieben und ist weg, futsch, kaputt!
In der Source sind auch einige, bereits genannte Probleme
A/ twi.h steht nicht mehr in avr/ sondern in util/. Das #include ist zu
ändern
B/ Der Funktionsaufruf Zulauf(0) ist nicht definiert. Entweder ist die
Schreibweise und der Parameter falsch, denn es gibt eine Funktion
zulauf() oder es fehlt Sourcecode
C/ Die Warteschleifen in der jetzigen Form auf Basis von pause() werden
vom GCC "gnadenlos" wegoptimiert. Ggf. die Optimierung abschalten ;-(
oder mit _delay_ms() und _delay_us() aus der avr-libc arbeiten
(Einsteiger) oder Timer einsetzen (Fortgeschrittene).
Gast
#559321
make > log.txt 2>&1 Ich hatte nur >log.txt, da wurde bloß der Vorspann übernommen, allerdings zeichnet > log.txt 2>&1 auch nicht immer alles auf. Also, das ... .c habe ich dranbekommen, nun wird die Datei als compilierungsfähig angesehen. Die Pfade zu den include-Dateien mußte ich seltsamerweise diesmal komplett angeben. Das Ergebnis der Compilerlaufes füge ich an. Die Errors wegen der multiplen Definitionen sind leider noch immer enthalten: -------- begin -------- avr-gcc (GCC) 4.1.1 (WinAVR 20070122) Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. avr-gcc -gdwarf-2 -DF_CPU=1000000UL -O1 -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-adhlns=./AVRTel21.lst -std=c89 -Wundef -gdwarf-2 -DF_CPU=1000000UL -O1 -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -fno-exceptions -Wall -Wa,-adhlns=AVRTel21.c -Wl,-Map=AVRTel21.map,--cref -lm AVRTel21.c -o AVRTel21 In file included from AVRTel21.c:76: C:/Progr-MCU/WinAVR070122/avr/include/avr/io.h:336:6: warning: #warning "device type nicht definiert. Was heisst das?" AVRTel21.c: In function 'main': AVRTel21.c:390: warning: unused variable 'i' Linking: AVRTel21.elf avr-gcc -mmcu=atmega16 -I. -gdwarf-2 -DF_CPU=1000000UL -O1 -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-adhlns=AVRTel21 -std=c89 -Wundef -MMD -MP -MF .dep/AVRTel21.elf.d AVRTel21 --output AVRTel21.elf -Wl,-Map=AVRTel21.map,--cref -lm AVRTel21: In function `__bad_interrupt': ../../../../../avr-libc-1.4.5/crt1/gcrt1.S:123: multiple definition of `__bad_interrupt' c:/progr-mcu/winavr070122/bin/../lib/gcc/avr/4.1.1/../../../../avr/lib/a vr5/crtm16.o:../../../../../avr-libc-1.4.5/crt1/gcrt1.S:51: first defined here AVRTel21: In function `__vectors': ../../../../../avr-libc-1.4.5/crt1/gcrt1.S:51: multiple definition of `__vectors' c:/progr-mcu/winavr070122/bin/../lib/gcc/avr/4.1.1/../../../../avr/lib/a vr5/crtm16.o:../../../../../avr-libc-1.4.5/crt1/gcrt1.S:51: first defined here make: *** [AVRTel21.elf] Error 1 Und zur Orientierung nochmals die modifizierte C-Datei AVRTel21.c als Anhang. Ob man den Fehler doch noch eliminieren kann ???
Gast
#559327
>warning: #warning >"device type nicht definiert. Was heisst das?" Wie oben schon gesagt wurde, ist dein makefile nicht in Ordnung. Hast du dir mal ein neues angelegt? Bei mir compiliert das Programm fehlerfrei, nur eine Warnung ../Main.c:390: warning: unused variable 'i' Oliver
Gast
#559329
Hier mal mein makefile. Oliver
Gast
#559342
Frage: was gibt which -a avr-gcc.exe aus? was gibt avr-gcc -print-file-name=include aus? Oliver
KPC wrote: > Also, das ... .c habe ich dranbekommen, nun wird die Datei als > compilierungsfähig angesehen. Die Pfade zu den include-Dateien mußte ich > seltsamerweise diesmal komplett angeben. Du hast immer noch den gleichen Fehler im Makefile, wie oben unter 1/ aufgeführt. Man erkennt den Fehler an der Statusmeldung vom Compilerlauf deines avr-gcc. Der Teil zwischen ### und ### ist zuviel! > avr-gcc -gdwarf-2 -DF_CPU=1000000UL -O1 -funsigned-char > -funsigned-bitfields -fpack-struct -fshort-enums -Wall > -Wstrict-prototypes -Wa,-adhlns=./AVRTel21.lst -std=c89 -Wundef ### > -gdwarf-2 -DF_CPU=1000000UL -O1 -funsigned-char -funsigned-bitfields > -fpack-struct -fshort-enums -fno-exceptions -Wall -Wa,-adhlns=AVRTel21.c > ### -Wl,-Map=AVRTel21.map,--cref -lm AVRTel21.c -o AVRTel21 Und der Subteil -Wa,-adhlns=AVRTel21.c führt dazu, dass beim ersten Mal wenn der Compiler ohne Fehler durchrattert, deine Source mit dem Assemblerlisting überschrieben wird. Und der Teil mit der MCU Definition und dem Includepfad fehlt bei der Compiler-Kommandozeile. Bei der Linker-Kommandozeile ist es übrigens korrekt (hier der korrekte Teil zwischen ***) > Linking: AVRTel21.elf > avr-gcc *** -mmcu=atmega16 -I. *** -gdwarf-2 -DF_CPU=1000000UL -O1 > -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall > -Wstrict-prototypes -Wa,-adhlns=AVRTel21 -std=c89 -Wundef -MMD -MP -MF > .dep/AVRTel21.elf.d AVRTel21 --output AVRTel21.elf > -Wl,-Map=AVRTel21.map,--cref -lm Wegen dem fehlenden MCU kommt diese Warnung: > In file included from AVRTel21.c:76: > C:/Progr-MCU/WinAVR070122/avr/include/avr/io.h:336:6: warning: #warning > "device type nicht definiert. Was heisst das?" Der Pfad C:/Progr-MCU/WinAVR070122/avr/include/avr/io.h sieht komisch aus. Das MCU kennen wir das? Kann es sein, dass du WinAVR070122 in einem Ordner mit Leerzeichen installiert hast? In diesem Fall verhaspelt sich vielleicht das Programm. Es wird allgemein empfohlen WinAVR NICHT in einem Pfad mit Leerzeichen (und Sonderzeichen) zu installieren. Die Fehlermeldungen beim Linken sind bestimmt auf die fehlende Definition des Targets (über MCU) zurückzuführen. Dadurch scheitert das Einbinden des korrekten Startupcodes bzw. der passenden Library. Mal sehen was auf Olivers vorgeschlagenen Test herauskommt. Und ich lege dir nochmals ans Herz ein neues Makefile mit Mfile aufzubauen (bzw. das von Oliver zu nehmen)
Wenn Du mit make so große Schwierigkeiten hast, kannst Du den GCC auch auf der Kommandozeile starten. Dazu startest Du die Eingabeaufforderung und gehst in Dein Projektverzeichnis, wo die *.c Dateien stehen. Und dann tippst Du folgende 3 Zeilen ein: path C:\Progr-MCU\WinAVR070122\bin;%path% avr-gcc.exe -xc -Os -mmcu=atmega16 -Wall -g -o test.out *.c avr-objcopy.exe -O ihex test.out test.hex Dann solltest Du ein test.hex darin finden. Peter
Gast
#559435
Also, auf die beiden Anfragen bekommt man zu lesen: > which -a avr-gcc.exe liefert C:\Progr-MCU\WinAVR070122\bin\avr-gcc.exe und avr-gcc -print-file-name=include liefert c:/progr-mcu/winavr070122/bin/../lib/gcc/avr/4.1.1/include. Ich habe mir nochmals die Pfade angesehen, bis auf den einen Bindestrich bei Progr-MCU gibt es nur Buchstaben und Zahlen, nirgends sind Leer- oder Sonderzeichen. Früher habe ich nie den ganzen Pfad eingeben müssen, erst heute hat der Compiler gemault: solche Datei nicht gefunden. Der komplette Pfad bis zum letzten Directory wurde verlangt! Meine makefiles habe ich mir nochmals genau durchgesehen, aber mit den unzählichen Parametern kann ich (noch?) nichts anfangen, obwohl es mich schon gejuckt hätte, bei remove target.hex usw einen Haken zu machen, denn daß jedesmal die C-Datei zerschossen wird, ist ziemlich lästig. Ich habe danach noch einen Kompillierungsversuch gemacht - wieder ohne Erfolg. Dann habe ich Olivers makefile original benutzt, wobei mich zwei Dinge gewundert haben: 1. Als C-Level war gnu99 angegeben - ist das angebracht? 2. Das Feld, wo die C-Source eingetragen wird, war leer - war das vielleicht in voller Absicht geschehen? Das Ergebnis war durchwachsen: Der Vorspann sah nicht nach doppelten Einträgen aus und meine C-Datei wurde nicht zerschossen (vielleicht ist er nur nicht bis dahin gekommen?) Anderseits ist er schon gleich zu Anfang über einen Fehler gestolpert, der dann zu seitenweisen Errors führte. Ich füge hier erst mal ein Stück der Ausgabe an und dann versuche ich, mit Olivers makefile etwas zu spielen (and. C-Level, Source nachtragen usw). Wäre nett, wenn Ihr dann mal das Ergebnis betrachten würdet. Schönen Abend noch Egon Hier ein Stück von AVRTel21 mit Olivers Original-makefile -------- begin -------- avr-gcc (GCC) 4.1.1 (WinAVR 20070122) Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compiling C: AVRTel21.c avr-gcc -c -mmcu=atmega16 -I. -gdwarf-2 -DF_CPU=8000000UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-adhlns=./AVRTel21.lst -std=gnu99 -Wundef -MMD -MP -MF .dep/AVRTel21.o.d AVRTel21.c -o AVRTel21.o AVRTel21.c: In function 'main': AVRTel21.c:390: warning: unused variable 'i' Linking: AVRTel21.elf avr-gcc -mmcu=atmega16 -I. -gdwarf-2 -DF_CPU=8000000UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-adhlns=AVRTel21.o -std=gnu99 -Wundef -MMD -MP -MF .dep/AVRTel21.elf.d AVRTel21.o --output AVRTel21.elf -Wl,-Map=AVRTel21.map,--cref -lm Creating load file for Flash: AVRTel21.hex avr-objcopy -O ihex -R .eeprom AVRTel21.elf AVRTel21.hex Creating load file for EEPROM: AVRTel21.eep avr-objcopy -j .eeprom --set-section-flags=.eeprom="alloc,load" \ --change-section-lma .eeprom=0 --no-change-warnings -O ihex AVRTel21.elf AVRTel21.eep || exit 0 c:\Progr-MCU\WinAVR070122\bin\avr-objcopy.exe: there are no sections to be copied! Creating Extended Listing: AVRTel21.lss avr-objdump -h -S AVRTel21.elf > AVRTel21.lss Creating Symbol Table: AVRTel21.sym avr-nm -n AVRTel21.elf > AVRTel21.sym Size after: AVR Memory Usage ---------------- Device: Unknown Program: 1436 bytes (.text + .data + .bootloader) Data: 16 bytes (.data + .bss + .noinit) -------- end -------- Mehr ist mit >log.txt >2&1 nicht zu bekommen, es gibt dann seitenweise error invalid digit in integer constant, in octal constant und auch einige in floating constant.
Es wurde doch übersetzt. Du hast jetzt ein fertiges AVRTel21.hex Im Makefile stimmt mindestens die F_CPU = 8000000 noch nicht (du hattest 1000000). Die Optimierung steht auf s (du hattest 1). Und du solltest den Abschnitt zu program: mit deinem alten Makefile vergleichen, wenn du mit make program das Hexfile in das µC-Flash senden willst. Die Zeile mit den C Sourcefiles ist in Olivers Makefile nicht leer. Dort steht SRC = $(TARGET).c und TARGET ist als TARGET = AVRTel21 definiert. Ergo ist SRC indirekt als AVRTel21.c definiert. Nicht verwechseln mit der Zeile mit dem CPPSRC, die ist für C++ Quelldateien!
Gast
#559452
>Es wurde doch übersetzt. Du hast jetzt ein fertiges AVRTel21.hex Stimmt! Und in der Applikation läuft es sogar, wenngleich an der LCD-Ansteuerung noch viel Nacharbeit nötig ist (ich vermutete veraltete Bitmanipulationen). >Im Makefile stimmt mindestens die F_CPU = 8000000 noch nicht (du hattest >1000000). Ich werde es auf 1000000 stellen, hier ist nichts auch nur im entferntesten zeitkritisch. >Die Optimierung steht auf s (du hattest 1). Inzwischen habe ich gelesen, daß meine handgemachten Zeitschleifen wegoptimiert werden, also dachte ich, zunächst ohne Optimierung bis zur Fertigstellung besserer Schleifen zu arbeiten. >Und du solltest den Abschnitt zu program: mit deinem alten Makefile >vergleichen, wenn du mit make program das Hexfile in das µC-Flash senden >willst. Bevor ich kein Manual, habe nehme ich lieber Olivers makefile von einem Projekt zum nächsten mit und mein makefile vergesse ich. >Die Zeile mit den C Sourcefiles ist in Olivers Makefile nicht leer. Dort >steht SRC = $(TARGET).c und TARGET ist als TARGET = AVRTel21 definiert. >Ergo ist SRC indirekt als AVRTel21.c definiert. Nicht verwechseln mit >der Zeile mit dem CPPSRC, die ist für C++ Quelldateien! Ist das so zu verstehen, daß man in dem GUI von mfile im Menuepunkt C/C++files die C-Datei n i c h t eintragen, sondern nur das Häkchen bei include setzen darf? Ist die gnu99-Einstellung für den z.Zt. betagten Code angebracht? Ins Auge fällt, daß er die // als Kommentarzeichen akzeptiert. Was ich bei der Gelegenheit noch ftagen wollte: gibt es ein neueres gcc-avr-libc reference manual? Meines ist von 2003 und ich finde kein neueres, aber vielleicht habe ich an den falschen Stellen gesucht? Gute Nacht noch wünscht Egon
Gast
#559484
Das makefile ist ganz einfach mit mfile erstellt. Das solltest du dir mal näher ansehen - einfacher als damit geht es gar nicht. Aufrufen, im Menu Prozessor, Takt und Sourcefiles anklicken, fertig. Das fertige makefile mit "save as..." in den Ordner abspeichern, in dem auch dein .c-file liegt, fertig. Im makefile selber brauchst du gar nicht mehr zu editieren. Mfile findet sich im Windows-Startmenu unter Programme/WinAVR. Die aktuelle avr-libc-Dokus gibt es immer unter http://www.nongnu.org/avr-libc/ Die Pfade scheinen auf deinem System alle richtig gesetzt zu sein. Poste doch nochmal die Fehlermeldung, die sich mit
1 | |
2 | |
3 | |
4 | |
ergeben. Oliver
Gast
#559608
> Das makefile ist ganz einfach mit mfile erstellt. Das solltest du dir > mal näher ansehen - einfacher als damit geht es gar nicht. Das benutze ich auch fast immer. Aber ich glaube, ich weiß, woran die letzten Fehlermeldungen gelegen haben: Wenn ich in mfile im Makefilemenue C/C++-Sources anklicke, öffnet sich ein Fenster, in das ich immer meine C-Datei eingetragen habe (und noch ein Häkchen bei include). Das darf man nicht! Das Feld muß leer bleiben, die Source darf hier nicht eingetragen werden. Dann funktioniert es. Man kann den Fehler gut reproduzieren. > Die Pfade scheinen auf deinem System alle richtig gesetzt zu sein. Poste > doch nochmal die Fehlermeldungen...... Ob es in solchen Programmen oder Schaltkreisen manchmal spukt? Die include-Aufrufe hatte ich immer so, wie Du sie gepostet hast. Gestern wurde gemault: "no such file or directory", solange, bis ich in die alten Aufrufe haarklein den gesamten Pfad eingetragen habe. Heute habe ich wieder die alte Form - und es gibt keine Fehlermeldungen. Ich glaube, meine Anfangsschwierigkeigen mit dem neuen WinAVR sind erst mal überwunden dank Eurer freundlichen Hilfe. Nun kann ich mich der Anpassung des alten Codes an das neue gcc und dann endlich der dringenden Weiterentwicklung widmen. Vielen Dank für Eure Hilfe mfg Egon @ Peter hätte ich fast vergessen: die Aufrufe über die Console haben funktioniert! (ist allerdings nichts für Leute wie mich, die sich so häufig vertippen)
KPC wrote: > Wenn ich in mfile im Makefilemenue C/C++-Sources anklicke, öffnet > sich ein Fenster, in das ich immer meine C-Datei eingetragen habe > (und noch ein Häkchen bei include). Lies bitte bei "include" mal weiter: da steht nämlich noch, was darin eingeschlossen ist. Sehr viele einfache Projekte bestehen ausschließlich aus einer Quelldatei, die dann den Projektnamen mit angehängtem ".c" hat. Daher ist die Voreinstellung, genau diese Datei (und sonst nichts) zu compilieren. Wenn du die gleiche Datei nun nochmal bei "C/C++-Sources" angibst ohne dabei das "include projectname.c" abzuwählen, hast du die Datei natürlich zweimal dabei. > Ich glaube, meine Anfangsschwierigkeigen mit dem neuen WinAVR sind > erst mal überwunden dank Eurer freundlichen Hilfe. Nun kann ich mich > der Anpassung des alten Codes an das neue gcc und dann endlich der > dringenden Weiterentwicklung widmen. Guck dir doch bitte gleich noch an, wie man Timer benutzt.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.