Hallo, ich bräuchte bitte Eure Hilfe bei folgender Aufgabe: Folgende Funktion soll im Atmega128 und AVR-GCC berechnet werden setting = exp(((adcval+offset)/scale)*factor)+dc Nun habe ich folgendes probiert und bekomme nicht das gewünschte Ergebnis, sondern der Wert springt von 79 zu 115 dann zu 173... #include "math.h" #define scale 128 #define dc 25 #define offset 1100 int16_t adcval; uint16_t setting; adcval = read_ad_channel(0); // Formel: // wert = exp(((adcval+offset)/scale)*factor)+dc double temp; temp = (adcval+offset)/scale; temp = temp/2; temp = exp(temp); setting = temp + dc; //weiter mit... //dac_channel[1].volts = setting; Wenn ich es in Excel rechne, passt alles prima, aufm µC nicht. Bin Anfänger und verstehe nicht, wo das Problem ist. Eine Tabelle scheidet aus, weil ich von 0-1023 alles umrechnen muss, ist etwas viel... Danke für Euere Hilfe, Harry
Integerdivisionen liefern ein Integer als Ergebnis, der gebrochene Anteil geht verloren.
1 | #define scale 128.0
|
2 | // ^^
|
sollte das Prolem lösen.
> temp = (adcval+offset)/scale;
Die Berechnung wird als Integer und nicht als Float ausgeführt.
Ich vermute da kommen deine Fehler her.
Eventuell ist es für dich interessant, die e-Funktion über eine
Reihenentwicklung zu berechnen. In diesem Fall kann eventuell Rechenzeit
gespart werden.
Besten Dank, es klappt! Wieder etwas gelernt, tolles Forum, tolle Leute hier! Ich danke Dir und schönen Abend, Harry
Gast wrote: > Eventuell ist es für dich interessant, die e-Funktion über eine > Reihenentwicklung zu berechnen. In diesem Fall kann eventuell Rechenzeit > gespart werden. Ich glaub wenn du gegen die libm antrittst ziehst du den Kürzeren :-) Erstens ist sich deren Implementierung über die Potenzreihe für exp durchauss bewusst, und von Hand anzufangen, erstmal den Wertebereich zurechtzurücken, will man eigentlich auch net...
Klar, die libm Implementation wird optimal sein. Je nach benötigter Genauigkeit kann bei einer eigenen Implementation früher abgebrochen und mit Integer statt Floats gerechnet werden. Beides kann auf einem uC von Vorteil sein. Ich denke das hängt davon ab, ob das Problem einen akademischen oder komerziellen Hintergrund mit möglichst schneller "Time to Market" hat.
>>>Ich denke das hängt davon ab, ob das Problem einen akademischen >>>oder komerziellen Hintergrund mit möglichst schneller "Time to Market" >>>hat. Und auch davon, ob Rechenzeit bei der Anwendung überhaupt eine Rolle spielt.
Bitte 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.