Hex to Dec -> C

Schau mal ob das dein Problem lösen kann:

https://cplusplus.com/reference/cstdlib/strtol/

1. Parameter: Input: Pointer auf den HexString.
2. Parameter: Output: Hier wird ein Pointer auf das erstes Zeichen nach der geparsten Zahl zurück gegeben, einfach 0 übergeben, wenn du es nicht brauchst.
3. Parameter: Input: Die Bases der Zahl, bei Hex ist es 16

Udo S. schrieb:

Sage ich ja auch :-)

Nur hattest Du keine Lösung dazu geschrieben.

@TO: Die (jetzt) oberst Antwort ist richtig und gut. Alles weiteren in Summe eher verwirrend.

John P. schrieb:

Oliver S. schrieb:

Wenns wirklich so ist, rechne halt zu Fuß um: abs(84/16) *10 + Rest *16

Geil! Vielen Dank auf sowas hatte ich gehofft. Kurz nachgerechnet passt es. Ich probiere es gleich mal aus.

???

Sollte das nicht eher (84/16)*10+Rest sein?

Also (84/16)×10+84%16 oder gleichwertig

Michael O. schrieb:

OutVal = (BCDVal >> 4) * 10 + (BCDVal & 0x0F);

Ich hatte mir mal für die Umwandlung DEZ ←→ BCD folgendes gebastelt:

1

 uint8_t bcd_to_dez (uint8_t bcd)

2

 {

3

   uint8_t einer = (bcd & 0x0F);

4

   uint8_t zehner = (((bcd >> 4) & 0x0F) * 10);

5

   return (einer+zehner); 

6

 }

7

/***********************************************************************/

8

 uint8_t dez_to_bcd (uint8_t dez)

9

 {

10

    uint8_t hex_zehner = dez/10; 

11

    uint8_t hex_einer = dez%10;

12

    return hex_einer + (hex_zehner << 4);

13

 }

bcd_to_dez deckt sich mit dem Vorschlag von Michael O.; er hat es nur etwas kompakter geschrieben ...

Michael O. schrieb:

Und um die (rechenintensivere) Division mit Restbildung zu umgehen shiftet man einfach die oberen 4 bit nach rechts und maskiert die oberen 4 bit für die Addition der Einerstelle aus.

Jeder wie er mag, der Compiler macht (bei unsigned skalaren) den gleichen Code raus.

Oliver S. schrieb:

Da kommt wirklich der Dezimalwert des Hex-Wert in einem int? Wer macht denn sowas?

Nennt sich BCD, eine kompakte Darstellung für mehrstellige Dezimalzahlen, die leicht nibble-weise zu dekodieren ist, z.B. auch direkt per Hardware mit dem 74xx47.

Das hat mit CHatGPT ausgegeben:

1

#include <stdio.h>

2

#include <stdlib.h>

3

4

int hex_to_decimal(int hex) {

5

  int decimal = 0;

6

  int digit;

7

  while (hex > 0) {

8

    digit = hex % 10;

9

    decimal = (decimal * 16) + digit;

10

    hex /= 10;

11

  }

12

  return decimal;

13

}

"Die Funktion nutzt eine Schleife, um durch die Ziffern der Hexadezimalzahl zu iterieren. Sie nimmt die letzte Ziffer der Hexadezimalzahl, indem sie den Rest von hex durch 10 dividiert, und fügt sie zur Dezimalzahl hinzu. Dann teilt sie hex durch 10, um zur nächsten Ziffer zu gelangen. Die Schleife wird fortgesetzt, bis hex 0 ist."

Und das macht ChatGPT bei BCD to Dez:

1

#include <stdio.h>

2

3

int bcd_to_decimal(int bcd) {

4

  int decimal = 0;

5

  int digit;

6

  int multiplier = 1;

7

  while (bcd > 0) {

8

    digit = bcd % 10;

9

    decimal += digit * multiplier;

10

    multiplier *= 10;

11

    bcd /= 10;

12

  }

13

  return decimal;

14

}

Und hier eine hex-bcd to dez:

1

#include <stdio.h>

2

#include <stdlib.h>

