achnee, unter Windows gibts ja keine man-Pages ^^Code:~> man exp
Also, dann klär ich mal auf: exp ist die natürliche Logarithmusfunktion
achnee, unter Windows gibts ja keine man-Pages ^^Code:~> man exp
Also, dann klär ich mal auf: exp ist die natürliche Logarithmusfunktion
Fast. exp ist die Exponentialfunktion.
Ja nach Verwendungszweck kann man ja nen anderen Weg wählen, als den Brummer double exp(double). (double ist eh ne Mogelpackung, intern ist das nur float)
-- Urbildbereich?
-- Genauigkeit?
-- Muss es Basis e sein? Oder tut's auch z.B. 2?
-- etc?
Disclaimer: none. Sue me.
Nein, es geht nur darum das OCR0-Register fuer eine PWM zu fuellen. Und zwar soll das Tastverhältnis mit 40*exp(-t/tau)+30 abklingen. Das Ergebniss muss also noch auf Werte von 0 ... 255 (OCR0 ist 8bit) scaliert werden. Die Zeit von der oberen Schwelle zur unteren Schelle soll ca. 300ms sein, also in der Zeit ist die PWM auf der unteren Schelle.
Natürlich kann man eine Tabelle machen, aber wie sieht es dann aus, wenn tau sowie die Schwellen als Paramenter vorgebbar sein sollen?!
also das 40*exp(-t/tau)+30 war dann natürlich das Tastverhältnis in Prozent
Was sind denn t und tau. Integrale Typen oder floats? *würmer-aus-der-Nase-zieh*
Disclaimer: none. Sue me.
entschuldigung ... fuer tau reichen ganze zahlen aus. t werde ich ueber eine Laufvariable gewinnen. Ich weiss noch nicht, da ich dann nicht so viele Zíschenwerte bekomme.
Wie gesagt. Eine PWM soll mit einem Tastverhältnis von 70% bis 30% innheralb von 0.3 sec exponentiell abklingen.
@fambi_mailZitat von fambi_mail
Ist doch nicht wahr !! Programmierst Du in Assembler ?
Wenn es keine direkte von Float zu integer gibt, so gibt
es immer eine von Float zu einem String und eine
von einem String zu einem Integer.
Die Programmiersprache für einen modernen uC (ausser Assembler)
die das nicht kann, möchte ich mal sehen....
Meinst Du dass wenn du den Befehl nicht kennst, es diesen Befehl
automatisch nicht gibt ??
MfG
Ruedi
Mal ganz abgesehen davon, daß
funktionieren sollte...Code:(int) exp ((double) t/tau)
Was du willst in eine geometrische Progression, d.h. zwei aufeinander folgende Werte haben immer den gleichen Quotienten.
Nehmen wir mal an, du begnügst dich mit einem duty von 16 Bit, also Werten 0...0xffff. Nehmen wir weiterhin an, zwei aufeinanderfolgende Werte haben einen Quotienten von 1.01. Auf 0xffff folgt also 0xfd76. Zwei benachbarte Werte sind also durch 1.01 zu teilen, was hier gleichbedeutend damit ist, sie mit 0x10000/1.01 = 0xfd77 zu multiplizieren. Wir haben also 16-Bit Werte, bei denen wir alle 16 Bits als Nachkommastellen interpretieren. Multiplizieren wir zwei dieser Werte, haben wir 32 Bit Nachkommastellen, und schieben das Ergebnis der Mul daher um 16 nach rechts:
Der Nachfolger von x ist dannCode:extern uint16_t fixprod16 (const uint16_t, const uint16_t); // Prototyp für *.h uint16_t fixprod16 (const uint16_t a, const uint16_t b) { uint32_t ab = (uint32_t) a*b; return ab >> 16; }
Das ist auf jeden Fall deutlich effizienter als Geschütze wie exp.Code:fixprod16 (x, 0x10000/1.01)
Als Argumente von fixprod16 gehen natürlich auch Werte, die nicht zur Compilezeit bekannt sind.
Disclaimer: none. Sue me.
Hallo Georg-Johann, ich habe nicht soviel verstanden von dem was du meinst.
uint16_t x,y;
for (x=10;x>0;x--){
y=fixprod16 (x, 0x10000/1.01);
}
also so funktioniert es nicht. Was ist denn x und ist fuer 0x10000 eine variable zu verwenden?
Eher so was:
Dabei gibt faktor an, um welches Verhältnis sich zwei aufeinander folgende dutys unterscheiden:Code:#include <avr/io.h> ... uint16_t i; // Laufvariable uint16_t duty = ...; // Duty, mit dem angefangen wird for (i=0; i<100; i++) { duty = fixprod16 (duty, faktor); OCR1A = duty; }
64887 --> 1.01
62415 --> 1.05
59578 --> 1.1
46341 --> Wurzel(2)
43690 --> 1.5
32768 --> 2
20860 --> PI
16384 --> 4
etc.
Disclaimer: none. Sue me.
Lesezeichen