Hi,
Ich hatte die Frage ürsprünglich hier
->Beitrag "Re: TLC5940 Effizient ansteuern" im späteren
Verlauf gestellt, aber ich mach mal einen eigenen Thread auf deswegen -
hängt ja nicht direkt zusammen
Ich erzeuge mit dem Timer0 einen schnelles Rechteck-Signal.
Timer1 soll dessen Pulse zählen (OC0 ist mit T1 verbunden).
Dies soll timer1 erledigen.
Timer 0 funktioniert. bracuht hier eigentlich nicht betrachtet werden.
das eigentliche Problem ist also, warum timer1 nicht zählt.
Hier der Code:
1
...
2
3
// timer 1 (16bit)
4
DDRB&=~(1<<PIN1);// T1 pin as clock input for 16bit timer
5
TCCR1A=(1<<WGM11)|(0<<WGM10);// Fast PWM with ICR1 as top
6
TCCR1B=(1<<WGM13)|(1<<WGM12)//
7
|(1<<CS12)|(1<<CS11)|(1<<CS10);// external clock (T1) on rising egde
8
TIMSK|=(1<<TOIE1);// enable overflow interupt
9
ICR1=4096;
10
11
12
// timer 0
13
DDRB|=(1<<PB3);
14
TCCR0=(1<<WGM01)|(0<<WGM00)// CTC
15
|(0<<COM01)|(1<<COM00)// Toggle on Compare Match
16
|(0<<CS02)|(1<<CS01)|(1<<CS00);// prescaler 64 for test
17
OCR0=0;// f(OCR) = F_CPU/2/Prescaler
18
19
...
20
21
ISR(TIMER1_OVF_vect)
22
{
23
LED_TOGGLE(STAT_LED_DEBUG_1);
24
tlc5940_blank();
25
}
Laut datasheet müsste er doch in dem modus den Overflow auslösen, wenn
der Counter TOP (ICR1) erreicht ist.
den FPWM-mode wollt ich nehmen, damit ich die die Compares noch frei
habe.
Hat jemand einen Hinweis?
und ja, ich hab die Brücke zwischen PB3 und PB1 wirklich eingebaut ;)
Die LED in der Timer1-ISR geht auch ;)
Danke im Voraus,
Vlad
Hi
>Laut datasheet müsste er doch in dem modus den Overflow auslösen, wenn>der Counter TOP (ICR1) erreicht ist.
Nein. Ausgelöst wird ein IC-Interrupt (wenn freigegeben).
MfG Spess
spess53 schrieb:> Nein. Ausgelöst wird ein IC-Interrupt (wenn freigegeben).
Sowie ich das Datasheet (siehe Anhang) verstehe, wird der OVF-Int bei
erreichen von TOP ausgelöst. TOP ist da definiert als ICR1.
Hi
>Sowie ich das Datasheet (siehe Anhang) verstehe, wird der OVF-Int bei>erreichen von TOP ausgelöst. TOP ist da definiert als ICR1.
Wenn Top durch ein Register bestimmt wird, wird nicht der
Overflow-Interrupt, sondern der dem Register zugehörige Interrupt
ausgelöst.
Bin ich auch schon darauf hereingefallen.
MfG Spess
spess53 schrieb:> Wenn Top durch ein Register bestimmt wird, wird nicht der> Overflow-Interrupt, sondern der dem Register zugehörige Interrupt> ausgelöst.
Hmm. Ich finde schon dass das Datasheet recht eindeutig ist:
> The Timer/Counter Overflow Flag (TOV1) is set each time> the counter reaches TOP. In addition the OC1A or ICF1> Flag is set at the same timer clock cycle as TOV1 is set> when either OCR1A or ICR1 is used for defining the TOP value.> If one of the interrupts are enabled, the interrupt handler> routine can be used for updating the TOP and compare values.
um ganz sicher zu gehen, habe ich grad mal den inputPin PB1 getestet.
Manuell geht er.
Hi
>Hmm. Ich finde schon dass das Datasheet recht eindeutig ist:
Hast Recht. Meine Aussage trifft auf die CTC-Modes zu. Bei den PWM-Modes
wird auch das TOV-Flag gesetzt.
MfG Spess
hm, ich habs jetzt auch mal in anderen Modi Probiert. er scheint den
externen Takt einfach nicht zu bekommen.
Gibts irgend was, was man noch beachten sollte?
Du solltest das hier:
> DDRB &= ~(1<<PIN1);
eigentlich nicht compilieren können. Wo kommt denn die Definition von
PIN1 her ? Aus der iom32.h sicher nicht.
Kann ja sein, daß dies hier aus der Forumformatierung resultiert, aber
das sieht aus, als ob ein Kommentar // dazwischen ist, damit ist der
Zähler ohne Takt:
TCCR1B = (1<<WGM13) | (1<<WGM12) //
| (1<<CS12) | (1<<CS11) | (1<<CS10);
MWS schrieb:> Kann ja sein, daß dies hier aus der Forumformatierung resultiert, aber> das sieht aus, als ob ein Kommentar // dazwischen ist, damit ist der> Zähler ohne Takt:
Ein // macht nur den Rest der Zeile zum Kommentar, und hat keinerlei
Einfluss auf die Folgezeile.
Das hier funktioniert genauso wie es soll, d.h. die Theorie um FPWM Mode
14 ist schon ok. ICR1 ist kleiner, da nur 'ne geringe Frequenz an T1 zur
Verfügung stand, das Toggle hätt' sonst zu lange gedauert.
MWS schrieb:> eigentlich nicht compilieren können. Wo kommt denn die Definition von> PIN1 her ? Aus der iom32.h sicher nicht.
das kommt aus der "avr/portpins.h", wie alle anderen Pin-Definitionen
auch
1
/* Port Input Pins (generic) */
2
#define PIN7 7
3
#define PIN6 6
4
#define PIN5 5
5
#define PIN4 4
6
#define PIN3 3
7
#define PIN2 2
8
#define PIN1 1
9
#define PIN0 0
Ich finde die bezeichnungen PB1 ziemlich dämlich, da man das dann auch
noch ändern muss, wenn man den Port ändert.
die PXn sind sowieso immer von 0-m numeriert. Ich denke das ist auch
eine Sache, wo man sich drauf verlassen kann, dass das so bleibt.
Die machen eigentlich bloß Sinn, damit es ein Compile-Error gibt, wenn
man einen Pin ansprechen will, den die MCU gar nicht hat.
MWS schrieb:> Das hier funktioniert genauso wie es soll, d.h. die Theorie um FPWM Mode> 14 ist schon ok.
Hmm, ich werde immer ratloser.
> Ich finde die bezeichnungen PB1 ziemlich dämlich, da man das dann auch> noch ändern muss, wenn man den Port ändert.
Damit war ich nicht vertraut.
> Hmm, ich werde immer ratloser.
Anbei mein Hex-File.
Du hast schon SEI() im Main geschrieben ?
Wenn ja, häng' Dein Hex-File an, möglichst mit wenig umgebenden Code.
MWS schrieb:> Du hast schon SEI() im Main geschrieben ?
*kopf gegen die Wand schlag*
was bin ich dämlich.
Beim Eingrenzen meines ersten Problems, warum es nicht funktioniert, hab
ich die Minimalvariante zum Testen an den Anfang meiner main gehangen -
und damit natürlich auch vor das sei().
Danke, ich geh jetzt erst mal in die Ecke mich schämen.
PS:
Ich schiebs jetzt einfach mal auf die unmenschlichen Temperaturen.
Thread beobachten
Seitenaufteilung abschalten