Moin, ich suche ein kleines PC-Programm, dass mir 32-bit float Zahlen in die 4 Bytes zerlegt, damit ich diese dann über Terminal und serielle Schnittstelle an meinen AVR schicken kann. Sprich: - ich gebe ein: 12.3456 - und bekomme vom Programm Mantisse und Exponent in 4 Bytes in hex in uC-üblichem Format. Gibt's da was? Danke & Gruß, X
> - und bekomme vom Programm Mantisse und Exponent in 4 Bytes in hex in > uC-üblichem Format. Was ist ein uC-übliches Format? Und was machst du mit dem Vorzeichen? Und wie sieht es mit Litte- bzw. Big-Endian (Bytereihenfolge) aus? > dass mir 32-bit float Zahlen in die 4 Bytes zerlegt, damit ich diese > dann über Terminal und serielle Schnittstelle an meinen AVR schicken kann. Sinnvoller ist da eine Übertragung im ASCII-Klartext: '1','2','.','3','4','5','6','\n' Dann kannst du die Daten nämlich ganz einfach mit einem Terminal mitlesen.
>> Sinnvoller ist da eine Übertragung im ASCII-Klartext: >> '1','2','.','3','4','5','6','\n' Wieso sollte das sinnvoller sein? So wie er das haben möchte braucht er nur 4 Bytes zu übertragen. Zudem kann er sich das "HEX_2_FLOAT" auf dem uC sparen. Du kennst ja die Applikation dahinter nicht. Gruss
> Wieso sollte das sinnvoller sein? Weil es maschinenunabhängig ist. Weil dann ASCII-Steuerzeichen (STX, ETX,...) verwendet werden können. Weil man das Ganze dann ganz einfach mit einem Terminal mitlesen kann. Weil es unabhängig von der Programmiersprache funktionieren wird. > So wie er das haben möchte braucht er nur 4 Bytes zu übertragen. Zudem > kann er sich das "HEX_2_FLOAT" auf dem uC sparen. Hast du schonmal was von little und big endian gehört? Sind dir die Konsequenzen daraus klar? > Du kennst ja die Applikation dahinter nicht. Da geht es mir in etwa wie dir :-o
Senf-Dazu-Geber schrieb: > Du kennst ja die Applikation dahinter nicht. Prinzipiell richtig. Wenn es aber schon daran scheitert, sich in 5 Minuten auf dem PC ein Programm zu schreiben, welches die Bytes eines float in Hex rausgibt, will ich mir die Probleme auf der µC Seite erst gar nicht ausmalen. Dazu kommt, dass sich Neulinge das gerne so einfach vorstellen: Da schick ich die Bytes zum µC und dann passt das schon. Das Erwachen kommt dann erst, wenn die Bytes aus dem Bytestrom auseinandersortiert werden müssen. Von Protokollfragen haben sie noch nie etwas gehört :-) Hinweis: Die Bytes müssen auf µC Seite ja auch wieder zusammengesetzt werden. Und das ist prinzipiell einfach nur die Umkehrung der Zerlegung. Kannst du sie zusammensetzen, kannst du sie auch zerlegen. Also: sei nicht so faul und schreib dir das entsprechende Tool selbst. Manchmal muss man sich auch einfach nur seine Hilfswerkzeuge selber machen.
>> Weil man das Ganze dann ganz einfach mit einem Terminal mitlesen kann. > http://www.sharewareconnection.com/rs232-monitor.htm Zählt für mich nicht als Argument. Denn dieses Programm habe ich garantiert nicht zur Hand, wenn ich es unbedingt bräuchte. Einen reinen ASCII-Text kann aber sogar Hyperterm mitloggen, jeder beliebiger Editor anzeigen und jedes Comparetool vergleichen.
@ Lothar Miller @ Karl heinz Buchegger Ich bin halt der Meinung, dass man auf Fragen auch direkt antworten kann und nicht immer großartig rumdiskutieren muss was besser, schöner, toller wäre.
Senf-Dazu-Geber schrieb: > @ Lothar Miller > @ Karl heinz Buchegger > > Ich bin halt der Meinung, dass man auf Fragen auch direkt antworten kann > und nicht immer großartig rumdiskutieren muss was besser, schöner, > toller wäre. Du bist noch nicht lange im Forum. Stimmts? Mit der Zeit wirst du merken, dass viele Fragen nach dem Muster sind: Ich habe mir da jetzt eine Systematik eingebildet, die ich zwar nicht beherrsche und von der ich keine Ahnung habe ob sie sinnvoll ist, die ich aber unbedingt aus keinem guten Grund zum Laufen bringen will. Natürlich kann man auf den Problemkreis eingehen. Aber noch viel öfter ist die vernünftigere Antwort die, ganz klar zu sagen: Du hast dich da verrannt. Da warten noch Probleme an die du noch gar nicht gedacht hast und die (mit deinem jetzigen Kentnisstand) alles andere als trivial sind. Wenn du aber deine Systematik dahingehend änderst, schiffst du dich um diese ganze Problematik elegant drum herum. Wenn es also keinen wirklich guten Grund gibt, dann lass dein Vorhaben, wie angedacht, fallen und geh über zu Plan B. Datentransfer auf binärer Bytebene gehört zb in diese Kategorie. Einzelne Bytes zu übertragen ist nicht weiter schwer. Aber die Verallgemeinerung auf ganze Datensätze leider schon, wenn man keine dezidierten Bytewerte zur Synchronisation verwenden kann. Eine ASCII Übertragung vermeidet all das von vorne herein und ist auch leichter zu vermitteln. Das eine Eingabe einen Abschluss braucht, kennt jeder: An das zeilen-abschliessende 'Return' haben sich alle längst gewöhnt und das man sich zwischen 2 Werte irgendein Trennzeichen reinmacht (Komma oder dergleichen) ist auch kein Hexenwerk. Empfangsseitig unterscheidet sich das in nicht viel. Einen Empfangsbuffer zum Zwischenspeichern benötigt man in jedem Fall und ob der jetzt ein paar Bytes länger ist, spielt auch nicht so die große Rolle. Einzig die Umwandlung von ASCII zum eigentlichen Datentyp muss man machen. Aber da gibt es ja fertige Funktionen. Und es schadet keineswegs, wenn man mit diesen umgehen kann.
@ Karl heinz Buchegger Auch wenn ich mich wiederhole: Du kennst die Applikation dahinter nicht. Daher halte ich es für müssig dem Fragensteller Antworten auf nicht gestellte Fragen zu geben. Aber das ist nur meine ganz persönliche Meinung. Gruss
Senf-Dazu-Geber schrieb: > @ Karl heinz Buchegger > > Auch wenn ich mich wiederhole: > Du kennst die Applikation dahinter nicht. Und auch wenn ich mich wiederhole: Prinzipiell richtig. Wer allerdings solche Fragen stellen muss, weiß noch gar nicht worauf er sich einlässt. Und diejenigen, die wissen worauf das hinausläuft, müssen konkret diese Frage nicht stellen. Woher ich das weiß: Aus ein paar zehntausend Anfragen in den letzten Jahren hier im Forum.
Hier ist ja was los! Aaaaalso, floats in ASCII-Format über USART ist kein Problem, das betreibe ich schon etwas länger. Meine jetzige Anwendung erfordert aber, dass mein ATmega64 von einem anderen uC (den mache nicht ich) single floats byte-weise über die USART bekommt. Und um das zu testen, wollte ich mir ein paar txt-files basteln, wo die floats in die 4 Bytes aufgeteilt sind, und diese über einen Terminal (Codevision) rausschicken. Ich suche also nur einen online Rechner, dem ich sage "gib mir mal die 4 Bytes aus denen der 32-bit float Wert x besteht". Empfangen und auswerten mit dem uC sollte kein Problem werden (Counter, Timer, Zeiger, casten, etc.) @ Senf-Dazu-Geber: Ich kucke mir mal den RS232-Monitor an, geht schon in die Richtung. Danke, X
Hmmmm, der RS232 Monitor ist nicht schlecht, aber ein einfacher Rechner wäre noch toller, dann kann ich die float-bytes in mein Protokoll einbauen.
Also in der Zeit wo du hier rumhampelst hättest du dir so einen "Rechner" schon 10x selbstschreiben können. Wo ist den das Problem? Du könntest das Senden sogar über einen weiteren uc der ASCII empfängt und "Bytes" sendet lösen wenn dir die 5 Zeilen Programmcode so zu wieder sind. Wenn wir dir jetzt einen Rechner nennen würden, dann hätte der doch bestimmt wieder das falsche Format oder einen nicht passende Hintergrundfarbe oder doch lieber für MacOS10 statt für Linux...
> Ich bin halt der Meinung, dass man auf Fragen auch direkt antworten kann
Okokok:1 | char *a, i; |
2 | float f = 12.3456; |
3 | a = (char*)&f; |
4 | for (i=0; i<4; i++) putchar(*a+i); |
> Ich bin halt der Meinung, dass man auf Fragen auch direkt antworten kann Da kenn ich noch einen: Klein Werner ist bei seinem Kumpel Otto. Er sieht, dass Ottos Vater einen Kugelschreiber nicht zum Laufen bekommt. Diagnose: Tinte eingetrocknet. Werner sagt: "Mein Vater hat ein Feuerzeug genommen und die Spitze warm gemacht." "Gute Idee", sagt Ottos Vater und heizt die Spitze mit einem Feuerzeug auf. Kurz danach: große Sauerei, Hemd und Hose hinüber. Das sagt Werner: "Das ist meinem Vater auch passiert!" Substitution: X-Rocka = Ottos Vater Und wer will Werner sein? > von einem anderen uC (den mache nicht ich) Little oder Big Endian ;-) > Ich suche also nur einen online Rechner Warum Online? Siehe Anhang...
1 | #include <stdio.h> |
2 | |
3 | int main(int argc, char* argv[]) |
4 | {
|
5 | char *a, i; |
6 | float f = 12.345; |
7 | while (1) { |
8 | printf("\n\nZahl eingeben (Ende mit q): "); |
9 | i = scanf("%f",&f); |
10 | if(i!=1) return 0; |
11 | a = (char*)&f; |
12 | for (i=0; i<4; i++) printf("\n%02x %c",(*(a+i))&0xff, (*(a+i))&0xff); |
13 | }
|
14 | }
|
> wollte ich mir ein paar txt-files basteln
Das Problem ist, dass die Bates dann kein Text mehr sind, sondern
irgendwelche Sonderzeichen, die dann vom jeweiligen Betriebssystem
unterschiedlich interpretiert werden...
Du wirst also einen Hex-Editor brauchen.
>Und um das zu testen, wollte ich mir ein paar txt-files basteln, wo die >floats in die 4 Bytes aufgeteilt sind, und diese über einen Terminal >(Codevision) rausschicken. merkst du eigendlich den Widerspruch zwischen Bytes und txt file? Das wird maximal ein bin file Thomas
Seufz... @Läubi: hier Fragen stellen ist also rumhampeln? Die Frage auf meine Antwort, ob's irgendwo so einen "Umrechner" gibt, heisst also: ihr wisst es nicht. Ist ja okay. Klar habe ich auch schon dran gedacht, mir das in den uC zu basteln, ähnlich wie Lothar Miller (das war zwar nicht die richtige, aber eine konstruktive Antwort, danke!) es vorschlägt. Hätte den Vorteil, gleich das korrekte uC-Format zu bekommen... vielleicht mache ich es doch so. Aber ich hatte mir da meinen Workflow etwas anders vorgestellt. Und natürlich brauche ich einen hex-Editor, den brauche ich auch für Test-Files mit ASCII-Sonderzeichen wie STX, CR, etcpp. Bei meiner nächsten Frage werde ich eine komplette 10-seitige Projektbeschreibung liefern, außerdem meinen Lebenslauf und alle bisherigen Projekte, so dass ihr wisst wie dämlich ich tatsächlich bin... ;-) Ernsthaft, war die Ausgangsfrage so bescheuert?
X- Rocka schrieb: > Ernsthaft, war die Ausgangsfrage so bescheuert? Wenn man bedenkt, dass man sich diesen 7 Zeiler in weniger als 2 Minuten selbst schreiben kann .... Die meisten hier haben das gewünschte Tool fertig, noch ehe dein Browser den Eröffnungsbildschirm von mikrocontroller.net anzeigt. > Aber ich hatte mir da meinen Workflow etwas anders vorgestellt. Alles klar. Schönen Tag noch.
nach 1min googeln und über Wikipedia findet man sowas hier: http://babbage.cs.qc.cuny.edu/IEEE-754/ Die Bytereihenfolge im Speicher hängt dann von der HW ab, aber das sollte ja kein Problem sein.
> Ernsthaft, war die Ausgangsfrage so bescheuert? Ich wollte dich nicht wie Ottos Vater dastehen sehen... ;-) > ich suche ein kleines PC-Programm, dass mir 32-bit float Zahlen in die > 4 Bytes zerlegt, damit ich diese dann über Terminal und serielle > Schnittstelle an meinen AVR schicken kann. > Sprich: > - ich gebe ein: 12.3456 > - und bekomme vom Programm Mantisse und Exponent Das hast du jetzt ja (incl. float2hex.exe) seit dem Beitrag "Re: PC-Tool: float in 4 Bytes (hex) zerlegen" Diesen Dreizeiler hatte ich übrigens in etwa 5 Minuten hingeklekst... EDIT: > Wenn man bedenkt, dass man sich diesen 7 Zeiler in weniger als 2 Minuten > selbst schreiben kann .... Ich musste erst noch das VisualStudio hochfahren... ;-)
> Ernsthaft, war die Ausgangsfrage so bescheuert? Also ich kann nichts verwerfliches daran finden nach einem PC-Tool zu fragen. Ich hab' meine Meinung zu manchen Antworten hier aber auch schon kundgetan. > Wenn man bedenkt, dass man sich diesen 7 Zeiler in weniger als 2 Minuten > selbst schreiben kann .... Das setzt aber voraus, dass ich eine PC-Entwicklungsumgebung installiert habe ;-) Gruss
Senf-Dazu-Geber schrieb: >> Wenn man bedenkt, dass man sich diesen 7 Zeiler in weniger als 2 Minuten >> selbst schreiben kann .... > > Das setzt aber voraus, dass ich eine PC-Entwicklungsumgebung installiert > habe ;-) Genau. Und das habe ich nicht, und der Weg der Float-Zerlegung über nen uC und Terminal ist doch etwas umständlicher.
JojoS schrieb: > nach 1min googeln und über Wikipedia findet man sowas hier: > http://babbage.cs.qc.cuny.edu/IEEE-754/ > Die Bytereihenfolge im Speicher hängt dann von der HW ab, aber das > sollte ja kein Problem sein. Vielen Dank! Ich gebe zu, ich war zum googeln in diesem Fall zu doof - aber glaube mir bitte, ich hab's versucht!
das AVR Studio hilft da aber auch weiter. Ein Programm wie
1 | #include <float.h> |
2 | |
3 | void main() |
4 | {
|
5 | float a = 1.234f; |
6 | }
|
übersetzen (mit -O0, sonst wird es wegoptimiert) und im Simulator starten. Das Watchfenster verrät wo ein Variable liegt und das Memoryfenster zeigt die Bytes an.
JojoS schrieb: > das AVR Studio hilft da aber auch weiter. Ein Programm wie > >
1 | > #include <float.h> |
2 | >
|
3 | > void main() |
4 | > { |
5 | > float a = 1.234f; |
6 | > } |
7 | >
|
> > übersetzen (mit -O0, sonst wird es wegoptimiert) und im Simulator > starten. Das Watchfenster verrät wo ein Variable liegt und das > Memoryfenster zeigt die Bytes an. Gute Idee. Ich muss mich irgendwann wohl doch mal ins AVR studio einarbeiten. Nutze es nur zum flashen, weil das Tool dafür in Codevision nicht so doll ist.
Lothar Miller schrieb: > Das hast du jetzt ja (incl. float2hex.exe) seit dem > Beitrag "Re: PC-Tool: float in 4 Bytes (hex) zerlegen" > Diesen Dreizeiler hatte ich übrigens in etwa 5 Minuten hingeklekst... > > EDIT: >> Wenn man bedenkt, dass man sich diesen 7 Zeiler in weniger als 2 Minuten >> selbst schreiben kann .... > Ich musste erst noch das VisualStudio hochfahren... ;-) Hindernis erkannt und trotzdem genau drauf zugehalten. Dein 3 Zeiler für sich allein liefert kein definiertes Ergebnis. Hätte dein Programm nicht wesentlich vergrößert, hättest du es mathm. und nicht per Zeiger gelöst, um dich damit von Big/Little-Endianess des Hosts unabhängig zu machen.
> Dein 3 Zeiler für sich allein liefert kein definiertes Ergebnis. Schon klar, ich bin doch der, der dauernd auf die Bytereihenfolge abzielt. Und ich meine, genau 2 Zeilen vor dem Code nochmal darauf hingewiesen zu haben. Mehr kann ich nicht tun. Wenn ich sage: die Kurve verträgt nicht mehr als 80, dann bin ich doch nicht Schuld, wenn einer mit 100 rausfliegt. > Hätte dein Programm nicht wesentlich vergrößert, hättest du es mathm. > und nicht per Zeiger gelöst, um dich damit von Big/Little-Endianess des > Hosts unabhängig zu machen. Die Worte hör ich wohl, allein mir fehlt der Glaube. :-) Und zudem wäre ich nicht so schnell fertig gewesen... > um dich damit von Big/Little-Endianess des Hosts unabhängig zu machen. Nur: was ist mit dem Target/Client? Wie bekomme ich die Abhängigkeit bei dem raus?
Beim Ziel ist es das Gleiche. Auch hier gilt: Zeigeroperationen sind systemabhängig (Betrifft nicht nur LE/BE, sondern auch Alignment, Busbreiten, etc), vorzeichenlose Arithmetik ist systemunabhängig. (die Einschränkung vorzeichenlos ist hier OBdA. wichtig jedoch um nicht in die 1er/2er Komplement Falle zu tappen) Teilen (Shiften) und Modulo(verunden) bei der Zerlegung. Multiplizieren (Shiften) und Addieren(verodern) bei der Rekonstruktion. Der Kompiler kümmert sich dann um den Rest, dass die physiche Umsetzung auch der Operation folgt. Die Ordnung ist dann nur noch für die Übertragung von Relevanz, das ist dann Aufgabe des Protokols sich auf eine (beliebige) Permutation zu einigen.
JojoS schrieb: > nach 1min googeln und über Wikipedia findet man sowas hier: > http://babbage.cs.qc.cuny.edu/IEEE-754/ > Die Bytereihenfolge im Speicher hängt dann von der HW ab, aber das > sollte ja kein Problem sein. Nochmals danke! Habe es jetzt getestet, funktioniert wunderbar. X
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.