ATTiny25 Timer0 Problem

[kai (Gast)]

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:

#define F_CPU 8000000L   
#include <avr/io.h>
#include <avr/interrupt.h>

//Anschluss ReadyLED
#define DDR_READY_LED    DDRB
#define PORT_READY_LED   PORTB
#define PIN_READY_LED    PB3

ISR(TIMER0_COMPA_vect)
{
  PORT_READY_LED &= ~(1<<PIN_READY_LED);
}

//Timer zu debugzwecken einstellen (auf 50Hz)
void TIMER0_init(void)
{
  //CTC-Modus aktivieren
  TCCR0A |= (1<<WGM01);

  //Vorteiler auf 1024
  TCCR0B |= (1<<CS00) | (1<<CS02);

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

  //Compare A Interrupt aktivieren
  TIMSK |= (1<<OCIE0A);
}

int main(void)
{  
  uint8_t i = 0;

  //ReadyLEDpin auf Ausgang setzen
  DDR_READY_LED |= (1<<PIN_READY_LED);
  PORT_READY_LED |= (1<<PIN_READY_LED);

  TIMER0_init();
  sei();

  while(1)
  {
    i++;
  }

return 0;
}

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

[Rolf Magnus (Gast)]

Also wenn ich das bei mir durch den Compiler schicke, warnt er:

"kai.c:10: Warnung: »TIMER0_COMPA_vect« scheint ein falsch geschriebener 
Signal-Handler zu sein"

[MachMalSo (Gast)]

ISR(TIMER0_COMPA_vect)
{
  PORT_READY_LED ^= (1<<PIN_READY_LED);
}

[AVRFan (Gast)]

>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.

[AVRFan (Gast)]

Ah, sorry, da stehts ja im Kommentar... 50 Hz.

[Johannes M. (johnny-m)]

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...

[kai (Gast)]

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

[Rolf Magnus (Gast)]

> 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.

[Johann L. (gjlayde)]

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 "countdown.c"
# 1 "<built-in>"
# 1 "<command line>"
# 1 "countdown.c"
# 1 "countdown.h" 1



# 1 "E:/WinAVR_20060421/avr/include/inttypes.h" 1 3
# 37 "E:/WinAVR_20060421/avr/include/inttypes.h" 3
# 1 "E:/WinAVR_20060421/avr/include/stdint.h" 1 3
# 116 "E:/WinAVR_20060421/avr/include/stdint.h" 3
typedef int int8_t __attribute__((__mode__(__QI__)));
...

Ist zwar unter Win32 und n alter avr-gcc, aber das sieht überall gleich 
aus.

[Jörg W. (dl8dtl) (Moderator)]

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. :-(