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
Hi! Ok, es geht wohl nicht. Vielen Dank für eure Antworten! Gruß PP
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.
Nicht getesteter Ansatz den man ausprobieren könnte... SetDefaultCommConfig http://msdn.microsoft.com/en-us/library/aa363438(v=vs.85).aspx
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
Hauptsache ihr fühlt euch nun besser. Ganz ohne Medikamente. Arme Irren.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.