I2C TWI BMP180 C#

[Holzmade (Gast)]

Hallo liebe pure C# Programmierer,
ich habe von meiner Techniker Schule die Vorgabe in C# ein Projekt zu 
machen.
Dieser Code wollte ich mit euch teilen und ein Problem von der Rechnung 
der Temperatur und Luftdruck besprechen.
Die Rechnung habe ich aus dem Datenblatt genommen und abgetippt.
Jedoch kommen noch die richtigen Werte raus.
Darum kümmere ich mich noch.
Trotzdem würde ich mich über Verbesserungsvorschläge freuen.

Vielen Dank
Eure Made

[Holzmade (Gast)]

Der Rechnungsteil um den es geht:

int32_t BMP_180_Temperatur_Rechnen(int32_t UT, uint16_t AC5, uint16_t AC6, int16_t MC, int16_t MD)
// Rechnet Temperatur aus
// Eingabeparameter:            UT, AC5, AC6, MC, MD
// Rückgabewert:                T  
{
  int64_t X1, X2, B5, t;
  int32_t  T;
  X1 = (((UT - AC6) * AC5) / 32768);
  X2 = ((MC * 2048) / (X1 + MD));
  B5 = (X1 + X2);
  t = ((B5 + 8) / 16);
  T=t;
  return T;   // Temperatur in 0,1°C
}

int32_t BMP_180_Luftdruck_Rechnen(int32_t UP, int32_t UT ,int16_t AC1, int16_t AC2, int16_t AC3,uint16_t AC4, uint16_t AC5,uint16_t AC6, int16_t B1, int16_t B2, int16_t MB, int16_t MC, int16_t MD)
// Rechnet Temperatur aus
// Eingabeparameter:            UT, AC5, AC6, MC, MD
// Rückgabewert:                T  
{
  int64_t B5, B6, X1, X2, X3, B3, p;
  uint32_t B4, B7;
  X1 = ((UT - AC6) * AC5) >> 15;// / 32768;
  X2 = MC * 2048 / (X1 + MD);
  B5 = X1 + X2;

  B6 = B5 - 4000;
  X1 = (B2 * ((B6 * B6) / 4096)) / 2048;
  X2 = (AC2 * B6) / 2048;
  X3 = X1 + X2;
  B3 = (((AC1 * 4 + X3)<<oss)+2)/4;

  X1 = (AC3 * B6) / 8192;
  X2 = (B1 * (B6 * B6 / 4096)) / 65536;
  X3 = ((X1 + X2) + 2) / 4;
  B4 = AC4 * (X3 + 32768) / 32768;
  B7 = (UP - B3) * (50000 >> oss);
  if (B7 < 0x80000000)
  {
    p = (B7 * 2) / B4;
  }
  else
  {
    p = (B7 / B4) * 2;
  }
  X1 = (p / 256) * (p / 256);
  X1 = (X1 * 3038) / 65536;
  X2 = (-7357 * p) / 65536;
  p = p + (X1 + X2 + 3791) / 16;

  return p;   // Luftdruck in Pa
}

[Nils L. (Firma: Trier) (holzmade)]

Da dieses Projekt noch nicht fertig ist wäre es nett wenn der Code nicht 
ohne nachfragen bis August 2021 weiterveröffentlicht wird.
Ab dann ist dieser Code ganz Open Source ;)

Copyright by Holzmade

[nicht"Gast" (Gast)]

Moin,


1. Das ist kein C#. Das ist einfach nur C.

2. Du solltest Variablen ordentlich benennen. Z.Bsp. X2 als Name geht 
einfach gar nicht. Wer soll denn da durchblicken.

3. Du hast ein haufen Wiederholungen drinnen. Du solltest mal 
nachforschen, wie das besser geht.

4. Die BMP_180_EPromData_Lesen() hat viel zu viele Parameter. Die 
solltest du einkürzen.

5. Warum gibt die BMP_180_EPromData_Lesen() Daten auf der Seriellen aus. 
Das gehört da nicht rein. Mach am besten eine getrennte Funktion dafür.

6. Warum sollte jemand so was veröffentlichen wollen. Damit schädigt man 
nur seiner Reputation :)

Das ist nur ein paar Sachen, die mir auf die schnelle Aufgefallen sind.

Grüße

[donvido (Gast)]

