Hallo liebe Gemeinde! Ich habe ine Frage bezüglich der Umwandlung eines Floats in eine IEEE754-Zahl. Ich habe mir grad selber einen Algorithmus geschrieben, der mit die 32Bit Bitfolge aus einem loat berechnet. Ziel ist es, diese Bitfolge später via UART zu übertragen. Ich habe auch schon das Forum durchsucht, jedoch passt nichts dazu auf meine Frage. Es geht also nicht darum, wie man diese Bitfolge errechnet, sondern ob ich nicht auch einfacher an die ahl rankommen kann. Ich arbeite mit IAR Embedded Workbench und kann mir ja den Float, den ich eingegeben habe auch in anderen Formen darstellen lassen. Binär ist leider nicht dabei, aber in HEX-Darstellung kann ich mir den Float ebenfalls anzeigen lassen und das entspricht, wie sollte es anders sein, natürlich genau der Bitfolge, wie sie auch aus meinem Algorithmus hervorgeht. Ist es nun möglich, ohne rechnen diesen Float als HEX-Darstellung einfach in seine 4 Bytes zu zerteilen und über den UART zu senden? Dann bräuchte man den Algorithmus ja garnicht. Hoffe, es ist verständlich wie ich das meine. Guß und danke! otto
Mhh, nee, irgendwie kann die einzelnen Bytes nicht sinnvoll da raus holen, bzw. weiß nicht wie. Wollte das jetzt byteweise in einen char übertragen. Aber wegen dem Datentyp float geht das nicht so einfach. Oder ich habe grad nen Denkfehler.
Also ich habe: float zahl = 17769.7 uint8_t temp1 = (zahl & 0x000000FF) geht nicht, wegen ungleicher Datentypen wenn ich temp1 = ((uint32_t) zahl & 0x000000FF)) dann schneidet er mir natürlich die Nachkommastellen ab... Also doch den Algorithmus?
Ich hab nicht wirklich verstanden, was du da von dir gibst. Aber ich denke herausgelesen zu haben, dass du einen float hast und an die einzelnen Bytes dieses float rankommen willst. Nichts einfacher als das. Du nimmst die Adresse des float, castest die um auf einen uint8_t* und voila: schon hast du Zugriff auf die einzelnen uint8_t, also die Bytes. Das geht mit jedem Datentyp, egal was sich dahinter versteckt. Du musst deinem C-Compiler nur weis machen: "Vergiss den Datentyp, der sich dort an dieser speziellen Adresse verbirgt. Ab jetzt tun wir so, als ob dort einfach nur eine Abfolge von Bytes rumlungert." Und das Werkzeug um das zu tun, ist ein Umcasten eines Pointers, bei dem du dem Pointer den speziellen Datentyp unter dem Allerwertesten wegziehst und ihm uint8_t unterjubelst.
1 | float a = 0.5; |
2 | uint8_t* pBytes; |
3 | |
4 | pBytes = (uint8_t*)&a; |
5 | |
6 | for( i = 0; i < sizeof( float ); ++i ) |
7 | mach_was_mit( pBytes[i] ); |
Bin nicht sicher ob es das ist, was dir Kopfzerbrechen macht, aber einen Versuch wars, denke ich, wert. PS: uint8_t ist der seit C99 standadisierte Datentyp für 'unsigned integer mit 8 Bit'. Wenn du den nicht hast: ein unsigned char tuts genauso.
Je nach Prozessor ist die Bytefolge im Speicher unterschiedlich, little und big endian. Da muß man aufpassen!
Und dann wird es spannend, was am anderen Ende der UART passiert. Falls der Rechner dasselbe Datenformat hat und beide Little Endian sind oder beide Big Endian, dann kann man sich umgekehrt wieder die originale Float analog zusammenbauen. Wenn nicht, dann geht es schief und führt hier zur nächsten Frage...
Klaus Wachtler schrieb: > Und dann wird es spannend, was am anderen Ende der UART passiert. > > Falls der Rechner dasselbe Datenformat hat und beide Little Endian > sind oder beide Big Endian, dann kann man sich umgekehrt wieder > die originale Float analog zusammenbauen. > > Wenn nicht, dann geht es schief und führt hier zur nächsten Frage... :-) Dann warten wir mal ab, was weiter passieren wird.
Ich mein, ich kann den Algorithmus ja druchlaufen lassen, aber wenn es schneller geht, dann wäre das natürlich auch nicht verkehrt. Bin da leider erst drauf gekommen, nachdem ich den Algorithmus schon fertig hatte. Nochmal zur Verdeutlichung was ich meine: Zahl: 17769.7 IEEE754: 01000110 10001010 11010011 01100110 in HEX: 46 8A D3 66 Und der Float ist halt gnauso im HEX hinterlegt, als 32Bit-Zahl lässt sie sich leider nicht anzeigen. Auf jeden Fall rechnet der Computer ja genau mit diesen Gleitkommatypen. Und da kam mir nur gerade in den Sinn, die vier HEX-Werte 46 8A D3 66 in einzelne chars umzupacken und mir den Algorithmus zu sparen.
karl-otto schrieb: > Ich mein, ich kann den Algorithmus ja druchlaufen lassen, aber wenn es > schneller geht, dann wäre das natürlich auch nicht verkehrt. Bin da > leider erst drauf gekommen, nachdem ich den Algorithmus schon fertig > hatte. Wieder mal ein Fall von: Massenhaft Mehrarbeit, weil man sein Werkzeug (die Programmiersprache C) und seine Möglichkeiten nicht kennt. Aber was red ich mir den Mund fusselig. Ist ja nicht so, dass es irgendwie Bücher gäbe, die einem den Umgang mit seinem Werkzeug in einer systematischen Art und Weise beibringen würden. Und da Programmieren ja auch die trivialste Tätigkeit der Welt ist, braucht man das auch nicht von der Pieke auf systematisch lernen. Try and Error tuts auch.
@karl-otto: Ja, ist schon richtig. Du musst es nur so machen wie KHB es beschrieb. Der kann das, weil er darin Übung hat - der letzte Thread mit dem gleichen Thema ist noch warm. Aber meine Warnung gilt trotzdem: Wenn die beiden beteiligten Rechner zu nunterschiedlich sind, kann es sein, daß die Übertragung der float 1:1 zu Unsinn führt.
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.