3

4

int hex_bcd_to_decimal(int hex_bcd) {

5

  int decimal = 0;

6

  int digit;

7

  int multiplier = 1;

8

  while (hex_bcd > 0) {

9

    digit = hex_bcd % 10;

10

    decimal += digit * multiplier;

11

    multiplier *= 16;

12

    hex_bcd /= 10;

13

  }

14

  return decimal;

15

}

Ja, dass man den Mod-Wert, bzw. die einzelnen Mod-Werte bei der Umwandlung auf den Stack pushen kann, bzw. in einen String schieben, um dann die Liste der Modwerte umgekehrt nach oben auszulesen, ist hier ein wenig untergegangen, oder nicht?

Ein anderer Punkt ist, bei so Uhren müsste man eigentlich noch zu einem 60er System übersetzen.

50/80 ist deswegen schwierig (bzw. sehr leicht), weil die Zahlensysteme (also hier Hexi und Dezi) gewisse Ähnlichkeiten haben. Ich vermute mal, diese Zusatzinfogeschichte hat die Verwirrung ausgelöst. Ist ja auch nicht uninteressant ;)

Die Hexwerte selber helfen, sofort die Bitwerte zu sehen. Man könnte also auch von den Bits her nach Dezi übersetzen. Oder eben erstmal von Hex nach Bits.

BCD-Zahlen sind noch mal eine ganz andere Rechnung. Das sind einfach die nomalen Dezimalen Zahlen also solche im Rechner abgebildet. ABCDEF (wie im Hexadezimalsystem gibt es da nicht und die Umrechnung ist aufwendig, aber teilweise gibt es Hardwarebeschleunigungen.

Was hier auch noch fehlt, wären ein paar Zusatzbeispiel für die Ausgabe. Bei 54/84 sehe ich nur Hex/Dez-Werte und eine ungefragte Konvertierung - was ja nun auch der ghci so gerne macht, wenn man einfach mit Hexwerten rechnen möchte.

Lothar M. schrieb:

rbx schrieb:

Lothar M. schrieb:

Yalu X. schrieb:

John P. schrieb:

ich hab eine Denkblockade.

Und der ganze Thread bloß weil der John sein Gehirn nicht angeworfen gekriegt hatte. Es ist wirklich erschreckend, wie sehr es hier an Grundlagenwissen fehlt. Aber ungeachtet dessen wollen eben dieselben Leute mit ihrem Steckbrett, Arduino oder ST-Cube-Zeugs zum Mond fliegen oder etwas gleichgroßes veranstalten. und unter

C.K. schrieb:

https://cplusplus.com/reference/cstdlib/strtol/

macht man's heutzutage nicht mehr.

W.S.

Darf ich noch was aus dem ghci nachreichen? Nur um Missverständnisse zu vermeiden (man kann nämlich leicht durcheinanderkommen). Bei kleinen Werten braucht man nur durch 16 teilen und den Rest draufzählen.

1

[rbx@fe1 ~]$ ghci

2

GHCi, version 8.8.4: https://www.haskell.org/ghc/  :? for help

3

Prelude> let hexzuruk ab = (div ab 16, mod ab 16)

4

Prelude> hexzuruk 84

5

(5,4)

6

7

Prelude> hexzuruk 73

8

(4,9)

Da darf man dann nicht vergessen/übersehen, dass da normalerweise noch abcdef kommt, die aber bei bei dieser Art von Rückkonvertierung kaum noch eine Rolle spielen.

1

Prelude> hexzuruk 74

2

(4,10)

3

4

Prelude> 0x53 + 0x1

5

84

6

;)

Yalu X. schrieb:

aber das war dir wohl zu C-ish ;-)

Eigentlich nicht, ich weiß ja, wie man es in asm macht. Aber das Beispiel mit dem uncurry finde ich schon gut. Auch wenn es natürlich die Schwierigkeit bis Unmöglichkeit der Übersetzung ein wenig verschleiert. Die Frage ist doch: wenn die Ausgangszahlen Dezimalzahlen sind, warum bleiben die das nicht? Zahlensysteme sind immer eindeutig. Doppelte Zahlen kommen da nicht vor. Die hätte man aber, wenn man abcdef nicht konkret berücksichtigt. 74 ist nicht 50, sondern 7A.

Mir ging es eher darum, darauf hinzuweisen, wie man Denkblockaden umgehen kann, beim Hin - und Herkonvertieren nicht durcheinander kommt, und die gelegentliche Schönheit des Hexadezimalsystems nicht übersieht, und ansonsten auch nur um ein wenig Austausch und die Dinge nicht allzu ernst nehmen ;)

rbx schrieb:

74 ist nicht 50, sondern 7A.

Was natürlich auch schon wieder Unfug ist..nix 7A - 4A war gemeint, entschuldigung. (man kann durcheinander kommen..) (7A war der Jump nach oben)

Das macht es auch nicht besser. Wenn man das ausgiebt kommt "J" heraus.

Meine Kenntnisse in C sind rudimentär. Aber es sollten doch einfache Anweisungen zur Umwandlung von Datenformaten geben. Selbst in Assembler genügen da weniger als 10 Zeilen.

John P. schrieb:

ich kriege die Sekunden von einer App als Hex Wert gesendet.

Beispiel: 54 sec

wird gesendet als int mit Wert 84[Dec] was einer 54[Hex] entspricht.

Wie kriege ich jetzt die 54[Hex] in eine 54[Dec] gewandelt?

Mir wird da ganz schwindelig. Welche APP? Wie sieht die Bytefolge konkret aus? Vermutlich wird BCD geschickt. 54H/84Dec ergibt "T".

michael_ schrieb:

Selbst in Assembler genügen da weniger als 10 Zeilen.

in C reicht:

1

 x-=(x/16)*6;

für den TO, wenn der Wert in x bleibt

michael_ schrieb:

Meine Kenntnisse in C sind rudimentär. Aber es sollten doch einfache Anweisungen zur Umwandlung von Datenformaten geben.

mit printf geht da so einiges..

Man muss aber auch unterscheiden zwischen Zahlensystemen, und Ausgabegeschichten (ASCII)/printf etc. oder Abbildungsstrategien im Rechner (BCD z.B.).

54Hex nach 54Dez geht sowieso schlecht und macht auch keinen Sinn. BCD-Zahlen haben eine ganz eigene Rechnerei. Echt was für µc-Profis.

Am sichersten ist es, wenn es von Hex nach BCD geht, erst nach Dez (durch "A" teilen..) und diese Resultate dann als BCD behandeln - und dass ist bei Intel-Asm einfach, hat halt eine eigene Unterabteilung. Aber auch nur für die Rechnerei. Bei DOS kommt die Zahl aus dem "Rechen-Register" typischerweise nach DL, und von da aus wird dann 30 draufgezählt für die Ausgabe per ASCII-Codierung. Völlig egal, ob aus dem Rechenregister für BCD-Zahlen, oder ob aus einem normalen Register. Zahl bleibt Zahl bzwl. eine 7 bleibt eine 7, eine 6 bleibt eine 6, eine 5 bleibt eine 5..

Da aber auch die Problembeschreibung / Ist/Soll vom TE oben nicht ganz durchsichtig bzw. logisch ist, denke ich mal das ist ein Teil des Problems an sich: Die Zusammenhänge des Geschehens nicht so recht durchblicken. Oft soll es ja schon helfen, das Problem zu verstehen, wenn man die Frage etwas genauer formulieren kann.

michael_ schrieb:

Das macht es auch nicht besser. Wenn man das ausgiebt kommt "J" heraus.

4A ist die Hexzahl für 74. 0111 0100 - Der ASCII-Code für 4A ist typischerweise 0011 0100 0100 0001 und hat nichts mit dem Zahlensystem zu tun, sondern nur mit der Ausgabe. 7A war der Hexwert für den ASM-Befehl JA - welcher Jump if above meinte. Ich hatte das deswegen durcheinander gebracht, ganz genau weil gewisse Dinge so merkwürdig sind: 7A, JA - 4A, J (Ja Ja..). - 4B -> K (ASCII) 4C -> L(ASCII).