Eine bessere R zu T Wandler Routine gesucht

[RoboHolIC]

Was im Programm gerechnet oder getan werden muss, muss eben abgearbeitet werden.

In erster Instanz solltest du sortieren, was davon _wirklich_ in der ISR erledigt werden muss und was nicht.
Wenn diese rechenzeitintensiven Funktionen in dieser Ausführungshäufigkeit unvermeidbar sind, ist höherer Takt oder eine leistungsfähigere CPU unvermeidbar. Bei einer Heizungssteuerung kann ich mir das aber beim besten Willen nicht vorstellen. Die Temperatur (darum dreht es sich doch !?!? )muss ganz bestimmt nicht jede Millisekunde neu bestimmt werden.

Wenn "pow" eine Exponentialfunktion bedeutet, dann kann sie -je nach Controllertyp und Taktung - schon ziemlich am 1ms-Zeitbudget nagen.
Wenn abs() statt pow() nur 50% Einsparung bringt, vermute ich noch einen anderen Zeitfresser, vielleicht Pointer-lastige Routinen.

[schorsch_76]

Danke für die Denkanstösse ... Ich werd es ausprobieren und dann meld ich mich wieder  

[Besserwessi]

Die pow() funktion ist ausgesprochen langsam. Da Steckt nämlich zumindest in der generischen Form ein Logarithmus drin versteckt: pow(x,y) = exp(x * ln(y)). In wieweit GCC da ggf bei pow( x,2) noch optimiert weiß ich nicht - möglich wäre es jedenfalls im Prinzip.

Die Suche muss man nun wirklich nicht mit Fließkomma Zahlen machen - pow erübrigt sich dann. Bei Float sollte auch fabs() deutlich schneller sein als das Quadrat (auch als x*x geschrieben), abs() für integer sowieso.

Peter(TOO) hat auch schon den richtigen Weg, ganz ohne pow() oder ähnliches angeben. Wenn man es noch schneller haben will, könnte man ggf. äquidistante Stützstellen (bevorzugter Abstand eine Potenz von 2) verwenden (ggf. auch ein paar mehr wenn man mag) - dann wird die Berechnung noch einfacher, weil das suchen und ggf. die Division wegfällt und man kommt ggf. auch ohne Fließkomma aus, wenn man die Temperatur intern etwa in 1/10 Grad handhabt.

Ein ISR im 1 ms Takt, die Widerstände (KTY) in Temperaturen umrechnet ist auch schon suspekt. So schnell ist der Sensor (und auch die Heizung) bei weitem nicht. Für die Heizungsregelung ist eher eine zuverlässige Messung und ggf. gute Auflösung für die Bildung von Ableitungen wichtig - ein Sekundentakt sollte ausreichen. Für eine Unterdrückung von Störungen sollte man eher den Sensor mehrmals über ein Zeitfenster von 20 ms (oder vielfachen davon) auslesen, und die Werte Aufsummieren / mitteln. Damit unterdrückt man recht effektiv 50 Hz und 100 Hz Störungen und bekommt durch Oversampling auch gleich noch etwas mehr Auflösung.

[schorsch_76]

So, nachdem ich gejoggt habe, gemütlich gebadet habe und der Kopf dadurch "freigeblassen" habe, habe ich eine Lösung gefunden. Jetzt bin ich bei 240µs anstatt 2.4 ms und habe auch noch knapp 400 Byte an Flash gespart, da kein abs und pow mehr gelinkt werden muss. Auch denke ich, das der Code einfacher ist. Wieviel der "einfachere" Code, oder besser kleinere Kode ausmacht, und wieviel abs, hab ich nicht gemessen.

 

Peters Hinweis hat mich in die richtige Richtung gelenkt. Es muss die Anzahl der Vergleiche und Abfragen reduziert werden. Wie hab ich das jetzt gemacht? Ich habe mich an qsort und co. erinnert. Binäre Suche [1]. Jetzt brauche ich nur noch log(n)/log(2) Anfragen. Entsprechend weniger memcpy_P und kein abs/pow mehr. Bei meinem 22 Samples brauche ich also nur noch 4.45 Abfragen. Sprich entweder 4 oder 5. Je nach dem wo der Eintrag liegt. Vorher war die Laufzeit O(n) anstatt O(log n).

Hier der Code:

118     // binary search without recursion
119     unsigned char st = 0;
120     unsigned char en;
121     unsigned char m;
122     switch (s)
123     {
124     case kt81_210: en = sizeof(t_kt81_210)/sizeof(sensorvalues_flash)-2; break; // -2: because start = 0 and endline is a 0/0 which we dont need
125     case kt81_110: en = sizeof(t_kt81_110)/sizeof(sensorvalues_flash)-2; break;
126     default:
127         return 0.0;
128     }
129 
130     sensorvalues_flash tmp;
131     while (en-st>1)
132     {
133         m = st + (en-st)/2;
134         memcpy_P(&tmp, &current[m], sizeof(sensorvalues_flash));    t1 = tmp;
135         if (r > t1.r) // if we use at sometime a NTC, we need to adjust this
136         {
137             // right side
138             st = m;
139         }
140         else
141         {
142             // left side
143             en = m;
144         }
145     }
146 
147     // read the best matching lines
148     memcpy_P(&tmp, &current[st+0], sizeof(sensorvalues_flash));    t1 = tmp;
149     memcpy_P(&tmp, &current[st+1], sizeof(sensorvalues_flash));    t2 = tmp;
150 
151     // interpolate
152     float dr = t2.r-t1.r;
153 
154     float f = (r-t1.r)/dr;
155     return t1.t+(t2.t-t1.t)*f;

Nochmals danke für den "Stuppser"  

@Besserwessi: Klar, ich habe eine Scheduler drin, der die Takte verteilt. Erst lauft die Konvertierung über den SPI (in mehreren Zyklen), dann die Umwandlung im letzten. Hier wird diese Funktion aufgerufen.

[1] http://de.wikipedia.org/wiki/Bin%C3%A4re_Suche