www.mikrocontroller.net

Forum: Compiler & IDEs Wie folgende Gleichung möglichst zeitsparend berechnen?


Autor: Jan Sams (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

ich möchte in einem Unterprogramm den Lambdawert berechnen. Folgende 
Formel habe ich mir dafür hergeleitet:

Lambda = k  m  t_m / t_B

Lambda ist die Luftzahl (Genauigkeit 0,0001, Wertebereich 
0,0000..3,0000)
t_B ist die Einspritzdauer (Genauigkeit 1µs, Wertebereich 0..20.000µs)
t_m ist die Zyklusdauer (Genauigkeit 1µs, Wertebereich 0..120.000µs)
m ist der Luftdurchsatz (Genauigkeit 0,1 kg/h, Wertebereich 
0,0..999,9kg/h)
k ist eine Konstante (Genauigkeit beliebig, Wertebereich 
~1*10^-2..3*10^-3)

Die Formel ist eine Zahlenwertgleichung d.h., die Werte können direkt 
mit obigen Einheiten eingesetzt werden und es ergibt sich der korrekte 
Lambdawert.

Ich habe bei der Berechnung zwei grundlegende Vorgaben:
(1) Lambda muss eine Genauigkeit von 0,0001 haben!
(2) Der Wert muss möglichst schnell zu berechnen sein!

Tja, wie gehe ich da am Besten ran? Ich hatte mir überlegt, den Wert als 
uint16_t darzustellen, so dass die höchstwertigste Dezimalstelle die 
Vorkammastelle ist. Dann käme ich auf einen Wertebereich von 
0,0000..6,5535.

Wie aber führe ich die Berechnung selbst am einfachsten aus? Welchen 
Term muss ich mit welcher Genauigkeit rechnen, damit ich am Ende die 
benötigte Genauigkeit von 0,0001 bekomme? Wie geht man an sowas 
grundsätzlich ran, gibt es ein Tutorial?

Grüße
Jan

P.s.: Zielsystem ist ein ATMega2561, Speicherplatz ist noch unkritisch!

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Lambda = k  m  t_m / t_B
Mit den Tokens (pre) und (/pre) in eckiger Klammer wäre das nicht 
passiert.
So siehts schöner aus:
 Lambda = k *  m * t_m / t_B

> t_m ist die Zyklusdauer (Genauigkeit 1µs, Wertebereich 0..120.000µs)
0...120000 sind schon doppelt soviel wie in ein unsigned short passt. 
also dürfte hier schon long integer Arithmetik nötig werden.

Wenn dann Lambda noch auf 1/10000 aufgelöst werden soll, dann muss
k * m * tm
 mindestens genau diesen Faktor größer als t_B sein, wenn das Ganze 
nicht mit Fließkommazahlen berechnet werden soll.

Ein paar Grundlagen siehe Festkommaarithmetik

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>(2) Der Wert muss möglichst schnell zu berechnen sein!

Gibt es auch eine Definition zu "möglichst schnell"?

>t_B ist die Einspritzdauer (Genauigkeit 1µs, Wertebereich 0..20.000µs)

Den Wertebereich glaube ich nicht.

>t_m ist die Zyklusdauer (Genauigkeit 1µs, Wertebereich 0..120.000µs)

Den auch nicht.

>k ist eine Konstante (Genauigkeit beliebig, Wertebereich
>~1*10^-2..3*10^-3)

;-) Konstanten haben eigentlich per Definition keinen Wertebereich. Oder 
soll das ein Wert aus einer Kennlinie sein?

Oliver

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lothar Miller schrieb:

> Wenn dann Lambda noch auf 1/10000 aufgelöst werden soll, dann muss
>
k * m * tm
 mindestens genau diesen Faktor größer als t_B
> sein, wenn das Ganze nicht mit Fließkommazahlen berechnet werden soll.

Fliesskomma hab ich mir auch überlegt. Aber seine Zahlen sind in einem 
derartig grossem Dynamikbereich, dass ich denke, dass da nur 
Phantasiewerte rauskommen werden. Mit den Vorgaben wäre ein naives 
Einsetzen in die Formel und float rechnen nahe an der 
Fahrlässigkeitsgrenze.