nicht"Gast" schrieb:
> 2. Du solltest Variablen ordentlich benennen. Z.Bsp. X2 als Name geht
> einfach gar nicht. Wer soll denn da durchblicken.

Macht eher keinen Sinn, weil das fast eins zu eins der Code von Bosch 
ist (siehe Datenblatt). Da wirds eher unübersichtlicher, wenn du dir 
noch eigene Namen einfallen lässt.

[nicht"Gast" (Gast)]

donvido schrieb:
> Macht eher keinen Sinn, weil das fast eins zu eins der Code von Bosch
> ist (siehe Datenblatt). Da wirds eher unübersichtlicher, wenn du dir
> noch eigene Namen einfallen lässt.

Öhm, nö

Nur weil das Datenblatt ebenso kacke ist, heißt es ja nicht, das der 
Code auch so schlimm sein muss. Zumal der geneigte Leser ja gewöhnlich 
nicht das Datenblatt zur Hand hat bzw es beim Lesen vom Code nicht 
brauchen sollte.

Außerdem scheinst du die Fomeln selber nicht zu verstehen. Sonst würde 
es dir keine Schwierigkeiten bereiten vernünftige Namen zu vergeben.

Grüße

[donvido (Gast)]

nicht"Gast" schrieb:
> scheinst du die Fomeln selber nicht zu verstehen

Aber du hast sie verstanden ja?
Dann lass uns bitte teilhaben an deinem Wissen über die 
Berechnungsformeln.

[nicht"Gast" (Gast)]

donvido schrieb:
> Aber du hast sie verstanden ja?
> Dann lass uns bitte teilhaben an deinem Wissen über die
> Berechnungsformeln.

Hab mir nicht die Mühe gemacht mich da durchzufriemeln. Wozu auch? 
Übrigens kannst du dir unnütze Angriffe auf meine Person sparen.

[Max M. (maxmicr)]

nicht"Gast" schrieb:
> Hab mir nicht die Mühe gemacht mich da durchzufriemeln. Wozu auch?
> Übrigens kannst du dir unnütze Angriffe auf meine Person sparen.

Es macht einfach keinen Sinn sich neue Variablennamen auszudenken wenn 
der Hintergrund eine komplexe Formel aus dem Datenblatt ist.

[Peter D. (peda)]

Der Code ist grauenhaft. Da sind haufenweise Codewiederholungen drin, 
das macht es unnötig unleserlich.
Z.B. aus

    while (bit_is_clear(UCSR0A,5)) {}         // UCSR0A warten bis gesendet wurde
    UDR0 = 48;                                // UDR0 Zahl senden

usw. macht man eine Unterfunktion:

void uputchar(char c)
  while (bit_is_clear(UCSR0A,5));
  UDR0 = c;
}
// ...
uputchar('0');

Dann kann man auch später ganz einfach die Ausgabe auf UART mit 
Interrupt und FIFO verbessern oder auf ein LCD umleiten.

Ebenso diese Wiederholungen:

        *AC1 = (TWIM_ReadAck () << 8);
        *AC1 += TWIM_ReadAck ();
    UART_Sende_Zahl(*AC1);
    UART_Sende_Tab();

Das kann man auch sehr schön modularisieren:

uint16_t read_twi_u16(void)
{
  uint16_t val = TWIM_ReadAck() << 8;
  return val | TWIM_ReadAck();
}

void usend_val_tab(unit16_t val)
{
  char buf[10];
  sprintf(buf, "%u\t", val);
  uputs(buf);
}
//..
  usend_val_tab(*AC1 = read_twi_u16());
  usend_val_tab(*AC2 = read_twi_u16());
// usw.

Vorzugsweise macht man aus allen ähnlichen Sequenzen, die >=2 mal 
auftreten, eine Unterfunktion.
Code sollte immer so kompakt wie möglich sein. Niemand möchte ähnliche 
Sequenzen wieder und immer wieder lesen müssen. Das erschwert nur das 
Verstehen der eigentlichen Funktion.

Und warum machst Du die Zahlenausgabe zu Fuß und nimmst nicht sprintf()?

[nicht"Gast" (Gast)]

Max M. schrieb:
> Es macht einfach keinen Sinn sich neue Variablennamen auszudenken wenn
> der Hintergrund eine komplexe Formel aus dem Datenblatt ist.

