Tastatureingabe simulieren

[Michael Eggert]

Moin!

Ich würde gerne eine Tastatureingabe (PS/2) simulieren, das heißt in
Hardware auf Knopfdruck eine bestimmte Zeichenfolge an den Rechner
schicken. Kollisionen zwischen Keyboard und Zeichenfolgen-Generator
sollten nicht vorkommen, es ist immer nur eins aktiv.

Verschiedene Lösungsansätze:

-1-
Direkt ins vorhandene Keyboard ein Pfund 4066 rein, um gedrückte
Tasten zu simulieren.

-2-
Man nehme eine Keyboardelektronik (für 4,20 bei Reichelt, muss nur die
Umverpackung aka Keyboard entfernen) und simuliere die Tasten per
4066. Das ganze parallel zum normalen Keyboard, über Dioden (Kathode
zum Simulator) so entkoppelt, daß der Simulator nur senden kann (pull
down) und sonst nix mitkriegt. Dummerweise wird das normale Keyboard
das als Befehl vom PC verstehen, muss also während der Simulator
sendet abgekoppelt werden (wieder 4066).

-3-
Simulator+Controller = AVR, das spart die 4066-Matrix.
Wieder parallel zum normalen Keyboard, wieder muss das normale
Keyboard beim Senden des Simulators abgekoppelt werden.

-4-
AVR _zwischen_ Keyboard und PC. Zu beiden Seiten pull-up. Signale "von
außen" werden per Software 1:1 durchgeschleift, und zwar auf
low-level-Ebene. Also "wenn Keyboard clock zieht, zieh ich auch
clock". Keinerlei Interpretation, kein Zusammensetzen zu bytes.

-5-
AVR _zwischen_ Keyboard und PC. Zu beiden Seiten pull-up. Signale
werden zu Bytes, Bytes werden zu Signalen.


Eure Meinung?

Gruß,
Michael.

 

[Uwe Hercksen]

Michael Eggert schrieb:

Moin!

Ich würde gerne eine Tastatureingabe (PS/2) simulieren, das heißt in
Hardware auf Knopfdruck eine bestimmte Zeichenfolge an den Rechner
schicken. Kollisionen zwischen Keyboard und Zeichenfolgen-Generator
sollten nicht vorkommen, es ist immer nur eins aktiv.

Verschiedene Lösungsansätze:

Hallo,

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

Welche Möglichkeit für Dich günstiger ist kann man Dir erst sagen wenn
Du genauer verrätst was Du vorhast.

Bye

 

[Arne Rossius]

Man nehme eine Keyboardelektronik (für 4,20 bei Reichelt, muss nur die
Umverpackung aka Keyboard entfernen) und simuliere die Tasten per

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

4066. Das ganze parallel zum normalen Keyboard, über Dioden (Kathode
zum Simulator) so entkoppelt, daß der Simulator nur senden kann (pull
down) und sonst nix mitkriegt. Dummerweise wird das normale Keyboard
das als Befehl vom PC verstehen, muss also während der Simulator
sendet abgekoppelt werden (wieder 4066).

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
http://www.elektronik.de.vu/schalt/fuerpc/keybrdsw.htm 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

 

[Michael Eggert]

On Thu, 11 Dec 2003 09:33:28 +0100, Uwe Hercksen
<hercksen@mew.uni-erlangen.de> wrote:

Hi!

Den Aufruf von SendMessage um die Tastatureingabe durch einen
Betriebssystemdienst zu simulieren hast Du als Möglichkeit vergessen.

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

Welche Möglichkeit für Dich günstiger ist kann man Dir erst sagen wenn
Du genauer verrätst was Du vorhast.

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.

Bye

 

[Michael Eggert]

On Thu, 11 Dec 2003 15:49:47 +0100, "Arne Rossius"
<ArneRossius@despammed.com> wrote:

Hi!

[Tastatur-Elektronik]

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

Ei fein!

