Hi, Ich erbitte mal Anfängerhilfe für mein erstes C Projekt. In Assembler hab ich schon programmiert und auch Erfolge gehabt. Nun meine ersten Gehversuche mit GCC - und ich komm nicht weiter. Als Projekt hab ich mir den Code von Microsyl.com geholt um ein Nokia 3310 Display am ATMega8 zum spielen zu bringen. Beim compilieren kommt diese Fehlermeldung: > "make.exe" all avr-gcc -g -Wall -O2 -mmcu=atmega8 -c -o 3310_LCD.o 3310_LCD.c In file included from 3310_LCD.c:20: 3310_LCD.h:19:1: warning: "NULL" redefined In file included from C:/Programme/WinAVR/avr/include/stdio.h:43, from 3310_LCD.c:17: C:/Programme/WinAVR/lib/gcc-lib/avr/3.3.2/include/stddef.h:402:1: warning: this is the location of the previous definition 3310_LCD.c: In function `Delay': 3310_LCD.c:587: error: unrecognizable insn: (insn 50 32 10 0 00000000 (set (reg/v:HI 41) (const_int 64000 [0xfa00])) -1 (nil) (expr_list:REG_EQUAL (const_int 64000 [0xfa00]) (nil))) 3310_LCD.c:587: internal compiler error: in extract_insn, at gcc-3.3.2/gcc/recog.c:2175 Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://gcc.gnu.org/bugs.html>; for instructions. make.exe: *** [3310_LCD.o] Error 1 > Process Exit Code: 2 -------------------------------------------------------------- Gcc meckert immer diese Funktion an: static void Delay ( void ) { int i; for ( i = -32000; i < 32000; i++ ); } -------------------------------------------------------------- ohne dass ich im Main überhaupt was eingetragen habe. Mein kompletter Code befindet sich im Anhang. Da ich nicht weiter weiss, bitte ich um Hilfe. Warum geht eine einfache Verzögerungsschleife nicht? Schon mal Danke für Eure Mühe! Gruss Holger
> In file included from 3310_LCD.c:20: > 3310_LCD.h:19:1: warning: "NULL" redefined > In file included from C:/Programme/WinAVR/avr/include/stdio.h:43, > from 3310_LCD.c:17: > C:/Programme/WinAVR/lib/gcc-lib/avr/3.3.2/include/stddef.h:402:1: > warning: this is the location of the previous definition Nun, hier steht eigentlich alles da. NULL ist ein Makro, der vom C-Standard festgelegt ist. Ein Anwenderprogramm (3310_LCD.h in diesem Falle) sollte nicht versuchen, diesen Makro neu zu definieren. > 3310_LCD.c:587: error: unrecognizable insn: > (insn 50 32 10 0 00000000 (set (reg/v:HI 41) > (const_int 64000 [0xfa00])) -1 (nil) > (expr_list:REG_EQUAL (const_int 64000 [0xfa00]) > (nil))) > 3310_LCD.c:587: internal compiler error: in extract_insn, at > gcc-3.3.2/gcc/recog.c:2175 > Please submit a full bug report, > with preprocessed source if appropriate. > See <URL:http://gcc.gnu.org/bugs.html>; for instructions. Auch hier steht eigentlich alles da. Ein interner Compilerfehler, Du sollst einen Bugreport dafür einreichen. :( Allerdings solltest Du das nur tun, wenn Du zuvor verifiziert hast, daß der aktuelle GCC (3.4.x) das Problem nicht schon beseitigt hat.
Hallo Jörg, erst mal Danke für die Antwort. Richtig weiter hilft mir das ja nun allerdings nicht. Bitte nicht böse sein - aber geh mal davon aus, dass ich des lesens mächtig bin. Das erste ist ja nur eine Warnung. Na ok, das Programm sollte trotzdem laufen. Nun die richtige Fehlermeldung: hier wird eine "einfache" Zählschleife angemeckert. Eine lokale Variable i wird erzeugt, von -32000 bis +32000 gezählt und die Funktion verlassen. Tada: delay Funktion fertig. So würde ich den Sinn jedenfalls verstehen. Das kann doch nicht einen internen Compilerfehler verursachen!? oder doch? Ich denke mehr an irgendwelche Systemlibs die ich nicht integriert habe oder irgend son Quatsch. Liege ich völlig falsch? gruss Holger
> Das erste ist ja nur eine Warnung. Na ok, das Programm sollte > trotzdem laufen. Besser wäre es trotzdem, das zugrundeliegende Problem zu beseitigen und NULL nicht neu zu definieren. > hier wird eine "einfache" Zählschleife angemeckert. Eine lokale > Variable i wird erzeugt, von -32000 bis +32000 gezählt und die > Funktion verlassen. Tada: delay Funktion fertig. Funktioniert sowieso nicht. Der Compiler wird Dir die Schleife durch die Optimierung zu sehr verkürzen. Benutze die Makros aus <avr/delay.h> stattdessen. > Das kann doch nicht einen internen Compilerfehler verursachen!? Warum nicht? Es steht doch klipp und klar da: das ist ein Bug im Compiler, und Du sollst ihn entsprechend als Bugreport einsenden, damit der künftig behoben werden kann. Bugs treten nun mal auf, ob in einfachen Zählschleifen (egal wie sinnvoll diese semantisch wirklich sind oder nicht) oder woanders -- dafür sind es eben Bugs. Programmierfehler derjenigen, die den Compiler geschrieben haben. Damit mußt Du leben. Einziger Ausweg: Du kannst Dir den Quellcode des Compilers nehmen und ihn selbst reparieren, wenn Du willst. Oder eben den Bugreport schreiben, damit jemand anders die Chance bekommt, ihn zu reparieren. (Aber s. o.: zuvor bitte auf einem aktuellen Compiler gegentesten.) > Ich denke mehr an irgendwelche Systemlibs die ich nicht integriert > habe oder irgend son Quatsch. Mit Libraries hat das alles gar nichts zu tun -- die behandelt der Linker. Du hast aber einen internen Fehler im Compiler gemeldet bekommen. Nein, trau bitte dem, was da geschrieben steht, statt irgendwas anderes zu mutmaßen.
Ich habe die Erfahrung gemacht, daß sich oft nicht sichtbare Sonderzeichen mit reingeschmuggelt haben und dadurch ein Assembler oder Compiler völlig aus den Fugen geraten kann. Da hilft dann nur, durch die Halbierungsmethode genau die Zeile zu finden, mit der dann die Fehlermeldung kommt. Dann kann man diese komplett löschen und neu eintippen (d.h. nicht mit copy + paste !). Bzw. man sieht dann doch, daß diese Zeile syntaktisch falsch ist. Insbesondere alle vorangegangenen #define sind gründlich zu prüfen. Peter
Also dass ein interner Compilerfehler mit der oben angegebenen Fehlermeldung durch Sonderzeichen verursacht wird möchte ich doch mal stark bezweifeln.
@Andreas, zweifel ruhig, aber nur ein Versuch macht klug. Z.B. der alte Metalink Assembler stürzte ohne jede Meldung ab und das alte PALASM brachte völlig abstruse Fehlermeldungen, sobald man Umlaute in Kommentaren benutzte. Ein häufiger Kandidat ist auch das ', es gibt richtige ' und falsche ´`, die sich je nach Zeichensatz täuschend ähnlich sehen. Und ein 0xFF sind oft wie ein ganz harmloses Leerzeichen aus. Peter
Hallo Leute, Vielen Dank für Eure Hilfe. Den Hinweis mit delay.h werd ich beherzigen! Übrigens hab ich mir gestern die halbe Nacht um die Ohren geschlagen und alles mögliche Zeug ausprobiert. Dabei hab ich mal ein neues Makefile mit mfile erzeugt. Ergebnis: Durchlauf ohne Fehler, *.hex File erzeugt! Ob das Ganze funktioniert werd ich mal Montag berichten, denn noch Main.c zu schreiben und das Target-Board zu proggen hatte ich keine lust mehr (Zeit 1:45 uhr) Nochmals Danke, es ist wirklich Klasse wie schnell hier versucht wird Leuten zu helfen und das Alles ja nur ala Hobby ohne komerziellen Hintergrund. Starkes Forum! Allen ein schönes Wochenende!! Gruss Holger
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.