mse-Comm

[mschnell]

Hi Martin,

Kannst Du Unterschiede und Gemeinsamkeiten zwischen mse-Comm und AsyncPro erläutern ?

Wenn ich das richtig sehe ist bei beiden die Grund-Idee gemeinsam:
- eine Objekt pro serielle Schnittstelle zu instanziieren
- jede Instanz erzeugt sich einen oder mehrere Threads zur "blocking" Kommunikation mit dem Treiber des Serien-Ports
- die Schnittstelle der Instanz Richtung User findet im Kontext des Mainthreads (mit zwischengepufferten Daten) statt, so dass das Hauptprogramm sich um Threads nicht kümmern muss.

Bei AsyncPro kann man statt serieller Schnittstelle mit demselben User-Interface auch TCP-Ports behandeln. Das finde ich ziemlich genial ! Man könnte das vermutlich problemlos auch noch für Pipes erweitern !

Gibt es irgendein prinzipielles Problem, mse-Comm in einem Lazarus Projekt zu benutzen ?

Wäre es sinnvoll, mse-Com in ein Lazarus-Paket einzubetten, das sich (wie AnsycPro in Delphi) auch "grafisch platzieren" lässt ?

Gruß und Dank,
-Michael

[mse]

Ich kenne AsyncPro nicht genau, die Produkte scheinen vergleichbar.
Die MSEgui comm Komponenten bestehen aus den älteren tcommport und den abgeleiteten Komponenten tasciicommport und tasciiprotport. tcommport arbeitet direkt auf den seriellen Port und hat Methoden zur Busrichtungssteurung und Protokollabwicklung, welche beispielsweise zur Kommunikation mit RS485 Bussen verwendet werden kann.
Zur asynchronen Datenübertragung werden tcommevent und Nachkommen verwendet.

Code: Alles auswählen

tcommevent = class(tmseevent)
  private
   fstate: commstatety;
   fpersistent: boolean;
   fsem: semty;
  protected
   procedure process(const thread: tcommthread; var ok: boolean); virtual;
   procedure processed(const thread: tcommthread; var ok: boolean); virtual;
  public
   onerror: commeventty;   //synchronized with maineventloop
   onsuccess: commeventty; //synchronized with maineventloop
   timeout: integer; //us
   constructor create(persistent: boolean; atimeout: integer = 200000); virtual;
   destructor destroy; override;
   function state: commstatety;
   function waitfordata: boolean; //true if no error
 end;
 
 tasciicommevent = class(tcommevent)
  protected
   procedure process(const thread: tcommthread; var ok: boolean); override;
  public
   commandstring: string;
   resultstring: string;
   resultcode: integer; //cpf_...
 end;

Diese event Objekte werden in die event queue des separaten Kommunikations-threads gespiesen und der Reihe nach abgearbeitet. onerror und onsuccess sind callbacks welche mit dem main thread synchronisiert werden.
tasciicommport und tasciiprotport sind spezialisierte Ableitungen zur Abwicklung von ASCII-Protokollen.

Für einfachere Anwendungen kann die neuere tsercommcomp verwendet werden. tsercommcomp beruht auf tpipereader, welche, wie der Name schon sagt, auch mit pipes funktioniert. Wird MSEide mit -dmse_with_ifirem kompiliert, kann mit den verschiedenen socket Komponenten auch via TCP/IP gearbeitet werden.

Gibt es irgendein prinzipielles Problem, mse-Comm in einem Lazarus Projekt zu benutzen ?

Man müsste die in MSEgui vorhandene locking-, synchronisations-, und event queue Funktionalität nachrüsten. Du hast ja bereits Erfahrung damit.

Wäre es sinnvoll, mse-Com in ein Lazarus-Paket einzubetten, das sich (wie AnsycPro in Delphi) auch "grafisch platzieren" lässt ?

Ich denke schon, das habe ich ja für MSEide auch gemacht.

Martin

[mschnell]

Man müsste die in MSEgui vorhandene locking-, synchronisations-, und event queue Funktionalität nachrüsten. Du hast ja bereits Erfahrung damit.

Ja. Das ist nicht so einfach . Ich hätte das gebraucht, weil Lazarus nur ein Event-Handling zur Verfügung stellt, wenn auch eine GUI angebunden ist. Mse kann das auch ohne GUI.

Bei dem hier diskutierten Fall ist eine GUI aber (für 99,9% der Anwender = alle außer mir) nicht verboten. Deshalb ist der naheliegende Weg, im mse-Comm Sourcecode den mse-typischen Mechanismus durch den Lazarus-Mechanismus zu ersetzen. Lazarus bietet dafür "TAppplication.QueueAsyncCall()". Funktioniert einwandfrei unter Windows und Linux ("GTK2"-Widget-Type). Mac habe ich nicht getestet.

Lets get it on !

-Michael

[mse]

Ein weiter Punkt den die MSEgui Komponenten mit threads benötigen und den Lazarus so viel ich weiss nicht zur Verfügung stellt ist application.lock()/unlock(). Dies wird anstelle von synchronize() verwendet. Will man in einem thread Hauptprogramm-Resourcen verwenden, ruft man application.lock() auf. Danach hat man die Resourcen des Hauptprogram reserviert und kann frei darauf zugreifen.
Hinter application.lock()/unlock() liegt eine komplizierte Maschine, welche möglicherweise nicht so ganz einfach auf Lazarus übertragbar ist.

Martin

[mschnell]

1) Warum wird das gebraucht ?
2) was ist gegen TCriticalSection für diesen Zweck einzuwenden ? Natürlich müssen sind dafür die Ressourcen, die geschützt werden sollen, bekannt sein. Das macht die Performace aber eher besser, da man jede Ressource einzeln schützen kann.

-Michael

[mse]

1) Warum wird das gebraucht ?

Zur Vermeidung von deadlocks, denke nur an thread terminate()/waitfor().

2) was ist gegen TCriticalSection für diesen Zweck einzuwenden ? Natürlich müssen sind dafür die Ressourcen, die geschützt werden sollen, bekannt sein. Das macht die Performace aber eher besser, da man jede Ressource einzeln schützen kann.

MSEgui benutzt ebenfalls MUTEX. Das einzelne Schützen von Ressourcen verlangt vom Anwender einiges an Disziplin und kann von den Bibliotheksroutinen für callbacks (event method properties) nicht automatisch sichergestellt werden. Beim Zugriff auf GUI-Elemente ist vom Anwedner kaum überblickbar, was da alles zusammenhängt. Auf jeden Fall muss der main thread in einem sicheren Zustand sein und bleiben.

[mschnell]

Ich hoffe, die kritischen Thread-Protections können komplett innerhalb der Serien-Komponente stattfinden (wie bei AsyncPro, das nur Mainthread-Events exportitert) und die Threads komplett innerhalb der Komponente bleiben. Dann sollte TCriticalSection als Semaphore ausreichen.

-Michael