crc über struct c#

C# ist eine Hochsprache und da kann man sich nicht darauf verlassen das 
die Bytes in einer Struktur so hintereinanderliegen wie man das 
maschinennah gerne hätte. Deshalb ist das hier etwas 'umständlicher':
- einen MemoryStream ms erzeugen
- einen BinaryWriter bw(ms) erzeugen
- die Elemente nacheinander mit bw.Write(data) in den Stream schreiben
- aus dem Stream ein Array erzeugen mit byte[] ba = ms.ToArray();

Alternativ kann man eine Struktur mit Marshalling Attributen versehen 
und mit Pointern hantieren, aber das ist weniger im Sinne von .Net.

> - die Elemente nacheinander mit bw.Write(data) in den Stream schreiben

Das wird so (noch) nix, weil die Endianness noch nicht erklärt ist 
(betrifft hier int und int16). Abgesehen davon gehts auch ohne Umweg: 
Ein byte[] hinreichender Größe erzeugen, die Daten (unter Beachtung der 
Endianness) byteweise reinkopieren, fertig.

HTH und HF

Danke für Deine Antwort.
hast du vielleicht ein Beispiel ?

Pingo

1

struct Protocol x = ..;

2

int länge = sizeof(struct Protocol) -sizeof(int16*) +x.len;

3

byte[] b = new byte[länge];

4

int i = 0;

5

b[i] = x.adress; i++;

6

b[i] = x.command; i++;

7

b[i] = x.len; i++;

8

9

for (int j = 0; j < x.len; j++) {

10

   b[i] =  x.recivebuffer[j]       & 0xFF; i++;

11

   b[i] = (x.recivebuffer[j] >> 8) & 0xFF; i++;

12

}

13

14

b[i] =  x.Rtimeout       & 0xFF; i++;

15

b[i] = (x.Rtimeout >> 8) & 0xFF); i++;

Der Süntacktische Schugar verbleibt beim geneigten Hausaufgabenmacher 
;-) Und ich kann hier gerade weder Syntax noch Semantik überprüfen weil 
ich gerade keinen Siehäsch-Compiler zur Hand hab - die Grundidee sollte 
aber rüberkommen.

Ob Big- oder Little-Endian (hier: letzteres) steht in der Protokolldoku. 
Ob die crc32 mit dazgehört, ggf. mit Nullen aufgefüllt, ob die Eingabe 
sonstwie aufgefüllt werden muss oder sonst noch was fehlt, das steht in 
der Doku :-)

HTH und HF

Ich stelle grad fest ein int ist 4 Bytes groß, also musses heissen..

1

[..]

2

int länge = sizeof(struct Protocol) -sizeof(int16*) +x.len *4;

3

[..]

4

for (int j = 0; j < x.len; j++) {

5

   b[i] =  x.recivebuffer[j]        & 0xFF; i++;

6

   b[i] = (x.recivebuffer[j] >>  8) & 0xFF; i++;

7

   b[i] = (x.recivebuffer[j] >> 16) & 0xFF; i++;

8

   b[i] = (x.recivebuffer[j] >> 24) & 0xFF; i++;

9

}

</ingrid>

Das die BinaryWriter Lösung nur Little-Endian kann ist richtig, sieht 
aber eleganter aus, vor allem wenn noch 32Bit Integer, Floating Point 
oder Textfelder in das Protokoll reinsollen. Ist dann vielleicht 
geschmacksache und glücksache das die Formate passen.

und wenn der receiveBuffer[] eine unbestimmte Länge hat wird 
sizeof(struct Protocol) nichts brauchbares liefern.

> und wenn der receiveBuffer[] eine unbestimmte Länge hat wird
> sizeof(struct Protocol) nichts brauchbares liefern.

Der soll genau die Größe der Stuktur liefern (inklusive des Zeigers auf 
das Array, der danach wieder abgezogen wird - oder ist das in Siehäsch 
anders definiert?). Die Größe des Datenpakets interpretiere ich jetzt 
einfach mal als das Feld len. Damit weiss man dann genau wie groß das 
Datenpaket wirklich ist (in Bytes).

Ob Big oder Litte, das steht wie gesagt in der Protokollspeck. Wie 
Floats anzugeben sind ebenso. Und der ganze Rest natürlich auch :-) In 
der Regel ist es zweckmäßig ebendieses Speck zu lesen ;-)

HTH und HF

Vielen Dank,
für Eure Hilfe !


PINGO