Virtueller Serial Port Splitter gesucht Win10

Torsten C. schrieb:
> Aber unter Win10 läuft com0com nicht

Auf der com0com-Seite selbst ist bizarrerweise Reklame für ein 
kommerzielles Produkt von Eltima zu finden:

http://com0com.sourceforge.net/

Sowas habe ich auch noch nicht gesehen.


Das eigentliche Problem dürften signierte Treiber sein. Die soll es 
für com0com hier geben:

http://pete.akeo.ie/2011/07/com0com-signed-drivers.html

(da steht zwar als Datum was von 2011, die Treiber aber sind vom Juni 
2016)

Das gute: Cool, klappt! :-) Danke, Rufus!

Das schlechte: Ich hatte wohl einen Denkfehler: Man müsste das 
DV4mini-Control-Panel (das betreffende Programm) dazu bringen, sich 
statt mit COM8 (Bild) mit CNCA0 oder CNCB0 zu verbinden, weil man 
geöffnete Ports gar nicht aufsplitten (anzapfen) kann.

Ich probiere mal, ob ich mit WireShark USBPcap was sehe. Aber eigentlich 
wollte ich die Daten in Echtzeit haben, nicht aus einer Log-Datei.

Torsten C. schrieb:
> COM8 (Bild) mit CNCA0 oder CNCB0 zu verbinden

Du kannst die Dinger auch umbenennen, so daß Dein abzuhörendes Programm 
auch die com0com-Ports akzeptieren sollte.

@STM32: So wie in Variante 1?

Ich behaupte mal: Das geht mit hub4com nicht. Oder bin ich zu blöd?

Es wäre aber cool, wenn das ginge. :)

Variante 2 wäre ohne hub4com:
* Ein neues Paar aus CNCX und COM8 erzeugen.

* Logger mit COM 8 verbinden
  (der ist dann belegt und wird nicht mehr gefunden)

* Im Logger CNCX TX an COM8 RX streamen (und loggen)
      … und COM8 TX an CNCX RX streamen (und loggen)

* Programm "SUT1" starten, das findet dann nur COM9
  … hoffentlich.

Das könnte gehen. Ich probiere das morgen mal,
mit einem Logger in C#.NET, wenn es keine bessere Idee gibt.

Ich hoffe, dass nicht auch noch DTR, CTS, RI usw. verbunden werden 
müssen.

STM32 schrieb im Beitrag #4734687:
> --route=\\.\COM9 \\.\CNCA1 \\.\COM9 \\.\CNCB1

Und dann geht COM9 TX bei COM8 RX an? ?!

Und wohin geht COM8 TX?

Falls das ein Tippfehler war, vielleicht meintest Du:
* --route=\\.\COM9 \\.\CNCA1 \\.\COM8 \\.\CNCB1
                                    ¯
Dann ginge COM8 TX zwar an CNCB1 RX, aber immer noch nicht an COM9 RX,
so wie ich das verstehe.

Mit zwei Terminals sehe ich noch kein Land.

Ein 'man in the middle' scheint leider nötig. :-(

Danke, Helen.
Wie gesagt: Über ein Terminal-Programm (zwei Terminal-Fenster) will ich 
den Datenverkehr mitschneiden.

Ich finde keinen Hinweis, dass man mit 'virtual-null-modem.com' die 
beiden TX-Streams 'anzapfen' und auf zwei weitere Ports leiten kann. 
Siehe auch Variante 1 im Bild oben.

Aaaaa! Jetzt habe ich das Konzept von hub4com.exe endlich verstanden.

Logisch:
* Die Port-Paare bleiben bestehen.
* Man benötigt 3 Port-Paare
* hub4com öffnet und blockiert die angegebenen Ports.

Also müssen die Terminals sich mit den Gegenseiten der Port-Paare 
verbinden (blaue Pfeile).

Danke für Deine Hartnäckigkeit, STM32 und auch nochmal an Rufus.

SUT1 findet COM9 und es klappt nun auch mit den Terminals. :)

Torsten C. schrieb:
> auch nochmal an Rufus.

Danke; ich werd's vermutlich selbst demnächst brauchen und bin insofern 
schon mal froh darum, das Windows-10-Problem gelöst zu haben.

Reiner Eigennutz also ...

Es ist zum Mäuse melken. :-(

Mit Putty klappt es.
Will ich nun ein C#-Programm verbinden, dann geht es nicht.

Kann das damit zusammen hängen, dass weder am CN2A-RX noch am CN1A-RX 
(siehe Bild) ein RX angeschlossen ist?
Also daran, dass CN1B-TX und CN2B-TX ins 'leere' gehen?

System.IO.Ports.SerialPort.DataReceived() wird ausgelöst, aber
System.IO.Ports.SerialPort.BytesToRead ist immer == 0.

Auch System.IO.Ports.SerialPort.BaseStream.BeginRead() ruft nie den 
Delegaten auf.

Die Variante mit dem BeginRead()-Delegaten, die auch nicht auf 
empfangene Zeichen reagiert, habe ich von:
http://www.sparxeng.com/blog/software/must-use-net-system-io-ports-serialport

SerialPort.Handshake steht auf "Handshake.None".
Schade, das kann also nicht die Ursache sein.

PS: Für --route=0:2 und --route=1:3 gibt es oben ja kein entsprechendes 
"--fc-route". Ich wüsste auch nicht, womit man den Flow-Control 
verbinden sollte.

Oder sollte ich für "--fc-route" vielleicht noch zwei weitere Port-Paare 
einrichten, wo dann z.B. Putty dran hängt? ?!

STM32 schrieb im Beitrag #4736365:
> Schau Dir mal die Ruhezustände der Handshakeleitungen an.

Meinst Du die Properties im C# SerialPort?
Mach ich heute Nachmittag, aber wie bringt mich/uns das weiter?

Oder meinst Du noch eine andere Anzeige-Möglichkeit,
die ich nicht kenne?