Kommunikation über serielle Schnittstelle: Polling serielle Schnittstelle vs mit seriell Port DataReceived Ereignisse

Question

Ich bin die Überprüfung nur einige Codes, den ich mit der seriellen Schnittstelle in C # auf CF2.0 kommunizieren schrieb. Ich verwende DataReceived Ereignis nicht, da sie nicht zuverlässig ist. MSDN heißt es:

  

Die DataReceived Veranstaltung ist nicht   gauranteed für jedes Byte erhöht werden   empfangen. Verwenden Sie die Eigenschaft BytesToRead   um zu bestimmen, wie viele Daten zu überlassen   in dem Puffer gelesen werden.

abfragen ich den Port mit read () und einen Delegaten haben, der die Daten verarbeitet, wenn es gelesen wird. Ich habe auch gelesen, dass irgendwo „Polling ist schlecht“ (keine Erklärung gegeben).

Irgendwelche Ideen, warum Polling könnte schlecht sein? abgesehen von dem üblichen Threading Verwarnungen - Ich habe einen eigenen Thread (Hintergrund-Thread), dass Umfragen des Port, der Thread beendet wird, nachdem die Daten gelesen werden, alle getestet und funktioniert gut

.

Answer 1

So wie ich gelesen, dass Sie möglicherweise ein Ereignis für mehrere Bytes bekommen, anstatt ein Ereignis pro Byte. Ich würde erwarten, noch ein Ereignis zu erhalten, wenn Daten bereit ist, und nicht habe es ganz ein paar Bytes „überspringen“.

Ich habe immer dieses Ereignis verwendet haben, und haben keine Probleme mit ihm.

Answer 2

Konventionelle Weisheit besagt, dass „Polling schlecht ist“, weil es am Ende oft ein CPU-gebundenen Prozess zu sein. Wenn Blockierung I / O statt verwendet wird, dann ist die CPU für andere Prozesse zur Verfügung, bis das Ereignis eintritt.

Das heißt, es in der Regel möglich ist, die Dinge so einzurichten, dass eine Umfrage für eine (kurze) Timeout wartet, bevor er zurückkehrt, wenn keine Zeichen verfügbar sind. Wenn ein geeignetes Timeout gewählt wird, dann einfache Abfrageschleife wird deutlich weniger CPU-Zeit und andere Prozesse erhalten auch ausgeführt werden.

Ich habe nicht serielle Schnittstellen von C # überhaupt verwendet, aber ich werde eine Vermutung zu wagen, was die Dokumentation von

gemeint

  

Das DataReceived Ereignis wird nicht garantiert für jedes Byte empfangen angehoben werden. Verwenden   die BytesToRead Eigenschaft, um zu bestimmen, wie viele Daten verbleibt in dem Puffer gelesen werden.

ist, dass Sie nicht pro Zeichen ein Ereignis zu bekommen erwarten. Es könnte unter Umständen liefert die Veranstaltung mit mehr als einem Zeichen zur Verfügung. Einfach abrufen alle verfügbaren Zeichen in der Event-Handler, und alles wird gut.

Edit: auf einem Leser Thread einen blockierenden Aufruf tun könnte insgesamt die beste Antwort sein. Es ist nicht Polling per se, da der Thread blockiert wird, bis Zeichen ankommen. Sie könnten die Puffergrößen und einige der Einstellungen des seriellen Schnittstelle zu stimmen müssen, wenn Sie die Daten verarbeiten müssen, wie es kommt und nicht in festen Größe Brocken.

Answer 3

Ich bin ziemlich sicher, der zugrunde liegende Code seriellen Port-Treiber Interrupt getrieben, auch wenn die Blockierung Read-Aufruf.