PureBoard

Kleiner Tip noch beim Setzen der Steuerleitungen, damit du nicht dran verzweifelst wie ich.... :

Wenn du mit "SetSerialPortStatus(port, #PB_SerialPort_RTS, 1)" die Steuerleitung aktivierst, kannst du sie nicht
einfach wieder auf 0 setzen. Man kann nur einmal den Status ändern, warum auch immer. Wenn der Port geschlossen wird, geht sie automatisch
wieder auf Zero......

Ok, aber normal müsste das ohne CloseSerialPort funktionieren. Aber, deinen Tip halte ich
mal fest.

Hiermit habe ich mal kurz mit meinem USB2Seriel-Adapter ein Crossoverkabel und ein CheckTester
mit entsprechenden LEDs mal drangehängt und folgenden Source ausprobiert. Also hier wird bei mir wegen dem Nullmodemkabel dann CTS und DSR abwechselnd ein und ausgeschaltet. Wobei ich aber jetzt nur den PC angeschlossen habe. Es könnte durchaus sein,
das Problem durch das zweite Gerät an der anderen Seite erzeugt wird. Anfangs sind bei mir RTS und DCD Grün und wechseln beim OpenserialPort() auf Rot. Dann aber bei der Schleife wir zuerst
die RTS-Leitung 10x an und ausgeschaltet und danach das gleiche mit DCD. Du kannst das ja mal kurz nur mit dem PC testen. Wenn das ohne eine Gegenstelle auch so bei dir ist, dann ist wohl die serielle Schnittstelle bei dir defekt. Morgen probiere ich das mit zwei PC's aus.

Gruß,
Falko

Aha, also bei dir gehen die Dioden abwechselnd an/aus. Ich habe bei mir zuhause während des Programmierens den Com2Com-Treiber
benutzt, um eine Gegenstelle zu simulieren. Man hat dann zwei virtuelle RS232-Schnittstellen. Deswegen gibts im Quellcode bei mir
auch einen Schalter "DevMode". Zum Debuggen sollte der dann 1 sein, wenn man die finale Version kompiliert, muss man DevMode auf 0 setzen.
Wahrscheinlich liegt das an dem Treiber, hab versucht das RTS-Signal wieder zu switchen, aber bei der Gegenstelle bleibt das ClearToSend partout auf 1....

Alex

Ich kannte nur com0com, nur damit kann man die Signale nicht prüfen, sondern nur
die virtuellen Schnittstellen verbinden. Ich habe mir die com2com gerade unter google gesucht und
gesichert. Werde es heute Abend ausprobieren. Vielleicht ist das auch so wie bei dir. Das muss ich noch
ausprobieren. Aber erstmal grillen

Gruß,
Falko

Ups, ich meinte auch Com0Com....

Aha

Naja, das Com0Com habe ich bei mir auch im Gebrauch zum Testen der Datenübertragung.
Aber die LEDs haben bei mir noch nie Ereignisse angezeigt.
Deswegen wundere ich mich, wie du dort sehen kannst, welche LED aktiv ist, oder nicht.
Oder startest du du das Programm mittels Parameter? Wenn ja, dann würde ich mich interessieren,
wie du das startest. Ich habe bisher das Windows-Setup ausgeführt, die virtuellen Schnittstellen gepaart und
dann einfach nur dir Datenübertragung über meine Programme als Client und Server getestet.
Für die Datenleitungen zu überprüfen, habe ich ein Adapter mit Ein und Ausgangs-SubD25-Buchse und Stecker, den ich
einfach dazwischen stecken, oder nur den PC-Ausgang testen kann.

Den kriegst du bei http://www.Reichelt.de sehr günstig: Artikel-Nr.: COM 934
Hierzu habe ich auch folgende Beschreibung:

COM 934
Check-Tester mit 18 LEDs
rote LEDs zeigen Datenfluß,
grüne LEDs zeigen unterbrochenen
Datenfluß der Leitungen 2,3,4,5,
6,8,11,19 und 20 an.

Um die hin und Rückleitungen nur mit dem PC zu testen lässt sich einfach
ein Loopbackstecker basteln der Ausgangsseitig für die Gegensignale sorgt.
Nur mit dem Nullmodemkabel wird dieser Teststecker leider falsch angeschlossen, wobei dann die
Rückleitungen angezeigt werden. Da aber zwei Dioden Antiparallel verbunden sind macht das nicht, man
muss halt nur etwas umdenken.


