float-Division

[Denglmann (Gast)]

Hallo Leute!

Habe folgende kleine Funktion geschrieben:

void resistance_calc(uint16_t rise_time, uint16_t fall_time, float cap, uint16_t *resistance) 
{
  const float ln=2.1972246;

  resistance[0]= round((float)rise_time/(cap*0.001*ln));
  resistance[1]= round((float)fall_time/(cap*0.001*ln));
}

Berechne hiermit die Rise- und Fall-Time eines Rechtecksignals, welches 
durch ein RS-Glied gejagt wird.
Mein Problem ist nun, dass die Float-Operationen den Speicherbedarf 
extrem belasten. AVR-Studio zeigt mir für diese kleine Funktion (wenn 
sie in der main mit Parametern ausgeführt wird) eine ca 13%-ige 
Belastung des Programm- als auch des Datenspeichers. Das sind einmal 
4042 Bytes und einaml 264 Bytes. Arbeite mit einem Atmega32. Es liegt 
eindeutig an Floatoperationen, denn sobald ich ganze Zahlen einsetze 
geht die Auslastung auf 0.5% zurück.(Datentypen hierbei auf int gesetzt)

Gaukelt mir das Programm da was vor mit den Speicherangaben oder ist 
solch eine Rechnung wirklch so "umständlich" für den Controller?

Habt ihr vielleicht Verbesserungsvorschläge um den Speicherbedarf zu 
reduzieren? Da soll ja noch wesentlich mehr auf den Controller drauf...

Vielen Dank!!

[Εrnst B. (ernst)]

Denglmann schrieb:
> Gaukelt mir das Programm da was vor mit den Speicherangaben oder ist
> solch eine Rechnung wirklch so "umständlich" für den Controller?

Ja.

> Habt ihr vielleicht Verbesserungsvorschläge um den Speicherbedarf zu
> reduzieren? Da soll ja noch wesentlich mehr auf den Controller drauf...

Festkommaarithmetik verwenden, wenn möglich.

oder hoffen, dass das "wesentlich mehr" dieselben Float-Funktionen 
verwendet, die du eh schon dazugelinkt hast.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Denglmann schrieb:
> Gaukelt mir das Programm da was vor mit den Speicherangaben oder ist
> solch eine Rechnung wirklch so "umständlich" für den Controller?
Willkommen in der Realität:
- Dein uC ist ein 8-Bit-Rechner.
- Eine float-Operation ist eine 32-Bit Operation.
- Eine Division ist prinzipiell aufwendig für einen uC
  (mehr noch, wenn der keine dedizierte Divisions-Einheit hat)
- jede float-Rechnung muß aufwendigst mit Bitschieberei (das kann
  der AVR auch nicht gut), Maskiererei und Elementaroperationen
  nachgebildet werden.

[(prx) A. K. (prx)]

Dann sollte man auch drauf achten, dass man richtig übersetzt, wenn man 
Fliesskommarechnung verwendet. Doku der avrlibc lesen. Ohne -lm frisst 
er weit mehr als mit.