COM Port Daten auslesen und auf bestimmtes Char reagieren

[Photoner]

WaitCommEvent

"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).

If hFile was not opened with FILE_FLAG_OVERLAPPED, WaitCommEvent does not return until one of the specified events or an error occurs."

In dem Overlapped Record muss also ein Handle auf ein Event (das mit CreateEvent erzeugt wird) drin sein. Wie schaut rOverlapped aus?

Alternativ:

Lass das FILE_FLAG_OVERLAPPED mal im CreateFile weg und verzichte auch danach darauf. Mir selbst ist nicht ganz klar wie der asynchrone Zugriff denn genau funktioniert. Ich glaube du musst vor dem ReadFile die Funktion WaitForSingleObject mit dem oben erwähnten Handle aufrufen. Synchron tuts hier auch da der Rücksprung aus WaitCommEvent ohne das rOverlapped erst kommt wenn dein RX_Char #10 tatsächlich im Buffer ist.

[AJ_Oldendorf]

hEvent wird gesetzt beim Init des ComPorts:

rOverlapped.hEvent := CreateEventA (NIL, True, False, NullStr); Dann kommt das WaitCommEvent wie oben schonmal geschrieben und wenn dieses getriggert wird sieht mein Aufruf so aus:

Delphi-Quellcode:

ReadFile (MyHandle, ReceiveBuffer, 1024, ReceivedBytes, Nil);  //<- ReceivedBytes ist hier 0
ReceivedBytes := SeriellComp.rOverlapped.InternalHigh; //<- ReceivedBytes ist hier 4
ResetEvent(rOverlapped.hEvent);

So wäre das ja richtig von der Reihenfolge oder?

Grüße

[AJ_Oldendorf]

@Sir Rufo...

Zitat:

Also ich würde so etwas immer aufteilen.

Eine Klasse holt Bytefolgen vom ComPort ab und gibt diese mit dem Zeitstempel weiter.

Eine Klasse nimmt die Bytefolge/Zeitstempel Nachricht und baut bei jedem Vorkommen von #13#10 eine Nachricht mit Bytefolge/Zeitstempel und gibt diese weiter.

Ich habe jetzt mal Byteweise die COM abgefragt und mir entsprechend beim Auftreten meines #10 den String zusammen gebaut. Das ist ja im Endeffekt ein Pollen der Seriellen Schnittstelle und man merkt dabei "deutlich", dass das mehr Rechenleistung benötigt.

Der bessere Weg ist auf ein bestimmtes Zeichen nur zur Triggern (WaitCommEvent) und dann die Daten auslesen.
Das Problem ist nur, dass dann bei mir nichts im Buffer steht wenn ich ReadFile nach dem WaitCommEvent aufrufe

[Sir Rufo]

Zitat von AJ_Oldendorf:

@Sir Rufo...

Zitat:

Also ich würde so etwas immer aufteilen.

Eine Klasse holt Bytefolgen vom ComPort ab und gibt diese mit dem Zeitstempel weiter.

Eine Klasse nimmt die Bytefolge/Zeitstempel Nachricht und baut bei jedem Vorkommen von #13#10 eine Nachricht mit Bytefolge/Zeitstempel und gibt diese weiter.

Ich habe jetzt mal Byteweise die COM abgefragt und mir entsprechend beim Auftreten meines #10 den String zusammen gebaut. Das ist ja im Endeffekt ein Pollen der Seriellen Schnittstelle und man merkt dabei "deutlich", dass das mehr Rechenleistung benötigt.

Der bessere Weg ist auf ein bestimmtes Zeichen nur zur Triggern (WaitCommEvent) und dann die Daten auslesen.
Das Problem ist nur, dass dann bei mir nichts im Buffer steht wenn ich ReadFile nach dem WaitCommEvent aufrufe

So sollst du das ja auch nicht machen

