Exponentialfunktion berechnen

[Harry (Gast)]

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

[yalu (Gast)]

Integerdivisionen liefern ein Integer als Ergebnis, der gebrochene
Anteil geht verloren.

#define  scale   128.0
//                  ^^

sollte das Prolem lösen.

[Gast (Gast)]

> 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.

[Harry (Gast)]

Besten Dank, es klappt! Wieder etwas gelernt, tolles Forum, tolle Leute 
hier!

Ich danke Dir und schönen Abend,

Harry

[Johann L. (gjlayde)]

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...

[Gast (Gast)]

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.

[sous (Gast)]

>>>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.