Hallo!
Ich muss mit dem MSP430F149 eine Berechnung nach der "Methode der
keinsten Fehlerquadrate" durchführen.
Dabei habe ich 4 Wertepaare, durch die eine Trendfunktion gelegt wird
und als Ergebnis die Polynomkoeffizienten der Trendlinie als Polynom 2.
Grades herauskommen.
Die Berechung muß mit größtmöglicher Genauigkeit ausgeführt werden. Die
32bit vom Typ float reichen nicht aus um brauchbare Ergebnisse zu
erhalten.
Daher habe ich unter der Projekteinstellung von IAR die Option "64bit
double" aktiviert.
float bleibt bei 32 bit
double hat jetzt 64 bit Auflösung
Hier die komplette Berechnung:
1
#include<msp430x14x.h>
2
3
// Variablen aus einem anderem Programmteil, der hier nicht aufgeführt ist. Daher als Konstanten.
Ergebnisse nach Excel:
a1 2694932,6511787300000
a2 94063,4110887131000
a3 3283,1974704867400
a4 114,5979265293400
a5 2755128,1768908500000
a6 96157,5351940173000
a7 3356,0490000000000
a8 28,6497109495794
a9 820,7993676216850
a10 242,5879582422780
a11 0,7525688776223
a12 43,1125556402839
a13 485,2799834604370
a14 1,5054626741476
a15 86,2436261000111
a16 0,4998920866958
a17 0,0003346785415
a18 0,0000494249378
X0 -2840,4189218876800
X1 -65,5708714165796
X2 6,7714509384405
Diese X-Werte sind realistisch.
Das Problem ist jetzt:
wenn ich die Zeile mit "a1=..." abarbeite erhalte ich einen Stack
overflow.
Der berechnete Wert a1 stimmt aber trotzdem mit dem theoretischen Wert
überein.
Zuerst habe ich das ganze mit dem Typ float durchgerechnet, habe aber
dann Fehler von >1000% erhalten.
Excel rechnet mit 30 signifikanten Stellen. Wenn man diese in Excel in
jedem Rechenschritt auf 9 Stellen rundet, erhält man ähnliche Wert wie
der Controller mit 32 bit ausgibt. Also: Die Art der Berechnung ist
richtig, es gibt aber eben nur zu große Rundungsfehler, da sehr große
und sehr kleine Zahlen miteinander verrechent werden müssen.
In den Projektoptionen habe ich den Stack auf 160 vergrößert. Jetzt
kommt kein Stack Overflow mehr, aber beim Abarbeiten der Berechnung
"a3=..." bleibt das Programm hängen (ohne das irgendwas passiert.) Beim
setzen eines Breakpointes in die Zeile a1=... hält das Programm dann
dort an.
Die Abarbeitungsgeschwindigkeit der Berechnung spielt keine Rolle, das
ganze darf auch gerne 10 oder 20 Sekunden dauern. Nur eben die
Genauigkeit muss stimmen. Speicherplatz ist ebenfalls unerheblich.
Gibt es irgendwelche Headerfiles für den MSP430 welche unter IAR eine
64Bit-Berechnung durchführen lassen?
Gibt es sonstige Lösungsvorschläge?
Gruß
Martin
> Das Problem ist jetzt:> wenn ich die Zeile mit "a1=..." abarbeite erhalte ich einen Stack> overflow.
Dann ist der Stack an dieser Programmstelle zu klein.
Abhilfe: Ausdruck vereinfachen. Teilsummen nacheinander addieren:
1
a1=(tau1*tau1*tau1*tau1);
2
a1+=(tau2*tau2*tau2*tau2);
3
a1+=(tau3*tau3*tau3*tau3);
4
a1+=(tau4*tau4*tau4*tau4);
Die Klammern sind schon im einzeiligen Ausdruck völlig unnötig; Punkt-
geht vor Strichrechnung, auch in C.
>In den Projektoptionen habe ich den Stack auf 160 vergrößert. Jetzt>kommt kein Stack Overflow mehr,...
Damit stellst du nur ein mit wieviel Stack der Compiler rechnen soll.
Wie groß der Stack TATSÄCHLICH werden kann ist damit überhaupt nicht
gesagt.
Wenn du einen Breakpoint gesetzt hast schau dir mal an wo der
Stackpointer tatsächlich steht und wieviel RAM du benötigst. Wenn beides
zusammen größer als die 2048Byte RAM sind hast du einen Stacküberlauf.
Die Klammern habe ich wegen der Übersichtlichkeit reingemacht. Der
Compiler sollte diese eigentlich ignorieren.
Ich habe jetzt noch mehr vereinfacht und noch mehr Zwischenvariablen
gebildet.
Anbei Screenshoots von der Einzelschrittabarbeitung des Programmes mit
Darstellung des Stacks und des Speicherbereiches des Stacks.
Stack size und heap size ist auf 160 eingestellt.
Beim Compilieren werden folgende Speichergrößen angezeigt:
4 170 bytes of CODE memory
64 bytes of CONST memory
368 bytes of DATA memory
Ab der Zeile a3c=.. setzt die normale Abarbeitung aus und das Programm
springt in die Zeile a1d=...
Das ganze kommt im Word-Format, da ich hier nicht 20 Einzelbilder
hochladen möchte.
Wäre nett, wenn mal jemand da drüber schaut und ein paar Tipps zur
Problembehebung geben könnte.
Danke+Gruß
Martin
>Beim Compilieren werden folgende Speichergrößen angezeigt:> 368 bytes of DATA memory
Dann hast du 1840 Byte für den Stackpointer fei. Das sollte ausreichend
sein würde ich mal sagen :)
> Archivprogramme wie ZIP sind Dir unbekannt?
Kopieren und einfügen in Word geht viel schneller als 20 Bilder in ein
Bildbearbeitungsprogramm einzufügen und einzeln abzuspeichern.
Gezippt hat das Word Dokument immer noch 1,6 MB. Ich sehe keinen
Vorteil.
Diese Frage trägt aber nicht zu meiner Problemlösung bei.
>Dann hast du 1840 Byte für den Stackpointer fei. Das sollte ausreichend>sein würde ich mal sagen :)
Schön :-) Warum funktioniert es dann nicht? :-(
Noch mehr vereinfachen geht doch nicht...
@Martin S. (martins)
>Das ganze kommt im Word-Format, da ich hier nicht 20 Einzelbilder>hochladen möchte.
Lesen bildet. Bildformate. Steht auch in Kurzform hier oben drüber.
:-(
MFG
Falk
>Arbeitest du auf der Hardware oder nur im Simulator?
Auf der Hardware.
>Vielleicht einfach nur der Watchdog der kommt?
In meinem komplettem Programm hab ich ihn deaktiviert.
Als ich mir den Berechnungsteil herausgeholt habe, habe ich ihn zu
Beginn nicht deaktiviert.
Das war´s !
Vielen Dank an Jörg für die Hilfe !
@Falk:
In Deiner Quelle steht:
>Will man im Forum eine Antwort erhalten, dann sollte man es den anderen>Forenteilnehmern so leicht wie möglich machen, sich die dazugehörigen>Abbildungen anzusehen. Muss man die Dateien erst speichern oder gar ein>Archiv entpacken und danach ein externes Programm benutzen, um die>Dateien anzusehen, wird die Resonanz signifikant geringer sein, als hätte>man einfach nur draufklicken müssen, um es gleich im Browser zu betrachen.
So und nun?
Was hätte ich anders machen sollen? Aufwendig 20 Bilder in ein Zip
packen und dann hochladen und anderen die Arbeit machen alles irgendwo
abzulegen und dann hoffen, dass der andere es auch noch in der richtigen
Reihenfolge anschaut?
So, das Thema mit dem Dateiformat ist für mich erledigt. Ich habe das
für mich und für die Personen, die mir konstruktiv bei dem von mir
geschilderten Problem helfen wollen, günstigste Dateiformat ausgewählt.
Gruß
Martin
@Martin S. (martins)
>So und nun?
So schlechtes Textverständnis?
>Was hätte ich anders machen sollen? Aufwendig 20 Bilder in ein Zip>packen und dann hochladen und anderen die Arbeit machen alles irgendwo>abzulegen und dann hoffen, dass der andere es auch noch in der richtige>n>Reihenfolge anschaut?
Ist schon wirklich schwer, ein paar Screenshots in PNG zu speichern und
mit aufsteigenden Nummern zu versehen. Vielleicht solltest du mal nen
EDV-Kurs an der VHS belegen?
>So, das Thema mit dem Dateiformat ist für mich erledigt.
Ignoranz ist ein Menschenrecht.
>geschilderten Problem helfen wollen, günstigste Dateiformat ausgewählt.
Irren ist menschlich. Mal so zum Vergleich. Wenn man einen deiner
Screenshots als PNG speichert braucht er ca. 28Kb. Macht bei 20
Screenshots 560kB, statt 1,8MB. Mal ganz abgesehn davon, dass es
reichlich sinnlos ist, 20 Screenshots mit einzelnen Schritten des
Debuggers hier zu posten.
MFG
Falk
Kinders, ruhig Blut. In einer Zeit, in der schwachsinnige youtube-Filme
zu GB heruntergeladen werden, kommt es auf ein 1,8 MB Filegroesse auch
nicht an. Schade um die Zeit, um darueber zu diskutieren.
Problem schildern mit Bordmitteln. Fertig.
Ja, ich weiss, es geht ums Prinzip. PNG ist toll und JPG ganz schlimm.
Aber wie auch immer, Problem ist gelöst. Und gut ist.
@ szimmi (Gast)
>Kinders, ruhig Blut. In einer Zeit, in der schwachsinnige youtube-Filme>zu GB heruntergeladen werden, kommt es auf ein 1,8 MB Filegroesse auch>nicht an.
Irrtum. Wenn solche Aktion nie kritisiert weren würden, dann würde in
kurze Zeit immer mehr Müll ier nageschwemmt. Währet den Anfängen. Und es
wird niemanden der Kopf abgerissen.
> Schade um die Zeit, um darueber zu diskutieren.
Es wird nicht diskutiert, aber darauf hingewiesen.
>Problem schildern mit Bordmitteln. Fertig.
Genau. Hirn aus, DSL rein. :-(
Die Regentschaft der Deppen.
>Ja, ich weiss, es geht ums Prinzip.
Nöö, um eine Hinweis.
> PNG ist toll und JPG ganz schlimm.
Gefasel.
MFG
Falk
Thread beobachten
Seitenaufteilung abschalten