Muss mich erst nochmal für Deine Geduld bedanken. Hab echt schon einige wertvolle Erkenntnisse sammeln können.
Zitat von
sirius:
Das mit den Threads ist prinzipiell ok. Da das USBZeugs aber ergeignisorintiert läuft hätte man vielleicht auch auf den Thread verzichten können und eine "normale" Klassen benutzen können. Schaden tut es nicht.
Welchen Thread genau hätte ich mir sparen können? Ich versuche die Struktur mal darzustellen:
Delphi-Quellcode:
USBJobThread
|
|_______SendCommandThread
| |
| |________USBWriteAsync
| |
| |________USBWritesync
|
|_______ReceiveCommandThread
|
|________USBReadAsync
|
|________USBReadAsync (Data)
Zitat von
sirius:
Wenn du die Größe kennst, dann nimm doch ein dynamisches Array (var Data:array of byte) und setze jedesmal vor dem Aufruf die Länge (setlength(x,Länge)).
Das klingt nach einer guten Vorgehensweise. Werde ich so machen. setlength kannte ich nicht.
Zitat von
sirius:
Musst du Data vorbelegen? Ich vermute nicht. Dann würde ich die Sache mit PDataFrame etc, ganz fallen lassen, sondern allein mittels synchronize arbeiten.
Okay. Das habe ich (logischerweise) auch noch nie gemacht. Verstehe den Ansatz auch nicht so ganz und finde kein einfaches Beispiel. Könntest Du evtl. anhand von dem Quellcode im Post #4 das kurz ganz grob skizzieren, damit ich einen Anfang habe? Steige mit dem synchronize trotz TFM nicht so ganz durch. Wäre echt nett
Zitat von
sirius:
Wie startest du den Thread?
Was sind das für Daten?
Einen Thread starte ich beispielsweise so:
Delphi-Quellcode:
ReceiveCommandThread := TBulkReceiveCommandThread.Create( aPipeHandles[1][0],
pData, //RxData,
@DSPMessage);
ReceiveCommandThread.Suspended := FALSE;
Ret := ReceiveCommandThread.WaitFor;
Die Daten sind halt Nutzdaten, welche auf die Applikation keinen Einfluss haben.