uint8 array zu const char, oder bessere möglichkeit

Irgend W. schrieb:
> "0029348593" ist halt was völlig anderes als {0x00, 0x29, 0x34, 0x85,
> 0x93}

Das ist mir bewusst, daher ja auch die frage, wie man so etwas am besten 
umsetzen könnte.
letztendlich wird ein array mit 128 bytes übergeben.

Aber dann muss ich mal weitergucken.
besten dank aber schonmal

Schau dir die readRad-Funktion an und teile sie auf.  Sie wird wohl das 
char-Array auch erstmals nach binär wandeln und dann damit was machen. 
Das "damit was machen" in eine extra Funktion packen, die dann sowohl 
von readRad als auch von dir mit dem uint8-Array aufgerufen wird.

Falls readRad aber nichts anderes als ein selbstgetricktes strol ist ...

ehm strol -> strtol, sorry.

Jens schrieb:
> gibt es eine Einfache möglichkeit den Wert irgendwie direkt zu
> übergeben? Also ohne eine extra konvertierung?

ähm, mit dem Präfix 0x und direkt als Zahl?

1

long long i=0x0029348593;

zitter_ned_aso schrieb:
> ähm, mit dem Präfix 0x und direkt als Zahl?

Jens schrieb:
> letztendlich wird ein array mit 128 bytes übergeben.

Jens schrieb:
> readRad(int *a, const char *str, int rad)
>
> readRad(&y, "0029348593", 16);

> "0029348593" ist halt was völlig anderes als {0x00, 0x29, 0x34, 0x85,
> 0x93}

Nicht wenn readRad den String schon als Hex Werte interpretiert

Jens schrieb:
> Irgend W. schrieb:
>> "0029348593" ist halt was völlig anderes als {0x00, 0x29, 0x34, 0x85,
>> 0x93}
>
> Das ist mir bewusst, daher ja auch die frage, wie man so etwas am besten
> umsetzen könnte.
> letztendlich wird ein array mit 128 bytes übergeben.

Er meinte den Dateninhalt, du wohl eher die Syntax

Zeigt doch mal die implementation von readRad oder beschreibe genauer 
was die macht

Wenn da bis zu 128 Zeichen lange hex Strings rein kommen kannst du das 
nicht anders machen (es gibt keinen einfachen Typ der so viel Daten 
aufnehmen kann)

Hier raten nur alle was deine Lösung sein könnte weil du zu wenig 
beschrieben hast, bissle mehr Infos und dann passend die Antworten auch 
zu deinem Problem

cppbert schrieb:
> Wenn da bis zu 128 Zeichen lange hex Strings rein kommen kannst du das
> nicht anders machen (es gibt keinen einfachen Typ der so viel Daten
> aufnehmen kann)

Ist natürlich quatsch was ich schreibe, sind ja nur maximal 64 bit

dann kanst wirklich einfach

Long long wert = 0x0029348593

schreiben, musst noch auf die Endianess 
(https://de.m.wikipedia.org/wiki/Byte-Reihenfolge) achten
heiss, deine Zahlen könnte verdreht raus kommen, einfach mit printf %x 
ausgeben und vergleichen

Dirk B. schrieb:
> Was macht eigentlich der Parameter rad?

Steht bestimmt fuer Radix ==> Basis,Basiszahl

Könnte also auch rad = 10 fuer dezimale Zahlen sein

D.h. macht wohl das gleiche wie: 
https://en.cppreference.com/w/c/string/byte/strtol

Dirk B. schrieb:
> cppbert schrieb:
>> Long long wert = 0x0029348593
>
> Nur das die Originalfunktion int ablegt.
> wie die 5 Byte auf 2 oder 4 int aufgeteilt wird, kann man am besten im
> Code  sehen.
>
> Oder TO zeigt, was in y geschrieben wird.

Die frage ist, wie kommt er zu dem Array mit den richtigen Werten - das 
könnte man ja auch "einfach" casten

cppbert schrieb:
>> Nur das die Originalfunktion int ablegt.

Ich denke seine readRad kann keine 128 Zeichen verarbeiten und er weiss 
das noch nicht, oder es gibt noch eine readRadL Funktion

Jens schrieb:
> diesen Wert habe ich aber nur als uint8 array
> {0x00, 0x29, 0x34, 0x85, 0x93}

Woher kommt das Array? Datei, Speicher?

Jag mal dein "0029348593" durch

https://www.scadacore.com/tools/programming-calculators/online-hex-converter/
und sag uns welches der vielen Ausgabeformate das richtige ist

Dirk B. schrieb:
> cppbert schrieb:
>> Ich denke seine readRad kann keine 128 Zeichen verarbeiten und er weiss
>> das noch nicht, oder es gibt noch eine readRadL Funktion
>
> Hinter int *a kann ja auch ein Array liegen.
> Die Länge wird halt durch str bestimmt.

Wir sind gespannt

cppbert schrieb:
> Er meinte den Dateninhalt, du wohl eher die Syntax

ich meine auch den Inhalt.
Dieser ist aber identisch wie die Werte von Hex werten.

Also ich habe einen array
uint8_t hex[128] = {0x00, 0x29, 0x34, 0x85, ... 0x93}
Diesen bekomme ich über CAN-Bus gesendet (lese den also eigentlich aus 
dem Speicher aus)
Die Funktion benötigt den wert jetzt aber in
const char hex[256] = "00293485...93";

Das es anders ist, als der Array ist mir bewust. Jedoch benötigt diese 
Funktion den Wert halt in diesem Format.

cppbert schrieb:
> Jag mal dein "0029348593" durch
>
> https://www.scadacore.com/tools/programming-calculators/online-hex-converter/
> und sag uns welches der vielen Ausgabeformate das richtige ist

Da wäre uint32 Big endian das richtige Format. Aber ich möchte den 
anderen weg.


Den Inhalt der Funktion weiß ich nicht, da diese in einer lib enthalten 
ist.

Jens schrieb:
> Da wäre uint32 Big endian das richtige Format. Aber ich möchte den
> anderen weg.

Mit der fuehrenden null kann es aber kein 32bit wert sein weil 5 bytes 
nicht in einen 4 byte uint32 passen - oder wie soll das gehen?

Noch dazu ist uns nicht klar wie 128 hex nibbles zeichen = 64 bytes in 
das int* a result passen sollen, oder ist a ein array mit n uint32?

> Den Inhalt der Funktion weiß ich nicht, da diese in einer lib enthalten
> ist.

Wie lautet die Beschreibung, Doku der Funktion? Ist die lib public?

Jens schrieb:
> Da wäre uint32 Big endian das richtige Format. Aber ich möchte den
> anderen weg.

Also so wie ich das sehe brauchst du die Funktion garnicht sondern 
kannst deinen puffer (das array) gleich in einen uint32 casten

Was fehlt ist
1. wiso passt dein 5 byte hex string in ein 4byte uint32? Werden 
fuehrende nullen ignoriert
2. Was ist das Ergebnis von readRad wenn du mehr als die 4 bytes in die 
funktion steckst also z.B. deine 128 bytes? Wie passt das?
3. Wie waere es wenn du uns einfach aufschreibst was in deinem CAN bus 
puffer alles so drin steht, oder ob du das auch nicht weisst?
4. Deine Informationstropfen machen es schwer dir einfach zu sagen was 
du machen musst

Die meisten hier haben kein Problem mif CAN, casten und Endianess :)
Nur deine Infos sind sehr lückenhaft