BME280 Sensor - Code für ATmega328 in C

Den Sourcecode könntest Du auch in Form einzelner Dateien anhängen, dann kann man die foreneigene Funktion zum Quelltextangucken verwenden. Mit Syntaxhighlighting.

Ich hab' mir die Freiheit genommen, das mal mit Deiner bme280.c zu machen.

Und dann kann man nämlich so fiese Fragen stellen wie:

1

l_ReadStatus:

2

  BME280_ReadRegisters (BME280_STATUS_ADDR, 1, &iStatus);

3

  if ((iStatus & 0x01) != 0)

4

    {

5

    Delay_ms (10);

6

    goto l_ReadStatus;

7

    }

Warum ausgerechnet mit goto? Kennt Dein C-Compiler kein do/while?

Das goto ist nicht schön. Funktioniert wenigstens. Das Delay_ms(10) finde ich viel unschöner.

@ Harald K.

Ich hasse es, mir den Quellcode im Browser anzusehen! Ich packe ihn lieber gleich ins Atmel Studio, da kann man gleich sehen, was falsch ist. Ansonsten ist die foreneigene Funktion schon sehr hilfreich - Danke dafür.

Ich muss den Compiler erst noch mal fragen, ob er do/while kennt :-) Ja - Du hast ja so recht, aber die do/while Anweisung ist in den alten grauen Zellen irgendwie verschütt gegangen.

@ N.M. (Mani)

Wieso soll das Delay_ms(10) unschön sein? Das Datenblatt sagt ausdrücklich, dass man auf das 0x01 Bit warten muss, bis es 0 wird. Unschön ist nur, dass ich kein Timeout eingebaut habe, der den Controller im Fehlerfall des Sensors im Endlos-Loop laufen lassen wird. Werde ich noch einbauen!

Manfred L. schrieb:

Wieso soll das Delay_ms(10) unschön sein?

Weil es unnötig ist. Jede vernünftige Library macht das Warten über einen zusätzlichen State in einer Statemachine. Wenn das Mal ein paar us sind, OK. Kann man drüber diskutieren. Aber 10ms ist ne halbe Ewigkeit in der durch das delay nichts mehr anderes gemacht werden kann. Wenn das mehrere Programmteile so machen geht am Schluss garnichts mehr.

Manfred L. schrieb:

Wieso soll das Delay_ms(10) unschön sein?

Weil es die CPU für 100.000 Takte bei 10 MHz lahmlegt, was sehr unvorteilhaft ist, wenn sie auch noch andere Dinge "parallel" zum Sensor-Auslesen tun soll, was ja nicht so ganz unwahrscheinlich ist.

Für solche in bestimmten Zeitabständen regelmäßig wiederkehrenden Aufgaben verwendet man einen Timer-Interrupt, den man gern auch als Trigger für verschiedene Aufgaben mehrfach benutzt (ggf. über Variablen hochzählen zur Erzeugung unterschiedlicher Wartezeiten).

Manfred L. schrieb:

Ich hasse es, mir den Quellcode im Browser anzusehen! Ich packe ihn lieber gleich ins Atmel Studio, da kann man gleich sehen, was falsch ist.

Nun, eine zunehmende Anzahl der Forennutzer nutzt das Forum unterwegs auf ihrem Smartphone -- da gibts kein Atmel Studio.

Und da so ein in C geschriebener "Treiber" auch für andere Microcontroller interessant sein könnte, denke ich mir, daß auch andere sich den Kram ansehen wollen, ohne ihn eigens herunterladen, irgendwohin auspacken und mit der IDE ihrer Wahl ansehen möchten.

Bei batteriebetrieben Anwendungen ist so ein delay, was mit 100% CPU-Stromverbrauch Däumchen dreht, immer ungern gesehen. Beim BME noch eher verschmerzbar, der ist (ohne Oversampling) flott. Bei z.B. DS18B20, der sich da mal 750ms genehmigt, unakzeptabel.

Idee: Mach dir eine "weak"-function

1

void BME280_yield(void) __attribute__((weak));

2

void BME280_yield(void) {

3

       Delay_ms(10);

4

}

und verwende die.

Falls jemand auf Kosten des Timings Strom sparen will, kann er einfach eine eigene Variante bereitstellen, die z.B. für x Timer-Ticks in den SLEEP geht.