Diese Seite ist unverschlüsselt! Um sicherzustellen, das Ihr Passwort nicht ausgelesen werden kann, sollten Sie auf die verschlüsselte Seite wechseln!

    Herzlich Willkommen, lieber Gast!
  Sie befinden sich hier:

  Forum » C / C++ (WinAPI, Konsole) » Overlapped?!
Forum | Hilfe | Team | Links | Impressum | > Suche < | Mitglieder | Registrieren | Einloggen
  Quicklinks: MSDN-Online || STL || clib Reference Grundlagen || Literatur || E-Books || Zubehör || > F.A.Q. < || Downloads   

Autor Thread - Seiten: > 1 <
000
23.11.2004, 19:24 Uhr
Mr. T



 Hallo, Leute!

Ich bin gerade mal wieder am Comport rumoptimieren...

Mein Problem: Ich lese und schreibe auf Comport. Leider ist das ganze nur dann richtig gut, wenn nebenher nicht gerade was anderes ausgeführt wird... DAS ist schlecht.

Was muß ich denn tun, damit keine eingehenden, bzw. ausgehenden strings verloren gehen?

Ich meine, wenn ich die Kommunikation über den Comport starte und nebenher kein weiteres Fenster öffne (z.B. Internetexplorer, Explorer, Rechner, ...) funzt es super. Wenn ich aber etwas öffne/starte, dann kommen nur ein Bruchteil der Daten an, bzw. sende ich wohl auch nur einen Bruchteil..

Kann ich sowas überhaupt in den Griff bekommen? Ich vermute, dass ich vielleicht zu viel vom Prozessor verlange..

Das Schreiben/Lesen habe ich so gelöst (für Verbesserungen bin ich dankbar):

C++:
char com1_gelesen[3000][8];

for(int i=0;i<3000;i++)
{
    writefile(..,...,..);                         //senden eines Startsignals Hexzeichen
    readfile(..,..,&com_gelesen[i],..);    //emfangen / speichern von 8 Hexzeichen
}


In den Funktionsaufrufen steht allerdings kein overlapped!

Danke!!
--
So ist das!
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
001
23.11.2004, 21:44 Uhr
ao

(Operator)


Da gibts mehrere Ansätze:

1. Das Empfangen in einen eigenen Thread auslagern oder asynchron - also overlapped - vom Betriebssystem ausführen lassen. Der Thread muss bereit sein, Daten entgegenzunehmen, wenn welche abzuholen sind. Darum bekommt er eine erhöhte Priorität, damit er nicht von fremden Applikations-Threads verdrängt werden kann.

2. Hardware-Flusssteuerung (Handshake) einsetzen, damit kann das Betriebssystem den entfernten Sender bremsen, solange es nicht empfangsbereit ist.

3. Dass du beim Senden Daten verlierst ist, nicht so wahrscheinlich; eher entstehen Lücken im Datenstrom; je nach Anwendung (z.B. Fax) ist das aber auch fatal (Timeout -> Verbindungsabbruch). Hier hilft ein Sende-Thread mit ebenfalls erhöhter Priorität.

4. Die Sende- und Empfangs-Threads sollten nur diese eine Aufgabe haben und nicht nebenher noch andere zeitraubende Aufgaben (GUI, Daten von Festplatte lesen oder wegschreiben, ...) tun.

5. Unterstützend wirkt die Bereitstellung von etwas Pufferspeicher. Das müssen keine Megabytes sein, eine Handvoll Blöcke, die so groß sind, dass sie rund 200 Millisekunden Sende- oder Empfangszeit überbrücken können, reichen schon, wenn das Protokoll nicht zu kompliziert ist.

ao
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
002
24.11.2004, 09:19 Uhr
Mr. T



 Gut!

Hmm, jetzt kann ich damit leider noch nicht so viel anfangen, weil ich von diesen Möglichkeiten überhaupt nichts weiß und keine kenne.

Das Protokoll ist so: Ich sende eine 0x01. Das wars. Dann werden 8 0x - Zahlen gelesen (weil vom 0x01 - Empfänger nach erhalt der 0x01 8 0x Zahlen gesendet weren). Dann muß das ganze wieder von vorne beginnen, also wieder 0x01 senden, 8 empfangen, 0x01 senden, 8 empfangen...

Kannst Du mir da konkretere Tipps geben? Wenn es Dir was sagt: im Vordergrund muß eine Protool Visualisierung laufen, die dann von mir irgendwann Daten bekommt. Wenn Protool aber im Vordegrund ist, läuft mein Prog, wie gesagt, nicht richtig. Andersrum aber darf das Protool aber nicht in den Hintergrund.

Vielen Dank!
--
So ist das!
Dieser Post wurde am 24.11.2004 um 09:21 Uhr von Mr. T editiert.
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
003
24.11.2004, 13:12 Uhr
~Mr. T
Gast


Also:

Wenn ich das ganze OVERLAPPED mache, dann habe ich ja das Problem mit wann ich was von beidem (lesen/schreiben) tue.. Und das Senden der 0x01 geht weiterhin auch im "schlafen", wie das Lesen des Ports??

Es muß gewährleistet sein, das NUR gesendet ODER empfangen wird.

Wie bekommt man das denn in Anbetracht auf die ursprüngliche Schleifenform hin?

Für mich alten Neuling ist das echt schwere Materie, aber ich muß da schnellstmöglich durch!

Ich bin für jede Hilfe echt dankbar..

Greetings
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
004
24.11.2004, 19:53 Uhr
ao

(Operator)


Gibts denn dazu keinen Beispielcode in der MSDN?
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
005
25.11.2004, 09:20 Uhr
~Mr. T
Gast



Zitat von ao:
Gibts denn dazu keinen Beispielcode in der MSDN?


Da gibts schon Code in der MSDN. Da habe ich mich echt durchgewühlt, aber mir fehlt noch das Gesamtverständnis. Es wird schön darauf eingegangen, wie man das zu programmieren hat, aber das reicht nicht. Es behandelt lesen und schreiben getrennt voneinander, ich muß aber unmittelbar nach dem Schreiben schon lesen. Wie man das ganze voneinander abhängig macht, ist mir auch nicht klar. Wenn gesendet --> Lausche & speichere --> wieder senden --> Lausche & Speichere --> ...

Wenn mir da jemand mit helfen könnte, auch Beispielcode - mäßig zum Anschubsen!?

Mir wurde geraten, alles in einem extra Thread zu machen, das hört sich toll an, aber wie?

CreateThread() und dann? Wo mache ich die Abhängigkeit erst senden/dann lesen&speichern... und das ganze soll eine definierte Abbruchbedingung bekommen, z.B. das wenn das Gelesene einen bestimmten Wert angenommen hat!
 
Profil || Private Message || Suche Download || Zitatantwort || Editieren || Löschen || IP
Seiten: > 1 <     [ C / C++ (WinAPI, Konsole) ]  


ThWBoard 2.73 FloSoft-Edition
© by Paul Baecher & Felix Gonschorek (www.thwboard.de)

Anpassungen des Forums
© by Flo-Soft (www.flo-soft.de)

Sie sind Besucher: