fortlaufenden Mittelwert berechnen

Brauchst du immer einen Mittelwert über die letzten 128 Werte oder 
willst du eigentlich einen Mittelwert seit Beginn der Aufzeichnung?

Chris schrieb:
> die Summe der Messwerte "schiebe" ich 7x (geht schneller als teilen,
> wenn ich die Forumsbeiträge richtig verstanden habe

Wenn du durch 2, 4, 16, 32, .... teilst, erzeugt der GNU C Compiler 
exakt den gleichen Maschinencode, als wenn du das mit Shift-Operationen 
machen würdest. Der Quelltext ist mit Divisionen aber besser lesbar.

Chris schrieb:
> Und springt der Z-Pointer von 128 wieder auf 1 (weil ich ja nur 128 Bytes
> im SRAM reserviert hab) oder muss ich das selber machen?

Warum sollte er das tun?
Es könnte natürlich von der von dir verwendeten 
Programmiersprache/Bibliotheken abhängen. Falls dort Ringpuffer direkt 
unterstützt werden, passiert das möglicherweise automatisch. Ein 
zyklisches Verhalten bei 128er Pufferlänge ist durch einfaches Maskieren 
aber auch leicht selber machbar.

Lothar M. schrieb:
> Mehmet K. schrieb:
>> sollte wegen
>> avgsum -= mem[ptr & 0x7F];
>> avgsum nicht "signed long" sein?
> Wenn der Eingangswert unsigned (und damit nie negativ) ist, kann die
> Summe auch nie negativ werden.

Aber wenn avgsum mit 0 initialisiert wird und das erste, was du machst, 
eine positive Zahl davon abziehst, ist dann der Ärger nicht schon 
vorprogrammiert?

Dieter R. schrieb:
> Mit der Formel für MMA (Modified moving average, weiter unten im
> Wikipedia-Artikel) geht es allerdings viel einfacher und ohne Array. Es
> wird nur der aktuelle Wert auf das (n-1) fache des bisherigen
> Mittelwerts addiert und das Ergebnis durch n dividiert.

Das ist aber kein gleitender Mittelwert mit gleicher Gewichtung der 
letzten n Werte (FIR-Filter), sondern eine Heruntergewichtung der alten 
Werte mit (n-1)/n, d.h. ein IIR-Filter und damit ganz etwas anderes, als 
vom TO beschrieben.
Der Vorsatz "modified" bringt nur sehr schlecht zum Ausdruck, dass das 
eine völlig andere Funktion ist und mit dem etablierten Begriff 
"gleitender Mittelwert" nichts zu tun hat. Da gleitet nämlich nichts, 
sondern die Gewichtung nimmt mit dem Alter gleichmäßig ab.

MMA find ich bei ständiger Meßbeobachtung meist geeigneter als ein 
echter (Array-) Mittelwert, wo Flanken zeitverzögert rauskommen, auch 
wenn sich der momentane Wert nicht ändert.
Kommt halt wiedermal auf den Zweck an.

Rolf M. schrieb:
> einfach die Division und lässt den Compiler entscheiden, was die beste
> Variante ist.

Genau darum geht es ja.
Im Zweifel entscheidet sich der Compiler halt für die langsame Division 
bei signed.

signed schrieb:
> Genau darum geht es ja.
> Im Zweifel entscheidet sich der Compiler halt für die langsame Division
> bei signed.

Besser langsam als falsch.

Jemand schrieb:
> Besser langsam als falsch.

Ich glaube es gibt hier ein Missverständnis.

Es geht darum, dass man unsigned verwenden soll, wenn die Zahl nicht 
negativ werden kann.
Denn sonst sind Divisionen teuer, weil sie eben nicht zu shift optimiert 
werden, auch wenn der Wert tatsächlich nur positiv sein kann.

signed schrieb:
> Denn sonst sind Divisionen teuer, weil sie eben nicht zu shift optimiert
> werden, auch wenn der Wert tatsächlich nur positiv sein kann.

Das war bei mir bisher das zeitlich teuerste Missverständnis: ein idx/8 
und idx%8 für einen bitbuffer. Wurde halt oft gebraucht, und ich war 
völlig überrascht, als das den Flaschenhals darstellte. Mit Wechsel auf 
unsigned war es noch ferner liefen.

Hi,

zuerst mal sorry für die späte Reaktion, dachte dass ich eine Info per 
Email bekommen, wenn eine Antwort gepostet wird (zumindest hotmail mag 
wohl nicht) - natürlich auch Danke für die Antworten.

Soweit ich Eure Antworten erstmal überflogen habe:

1. Ich hab meine Sachen direkt in Assembler geschrieben (asm-Datei), 
daher muss ich bei diversen Code-Beispielen von Euch erst noch 
"übersetzen"

2. Ich hab ja vorher schon was dazu hier im Forum und Web gelesen 
(Google sei Dank) und daher diesen Weg gewählt, weil ich dachte der 
gleitende Mittelwert ist tatsächlich nie der genaue Mittelwert

3. Ja ich wollte tatsächlich immer die letzten Werte nehmen (128 nicht 
100 weil ich dann einfach mit verschieben statt dividieren arbeiten 
kann, so war zumindest mein Verständnis bis jetzt)

4. Dass der Z-Pointer das nicht alleine erkennt, anhand des reservierten 
Bereichs im SRAM, hab ich schon vermutet, aber naja, besser nochmal 
nachgefragt :)

