Hallo zusammen, ich sitze leider im Moment komplett auf dem Schlauch bzgl. einer wahrscheinlich ziemlich trivialen Sache. Ich bekomme aus einen Sensor jede Sekunde einen Messwert. Den aktuellen Messwert will ich aber nur ausgeben, wenn sich der aktuelle Messwert vom letzten Messwert nicht mehr als 10% unterscheidet. Für jeden Messwert zählt sich ein Zähler hoch. Wenn ich nun eine feste Anzahl von Messwerten analysieren will, ist's ja einfach, da speichere ich einfach die Werte in Array und vergleich dannn z.Bsp. Messwert_old [2] mit Messwert[3]. Aber in meiner Anwendung will ja konkret nur den letzen Messwert mit dem Aktuellen vergleichen, dessen Zähler sich kontinuierlich nach oben zählt. Der aktuelle Messwert überschreibt ja immer den alten Messwert, also wie kann ich konkret in einer Messung den aktuellen Messwert speichern, der dann in der nächsten Iteration der alte Messwert sein wird. Sorry, ich komm da gerade nicht drauf, vielleich kann mir jmd. einen Tip geben. Danke schon ma und Grüße
1 | float Messwert_Neu |
2 | float Messwert_Alt |
3 | |
4 | Schleife: |
5 | Messwert_Alt = Messwert_Neu |
6 | |
7 | Messwert_Neu = machEineMessung() |
8 | |
9 | Wenn <10% Abweichung zwischen Messwert_Alt und Messwert_Neu: |
10 | print(Messwert_Neu) |
Braucht kein Array, du musst dir nur den Wert merken, bevor du einen neuen Messwert einholst.
:
Bearbeitet durch User
Mit der Methode kann es dir passieren, dass du gar keinen ausgeben wirst.
Michael F. schrieb: > Den aktuellen Messwert will ich aber nur ausgeben, wenn sich der > aktuelle Messwert vom letzten Messwert nicht mehr als 10% unterscheidet. Es soll also laufend was ausgegeben werden, wenn die Werte gleich sind? Wofür braucht man sowas? > vielleich kann mir jmd. einen Tip geben. Ein µC ist ein zutiefst binäres Ding. Deshalb fällt es ihm unheimlich leicht, mit 2er-Potenzen zu rechnen. Das sind 1, 2, 4, 8, 16, usw. aber auch 1/2, 1/4, 1/8 usw. Mit dem richtigen Rechenansatz fällt es ihm also recht leicht, 12,5% Abweichung (=1/8) auszurechnen. Er braucht aber einiges an Aufwand, wenn er 10% ausrechnen muss.
:
Bearbeitet durch Moderator
Lothar M. schrieb: > Mit dem richtigen Rechenansatz fällt es ihm also recht leicht, 12,5% > Abweichung (=1/8) auszurechnen. Er braucht aber einiges an Aufwand, wenn > er 10% ausrechnen muss. Ist Dir Dein Komentar nicht peinlich? Nachher soll man nicht einmal Dezimalzahlen anzeigen sondern nur eine Kette aus LEDs? Als Benutzer soll es einem völlig egal sein, wie der µC das Ergebnis erreicht, solange Rechenzeit und Speicher ausreichend sind. Und für solche trivialen Aufgaben ist das heutzutage immer der Fall, außer man konstruiert sich - wie hier öfter zu verfolgen ist - nicht lösbare Umstände. Und das nur aus Wichtigtuerei. :-(
Beitrag #7648973 wurde vom Autor gelöscht.
> Lothar M. schrieb: >> Mit dem richtigen Rechenansatz fällt es ihm also recht leicht, 12,5% >> Abweichung (=1/8) auszurechnen. Er braucht aber einiges an Aufwand, wenn >> er 10% ausrechnen muss. > > Ist Dir Dein Komentar nicht peinlich? > Als Benutzer soll es einem völlig egal sein, wie der µC das Ergebnis > erreicht, solange Rechenzeit und Speicher ausreichend sind. Und für > solche trivialen Aufgaben ist das heutzutage immer der Fall, Scherzkeks, auch heute sind noch 8bit µC zu programmieren, die kein Fliesskomma können. Und natürlich ist für einen selbst erklärten Anfänger wie dem TO einfachre einen Shift zu programmieren (">>") als ein korrekte Division durch 10.0. Zumal dafür der Sensorwert erstmal in eine korrekte (normalisierte) float zu konvertieren ist.
Lothar M. schrieb: > Mit dem richtigen Rechenansatz fällt es ihm also recht leicht, 12,5% > Abweichung (=1/8) auszurechnen. Er braucht aber einiges an Aufwand, wenn > er 10% ausrechnen muss. Aua. Du hast das Buch "Wie funktioniert eigentlich ein Computer?" gelesen", aber das war es dann auch schon. Diese Rechenaufgabe war schon vor 50+ Jahren für den 4-Bit-µP Intel 4004 ein Klacks, sowohl von der Programmlänge als auch von der Laufzeit. Zum Thema "richtiger Rechenansatz und Aufwand": Man muss bei dieser Aufgabenstellung gar nicht 10 % ausrechnen. Man multipliziert die Abweichung mit 10 und vergleicht anschließend. Das ist weniger Aufwand und der Rundungsfehler fällt weg. Und nebenbei: Wenn man tatsächlich unnötigerweise in Assembler programmieren würde und der uralte µP keinen Multiplikationsbefehl hätte, dann würde man die Multiplikation mit 10 so abkürzen: y = 2*x y = y + 4*y. Das kostet nur eine Addition mehr als das Berechnen von 1/8.
> Aua. Du hast das Buch "Wie funktioniert eigentlich ein Computer?" > gelesen", aber das war es dann auch schon. Warum reagieren manche Enkel beleidigt, wenn Opa ihnen einen Trick zeigt, der ihn vor Stalingrad überleben ließ??
Klar P. schrieb: > Und natürlich ist für einen selbst erklärten Anfänger wie dem TO einfachre > einen Shift zu programmieren (">>") als ein korrekte > Division durch 10.0. Lies nochmal. Der TO hat gar nicht nach der Berechnung von 10 % gefragt, und der erste Antworter hat dafür auch keine Lösung geliefert.
Klar P. schrieb: > Scherzkeks, auch heute sind noch 8bit µC zu programmieren, die kein > Fliesskomma können. Und natürlich ist für einen selbst erklärten > Anfänger wie dem TO einfachre einen Shift zu programmieren (">>") als > ein korrekte > Division durch 10.0. Zumal dafür der Sensorwert erstmal in eine korrekte > (normalisierte) float zu konvertieren ist. Der TO hat das mit 'float' schon begriffen. Ihn jetzt mit Bananen auf einen Baum zu locken, sollten die Opas ruhig lassen.
Sebastian R. schrieb: > float Messwert_Neu > float Messwert_Alt Ohne Initialisierung mit Werten, die niemals als Messwerte vorkommen können, ist das einfach falsch.
Klar P. schrieb: > Warum reagieren manche Enkel beleidigt, wenn Opa ihnen einen Trick > zeigt, der ihn vor Stalingrad überleben ließ?? Weil sie sich nicht vorstellen können, dass diese Tricks für ihre Leben jemals relevant werden könnten. Ich hätte bis vor kurzem auch nicht gedacht, dass ich mir Gedanken über Alternativen zu Klopapier machen musste. Dass es mal weder Nudel noch Mehr zu kaufen geben würde. Dass ich aus Sorge vor Stromausfall Wasser und Kerzen bevorraten würde. Das Krieg für mich relevant würde. ... Wer als junger Mensch in guten Zeiten aufwächst, hat keine Ahnung, was danach kommen kann. Und er will das auch nicht von Opa hören. Lieber schaut man sich Videos von "genialen" Tricks mit gefakten Erfolgen auf Youtube an, die machen gute Laune.
>> Division durch 10.0. > > Lies nochmal. Der TO hat gar nicht nach der Berechnung von 10 % gefragt, Doch, hat er. >> wenn sich der aktuelle Messwert vom letzten Messwert nicht mehr als 10% >> unterscheidet.
Rolf schrieb: > Sebastian R. schrieb: >> float Messwert_Neu >> float Messwert_Alt > > Ohne Initialisierung mit Werten, die niemals als Messwerte vorkommen > können, ist das einfach falsch. Pseudocode. Dass das keine fertige oder 100% funktionierende Lösung ist, sollte eigentlich klar sein, oder?
Klar P. schrieb: >> Lies nochmal. Der TO hat gar nicht nach der Berechnung von 10 % gefragt, > Doch, hat er. Gruß nach Schiefturmstadt.
Ich sehe das Problem u.U. dabei, dass z.B. eine entsprechend langsame aber kontinuierliche Änderung des Wertes nie zu einer neuen Anzeige führt. Das kann natürlich so gewollt sein - Details zum Problem wurde nicht genannt. Wenn nicht, dann nimmt man einen Ringbuffer, der in gewissen zeitlichen Abständen mit neuen Werten gefüllt wird und der neue Wert wird mit dem ältesten verglichen.
Klaus H. schrieb: > Ich sehe das Problem u.U. dabei, dass z.B. eine entsprechend langsame > aber kontinuierliche Änderung des Wertes nie zu einer neuen Anzeige > führt. "messwert_alt" darf erst dann angepaßt werden, wenn er auch angezeigt wurde. Dann würde das passen. Welchen Sinn da haben soll? Vielleicht sollen nur die 'wahren' Werte angezeigt werden.
Klaus H. schrieb: > Ich sehe das Problem u.U. dabei, dass z.B. eine entsprechend langsame > aber kontinuierliche Änderung des Wertes nie zu einer neuen Anzeige > führt. Es wird bei entsprechend schneller Wandlung sogar immer etwas ausgegeben. Nur, wenn der Unterschied mal zufälligerweise größer als 10% ist, wird einmal nichts ausgegeben. Mir erscheint diese Forderung des TO seltsam, deshalb hatte ich nachgefragt, wofür man sowas braucht. Rolf schrieb: > Aua. Du hast das Buch "Wie funktioniert eigentlich ein Computer?" > gelesen", aber das war es dann auch schon. Hach. > Diese Rechenaufgabe war schon vor 50+ Jahren für den 4-Bit-µP Intel 4004 > ein Klacks, sowohl von der Programmlänge als auch von der Laufzeit. Aber sie war auch auf dem 4004 mit einer Zweierpotenz schneller als mit einer Zehnerpotenz. > Wenn man tatsächlich unnötigerweise in Assembler programmieren würde Ja, tatsächlich: der Compiler "programmiert" in Assembler. Ob das nötig ist, kann nur ein Compilerbauer abschätzen. Und eine Multiplikation mit 8 geht bei geeignetem Variablentyp schneller als ein mit 10. Mi N. schrieb: > solange Rechenzeit und Speicher ausreichend sind. Du kennst den Rest der Aufgabe nicht. Und hier schlagen laufend Leute auf, die auf dem AVR alles Float rechnen und dann jammern, der wäre zu langsam oder das Programm würde seltsame Dinge machen. Oder andersrum: wenn ich von vorn herein "binär" denke und programmiere, dann spare ich mir hinterher die Fehlersuche, die durch "Rechenzeitverplemperung" nötig ist.
:
Bearbeitet durch Moderator
Lothar M. schrieb: > Mi N. schrieb: >> solange Rechenzeit und Speicher ausreichend sind. > Du kennst den Rest der Aufgabe nicht. Und hier schlagen laufend Leute > auf, die auf dem AVR alles Float rechnen und dann jammern, der wäre zu > langsam oder das Programm würde seltsame Dinge machen. Den Rest der Aufgabe kennst auch Du nicht und mir fallen immer die Leute auf, die antiquarische Vorbehalte gegen 'float' äußern. Man kann die Sache ja auch Intergerebene bequem mit Faktor 10 verarbeiten. > Oder andersrum: wenn ich von vorn herein "binär" denke und programmiere, > dann spare ich mir hinterher die Fehlersuche, die durch > "Rechenzeitverplemperung" nötig ist. Das ist doch albern!
Lothar M. schrieb: > Es wird bei entsprechend schneller Wandlung sogar immer etwas > ausgegeben. Nur, wenn der Unterschied mal zufälligerweise größer als 10% > ist, wird einmal nichts ausgegeben. Ja, du hast recht - meine Lesekompetenz :-(.
Mi N. schrieb: > Das ist doch albern! Kam doch letzthin wieder einer der Praktikanten zu mir und sagte: "Der µC ist zu langsam, der schafft die Rechnung in den nötigen 100µs nicht!" Ich habe ihm dann in etwa das selbe gesagt wie du und ihm geholfen, die Berechnung in diesen 100µs locker zu schaffen. Und ja, wir haben dazu auch den vom Compiler erzeugten Assembler angeschaut. > mir fallen immer die Leute auf, die antiquarische Vorbehalte gegen > 'float' äußern. Mir fallen immer wieder Leute auf, die ihr Unwissen mit Rechenleistung erschlagen. Am 32-Bit Float stört mich übrigens am meisten, dass er nur 6 signifikante Stellen hat. Deshalb nehme ich im Zweifelsfall (und vor allem, wenn ich die Dynamik eines Float nicht brauche) lieber einen 32-Bit Integer.
:
Bearbeitet durch Moderator
Mi N. schrieb: > Welchen Sinn da haben soll? Vielleicht sollen nur die 'wahren' Werte > angezeigt werden. Lothar M. schrieb: > Mir erscheint diese Forderung des TO > seltsam, deshalb hatte ich nachgefragt, wofür man sowas braucht. Man kann solche Strategien z.B. zur Messwertberuhigung verwenden. Ab einem gewissen Delta folgt die Anzeige schnell, innerhalb eines Delta folgt die Anzeige in 1 mV Schritten. Ich habe mal ein altes Beispiel von mir angehangen. Vielleicht hilft es ja zum Verständnis. Den Rest sollte der TO beisteuern.
Steve van de Grens schrieb: > Ich hätte bis vor kurzem auch nicht gedacht, dass ich mir Gedanken über > Alternativen zu Klopapier machen musste. Dass es mal weder Nudel noch > Mehr zu kaufen geben würde. Klopapier ist hier schon immer bevorratet. Als geiziger Mensch achte ich auf Preise und lagere haltbare Artikel großzügig ein. Was Elektronikkram angeht, gehe ich auch großzügig vor - lieber 50 Dioden als die benötigten drei kaufen, wenn der Preis passt und Aussicht auf weitere Anwendungen besteht. Mi N. schrieb: > "messwert_alt" darf erst dann angepaßt werden, wenn er auch angezeigt > wurde. Dann würde das passen. Das ist halt die Kunst des Entwicklers, solche Dinge zu bedenken. Wenn nicht gleich, bemerkt man das im Testlauf und biegt es gerade. > Welchen Sinn da haben soll? Vielleicht sollen nur die 'wahren' Werte > angezeigt werden. Meine Lötstation macht um 20 Messungen pro Sekunde, da aktualisiere ich die Isttemperatur nur, wenn sie min. 3K vom letzen Wert abweicht. Schreibe ich jeden Meßwert ins Display, wird das zur Flackerdisco und stiehlt mir auch Zeit, die ich lieber der Regelschleife überlasse. Lothar M. schrieb: > Es wird bei entsprechend schneller Wandlung sogar immer etwas > ausgegeben. Nur, wenn der Unterschied mal zufälligerweise größer als 10% > ist, wird einmal nichts ausgegeben. Mir erscheint diese Forderung des TO > seltsam, deshalb hatte ich nachgefragt, wofür man sowas braucht. Da das keinen Sinn macht, habe wohl die meisten von uns interpretiert, dass er es anderherum meint: Wert nur ausgeben, wenn größer 10% Änderung.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.