Hole dir alles was du vom ComPort kriegen kannst. Das ist ja eine Bytefolge. Diese packst du dann in einen Record

Delphi-Quellcode:

TDataBlock = record
  Data: TBytes;
  Timestamp: TDateTime;
end;

und den dann in eine Queue. Diese Queue wird dann von einem anderen Thread abgefragt und verarbeitet. Dort erfolgt dann das Untersuchen und Zerteilen der Nachrichten und wenn eine komplette Nachricht erkannt wurde, dann schickt dieser Thread die Nachricht raus bzw. reicht diese Nachricht an eine weitere Queue, wo dann ein Versender-Thread diese Queue abfragt und die Nachrichten an die Empfänger schickt.

Durch die unterschiedlichen Threads laufen Empfänger, Zerteiler und Versender völlig unabhängig voneinander und stören sich folglich nicht gegenseitig.

Das Konzept selber ist eine DataFlow-Pipeline und eine Implementierung findest du
https://github.com/gabr42/OmniThread...1_Pipeline.pas

[Photoner]

Readfile liefert in deiner Konstellation falsche Ergebnisse da es

entweder a) mit Overlapped wieder asynchron ist (Rücksprung bevor fertig gelesen)
oder b) mit nil beim Overlapped einfach falsche Ergebnisse liefern kann.

Du musst das Rückgabeergebnis von Readfile prüfen und wieder auf das Event warten:

Delphi-Quellcode:

if not ReadFile(MyHandle, ReceiveBuffer, 1024, nil, @rOverlapped) then
  if GetLastError()<>ERROR_IO_PENDING raise Exception.Create('COM Fehler');
case WaitForSingleObject(rOverlapped.hEvent,ATimeOutInMS) of
 ...

Ich muss nochmals auf die Quelle schlechthin, MSDN, hinweisen. Steht alles da.

ReadFile

"If hFile is opened with FILE_FLAG_OVERLAPPED, the lpOverlapped parameter must point to a valid and unique OVERLAPPED structure, otherwise the function can incorrectly report that the read operation is complete."

"lpNumberOfBytesRead [out, optional]
A pointer to the variable that receives the number of bytes read when using a synchronous hFile parameter. ReadFile sets this value to zero before doing any work or error checking. Use NULL for this parameter if this is an asynchronous operation to avoid potentially erroneous results."

Unter Remarks:
"Synchronization and File Position

If hFile is opened with FILE_FLAG_OVERLAPPED, it is an asynchronous file handle; otherwise it is synchronous. The rules for using the OVERLAPPED structure are slightly different for each, as previously noted.
Note If a file or device is opened for asynchronous I/O, subsequent calls to functions such as ReadFile using that handle generally return immediately, but can also behave synchronously with respect to blocked execution. For more information see http://support.microsoft.com/kb/156932.


Considerations for working with asynchronous file handles:

ReadFile may return before the read operation is complete. In this scenario, ReadFile returns FALSE and the GetLastError function returns ERROR_IO_PENDING, which allows the calling process to continue while the system completes the read operation.
The lpOverlapped parameter must not be NULL and should be used with the following facts in mind:
Although the event specified in the OVERLAPPED structure is set and reset automatically by the system, the offset that is specified in the OVERLAPPED structure is not automatically updated.
ReadFile resets the event to a nonsignaled state when it begins the I/O operation.
The event specified in the OVERLAPPED structure is set to a signaled state when the read operation is complete; until that time, the read operation is considered pending.
Because the read operation starts at the offset that is specified in the OVERLAPPED structure, and ReadFile may return before the system-level read operation is complete (read pending), neither the offset nor any other part of the structure should be modified, freed, or reused by the application until the event is signaled (that is, the read completes).
If end-of-file (EOF) is detected during asynchronous operations, the call to GetOverlappedResult for that operation returns FALSE and GetLastError returns ERROR_HANDLE_EOF.
"

[AJ_Oldendorf]

