ich bin gerade dabei, ein Programm zu schreiben, in dem eine Adresse in Hexadezimal von einem PC gesendet und weiter verarbeitet werden soll. Die Adresse lese ich mit fgets ein. Das Problem ist, dass der Wert 0x00 auch in der Mitte der Adressen vorkommt und nicht nur am Ende z.B. D3 88 00 FF FF 01 00. Die Adresse wird nur bis zu 88 eingelesen, schätzungsweise da die erste 00 als Ende angesehen wird. Gibt es eine Möglichkeit die komplette Adresse einzulesen? Programmiert wird in der Sprache C.
#include <stdio.h>
#include <string.h>
int main(){
char adresse[8];
fgets(adresse, 8, stdin);
printf("%s", adresse);
in dem eine Adresse in Hexadezimal von einem PC gesendet und weiter
verarbeitet werden soll.
Mein Tipp: nimm ASCII-Zeichenketten, dann kannst du auch die üblichen ASCII-Steuerzeichen für Textanfang (STX) und Textende (ETX) oder Zeilenende (wie z.B. 0x0a und 0x0d für CR/LF) verwenden.
Die Adressen sind schon so vorgegeben, die kann ich
nicht ändern.
Dann soll derjenige das lösen, der sich dieses krude Format ausgedacht hat.
Ein Datenformat muß so definiert sein, daß sich Daten und Steuerinformationen eindeutig zuordnen lassen. Ansonsten hat der Entwickler gepennt oder er ist unfähig.
Geht leider nicht. Die Adressen sind schon so vorgegeben, die kann ich
nicht ändern.
Wie sichert der, der dieses Format vorgegeben hat, die Übertragung ab, wenn in den Daten selber kein eindeutiges Ende erkennbar ist?
Was passiert im EMV-Labor? Oder wenn ich da mal mit meinem "Bursttest für Anfänger"(**) aka. Viehtreiber draufhalte und ein fehlerhaftes Start- oder Datenbit erzeugt wird?
Werden diese Werte gelesen, dann liegt kein Hex-Format vor. Zahlen im Hexformat werden immer als lesbare ASCII-Zeichen (0=0x30, 1=0x31, 2=0x32 ...) übertragen.
Die Daten liegen im Binär-Format vor!
Zeichenweise lesen:
1
#include<stdio.h>
2
3
intmain(){
4
charc;
5
6
printf("Bitte geben Sie ein Zeichen ein: ");
7
8
// Verwende getchar, um ein Zeichen einzulesen
9
c=getchar();
10
11
printf("Sie haben das Zeichen '%c' eingegeben.\n",c);
12
13
return0;
14
}
Oder Blockweise:
#include <stdio.h>
1
intmain(){
2
FILE*file;
3
charbuffer[100];// Ein Puffer, um Daten zu speichern
ähhhm, das Lesen mit fgets dürfte funktioniert haben. Stop Character ist „end of line“ und nicht Null. Und bei EOF stoppt fgets ebenfalls.
Die Ausgabe als String funktioniert natürlich nicht. Also einfach mal mit der schon vorgeschlagenen for-Schleife probieren. Als Ausgabeformat würde ich %.2hhx nehmen.
Als Funktion würde ich fread() verwenden. Siehe Beispiel.
fgets() ist ungeignet weil es für c-Strings ausgelegt ist.
Bei binären Daten ist fread() besser geeignet.
Gibt es eine Möglichkeit die komplette Adresse einzulesen?
Wie ist die Adresse formatiert? Gib mal drei Bespiele. Die zwei Ziffern
00 sollten das Lesen nicht stoppen ...
LG, Sebastian
Wenn man die Daten, dazu zählt auch die Adresse, mit String-Funktionen liest, dann wird es nicht gelingen Adressen in allen Kombinationsmöglichkeiten zu empfangen. Die Stringfunktionen erlauben keinen transparenten Empfang aller Bytekombinationen.
Üblicherweise verwendet man für ein transparentes Lesen die Funktion fread().
Die Variable buffer kann die Struktur sein, welche die Daten in ihrer Reihenfolge im Telegramm abbildet.
Was sind HEX-Zahlen?
Bekommst du jetzt einen Zeichenkette (String, ASCII Zeichen) oder Bytes gesendet? Bei einer Zeichenkette ist das 8. Zeichen schon bei der ersten 00.
Übrigens ist auch das Betriebssystem hier wichtig, denn stdin arbeitet defaultmäßig im Textmodus. Falls das Betriebssystem z.B. Windows sein sollte, führt der Stream in diesem Modus beim Lesen auch schon Änderungen durch, noch bevor die Daten im Programm ankommen. Dann muss man stdin erst mit freopen() auf den Binary-Modus umschalten.
Wie sichert der, der dieses Format vorgegeben hat, die Übertragung ab,
wenn in den Daten selber kein eindeutiges Ende erkennbar ist?
Ich würde jetzt bei so einem Format erwarten, dass Adressen keine beliebige Länge haben, sondern immer gleich lang sind und sich daraus ziemlich eindeutig das Ende ergibt.
Für die Hexadezimaldarstellung einer Zahl ist lediglich festgelegt, dass
ein ein Stellenwertsystem verwendet wird, in dem jede Stelle einen Wert
von 0 bis 15 hat, wobei die Werte 10 bis 15 in der für Menschen lesbaren
Schreibweise üblicherweise mit den Buchstaben A bis F notiert werden.
Für die Art und Weise, wie in der Computertechnik die einzelnen Ziffern
jeweils in Gruppen von mehreren Bits codiert werden, gibt es viele
Möglichkeiten und IMHO keine Norm, die einer dieser Möglichkeiten den
Vorzug gibt. Die Codierung jeder Ziffer als ASCII-Symbol ist nur eine
davon.
Im Fall des TE (der sich ja nicht mehr meldet) sind die Hexziffern
vermutlich als gepackte 4-Bit-Gruppen (Nibbles) codiert, was äquivalent
ist mit einer Binärdarstellung, die die Binärziffern als gepackte
1-Bit-Gruppen codiert und der üblichen internen Darstellung von
Integer-Zahlen im Hauptspeicher von Computern entspricht.
Im Fall des TE (der sich ja nicht mehr meldet) sind die Hexziffern
vermutlich als gepackte 4-Bit-Gruppen (Nibbles) codiert, was äquivalent
ist mit einer Binärdarstellung,
Das ist dann aber nicht "hex", sondern eben binär.
die die Binärziffern als gepackte 1-Bit-Gruppen codiert und der üblichen
internen Darstellung von Integer-Zahlen im Hauptspeicher von Computern
entspricht.
Du meinst das Dualsystem, bzw. für vorzeichenbehaftete Werte dessen Zweierkomplement.
Im Fall des TE (der sich ja nicht mehr meldet) sind die Hexziffern
vermutlich als gepackte 4-Bit-Gruppen (Nibbles) codiert, was äquivalent
ist mit einer Binärdarstellung,
Das ist dann aber nicht "hex", sondern eben binär.
Das kann als etwas ähnliches wie packed BCD angesehen werden, nur eben
für Hexadezimal- statt Dezimalziffern. Man könnte es deswegen auch
"packed BCH" (Binary Coded Hexadecimal) nennen. Da im Gegensatz zu BCD
der Wertebereich der einzelnen Nibbles voll ausgenutzt wird, ist es
letztendlich dasselbe wie binär codiertes Vierersystem und die übliche
Binärdarstellung, nur die Betrachtungsweise ist eine andere.
