Hallo,
ich möchte ein Programm schreiben (idealerweise C/C++ Konsolenanwendung,
Visual Studio 2005 Prof., Windows XP) das den COM-Port öffnet, ein paar
Zeichen rausschickt und den COM-Port schließt. Allerdings soll danach
die DTR Leitung auf "Aktiv" (+12V) bleiben.
COM-Port öffnen, Zeichen senden und schließen geht schon. Während der
Port geöffnet ist, kann ich auch DTR nach Belieben auf "Aktiv" (+12V)
und "Inaktiv" (-12V) setzen. Allerdings geht die DTR-Leitung nach dem
Schließen immer auf "Inaktiv", egal ob ich sie auf "Aktiv" oder
"Inaktiv" gesetzt habe.
Der COM-Port müsste nicht einmal "richtig" geschlossen werden.
Hauptsache, ein anderes Programm kann normal darauf zugreifen.
Gruß
PP
Paulchen Panther schrieb:> Allerdings soll danach> die DTR Leitung auf "Aktiv" (+12V) bleiben.
Das wäre ja ein Widerspruch in sich. Wenn der Port geschlossen ist, wäre
die Statusanzeige "Data Terminal Ready" Unfug, da ein geschlossener Port
nicht bereit ist. Warum sollte der Treiber das also zulassen.
Du mußt einen Server schreiben, der beide Clients "Programme" als Kunden
zuläßt.
Wobei ich mich momentan frage, was bei einem Windoof-Rechner passiert,
wenn man zwei Batch-Dateien in Serie, Daten an eine serielle
Schnittstelle schicken läßt. Ist DTR nur während einzelner Zeichen
aktiv? Es wird ja keine Schnittstelle geöffnet!
Ehrlich gesagt, ich benutze nie DTR ;-)
Abdul K. schrieb:> Wobei ich mich momentan frage, was bei einem Windoof-Rechner passiert,> wenn man zwei Batch-Dateien in Serie, Daten an eine serielle> Schnittstelle schicken läßt. Ist DTR nur während einzelner Zeichen> aktiv? Es wird ja keine Schnittstelle geöffnet!
warum sollte dabei die Schnittstelle nicht geöffnet werden. Es ist genau
so ein spezial device wie unter unix.
Hm. Es reicht wenn man so eine Batch-Datei ausführen läßt:
mode COM1:9600,N,8,1
echo bla bla >COM1
Selbst mode könnte man weglassen, wenn man mit den Default-Werten
vorlieb nimmt. Da wird nix geöffnet!!
Hallo,
Danke für die fixen Antworten. ;-)
Michael schrieb:> Das wäre ja ein Widerspruch in sich. Wenn der Port geschlossen ist, wäre>> die Statusanzeige "Data Terminal Ready" Unfug, da ein geschlossener Port>> nicht bereit ist. Warum sollte der Treiber das also zulassen.
Warum sollte der Treiber das explizit verbieten? ;-)
Ich steuere mit der DTR Signal ein Relais an. Dieses Relais soll auch
nach dem Beenden des Programms angezogen bleiben.
Abdul K. schrieb:> Ist DTR nur während einzelner Zeichen>> aktiv? Es wird ja keine Schnittstelle geöffnet!
Nein. DTR wird aktiv sobald der Port geöffnet ist und inaktiv wenn der
Port wieder geschlossen wird. Ob und wieviele Zeichen gesendet werden,
ist dabei egal.
BTW: Wie machen es diese COM-Port Sniffer dass ein anderes Programm den
COM-Port normal nutzen kann?
Gruß
PP
Abdul K. schrieb:> Selbst mode könnte man weglassen, wenn man mit den Default-Werten> vorlieb nimmt. Da wird nix geöffnet!!
Du hast wohl nicht den Schatten einer Ahnung, was im Hintergrund alles
abläuft, wenn du einen Befehl eintippst. Selbstverständlich behandelt
die Shell oder darin aufgerufene Systemprogramme den COM-Device korrekt,
wie man das von jedem anderen Programm auch verlangt.
Und wenn man eine Datei oder ein Device schliesst, "gehört" einem das
Objekt nicht mehr. Es wäre ein klarer Widerspruch zu den Grundlagen von
Multiuser/Multiprogramming, wenn man posthume Verfügungen treffen
könnte. Spätestens ein Programm, das den COM-Port für sich öffnet, kann
alles ändern, sonst würde ja kaum eine Software mit serieller
Schnittstelle funktionieren.
Und wenn einem das Default-Verhalten des Treibers nicht passt, muss man
einen eigenen Treiber schreiben.
Gruss Reinhard
Sollte es sich bei dem, an die COM-Schnittstelle angeschlossenenen,
Gerät um ein Modem handeln, welches nach der Anwahl nicht auflegen soll,
hilft auch ein "AT&d0", dann wird der Zustand der DTR-Leitung vom Modem
ignoriert.
mfG ingo
ingo schrieb:> Sollte es sich bei dem, an die COM-Schnittstelle angeschlossenenen,> Gerät um ein Modem handeln,Paulchen Panther schrieb:> Ich steuere mit der DTR Signal ein Relais an. Dieses Relais soll auch> nach dem Beenden des Programms angezogen bleiben.
Relais, die sich an den Hayes-Befehlssatz halten, sind, äh,
ungebräuchlich.
Reinhard Kern schrieb:> Abdul K. schrieb:>> Selbst mode könnte man weglassen, wenn man mit den Default-Werten>> vorlieb nimmt. Da wird nix geöffnet!!
Im Batch wird nix geöffnet!! Was andere Stellen im BS machen, war so
nicht erkennbar.
>> Du hast wohl nicht den Schatten einer Ahnung, was im Hintergrund alles> abläuft, wenn du einen Befehl eintippst. Selbstverständlich behandelt> die Shell oder darin aufgerufene Systemprogramme den COM-Device korrekt,> wie man das von jedem anderen Programm auch verlangt.>> Und wenn man eine Datei oder ein Device schliesst, "gehört" einem das> Objekt nicht mehr. Es wäre ein klarer Widerspruch zu den Grundlagen von> Multiuser/Multiprogramming, wenn man posthume Verfügungen treffen> könnte. Spätestens ein Programm, das den COM-Port für sich öffnet, kann> alles ändern, sonst würde ja kaum eine Software mit serieller> Schnittstelle funktionieren.
Ich weiß schon wie man einen UART bearbeiten muß, was allerdings Windoof
wie macht und nicht macht, das weiß ich nicht im Detail. Ich würde
nachmessen und mich nicht sonderlich auf andere verlassen.
Ein Relais fällt nicht sofort ab. Vielleicht reicht das ja.
>> Und wenn einem das Default-Verhalten des Treibers nicht passt, muss man> einen eigenen Treiber schreiben.>
Schrieb ich ja schon.
Es spricht nichts gegen eine serielle Schnittstelle, die mehrere Streams
gleichzeitig unterstützt. Oder den Eingangskanal anders verknüpft als
den Sendekanal. Oder beliebig andere Ideen, z.B. Sendeparameter andere
als Empfangsparameter etc.
Ein Beispiel ist TCP/IP über Ethernet.
Abdul K. schrieb:> Reinhard Kern schrieb:>> Abdul K. schrieb:>>> Selbst mode könnte man weglassen, wenn man mit den Default-Werten>>> vorlieb nimmt. Da wird nix geöffnet!!>> Im Batch wird nix geöffnet!! Was andere Stellen im BS machen, war so> nicht erkennbar.
Natürlich wird auch dort der Port geöffnet.
Die Redirection, respektive die Shell, macht das implizit mit.
Sorry. Aber es gibt nun mal gewisse Grundforderungen, die von jedem
eingehalten werden müssen. Eine davon lautet: Alle Resourcen eines
Prozesses werden bei Beendigung des Prozesses wieder freigegeben (sofern
das möglich ist, was bei einem von aussen erzwungenem Prozessende
manchmal gar nicht so einfach ist). Eine COM Schnittstelle kann von
einem Prozess für sich reklamiert werden und wird ihm dann, wenn sie
nicht anderweitig zugeordnet wurde, zugesprochen. Wird der Prozess, aus
welchem Grund auch immer, beendet, so verfallen alle seine Anforderungen
und das BS muss die Resource eventuell in einen Grundzustand
zurückfahren. Und das ist auch gut so, denn ansonsten würde dir jeder
abgestürzte Prozess sukzessive das System lahmlegen bzw. der nächste
Prozess würde eine Resource in einem fehlerhaften Zustand übernehme und
müsste sich erst mal damit herumschlagen, diese Resource aus dem Fehler
herauszubekommen. Das kann aber ein ordinärer Prozess unter Umständen
gar nicht, denn das BS muss gewisse Dinge auch abblocken und abfangen.
Dem BS selbst hingegen stehen ganz andere Möglichkeiten zur Verfügung
als einem ordinären User-Prozess.
Einfach mal weniger raten und dafür überlegen, wie ein Beamter im realen
Leben das machen würde/müsste. Den genau dasselbe muss auch ein BS tun,
nur dass ein BS das alles noch konsequenter durchzieht als das ein
Beamter aus prkatischen Gründen je tun könnte.
> Ich weiß schon wie man einen UART bearbeiten muß, was allerdings Windoof> wie macht und nicht macht, das weiß ich nicht im Detail.
Es macht genau dasselbe, was jedes andere Betriebssystem, welches die
Anforderungen mehrerer Prozesse verwalten und unter einen Hut bringen
muss, auch tut. Warum? Weil es das tun muss um einen geordneten Betrieb
sicher zu stellen, der nicht auf irgendwelchen windigen Annahmen beruht.
Es ist völlig uninteressant, was das BS intern macht. Allein interessant
ist, was man als User benutzen bzw. erreichen kann.
Darum ging es!
Wie gesagt, ich bin kein Windoof-Programmierer (auf welcher Ebene auch
man das betrachtet). Mein Wissen hört bei einer Batch-Datei oder PHP und
deren Möglichkeiten schlicht auf. Batch und PHP würde ich jetzt nicht
als richtiges Win-Programmieren betrachten.
Daher sinnlose Diskussion oder Forschen nach Nichtwissen.
Bleib lieber beim Thema. Danke.
Abdul K. schrieb:> Selbst mode könnte man weglassen, wenn man mit den Default-Werten> vorlieb nimmt. Da wird nix geöffnet!!
Da liegst du falsch.
Der Port wird geöffnet, "bla bla" wird über den Port gesendet und dann
wird der Port wieder geschlossen. Guck dir das mal mit einem Portmonitor
an.
Abdul K. schrieb:> Es ist völlig uninteressant, was das BS intern macht. Allein interessant> ist, was man als User benutzen bzw. erreichen kann.>> Darum ging es!
Eben. Man sollte aber auch akzeptieren, dass es für so manches Verhalten
einen guten Grund gibt.
> Wie gesagt, ich bin kein Windoof-Programmierer
Bei dem was du alles nicht weißt, wirkt es ein bischen lächerlich, wenn
du den Begriff Windoof benutzt. Windows hat unbestritten seine Schwächen
und seine Ecken und Kanten. Aber es kann nichts dafür, dass du nicht
durchschaust warum manche Dinge so sind wie sie sind (nicht nur auf
Windows)
Wo habe ich denn nichts durchschaut? Du redest Blödsinn.
Man startet obiges Batch und guckt mit einem Zweistrahler TXD und DTR
gleichzeitig an. Fertig.
Alles andere ist Zeitverschwendung, oder man weiß es halt vorher und
stellt keine Frage.
Abdul K. schrieb:> Wo habe ich denn nichts durchschaut? Du redest Blödsinn.
Ist schon gut. Ich denke mittlerweile haben es alle geschnallt, dass du
zumindest davon 0 Ahnung hast.
Karl Heinz Buchegger schrieb:> Ist schon gut. Ich denke mittlerweile haben es alle geschnallt, dass du> zumindest davon 0 Ahnung hast.
lass ihn noch ein bisschen schwafeln, ist grad so lustig
