Eventhandler für LPT Ports - Hardwareinterrupts behandeln

[JensHeinrichs]

Hallo Forum,

als Forum-Neuling habe ich gleich mal eine Frage an Euch:

Ich möchte gern über die LPT Schnittstelle einen Hardwareinterrupt einlesen, so wie das immer unter TP geklappt hat - ja ich weiss, das ist alt, hat aber immer sehr gut funktioniert.

Es gab da die Möglichkeit, irgendwelche Schalter über den PIN 1 und 10 der LPTs miteinander zu verbinden und bei dessen Betätigung wurde ein Hardwareinterrupt ( INT 17 ?? ) ausgelöst. Nun konnte man den Orginalinterrupt mit SetIntVec auf eine eigene Routine umbiegen und hatte einen prima Interrupt-Eventhandler für alle möglichen Überwachungsaufgaben.

Diese Zeiten sind ja nun vorbei und unter XP soll das ja auch nicht mehr so schön funktionieren - deshalb habe ich eine alte PS2-Maus auseinander gebaut, einen Kuzschluss erzeugenden Sensor an einen Taster gelötet und bekomme nun immer schön ein OnMouseDown- oder OnMouseUpEvent. So weit, so gut. Wäre da nicht das Problem, dass man mit solch einer Lösung mit dem OS fast nicht mehr arbeiten kann, da ständig vom Sensor Mausklicks erzeugt werden .... ohne Hardwarebastelei sehe ich da keine Lösung.


Daher nun endlich meine eigentliche Frage:

Gibt es für die Drucker auch so etwas wie "OnPaperOut" oder "OnPrinterBusy" ?? Dann könnte man externe Schalter einfach wieder an die LPT-Schnittstelle löten und alles wäre wieder gut ....

Leider habe ich bisher noch nirgendwo etwas gefunden....


Viele Grüße aus Lübeck!

Jens

[Robert Marquardt]

Als Neuling muss man erst lernen das man die Frage nur einmal stellt.

Mit Interrupts in Windows 2000/XP rumspielen ist nur mit einem Treiber moeglich und dann auch nur von einem Treiberexperten.
Generell gehoeren die Interrupts ausschliesslich dem Betriebssystem.

Ich empfehle zur Loesung deines Problems ein bischen Geld zu investieren und Hardware zu kaufen.
Eine digitale IO-Karte oder den IO-Warrior http://www.codemercs.com (ich bin Code Mercenaries Angestellter und mache deshalb einen "shameless product plug").

[Olli]

Zitat von JensHeinrichs:

Daher nun endlich meine eigentliche Frage:

Gibt es für die Drucker auch so etwas wie "OnPaperOut" oder "OnPrinterBusy" ?? Dann könnte man externe Schalter einfach wieder an die LPT-Schnittstelle löten und alles wäre wieder gut ....

Ja, man kann den Druckerstatus ermitteln. Allerdings hängt es vom Treiber und vom Drucker ab, ob er überhaupt sinnvolle Angaben zurückliefert. Wie an dieser Stelle (ganz unten von Xanadu) schonmal besprochen, ist dies in den meisten Fällen nicht der Fall.

Eventuell helfen könnte auch das hier: http://www.delphipraxis.net/internal...ect.php?t=9825

Ansonsten gilt was Robert gesagt hat. Mit einem DDK kann ich dich übrigens gern versorgen. Habe hier noch eines rumzuliegen. Bei Interesse PN an mich

[JensHeinrichs]

... das alles nützt mir nichts. Wie man das Daten, Status und Kontrollregister der LPT ausliest, ist mir bekannt. Ich will aber nicht ständig die Register auslesen, sonders dieses durch den Interrupt selbst erledigen lassen. Da dieser durch den IO-Controller bei Pin10 --> GND erzeugt wird, wäre das eine einfache Lösung.

Wie werden die Maustasten registriert und das OnMouseDown generiert - doch bestimmt nicht durch ständiges Auslesen der Kontrollregister?

Eine externe IO-Karte ist für diese Zwecke wohl etwas übertrieben.

[Robert Marquardt]

Das es dir nicht gefaellt aendert die Realitaet nicht.
Die Realitaet bei einem Betriebssystem wie Windows 2000 oder XP ist das ein Interrupt nicht von einer einfachen Anwendung uebernommen werden kann und selbst fuer einen Treiber ist es nicht einfach.

[JensHeinrichs]

Das es mit dem Übernehmen der Interrupts Probleme geben kann, sehe ich ein.