[Edit]
Ich habe oben den kleinen Testcode nochmal korrigiert.
Sobald ich #PB_SerialPort_RtsCtsHandshake aktiviere,
wechselt RTS leider nicht seinen Status. Erst wenn ich
#PB_SerialPort_NoHandshake anwende, wird das Signal
korrekt gewechselt.
Das ist nun wirklich komisch. Kann es sein, das die
Leitungen automatisch durch das Protokoll gesteuert
werden? Das kann ich nur testen, wenn ich zwei PCs verbinde.


Gruß, Falko

Ich hatte Com0Com einfach installiert und die Standardkonfiguration so belassen wie sie war.
Zum Testen hab ich dann mein Programm zweimal gestartet, eins zum Senden und das andere zum Lesen.
Mit dem Befehl "GetSerialPortStatus(#SerialPort, Attribut)" kannst du den Zustand der Leitung abfragen.
Hast du für Com0Com den Testsigningmodus von Windows auch aktiviert ? Hier ist ein PDF http://www.file-upload.net/download-431 ... p.pdf.html, dass beschreibt, wie man den Treiber richtig installiert.

Kannst du im RTS/CTS Handshake die Signalleitung garnicht aktivieren?. Mit dem Com0Com hat das hier keine Probleme gemacht,
bis auf die Tatsache, dass ich die Signalleitung nicht wieder auf 0 setzen konnte.
Das die RS232-Schnittstelle die Kontrolle übernimmt, konnte ich auch beim XON/XOFF Protokoll feststellen, dort kommt kein
gültiges XOFF oder XON als Datenbyte an, der Treiber schickt dann nur eine Fehlermeldung "#PB_SerialPort_XoffReceived" an die
Anwendung. Hab dann dazu im Netz gelesen, dass man das XON/XOFF Protokoll auch mit "#PB_SerialPort_NoHandshake" selber schreiben kann,
dann kommen die XONs und XOFFS auch als Datenbytes an, man muss dann aber selber darauf reagieren und die Übertragung pausieren.

Ich glaube, dass es so gewollt ist, dass das Zurücksetzen der Signalleitung nicht möglich ist. Du brauchst den Signalstatus während einer Übertragung
auch nicht ständig abzufragen. Er wird nur benutzt, um zu signalisieren, dass eine Übertragung beginnt. Wenn du eine Flusskontrolle der Daten haben willst, nimmst
du stattdessen das XON/XOFF-Protokoll.

Gruss

Alexander

Wenn ich also das
Handshake.l=#PB_SerialPort_RtsCtsHandshake
aktiviere, dann wird bei mir das RTS-Signal nur auf aktiv geschaltet und beim beenden des
Coms wieder ausgeschaltet. Ich kann da nichts schalten, wohl aber DCD. dieser geht bei allen
Protokollen wie gewünscht manuell an und aus. Das RTS-Signal lässt sich bei mir also nur
manuell schalten, wenn ich auf #PB_SerialPort_NoHandshake setze. Ich vermute hierbei,
das man wohl nichts manuell machen muss. Aber dazu muss ich mein Programm noch anpassen.
Ok, das Abfragen, wann die Daten gesendet werden können ist erforderlich um die Daten senden zu können.

Gruß,
Falko

gut zu wissen, scheinbar wird das je nach Hardware anders gehändelt. Wenn bei dir das RTS/CTS-Signal automatisch geschaltet wird, hat man immer noch
den DCD zum schalten. Das heisst dann ja, das man auch mittels DCD eine Flusskontrolle realisieren könnte...

Darie hat geschrieben:gut zu wissen, scheinbar wird das je nach Hardware anders gehändelt. Wenn bei dir das RTS/CTS-Signal automatisch geschaltet wird, hat man immer noch
den DCD zum schalten. Das heißt dann ja, das man auch mittels DCD eine Flusskontrolle realisieren könnte...

Genau. DCD kann ich ja steuern. Da ich vier USB2Seriel-Adapter habe, kann ich, wenn ich mir noch passende Adapter gelötet habe,
einen direkten Hardwaretest mit LED-Kontrolle machen und sehen, was sich da in Wirklichkeit abspielt. Dann würde man sehen, ob RTS/CTS
vom Computer automatisch gehändelt wird und ich nur noch prüfen muss, bis ich die Daten senden kann.

Gruß,
Falko