COM Port, kennt sich jemand aus?

[Matthias_Kattelmann_d2a1c6]

Hallo

Ich hab eine Frage, und zwar möchte ich endloses Experimentieren mit com Ports vermeiden.

Es gibt ja den(die) Com(seriellen) Port(s) unter Dos und Windows als Datei ansprechbar.
Beispiel: copy COM1 CON
oder: copy Com1 File1.txt

Meine Frage jetzt: Wann stoppt ein solcher Vorgang?
Wann ist der Übertragungsvorgang beendet und die Datei oder der Zielport ist wieder frei?
Beispiel: Ein GPS-Empfänger in einem portablen Device(Windows CE) ist über einen seriellen Port erreichbar.
Mich interessiert nur, was er „sagt“(das GPS über seriell).
Ich will nun einen Satz von Daten einlesen, mit Programm interpretieren und dann den nächsten Satz einlesen usw…
Kann ich irgendwie ein Stoppereignis vorbestimmen?
Kein Problem sollte ich mit VB5 unter Windows haben, da das Control für Com Ports Ereignisse bietet.
Das steht mir aber bei Dateibefehlen nicht so augenscheinlich zur Verfügung.

Vieln Dank für gute Tipps.

MfG
Matthias

[Reinhard_Kern_4bc529]

oder: copy Com1 File1.txt
Meine Frage jetzt: Wann stoppt ein solcher Vorgang?

Hallo Matthias,

ich will jetzt keine Einführung in die Programmierung der seriellen Schnittstellen schreiben, aber ganz kurz, damit du ein Stück weiterkommst:

Der Copy-Befehl sendet die Daten und gibt dann das COM-Port wieder frei - sonst könnte man ja nie mehr damit arbeiten. Ein Write-Befehl unter Windows ist auch beendet, wenn die Daten an das UART übergeben sind (was nicht heisst, dass sie bereits gesendet sind), aber schliessen musst du die Datei selbst. In einem Programm macht man das aber erst wenn die Schnittstelle nicht mehr gebraucht wird.

Bitte beachten, dass ein Open so etwa aussieht:
CHandle := CreateFile (pFN,GENERIC_READ + GENERIC_WRITE,0,nil,OPEN_EXISTING, File_Flag_Write_Through or File_Flag_No_Buffering,0);

Beim Empfang ist das nicht so einfach, Copy empfängt wohl endlos (bis du Ctrl-C drückst). Ein Read-Befehl liest normalerweise, was bereits empfangen worden ist. Du kannst das so Stück für Stück auswerten oder du setzt die Timeouts so, dass immer ein Datensatz empfangen wird - das geht nur, wenn dazwischen eine längere Lücke ist. Oder du legst z.B. CR als Abbruch-Char fest, dann bekommst du die Daten satzweise - sofern sie CR enthalten.

Events sind im Prinzip vom Datenstrom unabhängig auszuwerten, du kannst z.B. auch auf CR einen Event auslösen lassen und in diesem dann mit Read den Satz lesen.

Am besten ein bisschen experimentieren, Hyperterm oder ein ausgewachsenes Terminalprogramm (heute selten) hilft dabei.

Gruss Reinhard

[Marc_Balta]

Hi,

eine Datei wird mit einem Steuerungsbefehl abgeschlossen: End Of File. Dieser Steuerungsbefehel kann man mit dem drücken von Strg-D simulieren.

Probier einfach mal folgendes aus (ich hab leider kein Windows zur hand): Verbinde deine beiden com ports (Com1 mit Com2) mit einem Nullmodem kabel oder lade dir einen portsimulator runter der kann diesen Versuchsaufbau auch simulieren (z.b. VSPE). Dann verbinde dich mit einem Terminal Programm mit com2 (z.b. TeraTerm) starte das copy und drücke in TeraTerm Strg-D. Der copy befehl sollte sich dann beenden.

gruß,

marc

[Uwi]

Hallo

Meine Frage jetzt: Wann stoppt ein solcher Vorgang?

Wenn du erkennst, dass alle Daten übertragen wurden.

• beim Senden klar, wenn du Daten an die UART (Sendepuffer)übergeben hast
• beim Empfang komplizierter, weil da immer nur einzelene Zeichen im
  Empfangspuffer einlaufen und diese werden von Windows zeitgesteuert
  abgeholt. Wann also etwas komplett ist, kannst du nur am Protokoll
  erkennen (End of File oder anderes definiertes Ende eines Datenpaketes).

Wann ist der Übertragungsvorgang beendet und die Datei oder
der Zielport ist wieder frei?

Der Port wird nur frei ist, wenn du ihn im Programm schließt.
Merkst du auch, wenn z.B. im Terminalprog. eine Verbindung offen ist,
kannst du die COM nicht anderweitig benutzen

Beispiel: Ein GPS-Empfänger in einem portablen Device(Windows
CE) ist über einen seriellen Port erreichbar.
Mich interessiert nur, was er „sagt“(das GPS über seriell).

