sprintf(string,"%1.3lf",123.456) avrcc

long float? Würde meinen, das gibt's gar nicht. Wo hast Du das her?

Die Ausgabe von Gleitkommawerten (normalerweise double ) geht entweder 
mit f in der "normalen" Darstellung oder mit e in der 
Exponentialdarstellung. Schau mal in die lib-Dokumentation. Da müssten 
eigentlich die Formatkürzel drinstehen. Eine Unterscheidung nach "long" 
bzw. "nicht long" gibt es bei der Ausgabe standardmäßig nirgends (auch 
nicht bei ganzzahligen Werten).

Besser so:
sprintf(string,"%1.3f",123.456)


http://www.cplusplus.com/reference/clibrary/cstdio/sprintf.html

>Eine Unterscheidung nach "long" bzw. "nicht long" gibt es bei der Ausgabe 
>standardmäßig nirgends (auch nicht bei ganzzahligen Werten)
Da habe ich aber schon anderes gelesen:

K&R, Zweite Ausgabe, Seite 147 unten:
...Buchstabe h, wenn short ausgegeben werden soll, oder der Buchstabe l 
wenn das Argument long ist...

Lothar Miller wrote:
>>Eine Unterscheidung nach "long" bzw. "nicht long" gibt es bei der Ausgabe
>>standardmäßig nirgends (auch nicht bei ganzzahligen Werten)
> Da habe ich aber schon anderes gelesen:
>
> K&R, Zweite Ausgabe, Seite 147 unten:
> ...Buchstabe h, wenn short ausgegeben werden soll, oder der Buchstabe l
> wenn das Argument long ist...
Hast Recht (hab grad auch noch mal einen Blick in den K&R geworfen). Es 
gibt aber im Standard kein Flag für float , wenn ein l bei einem f 
steht, dann ist das long double ... f steht bereits für double

>LIBS =  $(LIBDIR)/nutinit.o -lnutos -lnutarch -lnutdev -lnutarch
>                    -lnutcrt -Wl,-u,vfprintf -lprintf_flt -lm $(ADDLIBS)

... -Wl,-u,vfprintf ...
Ich bin ja jetzt nicht so der Crack, aber:
Kommas in der Kommandozeile????

Lothar Miller wrote:

> ...Buchstabe h, wenn short ausgegeben werden soll

Das geht bei Gleitkomma gar nicht.  Da *printf() mit einer variablen
Argumentliste arbeitet, werden Argumente vom Typ float zwangsweise
zu double promotet.  (Achtung: scanf() ist in dieser Hinsicht anders,
denn da werden Zeiger übergeben.)

Der modifier `l' hat bei Gleitkommaformaten laut Standard keine
Wirkung.  Ich bin mir gerade nicht ganz sicher, wie sich die
avr-libc-Implementierung da verhält; ich vermute aber, dass sie das
auch wirklich genau so tut.

Der modifier `L' wäre vom Standard für den Datentyp `long double'
vorgesehen (den kann dein K&R noch nicht kennen, der ist erst mit
ISO C99 in den Standard gekommen); die avr-libc implementiert dieses
jedoch nicht.

Generell ist bei avr-libc (derzeit) sizeof(float) == sizeof(double)
== sizeof(long double) == 4, und die Konstante 123.456 hat den Typ
double.

Hast du denn aber überhaupt die Gleitkommaversion der printf-Bibliothek
gelinkt?

Jörg Wunsch wrote:

> Hast du denn aber überhaupt die Gleitkommaversion der printf-Bibliothek
> gelinkt?

Ja, das scheint OK zu sein.

Dann müsstest du mal sagen, was denn genau bei dier passiert.

Denis Jakel wrote:

> Ich erhalte beim compeilieren keine warnings oder Fehler

Weil der Compiler zu wenig über die tatsächlich in der Bibliothek
implementierten Details weiß.

> Auf dem Display erscheint:
>
> Zeile1 "Messwert"
> Zeile2 "f"

Dann schmeiß das blöde `l' aus dem Format raus.  Offenbar ignoriert
es die avr-libc doch nicht (kannste gern einen Bugreport dafür
aufmachen), und wie ich oben schon dargelegt habe, ist es so oder
so sinnlos.

Btw.: bitte schreibe alle #includes mit Vorwärtsschrägstrichen, das
macht deinen Code portabler.  Es gibt keinen vernünftigen Grund,
warum man #include <avr\io.h> statt #include <avr/io.h> schreiben
will.  Selbst wenn du den Code nicht auf was anderem als Windows
compilieren willst: sobald du hier Hilfe anforderst, stolperst du
über kurz oder lang halt über Leute wie mich, die den Code nicht
auf Windows compilieren wollen (weil ich keins habe und keins haben
will).

Hast du denn endlich mal das blöde `l' aus dem Format rausgelassen?

(Sorry, ich habe keine Lust, mir erst das Zipfile zu holen.)

Inzwischen hatte ich mal Zeit, das Zip-File anzugucken.  Ja, das l
ist nicht mehr drin.  Nein, ich kann es in der Simulation nicht
nachvollziehen, wenn ich ein simples sprintf(... "%1.3f") aufrufe,
bekomme ich im Puffer wirklich 123.456.

Blöde Frage, hast du das nach dem Entfernen des "l" auch wirklich
neu geflasht?

Das l ist ja nun auch raus.  Ja, es wäre ein Unterschied gewesen,
das L wird nämlich von der avr-libc auf keinen Fall verstanden,
das l zumindest im Zusammenhang mit integer-Formaten.  (Ich hätte
erwartet, dass es bei Gleitkomma-Formaten einfach ignoriert wird.)