C# serielle Schnittstelle: Empfangene Daten für Event festlegen, Problem

[Stephan (Gast)]

Hallo,

ich sitze seit einiger Zeit an einer Übertragung von einem µC zu meinen 
PC. Da ganze ist auf einem RS485 Bus (erweiterbar für 
Motorsteuermodule). Für RS 485 benutze ich ein Protokoll mit 9 Byte. In 
meinem PC Programm versuche ich nun die neun Byte zu empfangen und zu 
verarbeiten. Da habe ich aber gleich mein Problem.
Ich benutze eine freie Bibliothek für die Schnittstelle. Dort habe ich 
einen Eintrag in der Sendefunktion und Empfangsevent erstellt. So weit 
so gut.
Das Event wird aber standardmäßig nach unbestimmter Anzahl empfangener 
Bytes gefeuert (min 1 Byte). Dazu habe ich dann einen Buffer 
implementiert mit zwei Laufvaribalen (Anfang und Ende im verwendeten 
Buffer). Im Empfangsevent habe ich einen Suchalgorithmus implementiert 
der den Buffer nach der Adresse durchsucht und einen CRC Check danach 
ausführt. Problem hierbei manchmal wurde ein ganzer Protokollstring 
einfach ignoriert. Beim debuggen iss mir dann aufgefallen das die 
Laufvariablen für Anfung und Ende immer beim Aufruf "0" sind.
Dann habe ich die Variable "ReceivedBytesThreshold" gefunden und diese 
auf die Länge meines Protokolls (Länge gleich 9) gestellt. Damit dachte 
ich sind meine Probleme gelöst. Aber falsch gedacht. Trotz dessen wird 
hin und wieder ein Event ausgelöst was nur 8 empfangene Bytes 
beinhaltet.

ALs Anhang mal mein Code für den seriellen Schnittstellenmanager, der 
Interesante Teil ist unter der Region ComPort_DataReceived zu finden. 
Der erste Teil der auskommentiert ist, ist der der mit einem Byte ein 
Event auslöst der andere der mit neun Byte läuft.
Vielleicht kennt ja einer so ein Verhalten und es ist möglich irgendwie 
das Event wirklich nur dann zu erzwingen. Oder vielleicht gibt es auch 
eine andere Lösung und jemand kann mir helfen.

greetz
Stephan

[AkkiSan (Gast)]

Genau das ist der Grund, weshalb man derartige, serielle
Übertragungen üblicherweise in ein Paketchen packt:

[DLE] [STX] [DATA] [DLE] [ETX]

Nur so sind Start und Ende, auch im Fehlerfall, eindeutig 
identifizierbar.
(Es gibt natürlich noch viele andere Möglichkeiten...)