RS-232 Full-Duplex / GPS

[abacom]

jotteff



Anmeldungsdatum: 07.03.2007
Beiträge: 5

Verfasst am: 23.03.2007 10:00 Titel: RS-232 Full-Duplex / GPS

--------------------------------------------------------------------------------

Hallo Abacom,

eine Verständnisfrage, die direkt an den Thread von Bert Harms (RS-232) anschließt (wollte den englischsprachigen Thread aber nun nicht unvermittelt in Deutsch fortsezten):

Funktioniert das Senden und Empfangen auf demselben Com-Port unabhängig voneinander (full-duplex)?

Aus dem GPS-Beispiel sehe ich, wie man den Port quasi permanent empfangsbereit hält. Läuft der Empfang auch weiter, während man auf demselben Port gerade sendet, bzw. ist das gleichzeitige Senden überhaupt zuverlässig möglich?

Ich versuche gerade, PL mit einem Tektronix 222 Oszilloskop sprechen zu lassen (benutzt ASCII-Strings zur Abfrage bzw. zum Setzen der Betriebsparameter über RS-232). Da bekomme ich momentan noch oft die Rückmeldung, daß Kommandos nicht erkannt wurden, bei direkter Verbindung über Putty oder Hyperterminal läuft aber alles fehlerlos. Das kann aber auch an dem Tek-Scope liegen, das will die ankommenden Zeichen anscheinend sofort auswerten, ohne auf das Zeilenende zu warten.

Noch 'ne zweite Frage, wo ich schonmal bei dem GPS-Beispiel bin:
weiß jemand 'ne elegante Lösung um Prüfsummen von ganzen Zeichenketten zu checken bzw. zu generieren (bitweises XOR über alle Zeichen im String)?

Hier im Forum fand ich den Hinweis auf eine DLL, die bitweise Operationen auf ASCII-Zeichen implementiert, das wäre schon verwendbar.
Man müßte den jeweiligen String dann aber immer noch Zeichen für Zeichen verarbeiten, wär' natürlich schöner, wenn man das in einem Rutsch für den ganzen String machen könnte.

Nach oben


abacom
Site Admin


Anmeldungsdatum: 30.06.2006
Beiträge: 898

Verfasst am: 26.03.2007 13:20 Titel:

--------------------------------------------------------------------------------

Natürlich können Sie per RS-232 "gleichzeitig" senden und empfangen.
Für die Checksummenbildung ist in der Tat eine zeichenweise Verarbeitung notwendig. Als Anregung interessant.

Nach oben


jotteff



Anmeldungsdatum: 07.03.2007
Beiträge: 5

Verfasst am: 26.03.2007 14:36 Titel:

--------------------------------------------------------------------------------

Hallo,

danke für die schnelle Antwort.

Den Grund für die Kommunikationsprobleme mit dem Tek 222 habe ich inzwischen wohl gefunden.
Das Gerät überschreibt quasi die eigenen Fehlermeldungen, indem es seine Antworten mit Carriage Return ohne Linefeed sendet. In einem normalen Terminalprogramm sieht man dann nur die erwartete Antwort aufscheinen, in PL sieht man auch die Fehlermeldungen (die wohl durch CR und LF ausgelöst werden).

Eines fiel mir beim rumprobieren in PL allerdings auf:
Anscheinend werden die Einstellungen zum Einrahmen der Übertragung beim Bauteil "COM String senden" nur nach Schließen und erneutem Öffnen von PL korrekt übernommen.
Zumindest wurden CR und LF als Postfix immer noch gesendet, als ich das in den Bauteil-Eigenschaften längst wieder gelöscht hatte. Nach Schließen und erneutem Öffnen von PL lief dann alles wie gewünscht.

Wenn die Anregung wg. Prüfsummen über Strings aufgegriffen würde, würde mich das sehr freuen.
Ich arbeite ja im Bereich Navigationsgeräte für Schiffe, da ist z.B. das NMEA-Protokoll gang und gäbe, bei dem jede Message mit einer Prüfsumme versehen ist.
Das besondere Problem hierbei: die einzelnen Messages enthalten "lesbaren" ASCII-Text, ihre Länge ist nicht verbindlich festgelegt. Numerische Werte z.B. können mal mehr, mal weniger Nachkommastellen enthalten, bei negativen Werten wird dem Wert ein "-" vorangestellt, der String also um ein Zeichen länger usw.

In jedem Falle aber nochmals vielen Dank für die schnelle Antwort.

Nach oben


abacom
Site Admin


Anmeldungsdatum: 30.06.2006
Beiträge: 898

Verfasst am: 27.03.2007 08:29 Titel:

--------------------------------------------------------------------------------

Schauen Sie einmal das Beispiel
Datei->Beispiele ...\hardware\rs-232\gps-demo.prj an.
Könnte hilfreich sein.