Double Variablen nutzen

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • Double Variablen nutzen

      Guten Morgen liebes Forum,

      ich suche (und finde keine) Infos, wie man mit Double-Format rechnen kann.
      Das Problem ist, das ich für den Bosch-Luftsensor BME680 die Kalibrierung der Luftdruckwerte nicht hinbekommen, weil als Format für eine der Berechnungen (scheinbar) Double gebraucht wird.
      Die Kalibrierwerte sind rechnen im "Milliardenbereich".
      In der Hilfe steht zu Double eigentlich gar nichts, es gibt eine double.lbx. Kann man in Bascom denn überhaupt mit Double rechnen, ohne Klimmzüge machen zu müssen?
      In einem anderen Code habe ich mal gesehen, dass man niederwertige Typen zunächst über single wandeln muss, und von Single zu Double, obwohl mir das jetzt nicht ganz klar ist, warum.
      Denn wo ist das Problem, eine "kleine" Zahl in einen "großen" Zahlenraum zu schreiben....auch wenn die kleinere Zahl vorzeichenbehaftet ist, das passt ja trotzdem ins Double-format, das MSB muss eben nur nach vorn geschoben werden im Compiler.

      The post was edited 2 times, last by Peer Gehrmann ().

    • ach ne...somit kann ich in Bascom quasi gar nicht mit verschiedenen Typen rechnen?
      Gilt das auch für Rechnungen mit verschiedenen Typen, also ohne Funktion?
      Und gibt es Regeln, was mit welchem Typ wie zu verrechnen ist? Oder Konvertierungskommandos?
      Diese Formel von Bosch für den BME680 benötigt verschiedene Typen bzw. nutzt Casting in C im Beispiel.
      Das würde einiges erklären, also warum ich die Kalibrierungen nicht hinbekomme und nur dämliche Werte dabei herauskommen...
    • Peer Gehrmann wrote:

      Gilt das auch für Rechnungen mit verschiedenen Typen, also ohne Funktion?
      Sicher, die Funkton lagert nur eine Teil in den Stack aus die Operationen bleiben.
      Sie ist ein Kompromiss zwischen sparsamen Ressourcenverbrauch und viel zu können.
      Ein Beispiel ist die String Konvertierung. Dort hat man sich für die große Version entschieden. Braucht man die nur für Integer und Byte gibt dafür eine lib die erheblich Flash und Tausende Takte spart.
      Bei einigen Berechnungen ist es nicht die "große" damit z.B. ein tiny nicht mit wenigen Operationen Fashende hat. Das ganze läßt sich recht gut im Simulator erkennen. Da wäre es vielleicht wirklich schön wenn das in der Hilfe stände bevor man den Fehler suchen muß. Oder der Compiler würde entscheiden : Der braucht die "De Lux" (oder die Sparversion)
    • Peer Gehrmann wrote:

      ach ne...somit kann ich in Bascom quasi gar nicht mit verschiedenen Typen rechnen?
      Natürlich kannst in Bascom mit verschiedenen Typen rechnen. Was nicht geht ist dieses temporäre Casten, wie du das in C machen kannst.
      In Datenblatt sehe ich für die verschiedenen Werte immer zwei Berechnungen, eine mit Floating Point und eine mit Integer. Wenn du die Floating Point Version nehmen willst, dann dimensioniere die beteiligten Variable als Double und rechne mit denen.
      Das einzige, was der Compiler häufig nicht mag ist die Verwendung von verschiedenen Typen direkt in einer Rechnung. Für die Temperatur z.B. steht im DB

      var1 = (((double)temp_adc / 16384.0) - ((double)par_t1 / 1024.0)) * (double)par_t2
      die Double stehen da immer, weil temp_adc usw wahrscheinlich kein Double ist, sondern wohl Integer Werte.
      Wenn du jetzt so schreibst
      Dim var1 as Double
      Dim temp_adc as Integer
      temp_adc=29465
      dann akzeptiert der Compiler dies nicht:
      var1 = temp_adc / 16384
      Stattdessen erst einmel die Typkonvertierung machen und dann rechnen
      var1 = temp_adc
      var1 = var1 / 16384
      und entsprechend für die anderen Berechnungen, für die du dann auch noch temporäre Zwischenwerte brauchst.
    • Hi Leute,

      vielen Dank für die vielen Inputs.

      Soweit ist jetzt auch alles klar.
      In der Umsetzung muss ich halt höllisch aufpassen, dass ich bei Zuweisung von z.B. einem Byte zu einem Long die Long vorher lösche.
      Ich verwende nämlich hier ein paar "Universalvariablen", die ich im Programmkopf global definiere, nutze die also mehrfach bei der Auslesung.
      Oder ich verfrachte die Routine in eine Funktion mit loklen Variablen.
      Da die Korrekturbytes/Words des BME680 dann diesen Vars zugeordnet werden, könnte es sein, dass die von einer vorherigen Berechnung noch Werte enthalten, die im nächstgrößeren Zahlenraum lagen.

      Ich hatte das Problem zwar schon insgesamt erkannt, aber noch nicht korrekt im Code beachtet. Genau aus den oben genannten Gründen, eben dass ein Byte nur die unteren 8 Bit einer z.B. Long überschreibt.

      @Franz: Das mit den Double-Berechnungen ist dann halt die Alternative. Aber ich habe nun alles für die Integer-Berechnung programmiert, das war schon ein Stück Arbeit mit dem ganzen geschifte und Klammern auflösen.
      Wenn ich am Ende einfach zu blöd dazu bin, mache ich das mit den Double-Berechnungen.

      Viele Grüße
      Peer
    • Hast Du da ein Beispiel?
      Ist es nicht einer der Vorzüge von Bascom deutlich zu sein und nicht >>%&/$==<-< schreiben zu müssen um "was auch immer" zu bewirken?
      PS Bei mir löscht das Byte das Long (die oberen drei Bytes) bei der Zuweisung. Da wäre auch gut zu wissen wann das schief läuft.
    • Hier geht's bei der Zuweisung an L schief, weil gleichzeitig gerechnet und gecastet wird:

      BASCOM Source Code

      1. $regfile = "m1284pdef.dat"
      2. $crystal = 20000000
      3. $hwstack = 200
      4. $swstack = 200
      5. $framesize = 200
      6. Declare Function Test(byval Bb As Byte) As Byte
      7. Dim L As Long
      8. Dim B As Byte
      9. L = 1234567890
      10. B = 123
      11. L = Test(b)
      12. End
      13. Function Test(byval Bb As Byte) As Byte
      14. Test = Bb
      15. End Function
      Display All
    • Funtionen casten den Rüchgabewert nicht auf die zugewiesene Variable.
      Heißt, wenn eine Funktion als Rückgabewert ein Byte definiert hat, wird auch nur ein Byte in die zuweisung geschrieben.

      BASCOM Source Code

      1. dim tmpByte as Byte
      2. dim tmpInt as Integer
      3. dim tmpLng as Long
      4. tmpByte = &hFF
      5. tmpInt = -1
      6. tmpLng = -1
      7. Do
      8. tmpByte = FByte(20 , 50)
      9. tmpInt = FByte(20 , 50)
      10. tmpLng = FByte(20 , 50)
      11. Loop
      Display All

      Wenn man das im Simulator durchsteppt, erkennt man das, wenn man die Locals Variablen anschaut.

      Umgekehrt, wenn man eine Function mit Integer als Rückgabewert hat und weist die einem Byte zu, dann werden 2 Byte geschrieben.
      Kann man am eingeblendeten SRAM sehen. Beschrieben wird das Byte und das Folgebyte.

      Mir sagt das, dass intern nur ein Zeiger an die Funtion übergeben wird, wo die Variable steht, in die das Ergebnis soll.
      Anhand des Rückgabe-Werts der Funktion werden die Anzahl Bytes ab dieser Adresse geschrieben.

      BASCOM Source Code

      1. Function FByte(Byval a as Byte , Byval b as Byte) as Byte
      2. FByte = a + b
      3. End Function
      4. Function FInt(Byval a as Byte , Byval b as Byte) as Integer
      5. FInt = a + b
      6. End Function
      7. dim tmpByte as Byte
      8. dim tmpInt as Integer
      9. dim tmpLng as Long
      10. tmpByte = &hFF
      11. tmpInt = -1
      12. tmpLng = -1
      13. Do
      14. 'tmpByte = FByte(20 , 50)
      15. 'tmpInt = FByte(20 , 50)
      16. 'tmpLng = FByte(20 , 50)
      17. tmpByte = FInt(20 , 70) ' Integer als Rückgabewert
      18. Loop
      Display All

      The post was edited 1 time, last by Mitch64 ().