5. Es ist übrigens nicht zeitkritisch, ich hätte erstmal pro Sekunde 
eine Messung durchgeführt, sodass ich einen Zeitraum von gut 2 Minuten 
hätte für meinen Mittelwert (natürlich dauert es auch entsprechend lange 
bis ich ein erstes komplettes "Set" an Messdaten habe), ob dann das 
"Rechnen" im µC etwas länger dauert oder nicht wäre egal (außer 
natürlich es erzeugt ein grundsätzliches anderes Problem, dass ich nicht 
erkannt habe)


So, dann arbeite ich mich mal durch Eure Antworten durch und versteh es 
hoffentlich auch.

Gruß und danke
Chris

Chris schrieb:
> Ist das so sinnvoll? Und springt der Z-Pointer von 128 wieder auf 1
> (weil ich ja nur 128 Bytes im SRAM reserviert hab) oder muss ich das
> selber machen?

Von was für einem Z-pointer redest du?
Also, wenn du unbedingt einen Mittelwert aus den letzten 128 
ADC-Ergebnissen haben willst, dann ist dein Verfahren im Grunde schon 
richtig. Du brauchst ein Feld mit 128 Plätzen für die ADC-Ergebnisse und 
einen Index, der von 0..127 gehen kann und auch noch eine Variable für 
die Summe. Feld und Summe müssen initialisiert werden, das geht am 
simpelsten mit Ausnullen. Der Index kann irgendwo stehen im Bereich 
0..127.

Und dann machst du so wie du es selbst beschrieben hast: ältesten von 
Summe abziehen, neuesten addieren und an die Stelle des ältesten setzen. 
Dann Index eins weiterstellen.

Ob du nun diesen Index inkrementierst und nach 127 auf 0 setzt oder 
dekrementierst und bei 0 auf 127 setzt ist deine Wahl. Ich nehme mal an, 
den Index meinst du mit Z-pointer.

Es gibt noch ein paar Bemerkungen dazu:
1. Per Mittelwertbildung kann man - sofern die ADC-Ergebnisse 
einigermaßen gauß- oder linear verteilt rauschen - die Anzahl gültiger 
Bits erhöhen. Das geht so zumeist für 1..2 Bit ganz gut.
2. Wenn man die Feldgröße in Grenzen variabel macht, kann man per 
Mittelwertbildung auch das Gesamtergebnis skalieren, ohne dazu eine 
Multiplikation oder gar Division zu benötigen. Diese Skalierung ist 
natürlich nur so fein wie 1/Feldgröße. Bei 128 ist das etwas unter 1%, 
aber das reicht für manche Zwecke bereits aus.
3. Anstelle das Gesamtergebnis 7x rechts zu verschieben, kannst du es 
auch mit sich selbst addieren und dann nur den Hi-Anteil 
weiterverwenden.

W.S.

Im Tutorial für SRAM 
"https://www.mikrocontroller.net/articles/AVR-Tutorial:_SRAM"; werden die 
Register 30 und 31 als Paar zum Zugriff auf den reservierten 
SRAM-Bereich als Z-Pointer bezeichnet, dachte das wäre sowas wie ein 
gängiger Begriff und meinte damit dieses Registerpaar.

Danke für den Hinweis den Wert zu "verdoppeln" und dann das Hi-Byte 
verwenden :) :) :)

Chris schrieb:
> Hallo,
>
> ich hätte gerne fortlaufend den Mittelwert einer Spannungsmessung
> ermittelt. Angedacht war es so:
>
> 1. ich sammle erstmal bis ich 128 Messwerte habe und schreibe die in den
> SRAM
> 2. die Summe der Messwerte "schiebe" ich 7x (geht schneller als teilen,
> wenn ich die Forumsbeiträge richtig verstanden habe), dann sollte ich
> den Mittelwert haben
> 3. wenn ein neuer Wert kommt, ziehe ich zuerst den ältesten Wert meiner
> bekannten Summe ab und addiere dann dan neuen Wert dazu und berechne
> erneut den neuen Mittelwert
> 4. den ältesten Wert im SRAM ersetze ich dann natürlich auch durch den
> neuen
>


Kläre uns doch bitte mal genau dein Vorhaben.

Und nicht was Du wie in welcher Reihenfolge berechnen willst.

Was versprichst Du Dir?