AtTiny2313 Timer1 kein Interrupt

_|-|_ Gast #1805995
Lesenswert?
• ▲
▼ 
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:
1
ISP(TIMER1_COMPA_vect)

2
{

3
  PORTB= 0xFF;

4
}

5


6
int main(void)

7
{

8
  

9
  TCCR1A &= ~((1<<WGM11) | (1<<WGM10));

10
  TCCR1B |= (1<<WGM12);                  // Modus 4 CTC

11
  TCCR1B &= ~(1<<WGM13);

12
  TCCR1B |= (1<<CS11) | (1<<CS10);      // Prescaler 1/64

13
  TIMSK |= (1<<OCIE1A);

14
  

15
  OCR1A = 6249;        // Obergrenze auf 6249 setzten

16
  

17
  sei();        // Einschalten der Interrupts

18
  

19
  DDRB = 0xFF;

20
  PORTB = 0x00;

21
  

22
  while(1==1)

23
  {

24
  }

25
  

26
  return 0;

27
}
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
g457 Gast #1806148
Lesenswert?
• ▲
▼ 
> 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:
1
$ head -n 4 main.c 

2
#include <avr/io.h>

3
#include <avr/interrupt.h>

4


5
ISP(TIMER1_COMPA_vect)

6
$ avr-gcc -Wall -mmcu=attiny2313 -o main main.c 

7
main.c:5: warning: return type defaults to ‘int’

8
main.c: In function ‘ISP’:

9
main.c:7: warning: control reaches end of non-void function


..was wünscht man sich mehr? :-)
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Markus J. #1806195
Lesenswert?
• ▲
▼ 
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
Antwort Zitieren Bearbeiten Löschen Beitrag melden
g457 Gast #1806212
Lesenswert?
• ▲
▼ 
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.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Markus J. #1806245
Lesenswert?
• ▲
▼ 
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
1
__attribute__((OS_main,noreturn)) void main(void)

 definiere.

mfG
Markus
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren