-         

Ergebnis 1 bis 8 von 8

Thema: Effizienter Rechnen?

  1. #1
    Moderator Roboter Genie
    Registriert seit
    26.08.2004
    Beiträge
    1.228

    Effizienter Rechnen?

    Anzeige

    Hi!
    Ich habe das Problem, dass zwei neue Sensoren von meinem Mega8 so einiges an Rechenleistung bzw. Speicherplatz abverlangen.
    Es handelt sich hier um einen Lufttemperatur und -druck Sensor und einen Luftfeuchte Sensor.

    Beim Druck/Temperatur Sensor müssen aus einem integrierten ROM elf Variablen ausgelesen werden und die eigentlichen Werte damit verrechnet werden.

    Code:
    'Dim C(7) As Word, A(4) As Byte, Vas(3) As Single, Var(1) As Word, D2cs As Long
    
    Function Dut(byval D2 As Word)        'As Integer
    
       D2c5 = D2 - C(5)
       Vas(1) = D2c5 * D2c5
       Vas(2) = Vas(1) / 16384
       Var(1) = 2 ^ A(3)
    
       If D2 < C(5) Then                                        
          Vas(2) = Vas(2) * A(2)
          Vas(2) = Vas(2) / Var(1)
          Vas(2) = D2c5 - Vas(2)
          Dut = Vas(2)
       Elseif D2 >= C(5) Then
          Vas(2) = Vas(2) * A(1)
          Vas(2) = Vas(2) / Var(1)
          Vas(2) = D2c5 - Vas(2)
          Dut = Vas(2)
       End If
    
    End Function
    
    Function Dbr(byval D1 As Word , Dutb As Integer)     'As Word
    
       Local Offset As Integer
       Local Sens As Integer
       Local Xb As Integer
    
       Var(1) = C(4) - 1024
       Vas(1) = Var(1) * Dutb
       Vas(1) = Vas(1) / 16384
       Vas(1) = Vas(1) + C(2)
       Vas(1) = Vas(1) * 4
       Offset = Vas(1)
    
       Vas(1) = C(3) * Dutb
       Vas(1) = Vas(1) / 1024
       Vas(1) = Vas(1) + C(1)
       Sens = Vas(1)
    
       Vas(1) = D1 - 7168
       Vas(1) = Vas(1) / 16384
       Vas(1) = Sens * Vas(1)
       Vas(1) = Vas(1) - Offset
       Xb = Vas(1)
    
       Vas(1) = Xb * 10
       Vas(1) = Vas(1) / 32
       Vas(1) = Vas(1) + C(7)
       Dbr = Vas(1)
    
    End Function
    
    Function Tbr(dutb As Integer)        'As Integer
    
       Vas(1) = Dutb * C(6)
       Vas(1) = Vas(1) / 65535
       Vas(2) = 2 ^ A(4)
       Vas(2) = Dutb / Vas(2)
       Vas(3) = Vas(1) - Vas(2)
       Vas(3) = 250 + Vas(3)
       Tbr = Vas(3)
    
    End Function
    Diese drei Funktionen brauchen bestimmt 40-50% vom Flash des Mega8 und die Berechnung dauert auch ne ganze Weile. Da ich gerne noch ein paar andere Sensoren und eine Funkübertragung einbauen wollte, brauche ich mehr Platz.
    Wie kann ich also am besten die Rechnungen umstellen, verändern, durch andere Rechenoperationen schlanker gestalten? Sind Local-Variablen hier besser geeignet als "Globale"?

    Danke!
    Basti

  2. #2
    Benutzer Stammmitglied Avatar von Johnes
    Registriert seit
    07.12.2007
    Ort
    Neu Wu
    Beiträge
    44
    Ist ja schön und gut, wenn du die Werte jedesmal auf dem Chip ausliest, aber warum?

    Die Werte sind doch fest ins ROM gebrannt! Da reicht es diese einmal zu lesen und dann die Kompensation extern (von Hand mit dem Taschenrechner, etc.) zu errechnen und dann als Festwert ins Flash zu schreiben. Da braucht der Atmel die Werte dann nicht mehr errechnen!

    Nur der Sensorwert der sich ändern KANN muss dann noch mit dem FEST ins ROM gebrennten Wert verrechnet werden.

    MfG

  3. #3
    Moderator Roboter Genie
    Registriert seit
    26.08.2004
    Beiträge
    1.228
    Hi!
    Im Prinzip hast du recht, aber der Code soll so Universell wie möglich werden, damit ihn auch andere ohne viel Aufwand Benutzen können.

    Außerdem will ich ja auch noch was dazulernen, damit mein Code im Allgemeinen Effizienter wird.

    Basti

  4. #4
    Erfahrener Benutzer Roboter-Spezialist
    Registriert seit
    16.11.2003
    Beiträge
    355
    das /32 , /1024 und /16384 kann man mit einem shift genauso gut machen, und geht deutlich schneller... Über das /65535 wunder ich mich, das passt nicht ins Schema

    Ich vermute auch mal Array Zugriffe kosten mehr Performance wie normale Variablen?

  5. #5
    Super-Moderator Robotik Visionär Avatar von PicNick
    Registriert seit
    23.11.2004
    Ort
    Wien
    Beiträge
    6.836
    ...Array Zugriffe kosten mehr Performance ...
    Mächtig. besser temporäre variable und dann erst wieder ins Array

    Wenn die Funktionen nicht reentrant sein müssen, dann eher globale Variable statt call-Argumente

    ../32 , /1024 und /16384 kann man mit einem shift
    UNBEDINGT
    mfg robert
    Wer glaubt zu wissen, muß wissen, er glaubt.

  6. #6
    Super-Moderator Robotik Visionär Avatar von PicNick
    Registriert seit
    23.11.2004
    Ort
    Wien
    Beiträge
    6.836
    Weitergesponnen, weil jede Rechnung zählt
    Code:
    Das da, z.b.
       Var(1) = C(4) - 1024 
       Vas(1) = Var(1) * Dutb 
       Vas(1) = Vas(1) / 16384 
       Vas(1) = Vas(1) + C(2) 
       Vas(1) = Vas(1) * 4 
    
    Ist doch eigentlich :
       Vas(1) = ( (C(4) - 1024 ) * Dutb /  16384   + C(2) ) * 4
    
    Aufgedröselt:
       C(4)  * Dutb * (4 / 16384)  - Dutb * (1024 * 4  / 16384)   +  C(2) * 4
    
    Sowas:
    
    (4 / 16384) 
    (1024 * 4  / 16384) 
    
    kannst du schon beim kompilieren ausrechnen lassen 
    
    const factor = (1024 * 4  / 16384)
    OHNE GEWÄHR


    PS: und möglichst wenig typenumwandlungen (long->single etc)
    also eher alles gleich
    mfg robert
    Wer glaubt zu wissen, muß wissen, er glaubt.

  7. #7
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    26.05.2007
    Beiträge
    594
    Man kann in Bascom auch Konstanten mit Produkten anderer Konstanten festlegen. Die werden dann beim Compilen errechnet und entsprechend gespeichert.
    CONST A = B / C
    Wobei B/C auch Konstanten sind!

  8. #8
    Super-Moderator Robotik Visionär Avatar von PicNick
    Registriert seit
    23.11.2004
    Ort
    Wien
    Beiträge
    6.836
    äääh: Vorsicht ! bei singles und anderen float-Formaten geht das mit dem Shiften NICHT (so einfach) !
    mfg robert
    Wer glaubt zu wissen, muß wissen, er glaubt.

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •