AtTiny2313 Timer1 kein Interrupt

[_|-|_ (Gast)]

Ich benutze den AtTiny2313 mit einem externen 10MHz Quarz.
Nun will ich ein Interrupt, das 25 mal pro Sekunde auftritt, dafür nehme 
ich den Timer1 mit einem Vorteiler von 1/64 und lade das OCR1A noch mit 
6249.
Nun bekomme ich leider keinen Interrupt.

Hier mein Code:

ISP(TIMER1_COMPA_vect)
{
  PORTB= 0xFF;
}

int main(void)
{
  
  TCCR1A &= ~((1<<WGM11) | (1<<WGM10));
  TCCR1B |= (1<<WGM12);                  // Modus 4 CTC
  TCCR1B &= ~(1<<WGM13);
  TCCR1B |= (1<<CS11) | (1<<CS10);      // Prescaler 1/64
  TIMSK |= (1<<OCIE1A);
  
  OCR1A = 6249;        // Obergrenze auf 6249 setzten
  
  sei();        // Einschalten der Interrupts
  
  DDRB = 0xFF;
  PORTB = 0x00;
  
  while(1==1)
  {
  }
  
  return 0;
}

[Markus J. (markusj)]

_|-|_ schrieb:
> ISP
Gibts nicht. Heißt eigentlich ISR.
Ich gehe davon aus, dass du in deinem richtigen Quellcode auch die 
entsprechenden Includes hast:

#include <avr/io.h>
#include <avr/interrupt.h>

Davon abgesehen, simuliere ich den Code in AVR-Studio kommt der erste 
Interrupt nach ~40ms - der Rest stimmt also.

mfG
Markus

[_|-|_ (Gast)]

ok, ja danke
das war eindeutig das Problem, jetzt tut's.

Aber warum gibt mir der compiler da keinen fehler?
ich verwende avr-gcc

Naja, hauptsache es tut

[Stefan P. (form)]

Das While(1) ohne Inhalt könnte evtl. noch problematisch werden.

Wird wegoptimiert -> Es geht direkt weiter bei "return"....

[g457 (Gast)]

> Aber warum gibt mir der compiler da keinen fehler?
> ich verwende avr-gcc

Fehler gibts keinen, weils keiner ist. Aber schöne Warnings gibts auf 
Anfrage - zumindest wenn er noch die passenden Header bekommt:

$ head -n 4 main.c 
#include <avr/io.h>
#include <avr/interrupt.h>

ISP(TIMER1_COMPA_vect)
$ avr-gcc -Wall -mmcu=attiny2313 -o main main.c 
main.c:5: warning: return type defaults to ‘int’
main.c: In function ‘ISP’:
main.c:7: warning: control reaches end of non-void function

..was wünscht man sich mehr? :-)

[Hc Z. (mizch)]

Stefan P. schrieb:
> Wird wegoptimiert -> Es geht direkt weiter bei "return"....

Nö.

[Markus J. (markusj)]

Stefan P. schrieb:
> Wird wegoptimiert -> Es geht direkt weiter bei "return"....

Quark: Eine Endlosschleife kannst du mit keiner Optimierung der Welt 
wegtransformieren weil sie eben von Natur aus Endlos ist. Dagegen sagt 
es dem Compiler aber, dass der Code danach niemals aufgerufen werden 
kann.

@g457:
Warnings zur Compile-Time führen gerne Mal zu Laufzeitfehlern.
Daher sollte man Compiler-Warnings nur genau dann ignorieren wenn man 
Ursache, Bedeutung und Auswirkungen kennt.

mfG
Markus

[g457 (Gast)]

markusj schrub:
> @g457:
> Warnings zur Compile-Time führen gerne Mal zu Laufzeitfehlern.
> Daher sollte man Compiler-Warnings nur genau dann ignorieren wenn man
> Ursache, Bedeutung und Auswirkungen kennt.

Ähm wie meinen? Deswegen hab ich sie dem TO hier doch extra reinzitiert, 
eben weil Warnings entgegen landläufiger Meinunung ∗nicht∗ dazu da sind, 
um ignoriert zu werden. Ich bin im übrigen sogar dafür, dass -Wall per 
default an sein sollte. Hätte der TO das gehabt (und die Warnings 
korrekt interpretiert), dann hätte er auch den Fehler selbst gefunden 
:-)

Nix für ungut.

[Markus J. (markusj)]

g457 schrieb:

Pardon, der Beitrag war falsch adressiert, das war eigentlich für _|-|_ 
(Gast) (er sich angesprochen fühlen möge ;)! Irgendwie wäre das ja sonst 
ein Widerspruch in sich gewesen.

Zu -Wall: Könnte man glatt ne Petition zu machen, ich habe neben -Wall 
noch einen Stapel weiterer -W Schalter aktiv, daher bin ich es gewohnt 
dass der Compiler sich über jeden Mist (oder manchmal auch nicht-Mist) 
auslässt:
-Wall -W -Wextra -Wundef -Wunreachable-code -Wstrict-prototypes 
-Winit-self -Wno-main

Letzterer Schalter klemmt die "main gibt kein int zurück"-Meckerei ab, 
da ich main typischerweise als

__attribute__((OS_main,noreturn)) void main(void)

 definiere.

mfG
Markus