Timer Reload und Alte Werte.

[MaMü (Gast)]

Hi!

Ich möchte auf meinem MSP Hall-Sensorwerte verarbeiten und habe 
folgendes Problem:

Ich möchte mit einem Freilauftimer bei jeder Sensorflanke den Aktuellen 
Timerwert nehmen und von dem anschließend den vorherigen Wert abziehen. 
Funktioniert ja bis auf den Fall des Reloads ganz gut. Nur sobald ich 
einen Wert von vor dem Reload und einer nach dem reload habe, ist mein 
Delta kaputt...

Hat da jemand eine elegante Lösung parat um das "Anfängerproblem" in den 
Griff zu bekommen?

[Karl H. (kbuchegg)]

Die Frage ist eher, warum du überhaupt einen Reload hast. Meist gibt es 
bessere Möglichkeiten.

[MaMü (Gast)]

Da ich 3 Sensoren habe und ich daher leider nicht für jeden Sensor 
einfach einen eigenen Timer verwenden kann, ist mir bisher leider noch 
keine schönere Idee eingefallen.
 Ich möchte damit ein Tachosignal für einen Motor generieren.

[Kurt (Gast)]

MSP = ?

[Falk B. (falk)]

@ Kurt (Gast)

>MSP = ?

Most
Superior
Processor

;-)

[overflow (Gast)]

Wenn der Timer frei läuft, lass ihn überlaufen. Du brauchst keinen 
Reload.

Du benutzt die CC Einheit?

[MaMü (Gast)]

Den NSP 430 von TI meinte ich mit MSP ;-)


Ich habe ja den Timer mit Autoreload laufen aber wenn dieser wieder 
zurück auf Null geht und meine Alten Werte noch im oberen Zählerbereich 
des Timer sind und die neuen im unteren Zählerbereich, da kommt es zu 
Problemen da die neuen Werte ja kleiner als die alten sind....

[Rolf M. (rmagnus)]

MaMü schrieb:
> Ich habe ja den Timer mit Autoreload laufen aber wenn dieser wieder
> zurück auf Null geht und meine Alten Werte noch im oberen Zählerbereich
> des Timer sind und die neuen im unteren Zählerbereich, da kommt es zu
> Problemen da die neuen Werte ja kleiner als die alten sind....

Das ist aber kein Problem. Wenn du sie subtrahierst, kommt trotzdem das 
richtige raus. Das gilt natürlich nur, solange der Timer zwischen den 
beiden Werten nicht mehr als einmal überläuft.

Beispiel in 8 Bit:

1. Messung: 200
2. Messung: 100
100 - 200 = -100 -> ist aber vorzeichenlos nicht darstellbar. Deshalb 
kommt in 8 Bit stattdessen 256 - 100 = 156 raus.
Von 200 bis zur 0 nach dem Überlauf braucht es 56 Zyklen, dann nochmal 
100 Zyklen bis zum 2. Messwert, ergibt 156 Zyklen, also genau das 
Ergebnis, das rausgekommen ist. Das kannst du mit jeder Kombinatin 
probieren, bei der das korrekte Endergebnis vom Wertebereich des 
Datentyps dargestellt werden kann, und es wird immer das richtige 
rauskommen.

[MaMü (Gast)]

Hi und danke für die ausführliche Antwort!

Wenn das so ist, muss ich wohl irgendwo anders einen Fehler haben :-(

Ich hab genau das Phänomen dass in zeitlicher Abhängigkeit der 
Umdrehungsgeschwindigkeit für eine Umdrehung meine ganzen Werte total 
von dem Rest abweichen. Diese sinken dann kurzzeitig total in den 
negativen Bereich( ist ein signed int) Daher hätte ich gedacht dass ich 
da den Reload sehe...

[lalala (Gast)]

MaMü schrieb:
> Den NSP 430 von TI meinte ich mit MSP ;-)

Ist das nicht so eine genaue Bezeichnung wie AVR von Atmel? In dem 
Artikel http://www.mikrocontroller.net/articles/MSP430 steht, daß es 
verschiedene Typen gibt. Welchen denn jetzt genau?

[MaMü (Gast)]

Achso sorry ja klar :-D es ging um dn MSP430FR5739!

btw das Problem hat sich gelöst! Hab die Routine einfach nochmal neu 
aufgesetzt und beachtet was geschrieben wurde und jetzt läufts ;-)

danke nochmal!