SerialPort und 115 kbps

15/11/2007 - 19:46 von johannes | Report spam
Hallo allerseits,

ich habe (mal wieder) ein Problemchen mit der seriellen Schnittstelle
(.NET 2.0 VS2005 csharp).

Und zwar ist es diesemal vermutlich die hohe Bitrate von 115 kbps, die
mir Probleme macht.

Ich habe eine einfache WinForm geschrieben, die per Knopfdruck Daten
von Seriell abruft und in in Excel speichert. Die Daten liefert ein
spezielles Embedded Device, d.h. die 115 kbps sind vermutlich
'gnadenloser' als wenn sie von einem anderen Windows-Rechner erzeugt
werden.

Die Daten sind periodische Daten, wobei der Anfang einer Periode durch
ein Steuerzeichen (STX, also \02) definiert ist. Von diesen Daten soll
die Applikation 10 Perioden aufnehmen. Also habe zeichnet er solange
auf, bis er 12 STX-Zeichen hat. Dann schneidet er den Anfang und das
Ende raus.

Die Daten lese ich mit SPort.ReadExisting() ein.

Obwohl ich den Anfang rausgeschnitten habe, ist die 1. (gültige)
Periode manchmal fehlerhaft. Wir sind dann darauf gekommen, dass am
Anfang vermutlich der serielle Puffer nicht geleert ist und deshalb
dort noch ungültige Zeichen sind.

Ursprünglich wollte ich nach jeder Periode einen kurzen Verzögerungs-
Timer starten und einen Label in der GUI updaten, damit der Benutzer
schön sehen, kann, welche Periode gerade aufgezeichnet wird. Davon bin
ich aber weggekommen, hat einfach nicht funktioniert. Er hat oft die
1. Periode nicht korrekt wiedergegeben. Entweder waren zuviele oder
zuwenige Werte drin.

Jetzt mache ich es auf die harte Art: Ich polle einfach mit
SPort.ReadExisting() solange, bis die notwendige Anzahl von Zeichen
vorhanden ist, nix wird mehr geprüft. Die GUI ist natürlich auch
wàhrend dessen geblockt.

Vorher habe ich zu Begin den Puffer geleert (ebenfalls mit
SPort.ReadExisting()) und dann gleich einen benutzerdefinierten Event
abgeschickt. Offenbar geht das schon zu langsam (in Windows weiß man
ja nie, wann eine Message ankommt), also leere ich jetzt den Puffer
direkt bevor die Aufzeichnung beginnt.

Jetzt scheint es zumindest mit einer Applikation an einem anderen PC
zu klappen, die das Embedded Device simuliert, aber die serielle
Schnittstelle unter Windows scheint mir wie gesagt etwas 'gesoftet'.
Mal sehe, ob das mit der realen HW auch so funktioniert.

Frage: Ist Windows/.NET da schon am Ende, oder mache ich was falsch?
Vielleicht kann jemand noch was von seiner .NET-Erfahrung mit 115kb/s
seriell berichten.

Viele Grüße

Johannes
 

Lesen sie die antworten

#1 Thomas Scheidegger
15/11/2007 - 20:32 | Warnen spam
Hallo Johannes

Ist Windows/.NET da schon am Ende, oder mache ich was falsch?
Vielleicht kann jemand noch was von seiner .NET-Erfahrung mit 115kb/s seriell berichten.




115kb/s sind für aktuelle PCs/Windows eine Nebensàchlichkeit.
Voraussetzung ist die korrekte Konfiguration (Geràte-Manager, Ports)
der sog. Hardware-FIFOs.
Mit 16 Zeichen Zwischenspeicher (Interrupt-Level default beim 14.)
kommt eigentlich sogar ein stark belasteter Rechner bei 115kb/s mit,
sprich es gehen beim Empfang keine Datenbytes 'verloren'.
Die nachfolgenden Software-Buffer (Windows Serial Device Driver)
[im Prinzip via NET: SerialPort.ReadBufferSize]
dürften eh mehr als genug gross sein.

Obiges gilt aber nur für 'legacy' Serial-Ports (typ.: fix eingebaute Ports, '16550'),
irgendwelche neuere Zusatz-Adapter via USB/PCI/Ethernet usw. sind stets spezieller.


vermutlich der serielle Puffer nicht geleert ist



im Prinzip: SerialPort.DiscardInBuffer



ReadExisting()
Die GUI ist natürlich auch wàhrend dessen geblockt.



die Bedienung eines 'zeitkritischen' Protokolls aus dem GUI-(Thread)
ist ein fragwürdiges Konzept.
Ein Worker-Thread scheint mir da passender.

Daneben ist anzumerken, dass die .NET-SerialPort -Klasse leider keine sonderlich
brilliante Implementation darstellt (Stream/Thread-Mixtur).
Im Zweifelsfall hat man per Win32/PInvoke wesentlich bessere/direktere Kontrolle/Timing.


aber die serielle
Schnittstelle unter Windows scheint mir wie gesagt etwas 'gesoftet'.
Mal sehe, ob das mit der realen HW auch so funktioniert.



auch das Senden mit 115kb/s sollte mit Windows genauso schnell sein (mit FIFOs),
man sollte aber natürlich nicht zB Write/Send einzeln für jedes Zeichen aufrufen,
sondern möglichst grosse Pakete (Byte-Array) aufs mal absenden.
Wenn es trotzdem Unterschiede gàbe,
dann stimmt evtl. etwas mit den Stop-Bits nicht, oder ungenaue Baudraten usw.





Thomas Scheidegger - 'NETMaster'
http://www.cetus-links.org/oo_dotnet.html - http://dnetmaster.net/

Ähnliche fragen