Das ganze parallel zum normalen Keyboard, über Dioden (Kathode
zum Simulator) so entkoppelt, daß der Simulator nur senden kann (pull
down) und sonst nix mitkriegt. Dummerweise wird das normale Keyboard
das als Befehl vom PC verstehen, muss also während der Simulator
sendet abgekoppelt werden (wieder 4066).

Ja, muss es, das habe ich selber schon erfolglos probiert.

Das hab ich befürchtet.

Auch wird es
Probleme geben, wenn der PC einen Befehl sendet und beide Tastaturen
antworten.

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?

Also evtl. meinen Auto-Umschalter
http://www.elektronik.de.vu/schalt/fuerpc/keybrdsw.htm 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).

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.

Ein ľC in der Leitung wäre aber sicherlich die bessere Wahl.

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.

 

[Jürgen Schulz]

Ich würde gerne eine Tastatureingabe (PS/2) simulieren, das heißt in
Hardware auf Knopfdruck eine bestimmte Zeichenfolge an den Rechner
schicken. Kollisionen zwischen Keyboard und Zeichenfolgen-Generator
sollten nicht vorkommen, es ist immer nur eins aktiv.

schau mal hier nach
http://home.t-online.de/home/jens.dietrich/seite99.htm

Jürgen

 

[Michael Eggert]

On Thu, 11 Dec 2003 22:01:13 +0100, Jürgen Schulz
<schulle.juergen@t-online.de> wrote:

Hi!

schau mal hier nach
http://home.t-online.de/home/jens.dietrich/seite99.htm

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

Gruß,
Michael.

 

[ka-long]

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

 

[Jan-Hinnerk Reichert]

Michael Eggert wrote:

Moin!

Ich würde gerne eine Tastatureingabe (PS/2) simulieren, das heißt in
Hardware auf Knopfdruck eine bestimmte Zeichenfolge an den Rechner
schicken. Kollisionen zwischen Keyboard und Zeichenfolgen-Generator
sollten nicht vorkommen, es ist immer nur eins aktiv.

[1..3] fallen IMHO durch. Zu groß und zu unzuverlässig.

-4-
AVR _zwischen_ Keyboard und PC. Zu beiden Seiten pull-up. Signale
"von außen" werden per Software 1:1 durchgeschleift, und zwar auf
low-level-Ebene. Also "wenn Keyboard clock zieht, zieh ich auch
clock". Keinerlei Interpretation, kein Zusammensetzen zu bytes.

-5-
AVR _zwischen_ Keyboard und PC. Zu beiden Seiten pull-up. Signale
werden zu Bytes, Bytes werden zu Signalen.

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:

http://panda.cs.ndsu.nodak.edu/~achapwes/PICmicro/PS2/ps2.htm

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

 

[Jan-Hinnerk Reichert]

Jan-Hinnerk Reichert wrote:

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.

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

/Jan-Hinnerk

 

[Michael Eggert]

On 11 Dec 2003 15:23:30 -0800, kiqmarvin@web.de (ka-long) wrote:

Hi !

Ist der 4066 eigentlich teuer ?!?

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

Du braucht ja keinen Analog-Switch, ein einfacher digitaler
Multiplexer tut es auch (oder UND).

Tut nicht, muss bidirektional sein.

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

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: http://www.atmel.com/dyn/resources/prod_documents/DOC1235.PDF
unter "timing".

Gruß,
Michael.

Bye kal-long

 

[Arne Rossius]

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?^

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!

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?

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

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.

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).

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?

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

 

[Arne Rossius]

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

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

 

[Michael Eggert]

On Fri, 12 Dec 2003 03:15:22 +0100, Jan-Hinnerk Reichert
<hinni@despammed.com> wrote:

Hi!

fallen IMHO durch. Zu groß und zu unzuverlässig.

Hab mich derweil wohl auch dagegen entschieden.

-4-
AVR _zwischen_ Keyboard und PC. Zu beiden Seiten pull-up. Signale
"von außen" werden per Software 1:1 durchgeschleift, und zwar auf
low-level-Ebene. Also "wenn Keyboard clock zieht, zieh ich auch
clock". Keinerlei Interpretation, kein Zusammensetzen zu bytes.

4 geht sicherlich schief, da Du das Datensignal bidirektional ist.

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.

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.

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).

Ich kann zum Protocol folgende Seite empfehlen:

http://panda.cs.ndsu.nodak.edu/~achapwes/PICmicro/PS2/ps2.htm

Aah nett, schau ich mir später mal genauer an. Meine bisherige
Information hatte ich aus:
http://www.atmel.com/dyn/resources/prod_documents/DOC1235.PDF
(AN AVR313:Interfacing the PC AT Keyboard)

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

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

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

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

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

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

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

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

BTW: CLK-Frequenz ist so im Bereich 10-20kHz.

Aah, ist ja handlich.

Ist in Assembler kein Problem und auch in C sollte das noch gehen.

Eben, denk ich auch.

BASIC würde ich nicht versuchen.

Hatte ich auch nicht vor.

Dank und Gruß,
Michael.

 

[Michael Eggert]

On Fri, 12 Dec 2003 08:13:16 +0100, "Arne Rossius"
<ArneRossius@despammed.com> wrote:

Hi!

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?^

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!

Ja, Simulator an Dioden, normales Keyboard an 4066.

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?

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

Das ist gut.

Wo du aufpassen musst: den Bus nicht unterbrechen, wenn gerade gesendet
wird!

Das ist klar.

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).

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

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.

Das macht Mut.

So, ich muss zur Arbeit, Passwörter tippen

Dank und Gruß,
Michael.

 

[Harald Wilhelms]

"Arne Rossius" <ArneRossius@despammed.com> wrote in message news:<bra09o$ftg$01$1@news.t-online.com>...

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
http://www.elektronik.de.vu/schalt/fuerpc/keybrdsw.htm so umbauen, dass
er nach kurzer Zeit ohne Tastendrücke wieder auf die normale Tastatur
umschaltet

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

 

[Arne Rossius]

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

Tja, das ist eine gute Frage (die ich mir auch schon gestellt habe).
Laut http://hardwarebook.net/connector/userinput/keyboardpc6.html und
http://hardwarebook.net/connector/userinput/ps2mouse.html 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):
http://hardwarebook.net/adapter/userinput/ps2keyboardythinkpad.html
http://hardwarebook.net/adapter/userinput/ps2keyboardygateway.html

Wenn jemand genaueres weiß, bitte mal melden!

Gruß,
Arne

 

[Arne Rossius]

AVR _zwischen_ Keyboard und PC. Zu beiden Seiten pull-up. Signale
"von außen" werden per Software 1:1 durchgeschleift, und zwar auf
low-level-Ebene. Also "wenn Keyboard clock zieht, zieh ich auch
clock". Keinerlei Interpretation, kein Zusammensetzen zu bytes.

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.

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.

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.

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).

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

http://panda.cs.ndsu.nodak.edu/~achapwes/PICmicro/PS2/ps2.htm

http://www.atmel.com/dyn/resources/prod_documents/DOC1235.PDF

Da hätte ich auch noch was dazu zu sagen ;-)
http://www.beyondlogic.org/keyboard/keybrd.htm

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

Würde ich auch so machen.


Gruß,
Arne

 

[Michael Eggert]

"Arne Rossius" <ArneRossius@despammed.com> wrote in message news:<brbq2i$uvo$00$1@news.t-online.com>...

Hi!

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

Tut zumindest meiner nicht.

Sah hier auf dem Skop auch nicht danach aus.

Gruß,
Michael.

 

[Michael Eggert]

"Arne Rossius" <ArneRossius@despammed.com> wrote in message news:<brc7nj$gqc$06$1@news.t-online.com>...

Hi!

[Arbeitsanweisung für den ľC im Bus]

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.

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).

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.

Und aufpassen, dass du vom ľC Low gezogene Ausgänge nicht als extern Low
gezogene Eingänge interpretierst (vorher in DDRx nachsehen).

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.

http://www.beyondlogic.org/keyboard/keybrd.htm

Dankefein!

Gruß,
Michael.