Problem mit zwei .NET-Threads und Hardwarezugriff

8

Ich erstelle eine Anwendung, die über den USB / RS232-Konverter FT2232H mit dem Gerät kommuniziert. Für die Kommunikation verwende ich die FTD2XX_NET.dll-Bibliothek von der FTDI-Website.
Ich benutze zwei Threads:

  • erster Thread liest kontinuierlich Daten vom Gerät
  • Der zweite Thread ist der Hauptthread der Windows Form Application

    Ich habe ein Problem, wenn ich versuche, Daten auf das Gerät zu schreiben, während der Thread des Empfängers läuft. Der Haupt-Thread legt einfach die ftdiDevice.Write-Funktion auf.

    Ich habe versucht, beide Threads zu synchronisieren, so dass nur ein Thread die Read / Write-Funktion zur gleichen Zeit verwenden kann, aber es hat nicht geholfen.

    Unterhalb des Codes, der für die Kommunikation verantwortlich ist. Beachten Sie, dass folgende Funktionen Methoden der FtdiPort-Klasse sind.

    Empfänger-Thread

    %Vor%


    Schreibfunktion, die vom Haupt-Thread

    aufgerufen wird

    %Vor%


    Objekt zum Synchronisieren von zwei Threads

    %Vor%

    Methode, die den Thread des Empfängers startet

    %Vor% Die ftdiDevice.Write-Funktion legt nicht auf, wenn ich folgende Zeile kommentiere: %Vor%     
  • mack369 13.03.2010, 16:47
    quelle

    4 Antworten

    4

    Ein paar Dinge:

    1. Überprüfen Sie, ob Ihr Leseaufruf blockiert ist. Ist dies der Fall, können Sie möglicherweise Write nicht aufrufen, während der Read blockiert ist und auf eine Antwort wartet. Ihre API-Dokumentation enthält möglicherweise weitere Details dazu.

    2. Einige APIs unterstützen mehrere Threads nicht sehr gut, selbst wenn der Zugriff synchronisiert wird. Wenn dies der Fall ist, können Sie ein Design verwenden, bei dem Sie Ihre Schreibbefehle an Ihren Kommunikations-Thread delegieren. Wenn ich dieses Muster in der Vergangenheit verwendet habe, stehe ich normalerweise eine Art der Befehlsklasse mit den Informationen an, die ich schreiben möchte, und benutze entweder eine Threading-Signalklasse, um meinen 'command'-Methoden zu erlauben, etwas zu blockieren oder zu liefern asynchrone Benachrichtigung.

    Dan Bryant 13.03.2010, 16:59
    quelle
    6

    Alternativ können Sie den Ereignisbenachrichtigungsmechanismus von FTDI verwenden. Auf diese Weise benötigen Sie keinen blockierenden Thread zum Auslesen von Daten:

    %Vor%     
    Rogier 16.04.2010 09:17
    quelle
    2

    Ich habe eine ausführlichere API-Dokumentation gefunden. Tatsächlich blockiert die ftdiDevice.read-Funktion, wenn Sie den Wert für readTimeout nicht auf 0 setzen. Durch Festlegen dieses Zeitlimitwerts wurde das Problem behoben.
    Danke für deine schnelle Antwort.
    Grüße

        
    mack369 13.03.2010 17:34
    quelle
    1

    Beim Auschecken der API sieht es so aus, als könnte der Treiber einen COM-Port emulieren. Ich sehe die GetComPort () Methode, die eine "COMx" Zeichenkette zurückgibt. Das macht es sehr wahrscheinlich, dass Sie die System.IO.Ports.SerialPort-Klasse verwenden können. Was bereits versucht, was Ihr Wrapper zu tun versucht, unterstützt ein DataReceived-Ereignis. Einen Versuch wert.

        
    Hans Passant 13.03.2010 17:50
    quelle