MSP430 Timer mit TAR - Timingproblem

Hallo Falk,

danke für deine Antwort.

Eines mal vorweg: Es ist mir durchaus bewusst, dass Polling eine 
unprofessionelle "Lösung" darstellt, sie stammt auch nicht von mir, 
sondern war auf Atmel-Code bereits vorhanden. Messungen mit Scope haben 
jedoch gezeigt, dass diese für einfache Zwecke ausreichend war. Ich 
wollte sie nur probeweise auf den MSP portieren und testen, ob's hier 
genauso klappt. Keine Frage, programmiere für genaues Timing immer mit 
Interrupt, seit eh und je. ICH habe also kein Problem mit dem MSP430.

Inzwischen habe ich den Fehler auch gefunden, es lag am Interruptflag 
des TAR-Überlaufs, das ich fälschlicherweise noch von der CCR0 
übernommen hatte. Zuvor bekam ich nämlich nie einen Überlauf, daher 
meine Frage.

Es sieht so aus:

1

#define DELAY()  TAR=0xFD29;while(!(TACTL&TAIFG));TACTL&=~(TAIFG)

2

3

void delay_100us(uint16_t wTime)

4

{

5

  while(wTime){

6

    DELAY();

7

    wTime--;

8

  }

9

}

ICH WEISS, DASS DIES NICHT SEHR SCHÖN IST! Ich hab's ja nur mal testen 
wollen und festgestellt, dass es auf dem Atmel genauer als auf dem MSP 
läuft.

Was meine ich damit? Das Makro stellt die Zeit auf genau 100us ein. Ruft 
man die Funktion mit 1 im Argument auf, um 100us zu erzeugen, stimmt's 
exakt. Ruft man sie hingegen mit 10 auf, um 1ms zu erzeugen, dann messe 
ich mit dem Scope so ziemlich genau 948us - da hätte ich eher einen Wert 
grösser 1ms erwartet.

Nun gut, schätze, da ist das Polling dann wirklich eine extrem schlechte 
Option. Der Mega128 läuft da auf jeden Fall genauer. Stimme dir aber 
uneingeschränkt zu, dass dies prinzipiell ungenau ist und keiner 
professionellen Umsetzung entspricht.


Aber nun doch eine Frage, nur zur Klärung der Vollständigkeit halber: 
Was spricht dagegen, auf die CCRs gänzlich zu verzichten, wenn ich zum 
Beispiel nur einen simplen Timer brauche, der Überläuft und einen 
Interrupt erzeugt?

Um es etwas zu konkretisieren:

Ich starte den Timer A im Continuous-Mode, dann zählt das TAR-Register 
bis 0xFFFF und erzeugt beim Überlauf auf 0 einen Interrupt, durch den 
das TAIFG gesetzt wird. In der ISR kann ich dann per Abfrage das TAR als 
Quelle ermitteln, z.B. so:

1

interrupt (TIMERA1_VECTOR) Timer_A(void)

2

{  

3

   switch(TAIV)

4

   {

5

     case 10:

6

         TAR = 0xFFD6;              

7

         P6OUT ^= 0x80;           

8

         break;

9

   }  

10

}

Ich meine, es funktioniert ja perfekt und wenn ich keine weiteren Zeiten 
benötige, warum dann die CCRs benutzen?

An deiner Meinung wäre ich sehr interessiert, siehst du da irgendeinen 
Nachteil? Ich habe mich nur gewundert, warum die Beispiele einen 
einfachen Timer nicht auf dieser Basis berücksichtigen. Oder ist das 
zuuu trivial?

Danke dir und einen angenehmen Tag,
Gunb :-)

@Falk: DU BIST MEIN HELD!

MENSCH, DATT ISSET! Jetzt läuft datt Ding endlich so, wie es soll! 
TACCR0 geladen und TAR als Zähler - perfekt.Ich hab's vor lauter Bäumen 
nicht mehr gesehen, zu lange vor dem Compi gesessen ;-)


@Chris:

Hast natürlich Recht, ich nutze sie ja bereits seit Jahren. In dem oben 
geschilderten Fall hat mich aber mein Ehrgeiz gepackt und ich wollte 
einfach wissen, ob das mit dem MSP nicht auch ohne Weiteres geht. "Der 
muss das doch auch können", habe ich mir gedacht.

Nutzen werde ich die CCRs, aber interessant ist's schon. Der Hintergrund 
ist der, dass ich Geräte entwickle, die per Gesetz gewissen Empfehlungen 
unterliegen. Wenn ich auch darauf an dieser Stelle nicht weiter eingehen 
kann, so sei dazu soviel gesagt, dass die Verwendung von Interrupts 
möglichst vermieden werden sollte. Wenn dies wahrscheinlich auch ein 
etwas Interrupt-ängstlicher Bürokrat geschrieben hat, so ist doch 
verständlich, warum der Code für den Atmel bereits das Polling 
verwendete. Ich wollte dies nun einmal auf dem MSP checken. Nutze aber 
trotzdem die CCRs :-))))


Danke euch für den Support!

MfG
Gunb