Timerüberlauf für Periodenauswertung läuft falsch

[Em G. (exe87)]

Guten Morgen zusammen.
Ich hab ein Problem mit einer Periodenauswertung über einen TimerA
Hier mal der Code:

#include <msp430G2153.h>

#define Sleep 15000

volatile unsigned int stop, start;
volatile unsigned int Periode;
volatile unsigned int SignalChange=0;
volatile int bla=0;


//----ISR for Signalchange----
#pragma vector=PORT1_VECTOR
__interrupt void Port_1(void)
{
  stop=TAR;                            //Aktuellen Timerwert in stop schreiben
  SignalChange++;                          //Flankenwechsel

  if(TACTL & TAIFG)
    bla=1;
  else
    bla=0;

  //Periode Calculation
  if(!(TACTL & TAIFG)){
    Periode=stop-start;                      //Periode ausrechnen
  }
  else{
    if(TACTL & TAIFG){
      if(stop<start)
        Periode=(65535-(start-stop));
      if(stop>start)
        Periode=15001;
    }
  }                          //naechste Messung vorbereiten
  if(SignalChange<15 && Periode>=Sleep)
    _NOP();
  start=stop;
}

Also:
Er soll sich in "stop" den Wert aus TAR laden.
bla ist nur eine Hilfsvariable.
Wenn kein Überlauf stattgefunden hat, soll er ganz normal ausrechnen, 
ansonsten die anderen beiden Berechnungen durchführen.
der nächste Schritt war nur zur Überprüfung eines Fehlers.

Es können ja 3 Zustände bei der Berechnung auftreten:
1. Der Timer läuft ganz normal hoch und währenddessen soll die Zeit 
gemessen werden: zB stop=60000 und start war 10000 Differenz: 50000
2. Der Timer hatte einen Überlauf und stop ist größer als start, also:
stop=60000 und start war 10000, Differenz: 115535
3. Der Timer hatte einen Überlauf und stop ist kleiner als start, also: 
stop=10000 und start war 60000, Differenz: 15535

Normalerweise kann während der 15 Signalwechsel die Zeit nie größer sein 
als ca. 10000. Trotzdem springt er manchmal in die Berechnung rein, wo 
stop>start ist UND ein Überlauf stattgefunden haben soll.

      if(stop>start)
        Periode=15001;

Wenn ich aber die Hilfsvariable "bla" angucke, steht dort eine 0, welche 
ja normalerweise auf 1 sein müsste.
Also es wird quasi eine große Periodendauer gemessen, die eigentlich 
nicht sein darf.

Da der MSP430G2153 nur 16Bit hat, habe ich für Fall 2 einfach einen 
festen Wert genommen.

[Em G. (exe87)]

Also ich hab nochmal genau geguckt, diese Fehleranalyse tritt wohl nur 
auf, wenn der Timerüberlauf während der ISR auftritt.
Was kann man dann tun?
Weil so eine Art Prioritätenänderung der Interrupts gibt es laut 
Datenblatt nicht :(

LG

[Karl H. (kbuchegg)]

Em Gr schrieb:
> Also ich hab nochmal genau geguckt, diese Fehleranalyse tritt wohl nur
> auf, wenn der Timerüberlauf während der ISR auftritt.
> Was kann man dann tun?

Möglichst zeitnah Zählerwert und Überlaufflag auslesen. Und zwar nur 
einmal!
Und nicht so wie du quer über die ganz ISR verstreut immer wieder das 
Hardware-Flag checken.

Zusätzlich könntest du noch, wenn du bei der Reihenfolge
   Zähler auslesen
   Überlauf feststellen
bleibst:

wenn der Zählerwert an der oberen Grenze ist (65535) UND das 
Überlaufflag trotzdem gesetzt ist, dann könntest du die Messung 
verwerfen, weil du nicht sicher sein kannst, ob nicht das Überlaufflag 
zwischen den beiden Auslesevorgängen gesetzt wurde, oder ob es nicht 
tatsächlich vorher schon gesetzt war.


Wo setzt du eigentlich das Überlaufflag zurück?
Oder geschieht das automatisch mit dem Auslesen?


PS: wenn du sicher weißt, dass deine Differenz nie größer als 10000 sein 
kann, dann brauchst du auch das Überlaufflag nicht.
Rechne einfach stop - start und durch die unsigned Rechnung kommt auch 
dann das richtige Ergebnis raus. Da brauchst du nicht künstlich sowas
       Periode=(65535-(start-stop));
rechnen lassen.

Die einfache Subtraktion geht erst dann schief, wenn die absolute 
Differenz tatsächlich größer als 65535 ist, also mehr als 65535 
Timerticks gezählt werden müssen.

[Em G. (exe87)]

Super, es läuft nun richtig, hatte wohl etwas mit der Mehrfachabfrage zu 
tun.

#include <msp430G2153.h>

#define Sleep 15000

volatile unsigned int stop, start;
volatile unsigned int Periode, Help=0;
volatile unsigned int SignalChange=0;
volatile int bla=0;
volatile unsigned int OverflowCounter=0;


#pragma vector=TIMER0_A1_VECTOR      //TIMER0_A1_VECTOR
__interrupt void Timer_A(void){
  OverflowCounter++;
  TACTL &= ~TAIFG;          //TimerA Interrupt Flag loeschen
  P1OUT ^= BIT0;
}

//----ISR for Signalchange----
#pragma vector=PORT1_VECTOR
__interrupt void Port_1(void)
{
  stop=TAR;                            //Aktuellen Timerwert in stop schreiben
  Help=OverflowCounter;
  Periode=stop-start;
  if(Help>=1){
    if(stop<start)
      Periode=stop-start;
    if(Help>1 || stop>start)
      Periode=25001;

  }
  SignalChange++; 
  OverflowCounter=0;
  TACTL &=~ TAIFG;
}

Jedoch frage ich mich noch, wie es sein kann, dass der Timer in der 
Ruhephase nicht Regelmäßig läuft: rote Kreise(Habe testweise jeden 
Überlauf anzeigen lassen). Normalerweise müsste er doch wie in den 
weissen Kreisen sein.

[Peter D. (peda)]

Karl Heinz Buchegger schrieb:
> Möglichst zeitnah Zählerwert und Überlaufflag auslesen.

Das macht den Fehler nur seltener, beseitigt ihn aber nicht.
Eine garantiert fehlerfreie Auslesung macht man z.B. so:

Beitrag "AVR Timer mit 32 Bit"


Peter

[Em G. (exe87)]

Also die Signalauswertung funktioniert nun tadellos, vielen Dank!!

Aus dem ausgewerteten Signal sollen 4 PWMs erzeugt werden, welche auch 
genauso funktionieren, wie sie sollen, bis auf kleine Aussetzer(roter 
kreis) der PWM.
Diese führen dazu, das es "flackert".
Könnte dies an dem Timer liegen?

Prinzip:
Über das TAR wird die Zeit ausgelesen, und die Perioden ermittelt, 
daraus resultiert 1 oder 0. Diese ergeben die Dimmwerte.
Über TA0.1, TA0.2, TA1.1 und TA1.2 werden 4 PWMs erzeugt.