Hallo Forum, ich habe eine Frage: angemonnen ich habe einen String (const char*) der eine Zahl erhält. Diese Zahl möchte ich in einen fixed-point-Typ umwandeln. Bei float wäre es klar: atof(str); Aber gibt es das für fixed-point-Typen auch? Den Typ den ich nutzen möchte wäre der größtmögliche, also "long long sat fract". Also: Wie kann ich einen String zu einer fixed-Point-Zahl wandeln? (möglichst einfach) PS: Festkomma etc kenne ich, will ich nicht, da ich dann einen _int128 brauchen könnte den es für den avr-gcc nicht gibt. PPS: Platz und Zeit spielen eine untergeordnete Rolle (Zeit fast egal)
Boben schrieb: >> "long long sat fract". > > Unterstützt der AVR-GCC diesen Typen überhaupt? Jep, halt mit
1 | #include <stdfix.h> |
2 | |
3 | void func(void) { |
4 | long long sat accum num; |
5 | }
|
gibts so was:
1 | math.c:157:10: warning: 'num' is used uninitialized in this function [-Wuninitialized] |
Funktioniert also (zumindest unterstützt der GCC den Typen). Laut Changelog sogar fast vollständig, alles vorhanden bis auf die #pragmas die runden etc steuern.
weiß niemand Rat? Oder "Literatur" oÄ. Ich würde mir die atoX(char*)-Funktion ja gerne selber schreiben, aber ich weiß nicht genau wie, da ich die Darstellung einer long long sat accum-Zahl nicht kenne. Wäre nett wenn jmd mit dem Wissen was dazu sagen könnte
Das verstehe ich nicht ganz. N. G. schrieb: > angemonnen ich habe einen String (const char*) der eine Zahl erhält. > Diese Zahl möchte ich in einen fixed-point-Typ umwandeln. ... > PS: Festkomma etc kenne ich, will ich nicht "fixed-point" ist der englische Begriff für "Festkomma", ist also dasselbe.
Rolf M. schrieb: > Das verstehe ich nicht ganz. > > N. G. schrieb: >> angemonnen ich habe einen String (const char*) der eine Zahl erhält. >> Diese Zahl möchte ich in einen fixed-point-Typ umwandeln. > ... >> PS: Festkomma etc kenne ich, will ich nicht > > "fixed-point" ist der englische Begriff für "Festkomma", ist also > dasselbe. Natürlich, ich meinte dass man mich nicht auf den link 1) zum Wikiartikel verweisen sollte, weil ich den schon kenne 1) https://www.mikrocontroller.net/articles/Festkommaarithmetik
N. G. schrieb: > Natürlich, ich meinte dass man mich nicht auf den link 1) zum > Wikiartikel verweisen sollte, weil ich den schon kenne > > 1) https://www.mikrocontroller.net/articles/Festkommaarithmetik Verlinke es doch einfach richtig: Festkommaarithmetik.
Der ISO-Standard (ISO/IEC JTC1 SC22 WG14 N1169) sieht Routinen wie
1 | short fract strtofxhr(const char * restrict nptr, char ** restrict endptr); |
vor. Wo sind die denn beim AVR-GCC abgelegt? Welche LIB muss z. B. eingebunden werden?
Bleibtreu schrieb: > Wo sind die denn beim AVR-GCC abgelegt? > Welche LIB muss z. B. eingebunden werden? also der avr-gcc wirft implicit declaration, d.h. es fehlt auf jeden Fall schon mal ein Header. Der Linker meckert aber auch dass er die Funktion nicht finden kann, d.h. die Funktion ist auch nicht in einer lib des gcc, die in jedem Falle mitgelinkt wird. Kann man dafür ausgehen, dass beim avr-gcc dafür einfach der Support fehlt?
N. G. schrieb: > Bleibtreu schrieb: >> Wo sind die denn beim AVR-GCC abgelegt? >> Welche LIB muss z. B. eingebunden werden? > > also der avr-gcc wirft implicit declaration, d.h. es fehlt auf jeden > Fall schon mal ein Header. > Der Linker meckert aber auch dass er die Funktion nicht finden kann, > d.h. die Funktion ist auch nicht in einer lib des gcc, die in jedem > Falle mitgelinkt wird. > > Kann man dafür ausgehen, dass beim avr-gcc dafür einfach der Support > fehlt? Gute Frage. Die Datentypen (z. B. fract) und die Operatoren (z. B. Multiplikation) werden unterstützt. Vielleicht gibt es eine Library, die gelinkt werden muss?
Bleibtreu schrieb: > Wo sind die denn beim AVR-GCC abgelegt? Es hat sich noch niemand gefunden, der sie für die avr-libc beigesteuert hätte.
N. G. schrieb: > Ich würde mir die atoX(char*)-Funktion ja gerne selber schreiben, aber > ich weiß nicht genau wie, da ich die Darstellung einer long long sat > accum-Zahl nicht kenne. Im Zweifelsfalle frag mal Georg-Johann Lay danach, er hat die Implementierung ja beigesteuert. Kann mir auch vorstellen, dass er schon Fragmente für sowas hat. Ansonsten würde sich die avr-libc natürlich freuen, wenn du uns eine Implementierung von strtofxhr() beitragen könntest. ;-)
Jörg W. schrieb: > N. G. schrieb: >> Ich würde mir die atoX(char*)-Funktion ja gerne selber schreiben, aber >> ich weiß nicht genau wie, da ich die Darstellung einer long long sat >> accum-Zahl nicht kenne. > > Im Zweifelsfalle frag mal Georg-Johann Lay danach, er hat die > Implementierung ja beigesteuert. Kann mir auch vorstellen, dass > er schon Fragmente für sowas hat. Vllt schaut er ja demnächst hier rein, sonst schreib ihn ihn mal an. > Ansonsten würde sich die avr-libc natürlich freuen, wenn du uns eine > Implementierung von strtofxhr() beitragen könntest. ;-) Ich fände es auch cool, wenn ich an dem Projekt, zumindest in diesem begrenzten Rahmen, mitarbeiten könnte. Ich schau mal was sich da machen lässt. Wenn ich eine Lösung finde, werde ich sie auf jeden Fall veröffentlichen, vllt kommt die ja dann in die avr-libc. Zum Hintergrund: Es geht immer noch um den Taschenrechner, den ich für meine Seminararbeit baue. Ich möchte dort Vergleiche zwischen der Genauigkeit von verschiedenen Zählen Formaten anstellen. Zum Problem: Zeit: Abgabe ist in 2 Wochen (alles außer diesem Punkt ist fertig, aber wenns zeitlich nicht mehr geht streich ich ihn komplett), d.h. wenn ich bis dahin keine Lösung habe, wird es unwahrscheinlicher, dass ich noch eine finde, weil ich keinen Nutzen mehr davon habe. Aber ich schaue was sich machen lässt. PS: wie performant muss eine Lösung sein? Oder reicht es, wenn der Zweck erfüllt wird
N. G. schrieb: > wie performant muss eine Lösung sein? Bei solchen EA-Funktionen ist Performance eher wurscht. Wichtiger wäre noch Optimierung auf nicht allzu großen Flash-Verbrauch, aber das ist sicher auch nicht vordringlich.
Jörg W. schrieb: > N. G. schrieb: >> Ich würde mir die atoX(char*)-Funktion ja gerne selber schreiben, aber >> ich weiß nicht genau wie, da ich die Darstellung einer long long sat >> accum-Zahl nicht kenne. > [...] > Ansonsten würde sich die avr-libc natürlich freuen, wenn du uns eine > Implementierung von strtofxhr() beitragen könntest. ;-) Innerhalb der Toolchain wäre eine solche Implementierung nicht im eigentlichen Compiler, sondern in einer (Standard-)Bibliothek zu finden — hier wohl LibC (avr-libc). Ab avr-gcc 5 gibt es in stdfix.h einen "Hook" für die avr-libc:
1 | /* Hook in stuff from AVR-Libc. */
|
2 | |
3 | #if (defined (__WITH_AVRLIBC__) \
|
4 | && defined (__has_include) \
|
5 | && __has_include (<stdfix-avrlibc.h>))
|
6 | #include <stdfix-avrlibc.h> |
7 | #endif
|
__WITH_AVRLIBC__ ist aktiv außer configure wurde mit --with-avrlibc=no oder für RTEMS ausgeführt. __has_include gibt es ab 5.x, und falls ein Header <stdfix-avrlibc.h> existiert so wird dieser includiert. Was genau in stdfix-avrlibc.h drinne steht ist dann Sache der avr-libc. Sinnig sind Prototypen, zu welchen es Implementierung(en) in der avr-libc gibt, was aber bis dato nicht der Fall ist IIRC. Hauptproblem bei einer solchen Implementierung sind die printf/scanf Anteile, welche den erzeugten Code auch dann aufblasen, wenn printf/scanf ohne stdfix verwendet wird. Das Problem ist ganz analog zur printf/scanf-Implementierung von float. Falls ich noch irgendwelche Codefragmente hab, dann sind es fixed --> ASCII Routinen; ASCII --> fixed hab ich nie gebraucht...
Bitte 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.