Tastatur Scancodes und weitere Infos

    Hallo,


    ich möchte mit einem Microcontroller bestimmte Tasten einer ganz normalen PC-Tastatur emulieren - hat jemand eine gute Seite mit Infos darüber? Ich habe bisher eigentlich nur Infos über die Scancodes als solches gefunden, aber nichts näheres über das Protokoll selber. Gibt es Start/Stopp-Bits? Wie hoch ist die Frequenz usw.. wie sieht die Übertragung wirklich aus, bei z.B. Druck auf Taste "a"? Kennt jemand eine Seite, wo solche Basics erklärt sind? Vielleicht verwende ich auch einfach nur die falschen Googlesuchbegriffe ;)

    Je mehr Käse, desto mehr Löcher.
    Je mehr Löcher, desto weniger Käse.
    Ergo: Je mehr Käse, desto weniger Käse.

    Issen synchrones Protokoll, kein Start/Stopbit, ziemlich langsam.
    Infos finden sich zu Tonnen im Netz... vielleicht fällt mir noch was ein.
    Kollege hatte mal was mit einem MC68HC05 emuliert...

    "As we know, there are known knowns. There are things we know we know. We also know there are known unknowns. That is to say we know there are some things we do not know. But there are also unknown unknowns, the ones we don't know we don't know." (Donald Rumsfeld)
    "Ich weiß, dass ich nichts weiß." (Sokrates)
    "Ich weiß nicht mal, dass ich nichts weiß." (Simba2)
    "Ich weiß' alles" (Alpina-Katze)

    Guckst Du hier
    Suchbegriff: "ibm keyboard protocol"


    Achso, jede Taste macht einen "Make" und "Break"-Code (Drücken/Loslassen)

    "As we know, there are known knowns. There are things we know we know. We also know there are known unknowns. That is to say we know there are some things we do not know. But there are also unknown unknowns, the ones we don't know we don't know." (Donald Rumsfeld)
    "Ich weiß, dass ich nichts weiß." (Sokrates)
    "Ich weiß nicht mal, dass ich nichts weiß." (Simba2)
    "Ich weiß' alles" (Alpina-Katze)

    Einmal editiert, zuletzt von tcfkao ()

    Warum wusste ich, dass wenn DU darauf produktiv antwortest? ;))


    Ich danke dir, werde mir das morgen mal zu gemühte führen. Sogar ein ASM Source um sich etwas zu orientieren - mit richtigen Suchbegriffen geht eben alles ;)

    Je mehr Käse, desto mehr Löcher.
    Je mehr Löcher, desto weniger Käse.
    Ergo: Je mehr Käse, desto weniger Käse.

    ;) Ich bin halt mit jedem Bit auf Du und Du....

    "As we know, there are known knowns. There are things we know we know. We also know there are known unknowns. That is to say we know there are some things we do not know. But there are also unknown unknowns, the ones we don't know we don't know." (Donald Rumsfeld)
    "Ich weiß, dass ich nichts weiß." (Sokrates)
    "Ich weiß nicht mal, dass ich nichts weiß." (Simba2)
    "Ich weiß' alles" (Alpina-Katze)

    Zitat

    Original von tcfkao
    ;) Ich bin halt mit jedem Bit auf Du und Du....


    Ich, wegen Herkunft und Wohnort, mit jedem Kölsch :D

    Je mehr Käse, desto mehr Löcher.
    Je mehr Löcher, desto weniger Käse.
    Ergo: Je mehr Käse, desto weniger Käse.

    Ich habe irgendwie ein paar Verständnisprobleme.


    Sowie ich das verstehe, ist im Idle-Zustand CLK und DATA auf Highlevel. Drückt man eine Taste, fängt die Tastatur an einen Takt zu senden. Dann wird Data LOW gesetzt (Startbit) und bei der nächsten fallenden Flanke des Taktes, liest der PC das ein.. ist das soweit richtig? Das geht dann soweiter, bis wir beim Stopbit sind. Dann gehen DATA und CLK wieder HIGH.


    Was sollte passieren, wenn nun nichts mehr folgt - sollte die Taste dann immer weiter verarbeitet werden, bis man das BREAK sendet? Und wie soll HOST to DEVICE, also PC -> Tastatur funktionieren... wie soll der PC die CLK runterziehen, während die Tastatur/der uC sendet und vorallem wie sollte ich das in dem Moment erkennen?


    CLK und DATA vom Mainboard kommend haben übrigens HIGH Level, wenn nichts angeschlossen ist.

    Je mehr Käse, desto mehr Löcher.
    Je mehr Löcher, desto weniger Käse.
    Ergo: Je mehr Käse, desto weniger Käse.

    Mööönsch, /dev/null, steht doch alles da! ;)
    CLK und DATA sind partylines, open collector, da kann das kbd oder der
    Host dran zupfen. Die Pullups sind, soweit ich weiß, auf dem Mainboard,
    aber auf keyb Seite nochmals.
    Jedes Byte wird wie auf der Site beschrieben synchron übertragen, bei
    jeder fallenden CLK-Flanke wird DATA übernommen. Ok, es gibt doch ein
    Stop- und Startbit... :O


    Die Übertragung ist bidirektional, das keyboard sendet die Tastenanschläge,
    der Host kann die LEDs, den Autorepeat der Tasten, und noch ein paar Dinge
    mehr setzen. Bei den Host--->keyb commands gibt es auch ein paar Test-
    und Initialisierungskommandos, ich denke, die wirst Du auch implementieren
    müssen, sonst denkt der PC eventuell beim Booten, dass die "Tastatur" defekt
    oder nicht vorhanden ist. Ausprobieren, wie sich das in Deiner Applikation
    verhält, vielleicht lässt sich das umschiffen durch "Ignore keyb errors
    on boot" im BIOS-Setup.


    Wird eine Taste gedrückt, wird der Makecode von der Tastatur gesendet.
    Wird die Taste länger gehalten, wird der Makecode entsprechend den ein-
    gestellten Autorepeatparametern wieder gesendet. Wird die Taste losgelassen,
    wird der Breakcode 0xF0 gesendet, und dann der Scancode der losgelassenen
    Taste.
    Ich weiß allerdings nicht, ob alle Tasten autorepeat machen, kann sein,
    dass CTRL, ALT, Shift etc. nicht autorepeaten.

    "As we know, there are known knowns. There are things we know we know. We also know there are known unknowns. That is to say we know there are some things we do not know. But there are also unknown unknowns, the ones we don't know we don't know." (Donald Rumsfeld)
    "Ich weiß, dass ich nichts weiß." (Sokrates)
    "Ich weiß nicht mal, dass ich nichts weiß." (Simba2)
    "Ich weiß' alles" (Alpina-Katze)

    Zitat

    Original von tcfkao
    Mööönsch, /dev/null, steht doch alles da! ;)
    CLK und DATA sind partylines, open collector, da kann das kbd oder der
    Host dran zupfen. Die Pullups sind, soweit ich weiß, auf dem Mainboard,
    aber auf keyb Seite nochmals.


    Hier genau liegt das Problem, ich weiss nicht wie ich das angehen soll.


    Habe jetzt den PIC mit CLK und DATA direkt verbunden. Wie auch immer, ein Problem ist, dass ich die I/O Ports als Ein oder Ausgang definieren muss.. Umschalten im Betrieb ist zwar möglich, aber wie soll ich das anstellen bzw. wissen wann. Der Port ist ja Ausgang. Ich fürchte aber auch, ich muss das irgendwie einbauen.


    Habe versucht, z.b. "a" zu senden. Das ist 0x1C.
    Start Bit LOW, 0011 1000, Parity LOW, STOP HIGH, dann 0xF0 und dann versucht 0x1C nochmals bzw 0x9C (in Wikipedia stand, das oft das MSB 1 gesetzt ist im Brake). Da passiert nichts - Linux erkennt immer 0x7F, auch wenn ich nur 1 Bit sende. Irgendwas ist da faul.


    Btw, wer sendet das Zeichen eigentlich nochmal, wenn du die Taste festhälst? Der Controller in der Tastatur oder macht das der Controller auf dem Board (weil wenn es die Tastatur macht, wofür braucht man dann Brake?).



    Und /dev/zero ist was anderes als /dev/null :D

    Je mehr Käse, desto mehr Löcher.
    Je mehr Löcher, desto weniger Käse.
    Ergo: Je mehr Käse, desto weniger Käse.

    Einmal editiert, zuletzt von devzero ()

    /dev/doppelzero, jetzt enttäuschst Du mich aber!!! 8o 8o 8o :D


    Open Collector mir klassischem, bidirektionalem MCU-Pin simuliert man
    folgendermaßen: In das Datenregister des Pins schreibt man fest eine 0 ein.
    Will man am Pin ein H haben (entspricht gesperrten Open-Collector-Transistor),
    konfiguriert man den Pin über das Directionbit als Input.
    Analog, will man am Pin ein L haben (entspricht leitendem Open-Collector-Transistor),
    konfiguriert man den Pin über das Directionbit als Output;
    die eingeschriebene 0 treibt dann den Pin low.
    Solange der Pin als Input konfiguriert ist, kann man durch einen Read auf dem
    Pin mithorchen, ob jemand anders an der Leitung zieht (meistens nur durch
    Polling, da nur wenige MCUs freikonfigurierbare Interrupts an I/O-Pins erlauben).
    Aber Achtung, nach so einem Read kann eventuell das Datenregister über-
    schrieben sein, sicherheitshalber immer wieder eine 0 reinschreiben; am Besten
    vor dem Konfigurieren als Output.


    Der Autorepeat wird vom MCU auf keyb-Seite gemacht! Der Host schreibt nur
    in Richtung keyb beim Boot-Selftest, und wenn die Numlock, Shift etc. LEDs
    (durch Drücken der entsprechenden Taste) aktualisiert werden müssen.
    Der Brakecode wird erst gesendet, wenn die Taste losgelassen wird,
    der Autorepeat sendet weiterhin den Makecode... wieso ist das so schwer
    zu verstehen? ?(


    Hälst Du das Timing ein? Wie machts Du den Interbitdelay, durch ne
    Zeitschleife? Auf dem Scope verifiziert?


    Ausserdem, sagte ich schon, dass die Microchips Makrokacke sind? :D

    "As we know, there are known knowns. There are things we know we know. We also know there are known unknowns. That is to say we know there are some things we do not know. But there are also unknown unknowns, the ones we don't know we don't know." (Donald Rumsfeld)
    "Ich weiß, dass ich nichts weiß." (Sokrates)
    "Ich weiß nicht mal, dass ich nichts weiß." (Simba2)
    "Ich weiß' alles" (Alpina-Katze)

    Zitat

    Original von tcfkao
    Hälst Du das Timing ein? Wie machts Du den Interbitdelay, durch ne
    Zeitschleife? Auf dem Scope verifiziert?



    Was für ein Timing? Wenns nicht zuuu schnell ist, sollte es doch egal sein, oder nicht? Ist doch flankengesteuert.

    Je mehr Käse, desto mehr Löcher.
    Je mehr Löcher, desto weniger Käse.
    Ergo: Je mehr Käse, desto weniger Käse.

    SCHOCK! Das wird ja immer schlimmer mit Dir!
    Ist nicht egal! Du weisst doch nicht, wie die Gegenseite einliest...
    falls das gepollt wird, kannst Du nicht beliebig schnell die Bits senden.
    Und schnell sind die PICs ja.
    Bau eine Schleife ein, und halte das Timing ein, wie auf dem Link oben
    angegeben. Mit dem Scope verifizieren.

    "As we know, there are known knowns. There are things we know we know. We also know there are known unknowns. That is to say we know there are some things we do not know. But there are also unknown unknowns, the ones we don't know we don't know." (Donald Rumsfeld)
    "Ich weiß, dass ich nichts weiß." (Sokrates)
    "Ich weiß nicht mal, dass ich nichts weiß." (Simba2)
    "Ich weiß' alles" (Alpina-Katze)

    Nicht beliebig schnell.. das mag schon sein - aber wenn ich verzöger, und sagen wir alle 100ms (was langsam ist) ein Bit sende, muss das gehen.. wofür hab ich denn sonst die Flankensteuerung? Wenn es ein festes Timing gäbe, wäre das doch sinnlos. Und ehrlich gesagt, finde ich auf der Seite auch nichts genaueres übers Timing.

    Je mehr Käse, desto mehr Löcher.
    Je mehr Löcher, desto weniger Käse.
    Ergo: Je mehr Käse, desto weniger Käse.

    "The frequency of the clock signal typically ranges from 20 to 30 Khz."
    100ms sind viel zu langsam. Sorge für 25µs delay zwischen den Bits, ne
    kurze delayloop reicht dazu. Ins instruction set nachgucken, welche
    instruction wieviel Takte frisst... soweit ist weiß, sind die PICs RISC-ähnlich,
    da tut sich nicht viel in den Clk/instruction. Takt der Kiste wirst Du ja kennen,
    benötigte Anzahl Zyklen ausrechnen.

    "As we know, there are known knowns. There are things we know we know. We also know there are known unknowns. That is to say we know there are some things we do not know. But there are also unknown unknowns, the ones we don't know we don't know." (Donald Rumsfeld)
    "Ich weiß, dass ich nichts weiß." (Sokrates)
    "Ich weiß nicht mal, dass ich nichts weiß." (Simba2)
    "Ich weiß' alles" (Alpina-Katze)

    Der Takt wird ja von der Tastatur erzeugt.. ja, ist schon klar.



    Aber warum sollte ich denn nicht unter dem ganzen bleiben dürfen? Was würde theoretisch dagegen sprechen, wenn ich nur jede Stunde ein Bit senden würde? Das Bit wird doch erst gelesen, wenn der wechsel von H auf L erfolgt.

    Je mehr Käse, desto mehr Löcher.
    Je mehr Löcher, desto weniger Käse.
    Ergo: Je mehr Käse, desto weniger Käse.

    Im Prinzip richtig, aber ich glaube nicht, dass der Mainboard-Chipsatz das
    frisst... der sollte ja auch ESD-Störugen, etc., ausfiltern können.
    Probieren kannst Du es ja mal. Aber solche groben Timingviolations bergen
    immer das Risiko, dass es an einer Kiste läuft, und zwar dummerweise
    gerade das developer system. Hinterher wundert man sich, wieso nicht an
    anderen Targets... :D :D :D

    "As we know, there are known knowns. There are things we know we know. We also know there are known unknowns. That is to say we know there are some things we do not know. But there are also unknown unknowns, the ones we don't know we don't know." (Donald Rumsfeld)
    "Ich weiß, dass ich nichts weiß." (Sokrates)
    "Ich weiß nicht mal, dass ich nichts weiß." (Simba2)
    "Ich weiß' alles" (Alpina-Katze)

    Mhhh.. wenn das nicht wirklich beachtet wird, würde das auch erklären, warum Linux meckert wegen zu vieler Tasteneingaben, wenn DATEN _UND_ CLOCK LOW sind. Normal dürfte von der Logik her ja nichts passieren.

    Je mehr Käse, desto mehr Löcher.
    Je mehr Löcher, desto weniger Käse.
    Ergo: Je mehr Käse, desto weniger Käse.

    Sorge für ein anständiges Timing, alles andere ist völlig zeitverschwendende
    Spekulation.
    Du hast doch lt. Profil ein Scope, oder? :D
    Hänge das Scope auf CLK und DATA. Stell im Windows-Setup den Autorepeat
    eines herkömmlichen keyb auf Anschlag. Taste gedrückt halten, dann kannst
    Du auch ohne DSO sehen, wie, was da passiert, und ausmessen.
    Und checke mit dem Scope Deine Programmierei gegen, das spart Zeit ohne
    Ende! Glaub mir!

    "As we know, there are known knowns. There are things we know we know. We also know there are known unknowns. That is to say we know there are some things we do not know. But there are also unknown unknowns, the ones we don't know we don't know." (Donald Rumsfeld)
    "Ich weiß, dass ich nichts weiß." (Sokrates)
    "Ich weiß nicht mal, dass ich nichts weiß." (Simba2)
    "Ich weiß' alles" (Alpina-Katze)

    Wie auch immer.. ich werde das morgen mal versuchen. Das ungefähr zu berechnen ist kein Problem. Als einfache Faustregel sagt man bei den Typen OSC durch 4 und dann 1 Takt pro Befehl.


    Ich werde dich morgen (sonntag, oder montag) bestimmt nochmal nerven ;)


    Danke!

    Je mehr Käse, desto mehr Löcher.
    Je mehr Löcher, desto weniger Käse.
    Ergo: Je mehr Käse, desto weniger Käse.

    Einmal editiert, zuletzt von devzero ()

    Nix Faustregel!!! :rolleyes: :rolleyes: :rolleyes: :rolleyes:
    Das steht alles im DS, wieviel XTAL-Takte pro Befehl draufgehen... argl!


    PS Sorry, hatte das "OSC" überlesen, war gerade im Umbruch. Lies es trotzdem nach.

    "As we know, there are known knowns. There are things we know we know. We also know there are known unknowns. That is to say we know there are some things we do not know. But there are also unknown unknowns, the ones we don't know we don't know." (Donald Rumsfeld)
    "Ich weiß, dass ich nichts weiß." (Sokrates)
    "Ich weiß nicht mal, dass ich nichts weiß." (Simba2)
    "Ich weiß' alles" (Alpina-Katze)

    2 Mal editiert, zuletzt von tcfkao ()