Hallo, habe schon etliche Forenbeiträge gelesen, bekomme aber leider keine Gleitkommazahl auf mein Display. Als Hardware habe ich das Ethernut Board 2.1 mit einem Atmega128. Das Makefile war schon dabei, und ich habe folgende Option hinzugefügt: -Wl,-u,vfprintf -lprintf_flt -lm Jedoch leider ohne Erfolg!!! :-( Ich stelle mal mein c File sowie orginal makefile (Makefile_) und das von mir abgeänderte makefile (makefile) hoch. Wäre für jeden Ratschlag bzw. Tip sehr dankbar. MfG Denis Jakel
Was kommt denn raus? Und: wofür steht %lf im Formatstring und was übergibst du da...?
ich bekomme nur f angzeigt. lf steht für long float Möchte die empfangenen zeichen vom USART als string wandeln und als Gleitkommazahl ausgeben.
normaler sieht das so aus sprintf(string,"%1.3lf",x) die 123.456 ist nur zum test ob er float wandeln kann
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
Die Gleitkomma-Datentypen unterscheiden sich nur durch ihre Länge und damit in ihrer Genauigkeit. Datentyp Länge Vorzeichen Format-String float 32bit ja %f double (= long float) 64bit ja %lf, %e, %g long double 64/80bit(*) ja %lf(*) Die Datentypen “float“ und “double“ sind auch als „single-precision“ bzw. “double-precision“ bekannt. Man kann sich ungefähr merken, dass “float“ 6-7 signifikante Dezimalstellen besitzt, bei “double“ sind es 14-15.
mit %f geht es auch nicht es liegt denke ich am makefile Habe leider keine Ahnung von Makefiles kann jemand mal meins anschauen ob das so stimmt??? Im simple.zip (Makefile)
>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
das ganze hat ja auch schon mal funktioniert auf nem anderen kontroller mit AVR Studio kompeiliert Es liegt sicherlich am Makefile!!! Was mein ihr zum Makefile???
>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?
Hatte diesen Beitrag gelesen Beitrag "Re: sprintf() Funktion - kleines Problem" des wegen habe ich habe ich -Wl,-u,vfprintf eigebunden. Sonst soch nen Plan irgendjemand wegen dem Makefile???
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.
Das Linken wird doch im Makefile mit den Parametern -Wl,-u,vfprintf auf leitkommazahl gelinkt, oder??? Und ich denke daran liegt das Problem, das im Makefile etwas nicht stimmt..
Ich gebe euch nochmals den Quellcode da ich ein Teil des Empangs der USART auskomentiert habe. Ich erhalte beim compeilieren keine warnings oder Fehler Auf dem Display erscheint: Zeile1 "Messwert" Zeile2 "f" Also denke ich das er das Format der Gleitkommazahlen nicht wandelt oder nicht wandeln kann :-(
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).
ok habe den code der iclude files mit #includes mit Vorwärtsschrägstrichen trotzdem immer noch das selbe ergebnis... :-( Leider
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?
Ich bin nun auch nicht so der C-Freak, aber macht es nicht einen Unterschied ob man "l" oder "L" nimmt? Wenn man hier nachliest: http://www.cplusplus.com/reference/clibrary/cstdio/sprintf.html sieht man dass: l --> The argument is interpreted as a long int or unsigned long int for integer specifiers --oder-- L --> The argument is interpreted as a long double es einen Unterschied macht.
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.)
Angehängte Dateien:
-
Ethernut.png
37 KB
Hi Leute, ich habe es endlich geschaft die Gleitkommazahl auf dem Display auszugeben. Der Fehler lag darin, dass ich beim Nut/OS Configurator (der die Libraries für GCC erstellt) den Haken bei C Runtime(target spezific)/File Streams/Floating Point vergessen hatte. Danke Euch trotzdem Allen für die vielen Postings. Gruß Denis
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.