Mittlerweile habe ich mir auch mal aus Neugier das komplette Datenblatt 
angeschaut.

So einen Mist hab ich schon lange nicht mehr als Datenblatt gesehen. 
Keine Erklärungen, die Kalibrierwerte nur als Kürzel. Die Formeln nicht 
erklärt und mit Magic Numbers versehen.

Da kann ich verstehen, dass der TE das einfach kopiert hat.

[Cyblord -. (cyblord)]

nicht"Gast" schrieb:
> So einen Mist hab ich schon lange nicht mehr als Datenblatt gesehen.
> Keine Erklärungen, die Kalibrierwerte nur als Kürzel. Die Formeln nicht
> erklärt und mit Magic Numbers versehen.

Das ist eine Formel welche die Kalibrierwerte nutzt um echte Daten aus 
dem Sensor zu erhalten. Um die Formel zu verstehen müsste man also die 
internas des Sensors kennen.

> Da kann ich verstehen, dass der TE das einfach kopiert hat.

Die Formel selbst soll man ja auch einfach kopieren, man muss die aber 
halt schon auf seine Programmiersprache anpassen. Und die muss man dafür 
halt kennen. Nicht den Sinn der Formel.

[nicht"Gast" (Gast)]

Cyblord -. schrieb:
> Das ist eine Formel welche die Kalibrierwerte nutzt um echte Daten aus
> dem Sensor zu erhalten. Um die Formel zu verstehen müsste man also die
> internas des Sensors kennen.


Na ja, aber die Kalibrierwerte einem so hinzurotzen ist schon ziemlich 
mies. Wenn man die Namen vernünftig gewählt hätte und den Magic Numbers 
auch aussagekräftige Namen gegeben hätte und noch ein paar Kommentare 
zur Berechnung hinterlassen hätte, wäre schon viel erreicht. So ist das 
einfach nur Faul vom Dokumenteur.

(ganz schön viele 'hätte' im Text).

Ändert nicht viel dran, dass das Datenblatt Rotz ist und ein Beispiel, 
wie man es nicht machen sollte. Andere Hersteller bekommen das deutlich 
besser hin.

[nicht"Gast" (Gast)]

Nachtrag.

Eine vernünftige Vorgehensweise wäre natürlich gewesen, die Kalibrierung 
intern zu machen. Einen Prozessor haben die ja sicherlich eh schon 
drauf, nachdem die ja ADC und I2C und Eeprom drauf haben.

Aber das ist eine andere Diskussion und auch nicht Zielführend.

[donvido (Gast)]

nicht"Gast" schrieb:
> Wenn man die Namen vernünftig gewählt hätte und den Magic Numbers
> auch aussagekräftige Namen gegeben hätte und noch ein paar Kommentare
> zur Berechnung hinterlassen hätte, wäre schon viel erreicht. So ist das
> einfach nur Faul vom Dokumenteur.

Wenns nun aber einfach nur Koeffizienten eines Polynoms sind um die 
Nichtlinearität des Sensors zu kompensieren, dann kann man halt entweder 
kurze Bezeichner dafür verwenden, oder die Formel über 3 Seiten 
vollkommen unübersichtlich präsentieren.
In der Schule wird doch in der Regel auch nur mit einzelnen Buchstaben 
gerechnet und nicht mit ganzen Wörtern ;).

[Peter D. (peda)]

Der BMP180 ist EOL, Nachfolger ist der BMP280. In dessen Datenblatt ist 
auch C-Code drin.

https://www.bosch-sensortec.com/media/boschsensortec/downloads/environmental_sensors_2/pressure_sensors_1/bmp280/bst-bmp280-ds001.pdf

[Nils L. (Firma: Trier) (holzmade)]

Danke für all die Antworten.

Ich muss mich für meine Programmierung entschuldigen.
Außerdem habe ich eine neue Version, welche das Datentypenproblem löst.
Nicht schön aber funktioniert.

Kommentare kommen erst am Ende bei Abgabe des Projekt.

Vielen Dank für die Info mit dem Datenblatt vom BMP280.
Werde ich mir dann mal durchlesen.

Druck und Temperatur bekomme ich raus (sind geprüft).
Aber die Höhe kann ich so nicht berechnen:

