neues WinAVR macht Probleme

[Egon M. (kpc)]

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

[Stefan B. (stefan)]

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?

[Oliver (Gast)]

>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

[Karl H. (kbuchegg)]

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.

[Peter D. (peda)]

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:

#ifndef _no_gcc4_h_
#define _no_gcc4_h_
#if __GNUC__ == 4
#error **************************************************
#error
#error GNUC 4 may cause no working application !!!
#error because unforeseen optimizations !!!
#error
#error **************************************************
#endif
#endif

Mit ner Batchdatei schalte ich dann zwischen den Versionen um 
(WINAVR-Verzeichnis umbenennen).


Peter

[Jörg W. (dl8dtl) (Moderator)]

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.

[Oliver (Gast)]

>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

[KPC (Gast)]

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

[KPC (Gast)]

Zweiter Versuch, das Programm beizugügen

mfg Egon

[Oliver (Gast)]

Ist das das Original, oder schon mit Code-Änderungen für den "neuen" 
gcc?

Oliver

[Jörg W. (dl8dtl) (Moderator)]

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'

[KPC (Gast)]

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

[KPC (Gast)]

Der Controller ist ein ATmega16,
zur Build-Umgebung habe ich die makefile beigefügt (ich hoffe, diesmal 
funktioniert die Übertragung gleich)

[KPC (Gast)]

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

[Karl H. (kbuchegg)]

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 :-)

[Karl H. (kbuchegg)]

@Jörg

Wenn du schon dabei bist:
Baust du ihm bitte auch noch gleich eine lcdtxt_string
Funktion ein?

Sowas:

void aussen(void)
  {
  lcdtxt(51);    /* 3  */
  lcdtxt(0xA0);  /*    */
  lcdtxt(0xA0);  /*    */
  lcdtxt(0xA0);  /*    */  
  lcdtxt(0x61);  /* a  */
  lcdtxt(0x75);  /* u  */
  lcdtxt(0x73);  /* s  */
  lcdtxt(0x73);  /* s  */
  lcdtxt(0x65);  /* e  */
  lcdtxt(0x6E);  /* n  */
  lcdtxt(0xA0);  /*    */
  lcdtxt(0xA0);  /*    */
  }

ist nicht wirklich wartungsfreundlich :-)

void lcdtxt_string( const char* string )
{
  while( *string++ )
    lcdtxt( *string );
}

void aussen()
{
  lcdtxt_string( "3   aussen  " );
}

void zulauf()
{
  lcdtxt_string( "2  Zulauf  " );
}

void Teich_unten()
{
  lcdtxt_string( "1  Teichwasser " );
}

[KPC (Gast)]

Ich muß den Compiler in Schutz nehmen,
ich habe vorhin etwas an den Texten gebastelt, da könnte das geschehen 
sein.

E.

[Jörg W. (dl8dtl) (Moderator)]

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.

void pause(void)
        { 
                k=1000;              /* bei 15000 gibt es PCF-Error */
                 for (i=0; i<k; i++)
                 {;
                 };     
        }

void wartezeit(void)
        {
        pause();pause();pause();pause();

        }
        
void lange_warten(void)
        {
        wartezeit(); wartezeit(); wartezeit(); wartezeit(); wartezeit();
        wartezeit(); wartezeit(); wartezeit(); wartezeit(); wartezeit();
        }

Hier hat natürlich Peter Danneger dann wohl eher Recht...

Probier doch mal

#include <util/delay.h>

void pause(void)
{
  _delay_loop_2(1000);
}

Allerdings solltest du dir unbedingt mal angucken, wofür Atmel in
deinen AVR gleich 3 Timer eingebaut hat...

[Jörg W. (dl8dtl) (Moderator)]

Karl heinz Buchegger wrote:

>

> void aussen()
> {
>   lcdtxt_string( "3   aussen  " );
> }
>

Nicht ganz.

#define NBSP "\xa0"

...
void aussen(void)
{
  lcdtxt_string("3" NBSP NBSP NBSP "aussen" NBSP NBSP);
}

entspricht eher dem Original.  Keine Ahnung, warum er 0xa0 statt 0x20
für das Leerzeichen nimmt.

[KPC (Gast)]

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

[KPC (Gast)]

hier das Bild

[Oliver (Gast)]

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.

[Oliver (Gast)]

Nachtrag: Das .c fehlte schon bei der Datei, die du weiter oben 
angehängt hattest.

Oliver

[Jörg W. (dl8dtl) (Moderator)]

> ich weiß nicht, wie man das
> cmd-Fenster auf die Schnelle als Text extrahieren kann

make > log.txt 2>&1

Danach log.txt anhängen.

[Stefan B. (stefan)]

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).

[KPC (Gast)]

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 ???

[Oliver (Gast)]

>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

[Oliver (Gast)]

Hier mal mein makefile.

Oliver

[Oliver (Gast)]

Frage:

was gibt

which -a avr-gcc.exe

aus?

was gibt

avr-gcc -print-file-name=include

aus?

Oliver

[Stefan B. (stefan)]

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)

[Peter D. (peda)]

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

[KPC (Gast)]

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.

[Stefan B. (stefan)]

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!

[KPC (Gast)]

>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

[Oliver (Gast)]

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

#include <avr/io.h>           
#include <util/twi.h>
#include <inttypes.h>  /* io.h ist in twi.h enthalten */
#include <stdio.h>     /* ATmegaspezifische Defin. sind in iom16.h */

ergeben.

Oliver

[KPC (Gast)]

> 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)

[Jörg W. (dl8dtl) (Moderator)]

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.