ATTiny25 Timer0 Problem

kai Gast #890205
Lesenswert?
• ▲
▼ 
Hi,
ich habe versucht, den Timer0 des ATTiny25 zum Laufen zu bringen, aber 
irgendwas klappt nicht so ganz, bzw. ich übersehe wahrscheinlich 
irgendeinen trivialen Fehler :( Das Programm soll einfach ein LED am Pin 
2 anschalten und beim Aufruf des entsprechenden Interruptvektors wieder 
ausschalten (nur um zu sehen, ob der Vektor überhaupt angesprungen 
wird). Die LED ist gegeb Masse angeschlossen, und verwendet wird der 
Timer0 im CTC-Modus. Der Rest müsste aus dem Quelltext ersichtlich sein:


1
#define F_CPU 8000000L   

2
#include <avr/io.h>

3
#include <avr/interrupt.h>

4


5
//Anschluss ReadyLED

6
#define DDR_READY_LED    DDRB

7
#define PORT_READY_LED   PORTB

8
#define PIN_READY_LED    PB3

9


10
ISR(TIMER0_COMPA_vect)

11
{

12
  PORT_READY_LED &= ~(1<<PIN_READY_LED);

13
}

14


15
//Timer zu debugzwecken einstellen (auf 50Hz)

16
void TIMER0_init(void)

17
{

18
  //CTC-Modus aktivieren

19
  TCCR0A |= (1<<WGM01);

20


21
  //Vorteiler auf 1024

22
  TCCR0B |= (1<<CS00) | (1<<CS02);

23


24
  //Vergleichsregister A beschreiben (8mhz/1024/50 ~ 160, soll ungefähr 50Hz Netzfrequenz entsprechen

25
  OCR0A = 160;

26


27
  //Compare A Interrupt aktivieren

28
  TIMSK |= (1<<OCIE0A);

29
}

30


31
int main(void)

32
{  

33
  uint8_t i = 0;

34


35
  //ReadyLEDpin auf Ausgang setzen

36
  DDR_READY_LED |= (1<<PIN_READY_LED);

37
  PORT_READY_LED |= (1<<PIN_READY_LED);

38


39
  TIMER0_init();

40
  sei();

41


42
  while(1)

43
  {

44
    i++;

45
  }

46


47
return 0;

48
}


Die LED geht an, aber dann nicht mehr aus. Daraus schließe ich, dass der 
Vektor nie angesprungen wird. Findet jemand den Fehler? Vielen Dank 
schon mal im Voraus!

Grüße,
Kai
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
AVRFan Gast #890228
Lesenswert?
• ▲
▼ 
>Die LED geht an, aber dann nicht mehr aus.

Sehe im Moment keinen Fehler in Deinem Programm.  Hast Du mal die zu 
erwartende LED-Blinkfrequenz ausgerechnet?  Wenn die zu hoch ist, ist 
das Blinken von einem Dauer-An für das menschliche Auge nicht zu 
unterscheiden.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Johannes M. #890233
Lesenswert?
• ▲
▼ 
Beim Tiny25 heißt der Vektor TIM0_COMPA und nicht TIMER0_COMPA ...

(Warum das in dem Fall so ist, weiß ich nicht. In diesem Fall scheint 
die Übereinstimmung mit dem Datenblatt nicht gegeben, was ungewöhnlich 
ist)

Allerdings sollte man generell Warnmeldungen des Compilers nicht einfach 
ignorieren...
Antwort Zitieren Bearbeiten Löschen Beitrag melden
kai Gast #890298
Lesenswert?
• ▲
▼ 
Vielen Dank für die schnellen Antworten!
Es war tatsächlich die Bezeichnung des Vektors, die nicht mit dem Dbl. 
übereinstimmt. Die Warnmeldung des Compilers hab ich übersehen, ich bin 
wohl zu sehr auf die "Error:" Meldungen fixiert gewesen :) Jetzt klapts 
auf jeden Fall. Wo findet man eigentlich unter Linux die Dateien, die 
die Zuordnungen für den jeweiligen Controller enthalten? Da hätte ich 
dann wohl nachschauen können, wie der Vektor speziell beim Tiny25 
heißt...

Grüße,
Kai
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Rolf Magnus Gast #890305
Lesenswert?
• ▲
▼ 
> Wo findet man eigentlich unter Linux die Dateien, die die Zuordnungen
> für den jeweiligen Controller enthalten?

Das kommt drauf an. Bei Distributionspaketen ist es meist 
/usr/avr/include/avr. Wenn du die Toolchain selbst übersetzt hast und 
kein Ziel-Prefix angegeben hast, wäre es /usr/local/avr/include/avr.

> Da hätte ich dann wohl nachschauen können, wie der Vektor speziell beim
> Tiny25 heißt...

Einfacher wäre, das in der avr-libc-Doku nachzulesen.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Johann L. Persönliche Seite #890448
Lesenswert?
• ▲
▼ 
kai wrote:
> Wo findet man eigentlich unter Linux die Dateien, die
> die Zuordnungen für den jeweiligen Controller enthalten?

gib einfach als gcc-Option -save-temps an und cshau mal ins i-File. Das 
ist die Quelldatei nach auflösen der Präprozessor-Direktiven. Da steht 
dann auch drin, wo was hergenommen wird:

1
# 1 "countdown.c"

2
# 1 "<built-in>"

3
# 1 "<command line>"

4
# 1 "countdown.c"

5
# 1 "countdown.h" 1

6


7


8


9
# 1 "E:/WinAVR_20060421/avr/include/inttypes.h" 1 3

10
# 37 "E:/WinAVR_20060421/avr/include/inttypes.h" 3

11
# 1 "E:/WinAVR_20060421/avr/include/stdint.h" 1 3

12
# 116 "E:/WinAVR_20060421/avr/include/stdint.h" 3

13
typedef int int8_t __attribute__((__mode__(__QI__)));

14
...


Ist zwar unter Win32 und n alter avr-gcc, aber das sieht überall gleich 
aus.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Jörg W. Moderator Persönliche Seite #890474
Lesenswert?
• ▲
▼ 
kai wrote:

> Es war tatsächlich die Bezeichnung des Vektors, die nicht mit dem Dbl.
> übereinstimmt.

Die Änderung ist erst im XML von AVR Studio 4.13 Build 571 drin
gewesen, in Build 528 hatten die Vektoren beim ATtinyX5 noch die
kurzen Namen.  Von da hat sie die avr-libc geerbt.

Bitte schreibe einen avr-libc-Bugreport, da müssen wir wohl in
Zukunft wiedermal zwei Namen pflegen. :-(
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