Windows 10 setzt beim öffnen eines COM-Ports als Standard immer den DTR Pin auf ON gesetzt, leider sitzt auf der anderen Seite ein Device das bei DTR High einen Reset auslöst...
Flusssteuerung steht auf "Keine", leider wird der DTR trotzdem beim öffnen des Ports gesetzt. Im Gerätemanager gibt's leider auch keine Einstellungsmöglichkeit und ein inventieren des DTR-Signals (beim FT232RL möglich) ist auch nicht Zielführend, da dann bei geschlossenem Port ein Dauer-Reset gemacht wird.
Gibt es da irgendeinen Trick wie ich den DTR abschalten kann?
Dann muss das PC seitige Programm den DTR korrekt bedienen um das Gerät
korrekt zu bedienen.
Ja entweder die Software, was sie nicht macht, oder irgend was zusätzliches was den DTR fest deaktiviert (deshalb die Frage)
Erzähl doch einfach mal um was für ein Gerät es sich handelt und was du
genau machen willst.
Spielt eigentlich bei dem generellen Problem (DTR macht Hardware Reset) keine Rolle, aber die Software nennt sich CANHacker und Hardware ist ein alter USB SLCAN-Adapter
UART Ansteuerung mit hterm, ZOC (DTR Signal off) möglich, aber nicht mit CANHacker, Windows Terminal, putty, TeraTerm (nur mit Macro setdtr 0)
Staus LED normal immer an, bei (Dauer)Reset aus, Problem liegt also definitiv am DTR Signal.
Ja entweder die Software, was sie nicht macht, oder irgend was
zusätzliches was den DTR fest deaktiviert (deshalb die Frage)
Wenn Du in der Lage bist, eigene Software zu schreiben, könntest Du die Anwendungen, die Du benutzen willst, mit einem virtuellen Port von com0com reden lassen. Am anderen Ende hängt dann Dein Tool, das zwischen virtuellem und echtem COM-Port Daten schaufelt und dabei DTR ausgeschaltet lässt.
Geht etwas durch die Brust ins Auge, aber sollte funktionieren.
Windows 10 setzt beim öffnen eines COM-Ports als Standard immer den DTR
Pin auf ON gesetzt, leider sitzt auf der anderen Seite ein Device das
bei DTR High einen Reset auslöst...
Das Problem scheint bekannt zu sein. Daher wird oft der Resetpin über einen Kondensator angesteuert. Es wird also nur ein kurzer Impuls ausgelöst, egal wie DTR steht.
Erzähl doch einfach mal um was für ein Gerät es sich handelt und was du
genau machen willst.
Spielt eigentlich bei dem generellen Problem (DTR macht Hardware Reset)
keine Rolle,
Doch spielt eine Rolle, weil es schlicht unklar ist, wie es überhaupt zu der Situation kommen kann.
Du tust so als ob das ein Windows Problem wäre. Ist es nicht.
So viele Geräte laufen über UART und nutzen den DTR und es geht.
aber die Software nennt sich CANHacker und Hardware ist ein
alter USB SLCAN-Adapter
UART Ansteuerung mit hterm, ZOC (DTR Signal off) möglich, aber nicht mit
CANHacker, Windows Terminal, putty, TeraTerm (nur mit Macro setdtr 0)
Dann kann das Gerät eben schlicht NICHT mit der SW CanHacker zusammen arbeiten. So einfach manchmal.
Der DTR wird wohl nur für Firmwareupdates benötigt, die Idee mit temporärem deaktivieren im FTDI Chip EEProm oder der Treiber.ini hatte ich auch schon, aber außer den DTR zu inventieren habe ich keine andere Möglichkeit gefunden.
Die Software ist leider auch schon steinalt und wird schon viele Jahre nicht mehr gepflegt, stammt noch aus der Win XP/7 Zeit. Ich habe auch keine andere gefunden die das SLCAN Protokoll nutzt und freie Hardware über COM Port zulässt.
Das ist flash. Setzte die Flussteuerung mal auf "Hardware" oder "RTS/CTS".
Bei mindestens einer der Einstellungen lässt Windows die Steuersignale in Ruhe, es ist aber eben NICHT die Einstellung "keine".
Dafür muss aber der Code in der Anwendung selbst sauber programmiert sein. Oftmals gäbe es die Option aber irgendwo wenn der Code noch aus Zeiten von echten seriellen Schnittstellen stammte.
Das ist flash. Setzte die Flussteuerung mal auf "Hardware" oder
"RTS/CTS".
Bei mindestens einer der Einstellungen lässt Windows die Steuersignale
in Ruhe, es ist aber eben NICHT die Einstellung "keine".
Das ist natürlich kompletter Unsinn. Die einzige Einstellung, bei der "Windows" (in Wirklichkeit natürlich: der Treiber) selber mit den Signalen hantiert, ist natürlich "Hardware". Ist logisch, weil der Hardware-Handshake nunmal über eben diese Leitungen abgewickelt wird und der Treiber deshalb natürlich nicht umhinkommt, daran rumzuspielen.
Bei allen anderen Einstellungen hat die Software, die den Port öffnet, die Kontrolle über diese Leitungen. Windows mischt sich da nicht weiter ein. Dementsprechend kann man auch nur bei der Software selber ansetzen, um da etwas am Verhalten dieser Leitungen zu ändern.
Ist das nicht möglich, bleibt nur noch physisches Abtrennen der Hardware. Sprich: Dreileiterstrippe als Verlängerung verwenden und alles ist gut.
mode hat bei USB-Seriell Adaptern Einschränkungen bei Handshake Signalen.
Kanns leider nur mit CP210x nachvollziehen, laut Auskunft einer gewöhnlich gut unterrichteten Software könnte dies beim FT232RL auch so sein.
Spannungsmessung am DTR pin(Low = 0V, High = 3,3V)
1
nach Einstecken DTR High
2
mit teraterm öffnen DTR Low
3
teraterm schließen DTR High
4
mode com3 dtr=on DTR kurzer glitch nach Low, dann sofort wieder High
mit python:
1
DTR High
2
import serial
3
ser = serial.Serial('COM3') DTR Low
4
ser.dtr = False DTR High
5
ser.dtr = True DTR Low
6
ser.close() DTR High
Works as designed: Der Zweck von DTR ist es, einem angeschlossenen Gerät anzuzeigen, dass das Gerät (Computer) bereit ist, Daten zu kommunizieren.
mode hat bei USB-Seriell Adaptern Einschränkungen bei Handshake
Signalen.
Kann sein, dass es mit manchen Einschränkungen gibt.
Ich benutze es wenn ich den DTR Reset von Arduinos unterbinden möchte, um z.B. um per copy Daten vom PC zum Arduino zu spielen.
Funktionieren tuts mit 16U2 eines UNO und CH340 der Nano Nachbauten.
Mit "Mode" konnte ich leider auch keine funktionieren Einstellung machen...
Habe mit com0com zwei virtuelle Com Ports nur mit durchverbundenen TX/RX Steuerleitungen erstellt und da die sich ja nicht mit einem echten COM-Port verbinden lassen noch mit hub4com per Kommandozeile verbunden:
hub4com-2.1.0.0-386>hub4com --create-filter=pinmap:--dtr=!dsr --add-filters=0,1:pinmap --baud=115200 \.\COM4 \.\COM6
COM4 Open("\.\COM4", baud=115200, data=8, parity=no, stop=1, octs=on, odsr=off, ox=off, ix=off, idsr=off, ito=0) - OK
COM6 Open("\.\COM6", baud=115200, data=8, parity=no, stop=1, octs=on, odsr=off, ox=off, ix=off, idsr=off, ito=0) - OK
Route data COM4(0) --> COM6(1)
Route data COM6(1) --> COM4(0)
Route flow control COM4(0) --> COM6(1)
Route flow control COM6(1) --> COM4(0)
Filters:
1
\--------------->
COM4(0) |
________/<-{pinmap.OUT}<-
1
\--------------->
COM6(1) |
________/<-{pinmap.OUT}<-
COM4(0) Event(s) [DSR] will be monitored
Started COM4(0)
COM6(1) Event(s) [DSR] will be monitored
Started COM6(1)
Error COM4(0): OVERRUN, total RXOVER=0 OVERRUN=1 RXPARITY=0 FRAME=0
scheint zu funktionieren, LED bleibt an, aber dann kommt Error nach kurzer Zeit.
Eigentlich dürfte das egal sein, da RTS/CTS an jedem Port verbunden sind, aber mit ++octs=off funktioniert es jetzt endlich!!! Nur Schade das Windows dafür immer mit Startoption 7 (Treibersign. deaktivieren) gebootet werden muss...
Hier die funktionierende Config wenn USB-Device an COM4 hängt:
com0com wie auf dem Foto einstellen und in Adim Eingabeaufforderung:
Nur Schade das Windows dafür immer mit Startoption 7 (Treibersign.
deaktivieren) gebootet werden muss...
Sollte aber nur bei der Treiberinstallation, also beim Anlegen eines neuen Port-Paars notwendig sein, oder?
Aber schön, dass es funktioniert. Ich hatte hub4com gar nicht mehr im Hinterkopf und hätte mir wohl unnötig ein eigenes Tool für die Verbindung zwischen com0com und dem echten Port gebaut.
https://www.serialtool.com/ hat signierten Treiber, der unter Win10 und Win11 bei mir problemlos funktioniert.
Ein Pärchen kann man in der Free-Version installieren, harmoniert auch mit hub4com.
