WriteFile zu langsam?



  • Hm, wieso nimmst Du net das Beispiel aus der MSDN und änderst es, so wie Du es brauchst?

    HANDLE hCom=CreateFile( "COM1", GENERIC_READ|GENERIC_WRITE, 0, NULL,    OPEN_EXISTING, FILE_FLAG_OVERLAPPED, NULL);
    if (hCom == INVALID_HANDLE_VALUE) 
    {
        // Handle the error. 
    }
    
    // Set the event mask. 
    BOOL fSuccess = SetCommMask(hCom, EV_RXCHAR);
    if (!fSuccess) 
    {
        // Handle the error. 
    }
    
    // Create an event object for use in WaitCommEvent. 
    OVERLAPPED o;
    o.hEvent = CreateEvent( NULL, FALSE, FALSE, NULL);
    
    char szBuf[800];
    DWORD dwEvtMask, dwRead = 0;
    while( dwRead < sizeof(szBuf))
      if( WaitCommEvent(hCom, &dwEvtMask, &o))
      {
        ClearCommError( hCom, &dwDummy, &cs);
        min = min( sizeof(szBuf)-dwRead, cs.cbInQue);
        ReadFile( hCom, szBuf+dwRead, min, &min, &o);
        dwRead += min;
      }
      else
        break;  // Error reading from COM (maybe cancelled)
    PutBufInRingbuf( szBuf, dwRead);
    

    [ Dieser Beitrag wurde am 22.10.2002 um 16:26 Uhr von RenéG editiert. ]

    [ Dieser Beitrag wurde am 22.10.2002 um 16:29 Uhr von RenéG editiert. ]



  • Das ist eine gute Frage. Weil ich bis jetzt nicht über dieses Beispiel gestolpert bin. Kannst mir ja mal sagen, wie der Artikel heißt?

    Aber wenn ich mir das Beispiel so ansehe, erkenne ich einen gravierenden Nachteil. Meine Funktion PutBufInRingbuf wird erst aufgerufen, wenn 800 Zeichen eingetroffen sind. Was passiert aber, wenn nur 100 kommen? Hängt dann der Thread nicht die ganze zeit in der Schleife fest? (Oh oh, die Systemauslastung???)

    Aber vielleicht gibt es ja noch eine andere Mglk.?

    Grüße
    Franky

    [ Dieser Beitrag wurde am 22.10.2002 um 16:45 Uhr von Franky editiert. ]



  • Nanana, alles kann dir das System nun doch nicht abnehmen :).

    D.h. idealerweise setzt du ein Timeout oder definierst dir ein Übertragungsprotokoll. Also entweder es kam eine gewisse Anzahl Zeichen, oder du hast eine gewisse Zeit in der Abfrageschleife verbracht, oder dein im Übertragungsprotokoll definierter Übertragungsende - String wurde gesendet........



  • @Franky

    Was passiert aber, wenn nur 100 kommen? Hängt dann der Thread nicht die ganze zeit in der Schleife fest? (Oh oh, die Systemauslastung???)

    Ach Franky, übersezte doch mal den Befehl WaitCommEvent !! Für mich bedeutet das: "Warte bis nächstes Zeichen"
    Was wiederum bedeutet, dass der Thread NICHT in der Schleife, sondern in WaitCommEvent 'hängt'! Und diese Funktion braucht FAST GAR KEINE Prozessorzeit!



  • Also wenn ich das richtig verstanden habe, handelt es sich bei dem Aufruf von WaitCommEvent um eine overlapped Operation. D.h., sie kehrt sofort zurück und wartet nicht solange, bis ein Zeichen ankommt. Ich müsste dann mit WaitForSingleObject darauf warten, bis die Funktion beendet ist, also ein zeichen empfangen wurde. Und dies kann ich in dem Code nicht finden. Hat das evtl. etwas mit dem Event zu tun -> CreateEvent mit AutoReset deklariert???

    Oder habe ich da jetzt was falsch verstanden?

    Wie heißt denn nun der Artikel mir dem Beispiel?

    Grüße
    Franky

    [ Dieser Beitrag wurde am 23.10.2002 um 10:36 Uhr von Franky editiert. ]



  • Also erstmal steht in der MSDN:

    If hFile was opened with FILE_FLAG_OVERLAPPED and lpOverlapped is not NULL, WaitCommEvent is performed as an overlapped operation. In this case, the OVERLAPPED structure must contain a handle to a manual-reset event object (created by using the CreateEvent function).

    Ok, bei mir fehlt WaitForSingleObject, wäre aber kein Problem, das einzubringen. Mal ne andere Frage: Wofür brauchst Du überhaupt die Overlapped-Struktur? Willst Du wirklich asynchron auf die Schnittstelle zugreifen?



  • WriteFile & Co habe ich auch schon einmal probiert !!
    Kurze Zwischenfrage, wie macht man das unter XP mit Device Treibern ???
    Hat da jemand was auf Lager ?



  • @Snakey
    Keine Ahnung. Die anderen bitte.

    @RenéG
    Ja, ich ich brauche eine overlapped Struktur.
    Vorteile: Lesen und Schreiben quasi gleichzeitig. Bessere Ansprechbarkeit (blocking)

    Ist denn meine Lösung nicht in Ordnung? Funktioniert tadellos und ich habe eine IMHO relativ geringe Prozessorauslastung.

    Grüße
    Franky



  • Ich habe da noch mal eine Frage:

    Wer puffert eigentlich die Daten zwischen UART und meiner ReadFile- Funktion? SO weit ich weiß, ist der Puffer der UART gerade 16 Bytes groß. Weiß das jemand?

    Grüße
    Franky



  • Wer puffert eigentlich die Daten zwischen UART und meiner ReadFile- Funktion? SO weit ich weiß, ist der Puffer der UART gerade 16 Bytes groß.

    Der Treiber hält zusätzlich zum FIFO noch interne Buffer, Stichwort SetupComm().



  • Aha,

    jetzt wäre es noch interessant zu wissen, wie groß die Puffer standardmäßig sind. Ich konnte in der MSDN nur finden, daß man mit SetupComm die Ein- und Ausgangspuffer festlegen kann. Und dann steht da, wenn man dies nicht tut, werden die Standardeinstellungen genutzt. Aber wie groß sind dann die Puffer? Oder, was sind gängige Größen für solche Puffer?
    Danke.

    Grüße
    Franky


Anmelden zum Antworten