/*
  pi = p;
  H = 44330.0*(1.0-(pi/101325.0)^(1.0/5.255));
  Hi = H*1000;
  char AUSGABE_H[] = "Hoehe :";
  UART_Sende_Text (AUSGABE_H);
  UART_Sende_Tab();
  UART_Sende_Zahl(H);
*/

Hoch Float-Typen kann C nicht.
Also auch keine x-te Wurzeln.
Es gibt zwar Bibliotheken und Algorithmen aber das Problem wollte ich 
simpel lösen.


Ich bin Anfänger im Programmieren also verzeiht mir meine Fehler aber 
weist mich auch bitte darauf hin.

Vielen Dank
Holzmade

[Patrick (Gast)]

Der ^ Operator ist in C, C++ und C# der bitweise XOR Operator, also 
macht er nicht das was du erwartest.
Nachdem du die avr-libc verwendest, brauchst du nur math.h inkludieren 
und dann die Funktion pow() nutzen. Das ist der einfachste Weg. Da 
potenzieren für eine CPU/Microkontroller nicht wirkloch so einfach ist 
(schon gar nicht bei floats) gibt es dafür kein Sprachfeature, sondern 
nur plattformabhängige Implementierungen als Funktion.

Und warum schreibst du C++ code, wenn dein Projekt C# sein soll?

[Patrick (Gast)]

Und noch ein par Verbesserungen:
1.) Inkludiere cstdint für uint8_t und co., dass es so funktioniert ist 
Glück
2.) Mach alle Variablen, die sich nie ändern, und beim Compilieren schon 
einen bekannten Inhalt haben constexpr, dann kann der Compiler besser 
optimieren. Das sind bei dir alle globalen Variablen. Wenn du aus 
welchen Gründen auch immer einen C-Compiler (dann passt der Dateiname 
mit *.cpp aber nicht) oder eine C++ Version die älter als C++14 
verwendest, funktioniert das nicht, und du solltest sie zumindest const 
machen.

[Markus F. (mfro)]

Ich habe das jetzt nicht im Detail angeschaut, aber BOSCH Sensortec hat 
einen öffentlichen github-Account und dort auch ein Treiber-API für den 
BMP180 veröffentlicht:

https://github.com/BoschSensortec/BMP180_driver

Bevor Du dir also ein Bein rausreisst, solltest Du vielleicht lieber mal 
dort reinschauen.

[Wolfgang (Gast)]

nicht"Gast" schrieb:
> 2. Du solltest Variablen ordentlich benennen. Z.Bsp. X2 als Name geht
> einfach gar nicht. Wer soll denn da durchblicken.

Soll die Variable vielleicht besser 
int64_Zwischenwert_BoschAlgorithmus_Berechnung_Luftdruck_X2 heißen?

Da es sich um lokale Variablen in der Umrechnungsroutine handelt, ist es 
doch völlig in Ordnung, die Namen aus dem Algorithmus genau wie im 
Datenblatt zu verwenden.

[Roland F. (rhf)]

Hallo,
Patrick schrieb:
> Nachdem du die avr-libc verwendest, brauchst du nur math.h inkludieren
> und dann die Funktion pow() nutzen.

In C# wäre das dann Math.Pow(x,y).

rhf

[Nils L. (Firma: Trier) (holzmade)]

Hallo

Danke für die Hilfe mit dem Höhenproblem.
Ich habe mir die Funktionen der math.h angeschaut aber habe keine 
Funktion gefunden um eine x-te Wurzel zu ziehen.
Wenn ^ die XOR Funktion ist muss ich diese Berechnung outsourcen.
Könnte das mit einem Raspi als Display verbinden.
Dann kann ich die Umrechnung in Python schreiben.
Die Funktion dort habe ich mir schon angeschaut.

Ich habe zur Höhenberechnung 2 Formeln gefunden.
Die Internationale Höhenformel (Problem: 5,255te-Wurzel ziehen)
Die Barometrische Höhenformel (ungenauer und e^x Funktion)

Was ist außerdem cstdint?
Eine Bibliothek?

Vielen Dank
Ihr helft neuen Programmierern sehr :)

[nicht"Gast" (Gast)]

Kleiner Tip für beliebige Wurzeln mit pow

$$\sqrt[y]{x}= x^{1\over{y}}$$

[Patrick (Gast)]

Nils L. schrieb:
> Was ist außerdem cstdint?
> Eine Bibliothek?

Ein Teil der C++ Standardbibliothek