Hi, ich bin neu hier und hoffe das ihr mir Helfen könnt, nachdem ich schon Tausende von Beiträgen gelesen hab, aber leider keinen Fehler in meinem Programm finde. Ich möchte eigentlich nur mit meinem Timer0 bis zum Overflow zählen, um einen Interrupt auszulösen. Aber irgendwie hängt mein Programm in der Endlosschleife (die läuft auch, das seh ich an meiner blinkenden LED) aber löst nie einen Interrupt aus. Ich hab das gleiche Spiel auch schon im Compare Match versucht, mit dem gleichen Ergebnis. Im PWM mit direktem Pin ansteuern funktioniert es, deswegen bin ich arg verwirrt. Wie gesagt, mein Programm ist schön kommentiert (denke ich doch) damit jeder gleich sieht was ich bezwecken will. Ich hoffe ihr könnt mir weiterhelfen.
Ahhh ja du hast Recht, der Fehler ist jetzt ein wenig Peinlich, allerdings funktionierts imemrnoch nicht :( Gleiches Problem, Whileschleife läuft, kein Interrupt.
Chrstian Trohn schrieb: > Hi, ich bin neu hier und hoffe das ihr mir Helfen könnt, nachdem ich > schon Tausende von Beiträgen gelesen hab, aber leider keinen Fehler in > meinem Programm finde.
1 | TIMSK |= (1<<TOIE2); |
Für Timer0 besser TOIE0 verwenden :D
@Chrstian Trohn (christian_trohn) >allerdings funktionierts imemrnoch nicht :( >Gleiches Problem, Whileschleife läuft, kein Interrupt. Vielleicht ist dein LED an PD6 kaputt?
ATMEGA16 Ich verwende zum testen das Evaluationboard von Pollin, mein ATMEGA läuft erfolgreich auf 16mhz ext. crystal. Die Befehle für den Timer hab ich hier aus nem Forenbeitrag "geklaut" und seit einigen Tagen andenen ich am Probieren bin bestimmt 10 mal mit dem Datenblatt abgeglichen. @Falk Brunner, nein ich hab die Led die zum blinken in der Schleife hängt schon öfters mit der die dauerhaft Leuchten soll getauscht weil mir das auch schon in die Gedanken gekommen ist. Auch hab ich schon einen komplett neuen ATMEGA16 genommen weil ich dachte das der vielleicht hin sein könnte, du siehst wie verzweifelt ich bin :O
> (die blinkt auch schnell, also programm läuft mal endlos ab)
Da 10000 x 10000 bis zum Toggeln gezählt wird, dürfte die nicht schnell
blinken, ganz im Gegenteil.
Das sieht mir eher so aus, also ob der MC laufend resettet.
Hm da hast du vollkommen Recht wenn ich mir das jetzt mal Überleg. Ich hab die Werte einfach nur mal da Reingeschrieben das ich Seh ob das Programm überhaupt läuft. Ausgerechnet, bzw mir Gedanken darüber gemacht hab ich bis eben nicht. Aber warum sollte der MC dauernd Resetten ? Programme ohne Interrupt laufen einwandfrei.
MWS schrieb: >> (die blinkt auch schnell, also programm läuft mal endlos ab) > > Da 10000 x 10000 bis zum Toggeln gezählt wird, dürfte die nicht schnell > blinken, ganz im Gegenteil. Es wird ja gar nicht 10000 x 10000 mal gezählt, sondern 10000 + 10000 mal.
Stefan Ernst schrieb: > Es wird ja gar nicht 10000 x 10000 mal gezählt, sondern 10000 + 10000 > mal. Ja, auch gerad' gesehen, hatte' wohl eine sinnvolle Schachtelung vorausgesetzt. Schätze, die hätte dieses Konstrukt auch werden sollen.
Ahhhh, neeee, die Scheifen fliegen raus un der MC rödelt immer auf PortD rum, sodass deine Änderung nie wirksam wird. Probiers mal so.
1 | |
2 | #include <avr/io.h> |
3 | #include <avr/interrupt.h> |
4 | |
5 | #define F_CPU 16000000 //16mhz takt
|
6 | #include <util/delay.h> |
7 | |
8 | // globale Variablen
|
9 | |
10 | volatile uint8_t abc; |
11 | |
12 | int main() { |
13 | |
14 | // IO konfigurieren, sicherheitshalber einfach mal alles auf ausgang
|
15 | |
16 | DDRA = 0xFF; |
17 | DDRB = 0xFF; |
18 | DDRC = 0xFF; |
19 | DDRD = 0xFF; |
20 | // Leds an PORTD erstmal alle aus
|
21 | PORTD = 0x00; |
22 | |
23 | // Timer2 konfigurieren
|
24 | |
25 | TCCR0 = 0b00000101; // Vorteiler 1024 -> 15,625 takte pro zähler+1 -> 8bit zähler = 256 -> 0,015384 sek nach programmstart müsste schon |
26 | // interrupt kommen, also led PORTD 6 müsste gleich mitleuchten wenn timer funktioniert.
|
27 | TIMSK |= (1<<TOIE0); // Timer Overflow Interrupt freischalten |
28 | |
29 | // Interrupts freigeben
|
30 | |
31 | sei(); |
32 | |
33 | // Endlose Hauptschleife
|
34 | |
35 | while(1) { |
36 | _delay_ms(1000); |
37 | PORTD ^= (1<<PD5);// LED PORTD 5 an damit ich seh das überhaupt was geht (die blinkt auch schnell, also programm läuft mal endlos ab) |
38 | if (abc == 1) { // Einfach nur irgendwas zum arbeiten der CPU, damit will ich wenn endlich interrupt läuft mal im mainprogramm die led blinken lassen |
39 | abc = 0; |
40 | }
|
41 | }
|
42 | }
|
43 | |
44 | // Timer0 overflow Interrupt
|
45 | |
46 | ISR( TIMER0_OVF_vect ) { |
47 | abc = 1; |
48 | PORTD ^= (1 << PD6); //Wenn interrupt, dann soll einfach nur ne scheiss LED an PORTD 6 Leuchten |
49 | }
|
Nen anderen ATMEGA Typ hab ich noch nie Benutzt, also sollte das kein Thema sein, ich Programmieren über AvrStudio, AVRISP MKII. Bei AVR Optionen ist Atmega16 eingestellt, Read Signature zeigt mir 0x1E 0x94 0x03, Signature matches selected device, ISP Frequency ist zur zeit 125 kHz (dachte vielleicht läuft da was schief und hab den zwischenzeitig mal auf 1mhz internal gestellt). Mit 1mhz internal rc läuft das Programm genauso, nur das die led langsamer Blinkt.
@ Falk Brunner Gleiches Problem, nur LED tog Langsamer. Mit delay hatte ich das auch schon am Anfang versucht. Dachte das das vielleicht daran liegt, deswegen hab ich die 2 Zählschleifen reingeschrieben.
Es gibt in der Falk'schen Version übrigens einen kleinen Spass: PORTD ^= (1<<PD5); ist nicht atomar. Daher kann es beim Blinken von PD6 zu vereinzelten Arrhythmien kommen. Hier unwichtig, nur sollte man ab und zu an sowas denken.
Den code von Falk Brunner hab ich sowohl mit PORTD ^= (1<<PD5); als auch mit PORTD |= (1<<PD5); versucht. Sie Leuchtet nie. Hab ich vielleicht irgendwas an den Grundsätzlichen Einstellungen verkehrt gemacht und das Programm ist richtig?
Chrstian Trohn schrieb: > Hab ich vielleicht irgendwas an den Grundsätzlichen Einstellungen > verkehrt gemacht und das Programm ist richtig? Compiliert das Programm ohne Fehler ? Wurden die Projekteinstellungen mit Export Makefile auch in's Makefile geschrieben ? Das Programm compiliert hier korrekt und simuliert auch richtig. Flash doch mal anhängendes Hex.
Hier nochmal allen Input den ich euch Geben kann: ATMEGA16 16PU Fuses: HIGH 0xD9 LOW 0xEF ( OCDEN = 0 JTAGEN = 0 SPIEN = 1 mit sonem kleinen roten Fragezeichen rechts unten ? EESAVE = 0 BOOTSZ = Boot flash size = 1024 words start adress=$1C00 BOOTRST = 0 CKOPT = 0 BODLEVEL = Brown-out detection at VCC=2.7V BODEN = 0 SUT_CKSEL = Ext. Crystal/Resonator High Freq.: Start-up time: 16k CK +4ms ) Lockbits: 0xFF ( LB = No memory lock features enable BLB0 = No Lock on SPM and LPM in Application Section BLB1 = No Lock on SPM and LPM in Boot Section Compiliert wird ohne Fehler. Compiliert das Programm ohne Fehler ? Wurden die Projekteinstellungen mit Export Makefile auch in's Makefile geschrieben ? Wie kann ich das nachvollziehen ??? Bis jetzt hatte ich noch keine Probleme mit irgendwelchen Programmen. Dein hex lässt beide LED tog. Also heisst das wohl das ich Grundsätzlich irgendwas Falsch mach mit AVR Studio ??????? Das wär Katastrophal ... ihr Wisst ja garnicht wieviel Zeit ich jetzt schon an dem Timer hock.
NEEEEEEIN ICH HABS !!!!!!!!!!!!!!! Unglaublich, bei mir war im Makefile ATMEGA128 ............ Ich dreh noch durch, etliche Tage vor dem Programm gesessen und gedacht das ich zu blöd bin nen Timer zu initialisieren. Und jetzt isses das Makefile ... DANKE an alle die mir erstmal die Bestätigung gegeben haben das das Programm laufen müsste um jetzt auf son blöden Fehler zu stossen.
Chrstian Trohn schrieb: > Wie kann ich das nachvollziehen ??? Bis jetzt hatte ich noch keine > Probleme mit irgendwelchen Programmen. Naja, aber hier scheint's ja ein Problem zu geben, also alles überprüfen was Probleme bereiten könnte. Unter Build gibt's die Funktion "Export Makefile", damit zur Sicherheit das Makefile im Codeverzeichnis neu schreiben. Chrstian Trohn schrieb: > Dein hex lässt beide LED tog. > Also heisst das wohl das ich Grundsätzlich irgendwas Falsch mach mit AVR > Studio Ja, wobei die Led an PD5 möglicherweise mit der falschen Frequenz toggelt, hatte vergessen die richtige Frequenz in den Projektoptionen einzutragen, die Delay-Funktionen brauchen diese Info. Siehe oben, einfach mal das Makefile neu schreiben, bzw. auch unter Project -> Configuration Options die Projekteinstellungen überprüfen.
Die race condition beim Zugriff auf PORTD (auch wenn hier nicht viel passiert außer einer ab und zu falsch getoggelten LED) sollte vielleicht nicht unerwähnt bleiben. XOR ist nicht atomisch auf AVR.
Michael Buesch schrieb: > Die race condition beim Zugriff auf PORTD (auch wenn hier nicht viel > passiert außer einer ab und zu falsch getoggelten LED) sollte vielleicht > nicht unerwähnt bleiben. XOR ist nicht atomisch auf AVR. War nicht unerwähnt: A. K. schrieb: > Es gibt in der Falk'schen Version übrigens einen kleinen Spass: > PORTD ^= (1<<PD5); > ist nicht atomar. Jedoch war das eigentliche Problem ein leicht anderes :D
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.