Dazu zuerst mal Spion dazwischen schalten (Terminalprogr.).
HTerm ist z.B. gut zu verwenden.
http://www.der-hammer.info/terminal/

Ich will nun einen Satz von Daten einlesen, mit Programm
interpretieren und dann den nächsten Satz einlesen usw…

Änliches habe ich kürzlich gemacht, allerdings mit Delphi.
http://uwiatwerweisswas.dyndns.org/Uwi/PROGRAMM/Port…

Kann ich irgendwie ein Stoppereignis vorbestimmen?
Kein Problem sollte ich mit VB5 unter Windows haben, da das
Control für Com Ports Ereignisse bietet.
Das steht mir aber bei Dateibefehlen nicht so augenscheinlich
zur Verfügung.

Eine Datei bekommst du wie schon geschrieben nicht als solche,
sondern nur als Summe vieler Datenpakete. Zusammensetzen und
analysieren (Anfang, Ende, Checksummen, usw. mußt du selber).

Das GPS wird aber wohl gar keine Datei übermitteln, sondern nur
einfach Zeilen (am Ende immer Zeilenendezeichen z.B. CR, LF, CR+LF )
mit Koordinaten.
Einfach mal mit Terminalprogramm anschauen
Gruß Uwi

[Matthias_Kattelmann_d2a1c6]

Hallo Danke

Ich werde mir mal Terminalprogramme und nochmal die API anschauen.
MfG
Matthias

[Peter_TOO]

Hallo Matthias,

Es gibt ja den(die) Com(seriellen) Port(s) unter Dos und
Windows als Datei ansprechbar.
Beispiel: copy COM1 CON
oder: copy Com1 File1.txt

Meine Frage jetzt: Wann stoppt ein solcher Vorgang?

Meist mit der Eingabe von ^C. Wobei die keine Funktionalität des COM-Ports ist, sondern des Programms COPY oder des Betriebssystems.

Wann ist der Übertragungsvorgang beendet und die Datei oder
der Zielport ist wieder frei?

Das Port ist zwischen open() und close(), oder wie die Befehle in der entsprechenden Programmiersprache lauten, belegt.

Beispiel: Ein GPS-Empfänger in einem portablen Device(Windows
CE) ist über einen seriellen Port erreichbar.
Mich interessiert nur, was er „sagt“(das GPS über seriell).

Die meisten GPS-Empfänger verwenden das NMEA-Protokoll:
http://www.kowoma.de/gps/zusatzerklaerungen/NMEA.htm

Grundsätzlich gilt bei der Datenübertragung, dass man ein Protokoll benötigt, also eine Vereinbarung an welche sich Sender und Empfänger halten. Grundsätzlich kannst du mit 8 Datenbit, einfach 256 verschiedene Zeichen übertragen. Welches Zeichen nun was bedeuten soll muss zwischen Sender und Empfänger definiert sein.

Dann gibts noch das Problem der Synchronisierung zwischen Sender und Empfänger. Wenn der Empfänger nicht mehr mit Empfangen mit kommt, muss er den Sender stoppen können. dies macht man entweder über die Steuerleitungen der RS-232 Schnittstele oder über bestimmte Steuerzeichen (XON/XOFF).

Grundsätzlich muss man bei der Übertragung auch immer mal mit einer Störung rechnen. Das (Empfangs-)Programm sollte so gestaltet sein, dass es auch bei wirren Zeichen immer „auf die Füsse fällt“ und nicht anfängt wirre Aktionen auszulösen.

Für stabile Programme empfiehlt es sich auch mit Timeouts zu arbeiten; kommt ein erwartetes Zeichen nicht in innerhalb bestimmten Zeit an, sollte man eine Fehlerbehandlung ausführen, bzw. das Programm mit einer Fehlermeldung beenden.

MfG Peter(TOO)

[Matthias_Kattelmann_d2a1c6]

Hallo

Also doch etwas komplizierter als ich gedacht habe.
Was bedeutet „Eingabe von ^C“ ?
Ich vermute, Du gibst das in ein Terminalprogramm ein oder es ist Bestandteil eines Protokolls, und das BS interpretiert das als „fertig“.

MfG
Mathias

[Peter_TOO]

Hallo Mathias,

Also doch etwas komplizierter als ich gedacht habe.
Was bedeutet „Eingabe von ^C“ ?

CTRL+C, bei deutschen Tastaturen STRG+C

Ich vermute, Du gibst das in ein Terminalprogramm ein oder es
ist Bestandteil eines Protokolls, und das BS interpretiert das
als „fertig“.

Das BS interpretiert das als „Programm beenden“.

Deine Frage enthielt eine Sonderform ( copy COM1 xxxxx)
In diesen Fall ist nicht einfach zu erkennen, wann keine Zeichen mehr zu erwarten sind
Bei „copy xy.txt COM1“ wäre meine Antwort anders ausgefallen, da hier der Befehl copy erkennen kann wann das Dateiende erreicht ist.

MfG Peter(TOO)