Hallo
steh gerade auf dem Schlauch. Ich empfange Daten über eine UART-Schnittstelle, die Spannungen in ASCII kodiert überträgt. Spannung in mV. 26,100 Volt kommt da also als 32, 36, 31, 30, 30
daraus die Zahl 26100 zu machen ist kein Problem. So zum Vergleichen und weiterverabeiten bräuchte ich das jetzt als 16-Bit Integer in hex, das wäre lt meinem Taschenrechner 65F4. Nur wie komme ich dahin? habs mal mit google probiert, nur die rechnen dabei ja in Dezimal, das tut aber der uC nicht. Und ich komme nicht drauf, wie das gehen könnte, jongliere mit dem taschenrechner im Hex-modus, komm aber nicht klar. Kann mir einer nen Tipp geben?
So zum Vergleichen und
weiterverabeiten bräuchte ich das jetzt als 16-Bit Integer in hex
Ich glaube da liegt auch noch ein kleines Verständnisproblem vor. Der Wert als solches muss zum Weiterverarbeiten muss in eine Variable. Wie sie von Dir "interpretiert" wird, also Binär, Octal, Dezimal, HEX ist nur eine Betrachtungsweise.
Wenn Du z.B. schreibst "wert=0x5A;" wird im Speicher der 16-bit Variable das Bitmuster "0000000001011010" abgelegt. Du hättest auch "wert=90;" schreiben können und das Ergebnis ist exakt identisch.
Wenn Du z.B. schreibst "wert=0x5A;" wird im Speicher der 16-bit Variable
das Bitmuster "0000000001011010" abgelegt. Du hättest auch "wert=90;"
schreiben können und das Ergebnis ist exakt identisch.
Das stimmt zwar, geht aber an der Fragestellung völlig vorbei. Dass das Ergebnis in deinem Beispiel identisch ist, liegt ja nur daran, dass der Compiler freundlicherweise und quasi unsichtbar die Umwandlung aus dem Dezimal- ins Dualsystem vornimmt, bevor das Anwendungsprogramm gestartet wird. In dessen Speicher gibt es in dem Fall gar keine Dezimalzahl, soweit es die beiden Befehle betrifft: Die arbeiten beide mit dem Dualsystem.
Die Daten, die das Programm des OP über eine serielle Schnittstelle bekommt, gelangen aber als Dezimalzahl in den Speicher des Programms, da ist nirgendwo ein Compiler beteiligt, der irgendetwas umwandelt.
eine Variable. Wie die von Dir "interpretiert" wird, also Binär, Octal,
Dezimal, HEX ist nur eine Betrachtungsweise.
Nein. Das Rechenwerk des µP rechnet IMMER im Dualsystem, nie im Dezimalsystem. Der Unterschied zeigt sich z. B. bei den Ergebnissen von Addition, Multiplikation usw., die wären im Dezimalsystem ganz anders.
Hallo
steh gerade auf dem Schlauch. Ich empfange Daten über eine
UART-Schnittstelle, die Spannungen in ASCII kodiert überträgt. Spannung
in mV. 26,100 Volt kommt da also als 32, 36, 31, 30, 30
daraus die Zahl 26100 zu machen ist kein Problem. So zum Vergleichen und
weiterverabeiten bräuchte ich das jetzt als 16-Bit Integer in hex, das
wäre lt meinem Taschenrechner 65F4. Nur wie komme ich dahin? habs mal
mit google probiert, nur die rechnen dabei ja in Dezimal, das tut aber
der uC nicht. Und ich komme nicht drauf, wie das gehen könnte, jongliere
mit dem taschenrechner im Hex-modus, komm aber nicht klar. Kann mir
einer nen Tipp geben?
(%= Mod, Rest beim Teilen)
26100 -> gößer oder gleich 16, also ist es nicht das Ergebnis, also anfangen
26100 % 16 = 4 -> letzte Stelle
26100 / 16 = 1631 -> größer oder gleich 16, also nächste Runde
1631 % 16 = 15 = F -> vorletzte Stelle
1631 / 16 = 101 -> größer oder gleich 16, also nächste Runde
101 % 16 = 5 -> vorvorletzte Stelle
101 / 16 = 6 -> kleiner als 16, also vorvorvorletzte Stelle und Abbruch
Wozu dividieren? Einfach die Stellen (ASCII-0x30) der Reihe nach Addieren und zwischendrin die Summe mal 10 nehmen. Statt Multiplikation natürlich linksschieben und die Zwischenwerte x2 und x8 addieren.
...
Um aus einer Stelle ein ASCII-Zeichen zu machen addierst du '0' falls die Stelle in 0...9 ist und ansonsten 'a'-10 (hex in Kleinschreibung). Um Großbuckstaben zu erhalten addierst du stattdessen 'A'-10.
Die Lösung von fchk geht nicht, da der olle uC ja in hex rechnet, da kommt nur Mist raus - sorry, nicht böse gemeint, mit dem der nem ähnlichen Lösungsansatz habe ich mich schon 2 Stunden erfolglos rumgeschlagen.
So zum Vergleichen und weiterverabeiten bräuchte ich das jetzt
als 16-Bit Integer in hex, das wäre lt meinem Taschenrechner 65F4.
Hex ist eine Darstellungsart, genauso wie Dezimal und wird als Format bei der Ausgabe festgelegt. Was hat das mit der Verarbeitung zu tun?
Dafür wären die 16-Bit Integer möglicherweise ok, je nachdem, was du damit vor hast, d.h. wie du da irgendetwas weiter verarbeiten möchtest.
Was soll das sein?
0x26100 (155904 dezimal) wäre mindestens eine 24-Bit Integerzahl und hat mit 0x65F4 (26100 dezimal) nichts zu tun ('0x' sagt jeweils, dass die nachfolgende Zahl als Hexadezimalzahl zu lesen ist, d.h. 16er-System).
Die Lösung von fchk geht nicht, da der olle uC ja in hex rechnet
Der µC rechnet binär, z.B. mit 16-Bit Integer. Ob du das hinterher in Form einer Dezimal- (10er-System) oder Hexadezimalzahl (16er-System) schreibst, ist ihm egal.
Der µC rechnet binär, z.B. mit 16-Bit Integer. Ob du das hinterher in
Form einer Dezimal- (10er-System) oder Hexadezimalzahl (16er-System)
schreibst, ist ihm egal.
Oktal ginge auch noch. Oktal hätte 3 Binärstellen zum Schnellablesen, Hexzahlen 4.
(und weil das so ist, könnte man sich auch eine Tabelle erstellen)
atoi() wäre auch mein Favorit gewessen, gibts aber in C99 nicht mehr.
C99 ist die Sprache, die enthält nur intrinsische Funktionen, atoi ist eine Libraryfunktion, die gibt es so bald du die passende library, z.B. stdlib mit #include einschliesst.
Welche libraries auf deiner Plattform vorhanden sind, wissen wir natürlich nicht.
Was soll das sein?
0x26100 (155904 dezimal) wäre mindestens eine 24-Bit Integerzahl und hat
mit 0x65F4 (26100 dezimal) nichts zu tun
Lies nochmal.
Ja, du hast Recht, für manche Leute mögen Einheiten Schall und Rauch sein. Deswegen sind schon Marssonden oder Flugzeuge abgestürzt.
Für 0x26100 bräuchte man natürlich nur eine 18-Bit Integerzahl, bei byteweiser Speicherorganisation endet das eben trotzdem bei einer mindestens 24-Bit Variablen.
Mit 0x26100 als hexadezimaler Schreibweise ergibt sich binär 0b100110000100000000, d.h. als 3 Byte octal 0o460400.
Für 0x26100 bräuchte man natürlich nur eine 18-Bit Integerzahl
Mag sein, hat aber mit der Fragestellung nichts zu tun. Da kommt gar kein 0x26100 vor. Insofern: Frage nochmal lesen, solange, bis du die kapiert hast.
Ja, da hat der TO dann auch halluziniert. Die eigentliche Frage mit allen Infos steht in einem Thread, so auch hier, ganz oben. Da gibt es kein 0x26000
32, 36, 31, 30, 30
daraus die Zahl 26100 zu machen ist kein Problem.
Also ist dann ein ASCII-String "26100"?
Daraus soll nun eine echte 16-Bit Integer Binärzahl
0110010111110100 gemacht werden, damit der PIC damit
mathematisch rechnen kann? Und es soll diese 16-Bit Zahl in
Hex angezeigt werden, also als ASCII-String "65F4"?
Die 16-Bit Zahl muß also in ASCII umgewandelt werden.
Ich würde die 0110010111110100 in Vierergruppen aufteilen,
0110 0101 1111 0100. Eine Tabelle anlegen 0000 bis 1111,
und zugeordneter ASCII-Zeichen. Ein Programm schaut nun
in die Tabelle und bekommt das ASCII-Hex-Zeichen.
Den ASCII-String "26100" in Binär wandeln habe ich
erstmal keine Lösung.
