Hallo Leute, dies ist mein erster Beitrag hier in diesem Forum. Ich habe schon gestöbert, bin aber nicht wirklich fündig geworden. Seht es mir bitte nach, falls das so ähnlich schon mal gefragt wurde. Das Problem scheint etwas spezieller zu sein oder ich bin speziell ungeschickt oder so ;). Es geht um dieses Projekt: http://www.myplace.nu/avr/countermeasures/index.htm Ich kriege da mit Bascom Fehlermeldungen beim Compilieren. Vielleicht habe ich da das falsche Programm? Mit AVR-Studio 4 und dem GCC-Compiler andere Fehlermeldungen. Ich kriege da einfach keine .hex-Datei draus gemacht, die ich dann mit dem AVR-Studio flashen kann. Ich benutze normalerweise nur AVR-Studio mit dem AVR-ISP. Allerdings habe ich vom Programmieren selber leider keine Ahnung, kann also nicht analysieren woran es liegt. Kann mir da jemand helfen oder womöglich eine aus diesem Projekt (siehe URL oben) eine .hex-Datei machen und zusenden oder mir verraten, wie man das hinbekommt? Herzlichen Dank im voraus und beste Grüße Uwe
>Ich kriege da mit Bascom Fehlermeldungen beim Compilieren. Vielleicht >habe ich da das falsche Programm? Was zum Teufel hat Bascom mit C zu tun? Von nix ne Ahnung aber irgendwas wollen. Lernen und selber mal den Arsch hochkriegen ist ja nicht mehr modern. Blöde Fragen in Foren stellen ist einfacher. Geh woanders spielen Kleiner.
>wieso? In BASIC ist doch auch ein C drin.
Da ist auch ein A drin. Man könnte ja auch mal versuchen
den C Code durch einen Assembler zu jagen.
Also, das Problem ist nicht speziell, es ist ganz grundlegend. Das Programm counter.c ist in der Sprache C verfasst (wie man an der Endung .c leicht erkennen kann). Deswegen muss es mit einem C Compiler übersetzt werden. Bascom ist ein Basic Compiler, der ist nicht für C. AVR-GCC ist ein dafür geeigneter Compiler. AVR-Studio ist eine für den AVR-GCC (oder genauergesagt dessen Windowsversion WINAVR) geeignete Entwicklungsumgebung (IDE). Abgesehen davon, dass die Includeverzeichnisse für den neuen avr-gcc nicht mehr stimmen: Es muss heißen: #include <avr/io.h> #include <avr/signal.h> #include <avr/interrupt.h> Gibt es einen ganzen Haufen der verwendeten Assemblermakros nicht mehr: outp(TI0_L, TCNT0); usw... Das muss alles in heute übliche Syntax umgeschrieben werden. Grüße, Peter
Wie ich herausgefunden habe, gibt es jemanden, der diese Makros aufgelöst hat. Beitrag "Re: AVR Studio und AVR GCC" Wenn man das einbindet, ist es zumindest compilierbar, was aber noch nicht bedeutet, dass es auch läuft... Ich habe die include-Sektion geändert auf: #include <avr/io.h> #include <avr/signal.h> #include <avr/interrupt.h> #include "oldmacros.h" und oldmacros.h von oben genanntem Link im Projetverzeichnis abgelegt. Ich denke nicht, dass man von einem Anfänger erwarten sollte, dass er da drauf kommt. Mit dieser Information sollte es nun kein Problem mehr sein, den Code zu compilieren. Grüße, Peter
holger schrieb: > Was zum Teufel hat Bascom mit C zu tun? Das habe ich mich auch gefragt. Bin davon ausgegangen, daß da wie im AVR Studio auch ein C-Compiler enthalten ist. > Von nix ne Ahnung aber irgendwas wollen. "Von nix" ist ja wohl etwas anmaßend. > Lernen und selber mal den Arsch hochkriegen ist ja > nicht mehr modern. Blöde Fragen in Foren stellen ist einfacher. Umgangsformen und Höflichkeit lernte man wohl nicht auf deiner Klipperschule? > Geh woanders spielen Kleiner. Wo bin ich kleiner? Jünger vielleicht, wenn Du schon Rente kriegst. Kleiner womöglich wenn Du größer als 182 bist. Ansonsten hat es mich gefreut, daß Du wenigstens versucht hast, einen Beitrag mit Aussagewert zu verfassen. Weiter so!
Hallo Peter, vielen Dank für Deine sachliche Antwort. Peter Diener schrieb: > Ich habe die include-Sektion geändert auf: > > #include <avr/io.h> > #include <avr/signal.h> > #include <avr/interrupt.h> > #include "oldmacros.h" > > und oldmacros.h von oben genanntem Link im Projetverzeichnis abgelegt. Habe ich beides gemacht, den erwähnten Code durch das von Dir ersetzt und die Datei heruntergeladen aus dem anderen Thread und in meinen Arbeitsordner kopiert. Dann erscheinen folgende Meldungen:
1 | rm -rf counter.o counter.elf dep/* counter.hex counter.eep |
2 | Build succeeded with 0 Warnings... |
3 | avr-gcc.exe -mmcu=atmega8 -Wall -gdwarf-2 -O0 -MD -MP -MT counter.o -MF dep/counter.o.d -c ../counter.c |
4 | In file included from ../counter.c:45: |
5 | d:/winavr-20090313/lib/gcc/../../avr/include/avr/signal.h:36:2: warning: #warning "This header file is obsolete. Use <avr/interrupt.h>." |
6 | ../counter.c: In function 'capture': |
7 | ../counter.c:258: error: 'OCR1H' undeclared (first use in this function) |
8 | ../counter.c:258: error: (Each undeclared identifier is reported only once |
9 | ../counter.c:258: error: for each function it appears in.) |
10 | ../counter.c:259: error: 'OCR1L' undeclared (first use in this function) |
11 | ../counter.c: In function 'main': |
12 | ../counter.c:347: error: 'OCR1H' undeclared (first use in this function) |
13 | ../counter.c:348: error: 'OCR1L' undeclared (first use in this function) |
14 | make: *** [counter.o] Error 1 |
15 | Build failed with 6 errors and 1 warnings... |
> Ich denke nicht, dass man von einem Anfänger erwarten sollte, dass er da > drauf kommt. Das sehe ich auch so, da wäre ich auch nie drauf gekommen. Zumal ich es wahrscheinlich nicht mehr schaffe, mich halbwegs in die Programmierung einzuarbeiten, momentan macht es mir zumindest erst mal Freude, Projekte nachzubauen. Auch davon lernt man ja, wenn auch nicht das Programmieren. > Mit dieser Information sollte es nun kein Problem mehr sein, den Code zu > compilieren. Leider ja, es ist immer noch ein Problem, ich komme also noch nicht wirklich weiter. Ich teste noch mal was, aber vielleicht kann mir ja jemand anhand der Fehlermeldungen noch mal eine kleine Unterstützung angedeihen lassen. Vielen Dank, Peter. Herzliche Grüße Uwe
Sei froh, dass die Fehlermeldungen jetzt kommen und die Fehlersuche nicht erst nach dem Flashen und vergeigen der angeschlossenen Hardware los geht ;-) Der Originalcode ist ja für einen ATTINY2313 geschrieben. Für deinen Atmega8 sind Anpassungen nötig. Für dich ist es nötig, dass der Compiler die symbolischen Namen OCR1H und OCR1L auflösen kann. Üblicherweise wird diese Auflösung mit Hilfe der targetspezifischen (hier atmega8) Includedatei gemacht, die letztendlich über avr/io.h eingebunden wird. Hier könntest du der Sache nachgehen, wieso an dieser Stelle dem Compiler die Namen OCR1H und OCR1L unbekannt sind. Sind die bei dem Target atmega8 nicht vorhanden oder heissen die anders? Schaut man die Atmega8 spezifische Includedatei an http://www.koders.com/c/fid42D6B51EDB8FBE1A747586C2485A166105484CE9.aspx?s=include dann fallen einem diese Namen auf: #define OCR1B _SFR_IO16(0x28) #define OCR1BL _SFR_IO8(0x28) #define OCR1BH _SFR_IO8(0x29) #define OCR1A _SFR_IO16(0x2A) #define OCR1AL _SFR_IO8(0x2A) #define OCR1AH _SFR_IO8(0x2B) D.h. es gibt beim ATtiny2313 nur ein OCR1 Register aber beim Atmega8 zwei und die sind mit OCR1A und OCR1B benannt! Der Programmcode muss also für den Atmega8 umgeschrieben werden, damit die gleiche Funktion erreicht wird! Du musst dich wohl oder übel mit den Datenblättern des Attiny2313 und Atmega8 befassen und herausfinden, wie Timer1 arbeitet und wo beide µC anders sind.
Hallo Stefan, vielen herzlichen Dank für Deine erlösende Antwort. Stefan B. schrieb: > Der Originalcode ist ja für einen ATTINY2313 geschrieben. Für deinen > Atmega8 sind Anpassungen nötig. Genau da war das Problem. Ich habe das gar nicht mitbekommen (Anfänger eben), daß da noch von einem anderen Projekt "ATmega8" stand. Selbstverständlich benutze ich einen 2313. Habe das Ganze noch mal neu gemacht und jetzt geht es ohne Fehler und sogar ohne Warnings. Dann habe noch die eine Zeile entfernt (habe mal erfolgreich die Suchfunktionen genutzt und bin hier fündig geworden: Beitrag "<avr/interrupt.h> Was will er mir sagen?". Jetzt steht bei mir nur noch:
1 | #include <avr/io.h> |
2 | #include <avr/interrupt.h> |
3 | #include "oldmacros.h" |
Es funzt erst mal, BUILD ohne Probleme. Werde mal schnell das Teil flashen und dann die Hardware stricken. Mal schauen ob es läuft. Jedenfalls war Deine Antwort genau die Lösung! Vielen herzlichen Dank. So eine kleine sachliche Unterstützung ist doch - wie man sieht - viel mehr wert als niveauloses und unpassendes Angepflaume, wie man es leider in den Foren immer wieder hat, weil die Experten sich über Fehler von Newbees derartig echauffieren, daß sie manchmal die Contenance verlieren ... Nochmals besten Dank an alle im Forum. Viele Grüße Uwe
Worin besteht denn der Unterschied zwischen der "oldmacros.h" und <compat/deprecated.h> (Doku: http://www.nongnu.org/avr-libc/user-manual/group__deprecated__items.html )? scnr, Jörg
Ja, Kasperle hat Recht, der Compiler muss natürlich auf den AT90S2313 eingestellt werden. In wiefern der Tiny2313 als Alternative verwendet werden kann, habe ich jetzt nicht überprüft. >Worin besteht denn der Unterschied zwischen der "oldmacros.h" und ><compat/deprecated.h> compat/deprecated.h habe ich nicht gleich gefunden. Es sollte (habe ich nicht getestet) aber genauso funktionieren. Grüße, Peter
Bitte 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.