Nil und @rOverlapped ist sicherlich ein Tippfehler oder?

if not ReadFile(MyHandle, ReceiveBuffer, 1024, nil, @rOverlapped) then
Also sollte ich es so machen?

Delphi-Quellcode:

while not Terminated do
begin
  HandleBuffer[0] := rOverlapped.hEvent;
  HandleBuffer[1] := wOverlapped.hEvent;
  Return := MsgWaitForMultipleObjects (Handles, HandleBuffer, False,
                                       2000, QS_ALLINPUT);
  if Terminated then exit;
  Case Return of
    WAIT_OBJECT_0 : begin
                       if ReadFile (MyHandle, ReceiveBuffer, 1024, ReceivedBytes, @rOverlapped) then 
                       begin
                         ResetEvent(rOverlapped.hEvent);
                         rOverlapped.Offset := 0;
                         rOverlapped.OffsetHigh := 0;
                         if ReceivedBytes > 0 then
                         begin
                         end;
                       end;
...

Muss ich mal probieren aber steht dann in den ReceivedBytes nicht wieder 1024 drinne?

[AJ_Oldendorf]

@Himitsu:

Zitat:

Ganz im Ernst, egal, ob du einen Zeitstempel brauchst. ReadFile liest das aus, was schon im Cache des Port ist.

Mir geht es aber nicht um einen Zeitstempel wann ich mir den String zusammen gebaut habe sondern wann dieser sozusagen an der Schnittstelle an lag.

Aller 9ms steht sozusagen ein neuer Wert am COM an. Den brauche ich mir dem genauen Zeitstempel wann er kam.
Der nächste Wert ist dann eben 9ms später. Das ist aber abhängig davon, wie schnell das Gerät sendet.
Kann auch mal 12ms oder ähnliches sein...

[Photoner]

Zitat von AJ_Oldendorf:

Nil und @rOverlapped ist sicherlich ein Tippfehler oder?

Nein:

"lpNumberOfBytesRead [out, optional]
A pointer to the variable that receives the number of bytes read when using a synchronous hFile parameter. ReadFile sets this value to zero before doing any work or error checking. Use NULL for this parameter if this is an asynchronous operation to avoid potentially erroneous results."

Wenn du mit Overlapped arbeitest, steht nichts sinnvolles in diesem Parameter.

[himitsu]

Ganz im Ernst, egal, ob du einen Zeitstempel brauchst. ReadFile liest das aus, was schon im Cache des Port ist.

Ob du nun mühevoll NUR eine Zeilen ausliest, oder einfach alles und dass dann trennst, ist egal ... DA ist DA.

1 alles in einen Puffer kopieren (Neues hinten anhängen)
2 Zeilenumruch suchen
2.1 bis dahin die erste Zeile ausschneiden
2.2 verarbeiten
2.3 gehe zu 2
3 gehe zu 1

Im eigenen Puffer kann man schneller voraussuchen. Für den internen Puffer gibt es keine Preview.

Dauert das Verarbeiten länger, dann die extrahierten Zeilen mit Zeitstempel an einen anderen Thread übergeben.



Da es hier um TEXT geht, vielleicht besser ein AnsiChar-Array, einen AnsiString oder einen TStringStream vervenden.

PS: AssignFile+ReadLn geht auch bei COM, genauso wie der TStringStream+THandleStream/TFileStream.

[Photoner]

Der Rücksprung aus der Funktion WaitCommEvent erfolgt sofort obwohl das Ereignis RX_Char noch gar nicht eingetreten ist. Das Readfile danach findet dann meist auch nichts.

WaitForSingleObject ist das Stichwort.

Diese Funktion wartet auf ein bestimmtes Ereignis und hat einen Timeout.

Wenn das Event RX_Char auslöst, dann wird das Event im Overlapped signalisiert und ein Rücksprung aus WaitForSingleObject erfolgt.


WaitCommEvent
WaitForSingleObject
Readfile