Deshalb hatte ich ja auch eher nach einer Möglichkeit gesucht, wie man es über die DELPHI-Komponenten machen kann - also eine Art Eventhandler OnIrgendwas bei der LPT ... halt so wie bei der Maus. Die TPrinter Komponente sieht da ja eher etwas mager aus. Gibt es da nicht irgendetwas besseres? Ideal wäre doch ein OnBusy oder OnPaperOut - das kann man an der Schnittstelle simulieren.

[Olli]

Zitat von JensHeinrichs:

Deshalb hatte ich ja auch eher nach einer Möglichkeit gesucht, wie man es über die DELPHI-Komponenten machen kann

Daß man in Delphi aber keine Treiber schreiben kann, ist dir schon klar, oder?
Ich wollte und werde vermutlich auch noch irgendwann etwas schreiben, womit man die ganzen Extra-I/O-Treiber umgehen kann, da der Paralleltreiber von Windows schon vieles von Hause aus kann. Aber sowas wie du willst, kann er meiner Auffassung nach nicht.

[JensHeinrichs]

Treiber will ich auch bestimmt nicht schreiben - das übersteigt meinen Kenntnisse wohl etwas ....

Alles, was ich will, ist aus einer Delphi-Anwendung auf Betätigung eines Schalters reagieren, ohne ständig den IO pollen zu müssen.

Wäre mir auch egal, ob über LPT oder sonst wie - Hauptsache, der Aufwand hält sich in Grenzen und der angeschlossene Sensor stört den Rest des OS nicht.

Über den Taster der Maus geht's ja schon prima - wenn man diese Taste für Windows komplett abschalten und nur von der Anwendung aus wieder aktivieren könnte, wäre ich ja auch schon zufrieden....

[Olli]

Zitat von JensHeinrichs:

Treiber will ich auch bestimmt nicht schreiben

Du verstehst nicht. Zwar kannst du sie nicht mit Delphi schreiben, bei deinem Problem wirst du um einen Treiber aber vermutlich nicht herumkommen. Auch wenn's bitter klingt, genau für Probleme wie deine sind Treiber nunmal da. Und es hat schon seinen Grund, warum die Designer von Windows entschieden haben weder I/O-Portzugriffe noch Interruptzugriffe aus dem Usermode heraus zuzulassen. Einzige, aber beschränkte, Ausnahme sind DOS-Anwendungen in der DOS-Box.

Zitat von JensHeinrichs:

Über den Taster der Maus geht's ja schon prima - wenn man diese Taste für Windows komplett abschalten und nur von der Anwendung aus wieder aktivieren könnte, wäre ich ja auch schon zufrieden....

Kann denn ein Treiber oder die Anwendung überhaupt irgendwie unterscheiden, ob das Signal von einem solchen Taster oder einer echten Maus kommt?

[JensHeinrichs]

Das externe Geräte auch unter Windows über einen Treiber angesprochen werden, ist mir schon klar.

Mein "externes Gerät" ist aber nun so primitiv, dass man dafür die Druckerschnistelle inkl. des Windowstreibers nutzen könnte. Ich suche doch nur nach einer Möglichkeit, über DELPHI das Signal "PaperOut" zum empfangen. Wenn der Windowstreiber so ein Signal nicht unterstützt, habe ich keine Chance, das über DELPHI einzulesen, richtig? Falls der Windowstreiber das nun doch unterstützt, würde doch die Möglichkeit bestehen, dass es eine Komponente in DELPHI gibt, die diesen Treiber verwendet und dieses Ereignis verarbeitet. TPrinter tut das nicht, so weit ich das sehe - vielleicht gibt es ja eine andere, bessere Komponente.

Und genau das war eigentlich meine Frage - anscheined habe ich mich wohl missverständlich ausgedrückt oder bin völlig auf dem Holzweg..... ?


Meine Anwendung braucht das "originale" Maussignal gar nicht - sie läuft völlig allein und wertet in diesem Moment gar keine Usereingaben aus, sondern berechnet die ganze Zeit Daten - ein neuer Datensatz wird dann durch das Auslösen des Sensors angekündigt. Da ich den Sensor aber nicht bei jedem Programmstart an- und nach Programmende wieder abbauen lassen kann, stören dessen weiterhin produzierte Signale ausserhalb meines Programms das WINDOWS erheblich.

Das wäre nicht der Fall, wenn ich den pulsenden Sensor an die LPT hängen könnte - dort stört sich das WINDOWS nicht daran.

Hoffe, ich konnte mein Problem jetzt doch etwas besser erklären.