> Ich hatte mir überlegt, den Wert als
> uint16_t darzustellen, so dass die höchstwertigste Dezimalstelle die
> Vorkammastelle ist. Dann käme ich auf einen Wertebereich von
> 0,0000..6,5535.

Dein Problem ist nicht der Datentyp für lambda. Dein Problem ist, dass 
dir die Berechnung hinten und vorne überlaufen wird, wenn du nicht 
vorsichtig bist.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl heinz Buchegger schrieb:
> Mit den Vorgaben wäre ein naives Einsetzen in die Formel
> und float rechnen nahe an der Fahrlässigkeitsgrenze.
ACK

Leider fehlt immer noch die Angabe zur maximalen Dauer der Berechnung...

> t_m ist die Zyklusdauer (Genauigkeit 1µs, Wertebereich 0..120.000µs)
> Lambda ist die Luftzahl (Genauigkeit 0,0001, Wertebereich 0,0000..3,0000)
wenn Lambda nur auf 1/10000 aufgelöst werden soll, dann kann getrost 
auch  auch t_m in der Genauigkeit (Auflösung) reduziert werden. Es 
bringt nichts, mit 6 Nachkommastellen zu rechnen, und gleich darauf 2 
davon wegzuwerfen.

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>wenn Lambda nur auf 1/10000 aufgelöst werden soll,

Ich wollte es ja erst nicht fragen, aber was wird denn da für ein 
Luftmassensensor eingesetzt? Der Wertebereich umfasst zwar 10000 Werte, 
über die Genauigkeit sagt das aber gar nichts.

(Um nicht gleich zu fragen: Sind 0,0001 GENAUIGKEIT für Lambda nicht 
reines Wunschdenken?)

Oliver

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Er meint wohl Auflösung und nicht Genauigkeit...

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jan Sams schrieb:
> t_B ist die Einspritzdauer (Genauigkeit 1µs, Wertebereich 0..20.000µs)

Wo kriegt man denn diese Super-Extra-High-Präzisionsventile, die die 
Einspritzdauer auf 5 Stellen bzw. 1ns exakt einhalten?

Bei 0.000µs kriegst Du aber nen wunderschönen Division/0 Error.


Peter

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Er meint wohl Auflösung und nicht Genauigkeit...

:-)

Je nun, das ist die Original-Spezifikation:
>(1) Lambda muss eine Genauigkeit von 0,0001 haben!

Der Sinn meiner Frage war schon, das zu hinterfragen...

Oliver

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl heinz Buchegger schrieb:

> Fliesskomma hab ich mir auch überlegt. Aber seine Zahlen sind in einem
> derartig grossem Dynamikbereich, dass ich denke, dass da nur
> Phantasiewerte rauskommen werden.

Ausgerechnet mit dem Dynamikbereich sehe ich kein Problem. Grenzwertig 
ist eher die Genauigkeit einer "float" Mantisse mit 6-7 Dezmalstellen 
bei Parametern die schon 5-6 signifikante Dezimalstellen haben und einer 
gefordeten Genauigkeit des Ergebnisses von knapp 5 Dezimalstellen. Das 
ist knapp, könnte aber noch ausreichen.

