double Ausgabe

[neuer_benutzer55 (Gast)]

Hallo,


bei der Ausgabe der Temperatur eines DS18b20 stehe ich vor der 
Problematik die Nachkommastellen auszugeben, laut diesem Beitrag:
https://stackoverflow.com/questions/37815771/snprintf-not-working-as-expected-with-avr-gcc

Fehlten mir: -Wl,-u,vfprintf -lprintf_flt -lm

diese habe ich hier hinzugefügt:
CFLAGS += -Wl,-u,vfprintf -lprintf_flt -lm

(Die Makefile kommt hier aus dem Forum, minimal verändert)


Hier der Code zur Ausgabe, es wird ein "?" gesendet. USART_end() sendet 
'\r\n'.

        char zeichen[15];
        double myFloat2 = 2.2345;

        sprintf(zeichen, "%.4f", myFloat2);
        for (char *p = zeichen; *p; p++) {
            USART_transmit(*p);
        }
        USART_end();


Der rest vom Code funktioniert, ein USART_transmit('a'); sendet dieses 
ohne Probleme.
Sind die "Linker" Optionen richtig in den CFLAGS?

[Dirk B. (dirkb2)]

Die -l Flags gehören zum Linkern

[Jim M. (turboj)]

Linker Flags sind normalerweise LFLAGS und nicht CFLAGS, aber ich sehe 
ja das Makefile nicht.

[M. K. (sylaina)]

Dieses Gehampel mit der Float/Double-Ausgabe hab ich umgangen indem ich 
die Funktion:

...
#include <stdlib.h>
...
dtostrf(float_variable,
        zahl_aller_stellen_incl_komma,
        zahl_der_nachkommastellen,
        stringvariable);
...

benutze. Vielleicht hilft das dir auch.

[Wolfgang (Gast)]

neuer_benutzer55 schrieb:
> bei der Ausgabe der Temperatur eines DS18b20 stehe ich vor der
> Problematik die Nachkommastellen auszugeben

Mit Float (single Precision) Datenformat hast du 24 Bit für den 
Zahlenwert. Ein DS18B20 liefert dir maximal 12 Bit Auflösung bei einer 
Genauigkeit von 0.5K, i.e. 8 1/2 Bit.

Was versprichst du dir dabei von der Verwendung von Double?

[neuer_benutzer55 (Gast)]

@Dirkb
CFLAGS += -Wl,-u,vfprintf
und:
LDFLAGS += -lprintf_flt -lm

