MSP430F2410: TimerB 1.6 ISR

Gast #2087555
Lesenswert?

Hallo!

Bei meinem MSP430F2410 sind alle Timer B CCR aktiv.
CCR0 hat einen eigenen Interrupt-Vektor und somit eine eigene ISR.
CCR1 bis CCR6, sowie das Überlaufflag vom TimerB teilen sich den Vektor 
TBIV und eine ISR.

Nun suche ich die schnellste und effektivste Möglichkeit die 
aufgelaufenen Flags abzufragen.

Soll man das IFG der jeweiligen CCRx abfragen:
1
while(TBIV)
2
{
3
if(TBCCTL1 | CCIFG)
4
{
5
   ...
6
}
7
if(TBCCTL2 | CCIFG)
8
{
9
   ...
10
}
11
...
12
if(TBCTL | TBIFG)
13
{
14
   ...
15
}
16
}
oder den TBIV:
1
while(TBIV)
2
{
3
if(TBIV | 0x02)
4
{
5
   /* CCR1 */ 
6
   ...
7
}
8
if(TBIV | 0x04)
9
{
10
  /* CCR2 */
11
   ...
12
}
13
...
14
if(TBIV | 0x0E)
15
{
16
  /* Timer overflow */
17
   ...
18
}
19
}

Was ist denn eurer Meinung nach die beste Lösung?

Gruß
Markus
Gast #2087564
Lesenswert?

Markus schrieb:
> Soll man das IFG der jeweiligen CCRx abfragen:while(TBIV)
> {
> if(TBCCTL1 | CCIFG)
> {
>    ...
> }

Also so fragt man schonmal garnicht das IFG ab! Wenn dann schon mit "&" 
- aber trozdem ist es immernoch falsch.

Du hast doch extra den TBIV - dr ist doch genau für das schnelle 
auslesen des Registers gedacht:
1
...
2
ISR Timer B
3
{
4
  switch (TBIV)
5
  {
6
    case 1:
7
    {
8
      ...
9
      break;
10
    }
11

12
    case 2:
13
    {
14
      ...
15
      break;
16
    }
17
  }
18
}

Guck mal in den User's Guide. Da ist alles drin erklärt, welcher IV von 
welchem Timer kommt.
Gast #2087596
Lesenswert?

Dennis E. schrieb:
> Also so fragt man schonmal garnicht das IFG ab! Wenn dann schon mit "&"
>
> - aber trozdem ist es immernoch falsch.

Ja, du hast recht. Das sollte natürlich ein "&" sein.

Dennis E. schrieb:
> ISR Timer B
>
> {
>
>   switch (TBIV)
>
>   {
>
>     case 1:
>
>     {
>
>       ...
>
>       break;
>
>     }
>
>
>
>     case 2:
>
>     {
>
>       ...
>
>       break;
>
>     }
>
>   }
>
> }


Ja, aber was ist, wenn CCR1 und CCR3 überglaufen sind, bis die die ISR 
aufgerufen wird? Wie bekomme ich das raus?
1
0x02 = 0010 = CCR1
2
0x04 = 0100 = CCR2
3
0x06 = 0110 = CCR3
4
0x08 = 1000 = CCR4
5
0x0A = 1010 = CCR5
6
0x0C = 1100 = CCR6
7
0x0E = 1110 = Timer Overflow

CCR1 (0x02) + CCR3 (0x06) wäre ja 0x08 und somit CCR4. So kann es also 
nicht gehen!
Gast #2088406
Lesenswert?

Markus schrieb:
> Hallo und guten Morgen!
>
> Ist meine Frage so komplex, dass keiner mehr antwortet? ;(
>
> Viele Grüße
> Markus

Nö... sie ist so einfach, weil es im User-Guide eindeutig beschrieben 
und einfach nachzulesen ist!
TBIV enthält immer nur einen Eintrag, nämlich den mit der höchsten 
Prio
Gast #2088415
Lesenswert?

Stefan schrieb:
> Nö... sie ist so einfach, weil es im User-Guide eindeutig beschrieben
> und einfach nachzulesen ist!
> TBIV enthält immer nur einen Eintrag, nämlich den mit der höchsten
> Prio

d.h. Wenn zwei CCR angeschlagen haben, wird zweimal nacheinander die ISR 
aufgerufen?
Gast #2088694
Lesenswert?

Markus schrieb:
> Das ist ja doof.

Nee, isses nicht. Im Regelfall geht ja kein Interrupt verloren. Aber 
falls dir das Sorgen macht, dann setze ich noch einen drauf: Der 
Interrupt springt ja auch nicht sofort an, es dauert weitere Taktzyklen 
bis man in der ISR ist :( Problem beim Timer? Nein, das Ereignis ist ja 
jedesmal um diese Takte verzögert, also wieder völlig OK.
Gast #2088784
Lesenswert?

Markus schrieb:
> Das ist ja doof.
> Dann verliere ich ja unnötig Zeit, dadurch das erst die ISR beendet und
> danach wieder aufgerufen wird...

Wenn Dein Timing wegen der paar Taktzyklen derart kritisch ist, dann 
hast Du ein generelles Designproblem und musst Dir was schnelleres 
suchen.

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren