Tastatureingabe simulieren

Michael Eggert schrieb:

n

Hallo,

-6- Den Aufruf von SendMessage um die Tastatureingabe durch einen=20 Betriebssystemdienst zu simulieren hast Du als M=F6glichkeit vergessen.

Welche M=F6glichkeit f=FCr Dich g=FCnstiger ist kann man Dir erst sagen w= enn=20 Du genauer verr=E4tst was Du vorhast.

Bye

Oder Pollin, 0,95 Eur IIRC, und das ohne Umverpackung. Die Belegung ist meistens schnell rausgefunden.

Ja, muss es, das habe ich selber schon erfolglos probiert. Auch wird es Probleme geben, wenn der PC einen Befehl sendet und beide Tastaturen antworten. Also evtl. meinen Auto-Umschalter

so umbauen, dass er nach kurzer Zeit ohne Tastendrücke wieder auf die normale Tastatur umschaltet (deine Sende-Schaltung müsste dann aber einen Tastendruck vorrausschicken, weil der 1. Tastendruck ja den PC nicht erreicht). Ein µC in der Leitung wäre aber sicherlich die bessere Wahl.

Gruß, Arne

Hi!

Nö, hab ich nicht. Hab nur nach Euren Meinungen zu verschiedenen Hardware-Lösungen gefragt, weil eine Software-Lösung nicht passt.

Passwort-Eingabe. Beim booten (Novell-Anmeldung), beim Start vom Mailprogramm (Lotus), beim Start von SAP. Je >8 Zeichen und alle 3 Monate neu. Obwohl diese Passwort-Paranoia nicht von mir stammt, sondern von "oben" diktiert wird, würde ich die Passwörter lieber auf nem seriellen EEPROM am Schlüsselbund haben als auf der Festplatte (oder auf dem USB-Stick, den man ja auch nicht nur zum Anmelden ansteckt und dann gleich wieder abzieht). Ganz davon abgesehen, daß ich nicht wüsste, wie man Novell bei der Anmeldung was in den Tastaturpuffer schmuggeln sollte.

Inwiefern wirkt sich das nun darauf aus, wie ein AVR das PW aus dem seriellen EEPROM am besten auf den PS/2 Anschluss bekommt?

Gruß, Michael.

Hi!

[Tastatur-Elektronik]

Ei fein!

Das hab ich befürchtet.

Das sollte ja nicht vorkommen, wenn der Simulator (der braucht ja keinen Tastenwiederholgeschwindigkeitsbefehl bekommen) über Dioden so entkoppelt ist, daß er nur senden kann (Anode zum Simulator, er kann also CLK und DATA nahe GND ziehen), aber nichts empfängt (nur seinen pull-up sieht). So kommen Befehle vom PC oder Signale vom anderen Keyboard erst gar nicht beim Simulator an, da wird er auch nix antworten. Oder meldet er sich beim Start automatisch?

Die eigentliche Kommunikation beim Tippen läuft doch unidirektional? Ich meine, wenn die Tastatur ein Zeichen schickt, wird das doch nicht vom PC bestätigt, oder?

Ah, auch mit 4066. Wäre für meinen Zweck aber weit zu umständlich, der Witz ist, daß der Simulator ja weiß, wann er was schickt (und wie lange es in etwa brauchen wird). Insofern kann er für diese Zeit einfach die normale Tastatur abklemmen, ohne dafür den Bus beobachten zu müssen.

Vom Hardwareaufwand wäre es sicher am einfachsten, den ganzen Simulator in einen Controller zu stecken. Alleine einem Tastaturcontroller die Tasten zu simulieren, wäre ja schon ein

4066-Grab. Und so kompliziert scheint das Protokoll ja nicht zu sein, daß man das nicht gleich mit in einen Controller stopfen könnte - den ich ja sowieso brauche (um das serielle EEPROM auszulesen).

Die Frage wäre, ob der AVR schnell genug wär, ganz "dumm" die Signale von einer Seite zur anderen durchzuleiten, wenn er selbst nix senden soll. Also CLK und DATA mit vielleicht 10facher Überabtastung direkt aufs andere Ende durchzureichen. Mist, jetzt hab ich schon wieder nicht mit dem Scope gemessen, wie da die Übertragungsrate ist (und hier zuhause kann ichs nicht). Aber ich glaub, es liegt so im Bereich

1 bis wenige kbit/s, oder?

Dank und Gruß, Michael.

schau mal hier nach

Jürgen

Hi!

Und wieder 4066.. Scheint ja ne gängige Lösung zu sein.

Gruß, Michael.

Hi !

Ist der 4066 eigentlich teuer ?!? Du braucht ja keinen Analog-Switch, ein einfacher digitaler Multiplexer tut es auch (oder UND).

Die CLK muss immer vom Keyboard erzeugt werden, die kommt nicht vom PC.

Bye kal-long

[1..3] fallen IMHO durch. Zu groß und zu unzuverlässig. 4 und 5 haben die selbe Hardware, so sollte man es IMHO auch machen. Ist wirklich minimale Hardwarelösung. 4 geht sicherlich schief, da Du das Datensignal bidirektional ist.

Das einzige, was wirklich zuverlässig hilft, ist für die Tastatur einen PC zu simulieren und für den PC eine Tastatur zu simulieren.

Ich kann zum Protocol folgende Seite empfehlen:

Als Suchbegriff bei google ist "ps2 pic at-keyboard" ganz brauchbar, auch wenn Du keinen PIC benutzt.

----------------

In Deinem Fall kannst Du natürlich überlegen, ob sich da was (an der Software) sparen läßt. Wenn man nicht richtig nachdenkt, ergeben sich daraus aber Einschränkungen im Betrieb.

Man sollte auf jeden Fall vermeiden, daß eine Übertragung unterbrochen wird. Übertragungen können auch mehrere Bytes umfassen. Auch zwischen dem Senden eines Befehls vom PCs und dem ACK der Tastatur macht sich eine Unterbrechung nicht gut

Bist Du sicher, daß der PC nicht periodisch Befehle (z.B. für Leuchtdioden) sendet, auch wenn es eigentlich nicht nötig ist?

Ein bißchen Protokoll-Wissen mußt Du wohl auf jeden Fall reinstecken.

BTW: CLK-Frequenz ist so im Bereich 10-20kHz. Ist in Assembler kein Problem und auch in C sollte das noch gehen. BASIC würde ich nicht versuchen.

/Jan-Hinnerk

Hab' ich ganz vergessen, bei der Lösung kann man das ganze natürlich auch als Keyboard-sniffer zweitverwerten ;-)

/Jan-Hinnerk

Hi !

Nö, 0.18 für die CMOS Version bei Reichelt, und es sind 4 Schalter drin.

Tut nicht, muss bidirektional sein.

Stimmt. Aber wenn der PC was senden will, macht er: CLK ziehen, DATA ziehen, CLK loslassen. Erst dann macht das Keyboard den Takt und der PC kann Befehle schicken. quelle:

unter "timing".

Gruß, Michael.

Eigentlich nicht - das müsste man probieren, ob es mit den Dioden funktioniert. Aber: dann kriegt die andere Tastatur immer noch die Daten mit ab!

Soweit ich weiß, nicht. Jedenfalls sendet die Tastatur das auch fröhlich ohne Bestätigung.

Wo du aufpassen musst: den Bus nicht unterbrechen, wenn gerade gesendet wird! Und es reicht nicht, bei Bedarf die normale Tastatur abzuklemmen, sondern auch die andere Tastatur abzuklemmen, wenn die normale nicht abgeklemmt ist (also immer genau 1 Tastatur verbunden). Sonst melden sich bei Befehlen vom PC beide Tastaturen zurück (oder du machst das mit den Dioden, aber in einem 4066 sind ja eh schon 4 Schalter drin).

20-20KHz, soweit ich weiß. Aber der AVR schafft das problemlos, ich habe hier einen IR-Empfänger aus der Elektor, der eben dies mit einem 2313 bei 4MHz wunderbar hinbekommt.

Gruß, Arne

Tut zumindest meiner nicht. Sonst müsste ja nach dem Umschalten der Tastatur auf der anderen auch irgendwann die NUM-LED angehen, aber die bleibt aus, bis ich 2x auf NUM gedrückt habe.

Gruß, Arne

Hi!

Hab mich derweil wohl auch dagegen entschieden.

Genau in dem Punkt machts doch mal überhaupt nix. Wenn alle Leitungen high dann nix tun. Wenn links ne Leitung low wird, tu die rechts auch low, und kümmer dich solange nicht drum, bis sie links wieder high wird. Ist doch ganz einfach.

Hatte gehofft, daß ich das nicht tun muss. Klar hätte Vorteile, zB könnte man dann auch eine unbenutzte Taste auf dem Keyboard nehmen, um den Simulator zu triggern (ich dachte da mehr an einen Knopf am Simulator).

Aah nett, schau ich mir später mal genauer an. Meine bisherige Information hatte ich aus:

(AN AVR313:Interfacing the PC AT Keyboard)

Tjo, ich hatte nach "avr ps/2" gesucht.

Der Simulator soll ja recht selten und nur auf Knopfdruch senden. Kollisionen mit Initialisierung oder Tippen dürfte da nicht vorkommen.

Ich schau nachher mal mitm Skop, ob sich da was tut.

Schaunmermal. Da ja die Hardware von -4- und -5- gleich sind, kann ich ja erstmal -4- versuchen.

Aah, ist ja handlich.

Eben, denk ich auch.

Hatte ich auch nicht vor.

Dank und Gruß, Michael.

Hi!

Ja, Simulator an Dioden, normales Keyboard an 4066.

Das ist gut.

Das ist klar.

Hm stimmt schon, mir fällt auch sonst nix ein für die beiden anderen

4066 :-)

Das macht Mut.

So, ich muss zur Arbeit, Passwörter tippen :-)

Dank und Gruß, Michael.

Hallo Arne, weisst Du eigentlich, wie im Laptop Maus und Tastatursignale voneinander getrennt werden? Die werden doch auch über e i n e PS2-Buchse angeschlossen. Gruss Harald

Tja, das ist eine gute Frage (die ich mir auch schon gestellt habe). Laut

und ist die Belegung identisch, so dass der Laptop wohl am Protokoll unterscheiden muss. Gerüchteweise habe ich auch schon was von unterschiedlicher Belegung und parallel geschalteten Buchsen in PCs gehört. Scheint aber nicht Standard zu sein. Für Y-Kabel habe ich das hier gefunden (gehört aber wohl nicht zum PS/2-Standard und könnte nicht überall funktionieren):

Wenn jemand genaueres weiß, bitte mal melden!

Gruß, Arne

Wo du aufpassen musst: das ist ein Open-Collector-Bus, das heißt, du darfst nie einen Ausgang auf High haben! Meine Empfehlung: PORTx auf Dauer-0 und DDRx bei Bedarf umschalten (0=Eingang=High, 1=Ausgang=Low). Und aufpassen, dass du vom µC Low gezogene Ausgänge nicht als extern Low gezogene Eingänge interpretierst (vorher in DDRx nachsehen). Pullups brauchst du dann extern.

Keine Sorge, das musst du nicht, das klappt auch so. Das Protokoll ist für sowas primitiv (und langsam) genug.

Da hätte ich auch noch was dazu zu sagen ;-)

Würde ich auch so machen.

Gruß, Arne

Hi!

Sah hier auf dem Skop auch nicht danach aus.

Gruß, Michael.

Hi!

[Arbeitsanweisung für den µC im Bus]

Geht das schnell genug?

Ich könnte auch je 2 Pins pro Leitung und Seite vorsehen, einen als Eingang, und einen mit externem open collector Transistor als Ausgang. Ports hab ich genug, da ich wegen integriertem I2C nen ATMega nehmen werde, wohl irgendeinen im PLCC44.

Genau das ist ja mit der "Arbeitsanweisung" erledigt: Sobald von _einer_ Seite ein LOW kommt, wirds auf die andere Seite übertragen, bis es auf der _einen_ Seite wieder weg ist. Und solange die _eine_ Seite low ist (auf der das LOW zuerst detektiert wurde), interessiert die andere Seite überhaupt nicht. Das ganze natürlich unabhängig für CLK und DATA, sonst kann der PC kein Senden einleiten.

Dankefein!

Gruß, Michael.