so funktioniert es leider auch nicht :(
makefile: https://bpaste.net/show/WQn0

@Wolfgang
Bisher habe ich diesen Code für die Ausgabe verwendet:

        int temp;
        int temp2;
        temp2 = temp / 16;
        char buf[10];
        itoa(temp2, buf, 10);
       
        for (char *p = buf; *p; p++) {
            USART_transmit(*p);
        }
        USART_end();

Warum durch 16 teilen? Weil dieses Library:
https://github.com/Jacajack/avr-ds18b20/wiki

den Wert mit 16 multipliziert, für eine einfachere Ausgabe weil die 
Werte im Register des Sensors anders liegen sonst.

Durch die Integer Divsion kann natürlich auch nur ein Integer Wert 
angezeigt werden. Darum bin ich auf double / float gekommen.



Zweiter Versuch mit double:

        volatile double db1;
        db1 = temp / 16;
        char buf[20];
        dtostrf(db1, 4, 3, buf);
        for (char *p = buf; *p; p++) {
            USART_transmit(*p);
        }
        USART_end();

Das liefert jetzt 20.000, 21.000 aber nie Werte dazwischen.

Wenn ihr da ein besserers Library habt immer her damit.

[Dirk B. (dirkb2)]

neuer_benutzer55 schrieb:
> CFLAGS += -Wl,-u,vfprintf
> und:
> LDFLAGS += -lprintf_flt -lm

neuer_benutzer55 schrieb:
> CFLAGS += -Wl,-u,vfprintf
> und:
> LDFLAGS += -lprintf_flt -lm
>
> so funktioniert es leider auch nicht :(
> makefile: https://bpaste.net/show/WQn0

Zeile 121 auskommentieren hätte gereicht.

Gefällt dir der Zahlenwert von sprintf nicht, oder kommt nur wirres Zeug 
raus?

[Stefan F. (Gast)]

Der avr-gcc kennt kein double. Wenn du double hin schreibst, nutzt er in 
Wirklichkeit float.

[neuer_benutzer55 (Gast)]

@Dirkb: Ahja, stimmt. 121 ist der passende Ort.

Die Zahlen können von meinem Bluetooth Terminal interpretiert werden und 
passen auch, aber es wundert mich das ich bisher nur 20.000 oder 21.000 
gesehen habe, in den Beispielen im Datenblatt gibt es auch; +25.0625.
Also 4 Nachkommastellen Präzision, da müsste ja irgendwann mal ein 
anderer Wert gekommen sein.

[Stefan F. (Gast)]

neuer_benutzer55 schrieb:
>         db1 = temp / 16;

Wenn temp ein Integer ist, dann ist das Ergebnis der Division auch ein 
Integer. Simple Lösung:

db1 = temp / 16.0

[Dirk B. (dirkb2)]

Dirk B. schrieb:
> Gefällt dir der Zahlenwert von sprintf nicht, oder kommt nur wirres Zeug
> raus?

ich meinte wirklich sprintf und nicht dtostrf

[Wolfgang (Gast)]

neuer_benutzer55 schrieb:
> Darum bin ich auf double / float gekommen.

Double und Float haben völlig verschiedene Auflösung.

Nochmal: Warum Double und nicht Single/Float?

[Dirk B. (dirkb2)]

Wolfgang schrieb:
> Double und Float haben völlig verschiedene Auflösung.

nicht immer

[Dirk B. (dirkb2)]

Wolfgang schrieb:
> Nochmal: Warum Double und nicht Single/Float?

da dbl nur ein Zwischenergebnis aufnimmt und printf kein float kann, ist 
double ok.

[Stefan F. (Gast)]

Wolfgang schrieb:
> Double und Float haben völlig verschiedene Auflösung.

Nicht bei AVR.
https://gcc.gnu.org/wiki/avr-gcc#Deviations_from_the_Standard

[Wolfgang (Gast)]

Stefanus F. schrieb:
> Wolfgang schrieb:
>> Double und Float haben völlig verschiedene Auflösung.
>
> Nicht bei AVR.
> https://gcc.gnu.org/wiki/avr-gcc#Deviations_from_the_Standard

Soviel zum Thema Portierbarkeit von C ;-(

Nichtmal auf die Auflösung der Zahlenformate für rationale Zahlen kann 
man sich verlassen.

[Dirk B. (dirkb2)]

Wolfgang schrieb:
> Soviel zum Thema Portierbarkeit von C ;-(
>
> Nichtmal auf die Auflösung der Zahlenformate für rationale Zahlen kann
> man sich verlassen.

Der C-Standard gibt nur einen Mindeswertebereich für float und double 
vor.
Und der ist identisch.

Also ist es Standardkonform, wenn float und double denselben 
Wertebereich haben.

[Wolfgang (Gast)]

Dirk B. schrieb:
> Also ist es Standardkonform, wenn float und double denselben
> Wertebereich haben.

Trotzdem ist es Käse, wenn double ≠ IEEE double precision ist, weil 
man dann keine portierbare Möglichkeit hat, gesichert mit /IEEE double 
precision/ zu rechnen.

[Stefan F. (Gast)]

Portierbaren Code bekommst du z.B. mit Java. Bei C liegt der Fokus eher 
in der Hardware-Nähe.

[Dirk B. (dirkb2)]

Wolfgang schrieb:
> Trotzdem ist es Käse, wenn double ≠ IEEE double precision ist, weil
> man dann keine portierbare Möglichkeit hat, gesichert mit /IEEE double
> precision/ zu rechnen.

IEEE Unterstützung wird auch erst seit C11 gefordert.

Viele Systeme unterstützten das auch vorher.
Nur sollte man bei C nicht von dem Verhalten des eigenen System auf die 
Allgemeinheit schließen.

[Dirk B. (dirkb2)]

Stefanus F. schrieb:
> Portierbaren Code bekommst du z.B. mit Java.

Java auf einem 8-Bit AVR ?

(da galt die Einschränkung float == double)

[Bauform B. (bauformb)]

Auf einem 8-Bit uC hatte ich es mal sinngemäß so gemacht (hier als 
PC-Version zum ausprobieren)

#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>

int
main (int argc, char *argv[])
{
   char    *bp, buf[42];
   int      bc, len;
   int32_t  temp;

   if (argc != 2) {
      printf ("usage: %s DS18B20-Datenwort\n", argv[0]);
      exit (EXIT_FAILURE);
   }
   temp = strtol (argv[1], NULL, 0);


   if (temp & 2048) {
      temp |= 0xfffff000UL;
   }
   len = snprintf (buf, sizeof buf, "%+06d", temp * 625);
   bp = buf;
   for (bc = 0; bc < 9 - len; bc++) {
      putchar (' ');
   }
   for (bc = 0; bc < len - 4; bc++) {
      putchar (*bp++);
   }
   putchar ('.');
   for (bc = 0; bc < 4; bc++) {
      putchar (*bp++);
   }
   putchar ('\r');
   putchar ('\n');
   return 0;
}

[neuer_benutzer55 (Gast)]

@Stefanus F.

/16.0 funktioniert :)


Mit der Prezision, double, float, single werde ich mich Morgen 
auseinander setzen.

[foobar (Gast)]

Wenn es dir nur um die Nachkommastellen, die durch die Division mit 16 
entstehen, geht, kannst du das auch ohne float/double erreichen:

    char buf[12];
    unsigned t = abs(temp);
    sprintf(buf, "%u.%03u", t/16, t%16 * 1000 / 16);
    if (temp < 0)
        USART_transmit('-');
    USART_transmit_string(buf);