Protokoll-Kommunikation mit einem IC in .NET abbilden -> HowTo?

Byte-Array zusammenbauen mache ich immer per MemoryStream (einfach 
rein-schreiben und anschließen .ToArray() aufrufen)

Ich würds vermutlich einfach so bauen:

Für Senden eine Helfer-Funktion wie z.B. sendMessage(byte commandId, 
byte[] payload) basteln.

Beim Empfangen: Nachricht parsen, und an eine Funktion übergeben:

1

void handleMessage(byte commandId, byte[] payload)

2

{

3

    if (commandId==XYZ)

4

    {

5

        handleCommandXYZ(payload); // handleCommandXYZ darf dann den payload irgendwie zerflücken.

6

    }

7

    ....

8

}

...sofern man nicht gerade tausende oder riesige Nachrichten bekommt, 
dürfte das ständige Kopieren von Daten praktisch nicht bemerkbar sein.

@ bluppdidupp:
> per MemoryStream
Danke, ich les mir das mal durch.

> ...sofern man nicht gerade tausende oder riesige Nachrichten bekommt,
> dürfte das ständige Kopieren von Daten praktisch nicht bemerkbar sein.
Sehe ich auch so, da bei diesem IC die UART-Übertragungsrate max. 
115200Bd ist. Im SPI-Modus isser natürlich schneller, aber da ist dann 
eh das SPI-Interface zwischen Rechner und IC der Flaschenhals.

Ralf

Hallo,

die Schichtenmodelle haben schon ihre Vorteile. Start, Länge, CRC 
gehören in eine andere Ebene wie die Nutzlast. Z.B. muss man sich mit 
der Bedeutung der einzelnen Bytes erst beschäftigen, wenn eine Message 
mit CRC korrekt empfangen wurde, bei einem Fehler fordert die 
Protokoll-Ebene selbstständig ein erneutes Senden an.

In embedded Systemen würde ich daher den Empfang bis zur CRC-Auswertung 
im Treiber lösen und nur fertig empfangene Messages an die nächsthöhere 
Ebene übergeben. Unter Windows will man natürlich Treiber-Programmierung 
vermeiden, da würde ich 3 Ebenen verwenden, den Windows-Treiber, auf den 
man keinen Einfluss hat, den Protokolltreiber und die 
Nutzlastauswertung. Dadurch kann man z.B. den Protokolltreiber wechseln 
ohne an der Nutzlast was ändern zu müssen. Auf die Art schreibe ich 
Protokolle, die je nach Einstellung mit einer seriellen Schnittstelle, 
Ethernet oder USB betrieben werden.

Ich erstelle für Antwort-Messages normalerweise eine Klassen-Hierarchie 
mit einer Grundklasse und Ableitungen für jede Kommandoart. D.h. die 
Message ist ein Objekt. Verschiedene abgeleitete Klassen können durchaus 
mal ein Array, eine Struktur usw. oder eine Zusammensetzung davon als 
Felder haben. Für ein bestimmtes Kommando z.B. ein Zeit-Record mit Jahr 
(word), Monat, Tag usw. (byte), danach 10 Messwerte (IEEE float), und so 
weiter.

Gruss Reinhard

Hallo Reinhard,

das hört sich gut an. Den IC selbst wollte ich ebenfalls als Objekt 
implementieren, da ich evtl. mehrere gleichzeitig betreibe. Die 
Kommandos und deren Antworten als Objekte zu implementieren war auch ein 
Gedanke, den ich hatte, aber dazu fehlt mir noch ein ausgereifter 
Ansatz.
Ich werd mich mal ransetzen und notieren, was denn ein Objekt "Kommando" 
so an Eigenschaften hat. Vielleicht komm ich dann der Lösung einen 
Schritt näher :)

Ralf