Autor: Jan Sams (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
In aller Kürze, weil noch zwei Fragen von Euch offen sind:

Es handelt sich nicht um eine Hardware die im Fzg. eingesetzt werden 
soll, sondern um einen Simulationsprüfstand (HiL). Das ist der 
Hintergrund für die hohe Genauigkeit.

Auf eine Ausführungszeit möchte ich mich nicht festlegen. Es geht darum, 
die Berechnung möglichst schnell auszuführen. Anders herum: angepeilt 
sind ungefähr 1ms. Wenn's schneller geht -> sehr gut. Wenn's länger 
dauert -> schade, aber hilft ja nichts.

Danke für Eure Antworten!

Grüße
Jan

P.s.: Das mit der Konstante stimmt schon, sie ist in Wirklichkeit nicht 
konstant. Sie setzt sich, je nach Testfall, aus anderen Konstanten 
zusammen (Dichte Benzin oder Dichte Diesel etc.).

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:

> Ausgerechnet mit dem Dynamikbereich sehe ich kein Problem.

dito.

Ich dachte genau das wäre der Vorteil von Fließkomma.
Wenn man große und kleine Werte addiert, dann kann es Probleme geben, 
aber wenn man z.B. 10E+25 durch 10E-12 teilt, dann sollte das Ergebnis 
(im Rahmen der Auflösung, also die 6-7 Stellen) genau sein.

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Das mit der Konstante stimmt schon, sie ist in Wirklichkeit nicht
>konstant. Sie setzt sich, je nach Testfall, aus anderen Konstanten
>zusammen (Dichte Benzin oder Dichte Diesel etc.).

Was die Sache auch nicht genauer macht. Oder hast du da auch eine 
supergenaue Temperaturmessung dran?

Noch 'ne Frage:

Wie (d.h. in welcher Form/Darstellung/Protokoll, und wie schnell) 
bekommst du denn die Werte in den Prozessor?

Oliver

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Karl heinz Buchegger schrieb:
>
>> Fliesskomma hab ich mir auch überlegt. Aber seine Zahlen sind in einem
>> derartig grossem Dynamikbereich, dass ich denke, dass da nur
>> Phantasiewerte rauskommen werden.
>
> Ausgerechnet mit dem Dynamikbereich sehe ich kein Problem.

Du hast recht.
Sind ja nur Multiplikationen und keine Additionen enthalten.

: Wiederhergestellt durch Moderator
Autor: Jan Sams (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo nochmal,

zuerst einmal vielen Dank für Eure Antworten.

Ursprünglich wollte ich nur wissen, wie man am sinnvollsten an so eine 
Formel herangeht. Da aber hier Fragen über die Zweckmäßigkeit 
auftauchen: Es geht darum, einen Teststand für Motorsteuergeräte zu 
bauen. Da ich u.a. die Luftmasse also selber vorgebe, kann ich sie auch 
als beliebig genau annehmen. Die Frage, wie die Werte in den Prozessor 
kommen, erübrigt sich damit auch.

Die "Konstante" setzt sich aus weiteren Konstanten zusammen. Je nach 
verwendetem Kraftstoff oder Einspritzventilen ergibt sich ein anderer 
Wert. Demnach ist die "Konstante" zwar für jeden Testfall konstant, kann 
aber für andere Fälle halt doch variieren.


Aus Euren Antworten lese ich, dass ich die Berechnung mit 
float-Datentypen machen soll.

Grüße
Jan

Autor: Jan Sams (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
P.s.: Danke für den Tipp mit dem (pre)!

Autor: Stefan Kunz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Frage ist ehr wie schnell du das berechnen willst. ein AVR Prozessor 
ist damit hoffnungslos überfordert. Mit float Zahlen noch mehr als mit 
Int. Wenn du diese Formel schnell berechnet haben willst solltest du 
dich mit 32bit Prozessoren wie ARM7 oder ARM9 bzw dem Cortex-M3 
anfreunden.
Selbst ein ARM9 mit 200MHz Taktung braucht µs für die multiplikation von 
Floatzahlen

MfG
Stefan

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oben schreibt er, dass eine solche Berechnung pro Millisekunde 
ausreicht. Dafür tut es auch ein AVR.

Autor: Jan Sams (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die erste Multiplikation
k*m
kann ich ja mit einer Tabelle lösen. Kostet mich zwar 20kB (da die 
Luftmasse 10.000 16-Bit Werte hat), aber das stört mich nicht. Der 
Mega2561 ist groß und meine Hardware ein Einzelstück.

Deutlich aufwändiger wird die Division...

Autor: Helmut Lenzen (helmi1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Warum programmierst du das nicht einfach mal und testes das im Simulator 
mal aus. Dann siehst du doch ob es klappt oder nicht. Oder schreib mal 
die Zyklen neben deinen Befehlen.

Gruss Helmi

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Probier doch erst einmal aus, was bei Fliesskommarechnung als Laufzeit 
rauskommt, bevor du sämtliche Räder neu erfindest.

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das du das Ergebnis vermutlich als float speichern willst, braucht es 
für die Tabelle 40 KB.

Ich würde aber erst einmal abschätzen, wie lange die Berechnung nun 
wirklich braucht. Im AVR-Studio simulieren, und die Laufzeit für ein 
paar Wertekombinationen durchspielen. Dann weisst du, ob manuelle 
Laufzeitoptimierungen überhaupt erforderlich sind.

Oliver

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Probier doch erst einmal aus, was bei Fliesskommarechnung als Laufzeit
> rauskommt, bevor du sämtliche Räder neu erfindest.

Seh ich auch so.

Ich würd sogar weiter gehen:
Auf dem PC in ineinandergeschachtelten Schleifen den kompletten 
Wertebereich aller Variablen durchackern lassen. Dabei jeweils eine 
double Version mit einer float Version vom Ergebnis her vergleichen und 
den prozentuellen Fehler feststellen und das Maximum davon festhalten.

Ist mir doch egal, ob der PC da ein paar Stunden (wenn überhaupt) daran 
knabbert. Optimierung aus, FPU Unterstützung abdrehen, damit sich das PC 
Programm in der Berechnung möglichst gleich dem verhält, was sich auch 
auf dem AVR abspielen wird (ev. float Zwischenvariablen einführen, damit 
die eigentliche float Rechnung auch mit der kleineren Mantisse gemacht 
wird.)

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Viel Vergnügen. Das sind 2.4e13 Operationen.

Ich würde eher sagen, dass der maximale Fehler bei korrekt arbeitender 
Fliesskommalib ungefähr ein letztes Mantissenbit pro Operation rauf oder 
runter ist. Das ist bei 3 Operationen weniger als eine Dezimalstelle, 
also ausreichend.

Und wenn die Lib nicht ganz so korrekt ist, dann nützt dir das Ergebnis 
vom PC auch nix.

Autor: Oliver Döring (odbs)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kompletten Wertebereich durchgehen kannst du vergessen. Wenn das bei 
mehreren Eingangsvariablen so einfach wäre, könnte man Software sehr 
leicht brute-force-mäßig auf Korrektheit prüfen. Geht aber in der Praxis 
nicht, weil der Kunde schon gestorben ist, wenn das Ergebnis da ist.

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Berechnung in float scheint um die 800 Takkte zu benötigen (ich hab 
nur ein paar Wertekombinationen überprüft). Das ist selbst bei 1MHz 
Prozessortakt schnell genug für 1ms, wenn das Programm ansonsten nicht 
allzuviel anderes machen muß.

Allerdings bleibt nach wie vor die Frage, wo die Werte für die 
Berechnung herkommen. Wenn die als Tabelle im Speicher liegen, reicht es 
ja nur für ein paar Sekunden Meßzeit.

Oliver

Autor: Jan Sams (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo

Auf die 800 Zyklen bin ich gestern Abend auch gekommen. Die Division ist 
dabei der zeitaufwändigste Teil.

Ich verstehe Deine Frage nach der Herkunft der Werte leider nicht: Der 
Luftmassenstrom m wird vom Anwender eingegeben. Eine Tabelle gibt es 
dafür nicht. Einspritzdauer t_B und Zykluszeit t_m werden über die Input 
Capture Funktion gemessen.

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Ich verstehe Deine Frage nach der Herkunft der Werte leider nicht: Der
>Luftmassenstrom m wird vom Anwender eingegeben. Eine Tabelle gibt es
>dafür nicht. Einspritzdauer t_B und Zykluszeit t_m werden über die Input
>Capture Funktion gemessen.

Nun denn, wenn man das weiß, könnte man auf die Idee kommen, k*m bei der 
Eingabe einmal zu berechnen, und danach als konstant anzusehen. Das 
spart eine Multiplikation im ms-Takt.

Aber es ist deine Entscheidung, die interessanten Randbedingungen von 
den uninteressanten zu unterscheiden.

Oliver

Autor: Horst (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

wenn die Lufmasse konstant sein soll, da Handeingabe , dann muss 
mindestens auch die Drehzahl konstant sein.Dann ist auch t_m auch kein 
Kriterium mehr, sondern nur die absolute Einspritzmenge/ Umdrehung ~ 
t_b.
Ausser t_m beeinflusst die Einspritzmenge/Zeiteinheit.
Wenn nun k*m = konstant , kann man ja eine Tabelle für 1/x [1..20000] 
nehmen.
Oder eine kleine Tabelle mit 1/1,1/2,1/4,1/8,1/2^n der Tabellenplatz 
käme aus dem Exponenten von t_b.
Und dann die Näherungsformel:
(1) xi+1 = xi(2 − D · xi), wobei D eben t_b wäre und xi als Startwert 
aus der Tabelle käme.
Viel wichtiger:
Wenn sich die t_b Werte nicht schnell ändern, wäre eine Berechnung 
mittels des vorherigen Wertes möglich.
Wäre der nächste Wert 5% vom vorherigen entfernt, wären nach 2 
Berechnungen von (1) der Wert auf 1e-6 genau.
sei t_b_alt = 1 und der neue Wert 1.05
x1 = 1*(2-1.05*1)= 0,95
x2 = 0.95*(2-1.05*0.95)= 0.952375 = 1/1.050006563
Jetzt bleibt die Frage, sind 4 Mul+2 Diff für die Bestimmung von 1/x und 
1 Mul zur anschliessenden Berechnung schneller als 1 Division.

Gruß Horst










Gruß Horst

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Subtraktion von Daten in grossem Dynamikbereich reduziert die 
Genauigkeit erheblich. Iteration führt zusätzlich zu Fehlerakkumulation. 
Da hier ohnehin schon wenig Genauigkeitsreserve ist: davon würde ich 
abraten.

Autor: Chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich würde mit Fixed point gehen,
Lambda = k  m  t_m / t_B
sowie 16.16 Integer, was dann später ev. aufgeweitet werden kann, mit
mehr Nachkommastellen.

Autor: Horst (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
@A. K:
die Subtraktion in (1) xi+1 = xi(2 − D · xi), liegt doch bei  2.0-1.0, 
da verliert man 1 Bit an Genauigkeit. Da ist keine hohe Dynamik.Es 
korrigiert sich ja auch selbst.
Falls es unklar beschrieben war:
D ist die Zahl und xi die Näherung für 1/D, also ist D*xi ~ 1.0 wie in 
dem Rechenbeispiel bei 5% Abweichung zu sehen.
Diese Formel macht nur Sinn, wenn man schnell multiplizieren kann und 
eine gute Näherung hat, deshalb die Tabelle, die aber nur Sinn macht, 
wenn man stark schwankende Werte hat.
Selbst D= 1.5 und Näherung x0= 1
x1= 1(2-1.5*1) = 0.75 (das wäre auch die lineare Näherung zwischen 1/1 
und 1/2 )
x2= 0.75(2-1.5x0.75) = 0.65625
x3= 0.65625(2-1.5*0.65625)= 0.6665039
x4= 0.6665039(2-1.5*0.6665039)= 0.666666626 hat schon 6..7 Stellen

Da der AVR nun einmal einen MUL Befehl kennt, "kann" es schneller sein.

Gruß Horst

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hatte nicht untersucht wie gross der Fehler tatsächlich ist.

Nachdem die ursprüngliche Lösung schon viel schneller als nötig ist 
(50µs@16MHz statt 1ms), sehe ich keinen Grund für eine derartige 
Optimierung.

Autor: Läubi .. (laeubi) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und wer liest die daten im ms Takt ab/aus?

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Horst schrieb:

> Wenn sich die t_b Werte nicht schnell ändern, wäre eine Berechnung
> mittels des vorherigen Wertes möglich.

Das ist der Punkt in dem ich Probleme sehe. Jede Rechnung bringt 
potentiell zum Fehler aus der vorherigen Rechnung einen zusätzlichen 
Fehler hinzu. Nach 1000 solchen iterativen Rechnungen ist das Ergebnis 
bei der geringen Genauigkeitsreserve möglicherweise nur noch Phantasie.

Ein Aspekt den man bei Iteration stets im Auge behalten sollte.

Autor: Horst (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

die Optimierung ist nun gänzlich unproblematisch.
Wie die Wurzel bei der Heron-Formel , verdoppelt sie im jedem Schritt 
die Anzahl der genauen Stellen.
Das der vorherige Schätzwert für neuen 5% davon abweichenden,  selbst 
1e-6 davon liegt, macht sich nirgendwo bemerkbar (ob 0.050001 oder 
0.049999 ).
Hier von 1.0 ausgehend immer 5% mehr bei jeweil zweimaliger Iteration:
program DivTest;//freepascal oder Delphi
{$Apptype console}

function  DiVIter(x,rez:single):single;
begin
  DivIter := (single(2.0)-single(x*rez))*rez;
end;

var
  i : integer;
  x,d : single;
begin
  x := 1.0;
  d := 1.0;
  For i := 0 to 29 do
    begin
    x := x*1.05;
    d := diviter(x,d);d := diviter(x,d);
    writeln(x:10:5,d:10:5,'  ', x*d-1.0)
    end;
end. 

     X        1/X        rel. Abweichung
   1.05000   0.95238  -6.238336566E-06
   1.10250   0.90702  -6.243170217E-06
   1.15763   0.86383  -6.243170217E-06
   1.21551   0.82270  -6.211577640E-06
   1.27628   0.78352  -6.209570961E-06
   1.34010   0.74621  -6.231809776E-06
   1.40710   0.71068  -6.210872121E-06
   1.47746   0.67684  -6.224567214E-06
   1.55133   0.64461  -6.219126986E-06
   1.62889   0.61391  -6.275373592E-06
   1.71034   0.58468  -6.219858873E-06
   1.79586   0.55683  -6.219383975E-06
   1.88565   0.53032  -6.195066254E-06
   1.97993   0.50506  -6.274746239E-06
   2.07893   0.48101  -6.263777534E-06
.....

Natürlich hat sich das ganze bei 50e-6 Sekunden Rechenzeit erledigt.

Gruß Horst
P.S:
Warum schafft man sich eine AVR 256er an, wenn nicht weiß, ob der 
überhaupt schnell genug ist... :confused:

Autor: Jan Sams (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe von Anfang an geschrieben, dass ich eine möglichst schnelle 
Berechnung suche. Die 1ms habe ich einmal in den Raum geworfen und 
gleich im nächsten Satz darauf hingewiesen, dass es schneller besser 
wäre. Warum steht das hier den ganzen Thread über im Mittelpunkt? Die 
Anforderung "so schnell wie möglich" ist doch eindeutig!

@laeubi: Die Daten liest niemand im ms-Takt aus. Aber wenn ich nur 1ms 
für diese Berechnung brauche, kann ich mit dem Prozessor auch noch 
andere Dinge erledigen.

Ich schaue mir gerade die Methode mit der Iteration an. Sieht 
vielversprechend aus! Ich melde mich wieder, sobald ich sie simuliert 
habe.

Grüße
Jan

P.s.: Den Mega2561 habe ich ausgewählt, weil ich in der AVR-Architektur 
bleiben möchte und für LUT viel Programmspeicher benötige. Er ist ein 
guter Kompromiß!

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Jan Sams (Gast)

>wäre. Warum steht das hier den ganzen Thread über im Mittelpunkt? Die
>Anforderung "so schnell wie möglich" ist doch eindeutig!

Eben, sie ist eindeutig Unsinn!
So schnell wie möglich kann auch heissen, nimm nen Quad-Core mit 3 GHz!

>@laeubi: Die Daten liest niemand im ms-Takt aus. Aber wenn ich nur 1ms
>für diese Berechnung brauche, kann ich mit dem Prozessor auch noch
>andere Dinge erledigen.

Schon, aber meist dreht der Prozzessor bei vielen Leuten Däumchen. In 
Warteschleifen ;-)

MFg
Falk

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk Brunner schrieb:
>>@laeubi: Die Daten liest niemand im ms-Takt aus. Aber wenn ich nur 1ms
>>für diese Berechnung brauche, kann ich mit dem Prozessor auch noch
>>andere Dinge erledigen.
>
> Schon, aber meist dreht der Prozzessor bei vielen Leuten Däumchen. In
> Warteschleifen ;-)

Ja und wie sagt man hier so schön: Das Geld gibt es für nicht gebrauchte 
Ressourcen nicht zurück.

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Ich habe von Anfang an geschrieben, dass ich eine möglichst schnelle
>Berechnung suche.

Du hast von Anfang an ziemlich deutlich gemacht, daß du die 
tatsächlichen Anforderungen an das System noch gar nicht kennst. Selbst, 
wenn das ganze "nur" eine Studien-/Praktikums-/Semesterarbeit ist, gilt 
doch für die genauso, wie für alles andere: Ohne Kenntnis und Festlegung 
der Anforderungen ist jede Lösung falsch.

Nur so als Beispiel:
>t_m ist die Zyklusdauer (Genauigkeit 1µs, Wertebereich 0..120.000µs)

Nett, aber sinnlos. Ich rate jetzt mal drauf los: Es geht um einen 
Kolben-Verbrennungmotor. 120.000µs entspräche da einer Leerlaufdrehzahl 
von 500 1/min, ein realistischer Wert. Nur, viel mehr als das 15-fache 
wird die Maximaldrehzahl nicht betragen. Also ist das Minimum des 
Wertebereiches nicht 0 bzw. 1, sondern irgenwas um 8000, und die 
minimale Zyklusdauer 8ms.

Ob du jetzt aus diesen 8ms eine Anforderung für eine maximale 
Berechnungszeit von Lambda anleiten kannst, oder ob diese von etwas ganz 
anderem abhängt, keine Ahnung. Das musst (!!!) du selber erarbeiten.

Und wenn du dann irgendwann sagen kannst: Die Lösung muß sicherstellen, 
daß die Berechnung von Lambda maximal 1ms dauert, weil/damit...
dann bist du einen wichtigen Schritt weiter.

Oliver

Autor: Jan Sams (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei der Diskussion, warum unbedingt die genaue Zeitdauer benötigt wird, 
hast Du mich zwar nicht überzeugt.

Mit der Berechnung hast Du allerdings recht (darauf hast Du doch auch 
schon in Deinem ersten Posting hingewiesen?) und zugegeben, da habe ich 
nicht richtig nachgedacht.

Autor: Schorsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Besondere Anforderungen sind mir immer verdächtig, d.h. es könnte oft 
einfacher gehen.

Probleme dieser Art kann man oft mit LUT=Lookup Tabellen umgehen ggf. 
interpolieren, ich denke da auch an Fuzzy Logik. Meist wird nicht jede 
Zwischenstufe benötigt sondern nur konkrete Zielwerte.

Musst halt gucken, ob das für dich eine Option ist.

Autor: Schorsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe noch eine Idee, ohne zu wissen was du genau brauchst.

Ich musste an die alten Rechenschiebertricks denken:
Multiplikation und Division kann über logarithmieren in eine 
Addition/Subtraktion überführt werden.

Autor: Mark Brandis (markbrandis)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schorsch schrieb:
> Multiplikation und Division kann über logarithmieren in eine
> Addition/Subtraktion überführt werden.

log (a*b*c) = log a + log b + log c

Und was genau bringt das? Soll man jetzt megabyteweise Lookup-Tabellen 
für Logarithmen anlegen? :-)

Autor: Schorsch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Und was genau bringt das? Soll man jetzt megabyteweise Lookup-Tabellen
>für Logarithmen anlegen? :-)

http://de.wikipedia.org/wiki/Cordic

Ich nehme an es geht um die Realisierung für einen Regler, da reichen 
ein paar Werte.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.