Hallo Kollegen, seit Tagen suche ich in allen Foren eine Lösung, es will partou nicht klappen: Ich habe ein Prog auf dem ATMega8 geschrieben. Leider ist das Projekt zu groß geworden und ich bin auf den ATMega168 umgestiegen. Der ist zwar Pinkompatibel, das mit dem Interrupt funzt aber nicht. Der alte Code lautete: ISR(TIMER0_OVF_vect) { hier passiert was, ca. 4x pro sekunde } im Hauptprogramm dann: int main(void) { // interrupt initialisieren // Set values for Timer 0: No Prescaler, Timer start, Preload TCCR0 |= (5 << CS00); //TCNT0 = timerStartValue; TIMSK |= (1 << TOIE0); sei(); // und start Der ATMega168 hat aber andere Register. Aber auch mit Datenblatt bekomme ich es einfach nicht hin. Danke schon mal für Eure Hilfe
Bist Du sicher das: 1. Dein Compiler den Mega168 unterstützt ? 2. Du auch als Target den Mega168 ausgewählt und neu compiliert hast ? 3. Keine ASM Teile verwendest ? Es ist immer hilfreich (um nicht zu sagen notwendig ;) ) alle Umgebungsparameter, wie: - Programmer - Compiler - OS wo beides läuft usw. zu kennen, dann werden können geholfen ;) Schau erstmal im Makefile nach, ob da noch als Target Mega8 steht ;) So Du das denn wegen Deines Compilers/Entwicklungsumgebung manuell einsehen und ändern kannst !
Hallo Markus, vielen Dank für die Antwort. Der Compiler (AVR-Studio und Codevision) unterstützen den 168er. Habe auch überall den 168er angewählt (Wähle ich den ATMega8 aus, kommt auch keine Fehlermeldung.) Als Programmer benutze ich Ponyprog oder den Internen von Codevision. Mein OS ist Win2K Aber was meinst Du mit ASM-Teilen? Und du meinst also, die Register sind gleich? Danke Dagmar PS: im Makefile ist auch der ATMega168 angegeben.
Daß die Register auf anderen Adressen sitzen, darum kümmert sich der Compiler. Leider habe aber auch einige Bits ne andere Bedeutung bzw. sitzen in anderen Registern. Da bleibt also nichts anderes übrig, als jedes verwendete Bit zu überprüfen. Peter
Codevision passt aber nicht zu "Makefile" und ISR(..._vect) (und auch nicht zum Thema dieses Forums).
@Dagmar: Mit Codevision und dem AVR-Studio kenne ich mch nicht aus. Allerdings solltest Du mal überprüfen, ob Dein Projekt nicht doch "versehentlich" irgendwo einen Mega8 spezifischen Teil hat. Wie Peter schon sagte gibt es da ein paar kleine aber feine Unterschiede. Hol dir beide Datenblätter und schau Dir mal an, ob bei den Dingen die Du verwendest in den Datenblättern die gleichen Namen der Register und Bits vorhanden sind ! Mit ASM meinte ich ob in Deinem C-Code Assembler inline auftaucht, denn damit kommt der Compiler dann meistens nicht klar !
@Markus: Eigentlich habe ich wirklich überall den richtigen Controller eingestellt. Allerdings habe ich langsam das gefühl, das weder Codevision, noch AVR-Studio und erst recht Ponyprog nicht wirklich mit dem ATMega168 klarkommen. Ich habe auch ein "Lampe ein-aus-Testprogramm" nicht zum laufen bekommen. Auf ATMega8 und ATMega16 bekomme ich keine Fehlermeldung. Lt. Datenbläter sind die von mir verwendeten Register vorhanden. Ich bekomme aber Fehlermeldungen, dass es diese Register gar nicht gibt. Ich habe ein paar Assemblercodes verwendet, das ist aber beim ATMega8 kein Problem. Ich werde wohl oder über den Code kleinschrumpfen müssen oder den ATMega16 nehmen. Halt blöde weil ich alles umfriemeln muss. Danke für Eure Hilfe. PS: @Jörg Wunsch: ...passt nicht ins Thema...?? AVRStudio erzeugt doch ein eigenes Makefile. Aber wieso passt Codevision nicht zu ISR(..._vect)? Und welches Forum würdest Du wählen? Avrstudio basiert doch auf GCC. Halt nur ohne Kommandozeile.
> Lt. Datenbläter sind die von mir verwendeten Register vorhanden. Ich > bekomme aber Fehlermeldungen, dass es diese Register gar nicht gibt Welche Register? Wie sehen die Fehlermeldungen aus? Wie sieht der Code aus? > Ich habe ein paar Assemblercodes verwendet, das ist aber beim ATMega8 > kein Problem. Hast du die denn auch an den Mega168 angepasst?
> ...passt nicht ins Thema...?? Das ist hier ein GCC-Forum. CodeVision ist etwas ganz anderes. > Aber wieso passt Codevision nicht zu ISR(..._vect)? Weil CodeVision eine völlig andere Syntax für Interrupt-Handler verwendet. ISR(VEKTORNAME_vect) ist WINAVR-Syntax (AVR-libc). Ich verstehe auch nicht ganz Deine Vorgehensweise: Versuchst Du, den CodeVision-Compiler als C-Plugin in AVR-Studio zu verwenden? Das geht nicht und wäre wenn es überhaupt ginge ziemlich unsinnig, weil der CodeVision-Compiler seine eigene IDE mitbringt. Er benutzt lediglich den Simulator von AVRStudio. Der WINAVR-C-Compiler (AVR-GCC) lässt sich dagegen problemlos in AVRStudio einbinden...
Hallo Zusammen, das Rätsel scheint gelöst: Die Initialisierungssequenz mit den zugehörigen Registern für ATMega8 (und ATMega16 ?) lauten: TCCR0 = (1 << CS00); TIMSK |= (1 << TOIE0); sei(); // bei Codevison muss hier :#asm("sei"); stehen für den ATMega168 ist es: TCCR0A = (1 << CS00); TIMSK0 |= (1 << TOIE0); sei(); // bei Codevison muss hier :#asm("sei"); stehen Dieses Wissen nützt mir jetzt aber gar nix, denn: 1. AVRStudio hat einen Fehler, den man nur durch (inzwischen 5-tägiges) Suchen in einschlägigen Foren und Suchmaschienen findet und hiermit beheben kann: Beitrag "pgmspace.h -> Absturz" Ohne dieses Update (nicht zu verwechseln mit dem Servicepack, das bringt den PC zum Absturz) lässt sich der 168er nicht verwenden. Mit Update könnte ich auch den 168er nehmen. Leider nur Theoretisch, denn: 2. Ich habe keine Software, die den ATMega168 Proggen kann. Zumindest nicht die ausreichend aktuellen Versionen von Codevision oder Ponyprog. Mit AVRDude soll es angeblich gehen, hab aber keine Lust mehr auf Ausprobieren, weil: 3. Mit dem Update funzt auch die Optimierusgsstufe 3, womit mein Prog wieder auf den ATMega8 passt. Viele Grüße Dagmar Wg: ...Das ist hier ein GCC-Forum. CodeVision ist etwas ganz anderes... ´tschuldigung dass ich neben GCC auch einen anderen (bösen?) Compiler benutze ;-)
Öh, das war nur ein Hinweis, warum Jörg meinte, dass das "nicht zum Thema dieses Forums passt". Hat nix damit zu tun, dass CodeVision "böse" ist. Ich habe ihn auch lange Zeit verwendet und für den Preis, den die Vollversion kostet, ist er sicher eine feine Sache, auch im Vergleich mit anderen kommerziellen Compilern... Nur gehen die Leute, die das hier ab und zu lesen, davon aus, dass die Postings hier sich auf GCC beziehen, und es deshalb bei nicht eindeutigen Hinweisen des öfteren zu Missverständnissen kommt...
... und proggen des 168 mit PonyProg2000 geht auch. Muss man halt einen anderen Mega mit 16k auswählen und darf dann nur den Flash programmieren. Fuses erst auslesen und separat brennen. Kommt man zwar nicht an alle 168er Fuses ran aber für die gängigen (Oszillator, etc.) geht's
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.