www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Tastatur Scancode falsch übertragen


Autor: Elzz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich will mit Hilfe eines 80c515 µc (siehe goBlack.de 4 info) und 
einfachem Assembler einen Scancode an den PC schicken.
Übertragung über den PS/2 Anschluss über einen PS/2 -> USB Konverter zum 
Host. Verbindung steht.

Mein Timer2 setzt das Clockbit jeweils für 50µs auf LOW/High. Die 
aufsteigende Taktflanke löst hier ein Interupteinsprung aus. Dort wird 
dann jeweils das entsprechende Bit angelegt.


1 Startbit.  Dieses ist immer 0
8 Datenbits mit LSB voran
1 Parity-Bit (ungerade Parität)
1 Stopbit. Diese ist immer 1

Beispiel Taste Q: MakeCode: 15h BreakCode: F0h 15h
;    <StartB>      <-----Datenbits-(LSB)->    <Paritätsb> <StopB> 

qtab: 
.dc.b  0,   1, 0, 1, 0, 1, 0, 0, 0,      0,        1 ;Make 15h
.dc.b   0,   0, 0, 0, 0, 1, 1, 1, 1,      1,         1 ;Break F0h
.dc.b   0,   1, 0, 1, 0, 1, 0, 0, 0,       0,        1 ;Break 15h

Ergebnis: ich muss die Bitreihenfolge 1-20 Mal ablaufen lassen, bis dann 
der Makecode (aber nicht der Breakcode) korrekt übertragen ist. Das 
heißt, es werden nur noch "q"'s geschrieben. Ich weiß mir dann nicht 
weiter zu helfen und muss einen PC Neustart machen.

Bei anderen Bitreihenfolgen gabs ähnliche Ergebisse: Anstatt den PC in 
den "Sleepmodus" zu schicken (-E0, 3F-  -E0, F0, 3F-) wird Pausenlos der 
Befehl für "WWW Search" (E0, 10) ausgeführt.
Es wird also das erste Frame aus 11Bits korrekt übertragen (nach 
mehrmaligem starten), die weiteren Frames haben aber keine Ähnlichkeiten 
mit den angelegten Bits.


Woran liegt das?
Synchronisationsfehler?
Gibt es einen Mindestabstand zwischen zwei Frames? Einen Mindesabstand 
zwischen Make- und Break-Code? (Einfach nach jedem Stopbit ca. 10 
weitere Takte das Databit auf High lassen hat keine Auswirkung gehabt)

Oder mach ich es mir zu einfach, wenn ich einfach den Timer und die 
Interrupts konfiguriere, das Databit setze, und dann einfach die 
Bitreihenfolge anlege?
Möglicherweise habe ich ganz grobe Denkfehler gemacht, habe kaum 
Erfahrung mit Tastatur/µC/Assembler (alles Wissen aus der Schule).

Danke für jeden Hinweiß!

mfg

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
www.marjorie.de

Autor: Elzz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Seite ist mir bekannt, hat mir auch sehr geholfen bisher.

Ich weiß aber nicht was jetzt falsch ist.

[...]"Zwischen der steigenden Flanke von Clock und einem Wechsel von 
Data müssen mindestens 5 µs liegen. Zwischen einem Wechsel von Data und 
der fallenden Flanke von Clock müssen mindestens 5 µs und maximal 25 µs 
liegen." [...]
Hat nichts an der Situation geändert, wobei mir hier auch nicht 
einleuchtet, warum das einen Unterschied macht. Der Host holt sich das 
angelegte Bit doch so oder so, sobald das Clockbit Low ist.

Da ich das Programm möglichst schlicht halten will und es auch nicht für 
öffentliche Zwecke her halten muss, muss die Zuverlässigkeit nicht bei 
100% liegen. Deshalb habe ich über die Tatsache, dass der Host das 
Clocksignal auch mal selbst auf Low zieht, einfach drüberweg gesehen.

Aber das Ergebnis von mir weist ja Regelmäsigkeiten auf.


ratlose Grüße
Elzz

Autor: Bobby (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich bin mir jetzt nicht sicher, denn es
ist schon etwas her, seit ich das letztemal
damit zu tun hatte.

Du meinst doch Tastatur-Scancodes, oder?
In diesem Zusammenhang habe ich noch nie
etwas von Parität gehört: setz das Bit mal
konstant auf 1.

Und wenn das nicht hilft, würde ich alle
Mikrosekunden-Werte mit 10 oder 100 multiplizieren.

Ich hoffe es ist was brauchbares für Dich dabei.

Bobby

Autor: Otto (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Elzz, hallo bobby

doch - die Parität wird gebildet und sollte auch vom Host ausgewertet 
werden.

ich gebe "Bobby" im 2. Punkt recht - die Zeiten scheinen mir viel zu 
gering zu sein

Gruss Otto

Autor: Otto (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gerade habe ich noch einmal nachgesehen und möchte mein dummes Geschwätz 
von eben korrigieren:

Hier ein Ausschnitt aus funktionierendem Code (AVR)

KB_WAIT:   rcall  delay10    ; nun 5-25µs Pause
         cbi  PORTA,KBCLK  ; clock - line = low -_ 
; max.  50 us      rcall  DELAY30    ; typ.  30 us    "CLOCK LOW TIME" 
rcall  DELAY15    ; Summe 45

  sbi  PORTA,KBCLK  ; clock - line   = high _-      rcall  delay10    ; 
typisch  14 us = Daten gültig
  sbi    PORTA,KBDAT  ; data  - line   = 1 _-

Die "Clock low" Zeit darf maximal 50µs betragen

Gruss Otto

Autor: Bobby (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja Otto. ich denk gerade mal etwa 15-20Jahre zurück.
Auch damals gab es schon PS2-Tastaturen. Glaubst Du
im Ernst, das wären damals maximalwerte gewesen?
Ich denke eher Minimalwerte.....

Kann mich natürlich täuschen, aber 8042 war glaub ich
der Tastaturprozessor im AT.

Autor: Otto (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Bobby,

ich kenne die Zeiten - mein erster Controller mit dem ich gearbeitet 
habe, war der 8048 - trotzdem waren damals auch 50µs (0,00005 s) kein 
Problem.

Zugegeben habe ich auch etwas länger mit dem PS/2-Protokoll 
experimentiert bis es lief.....

Gruss Otto

Autor: Elzz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi, vielen dank schonmal für eure Antworten. Hab mal meine grenzwertigen 
50µs High/Low auf 40µs gesenkt und zusätzlich, bevor der Timer das 
regelt den Clockport manuel für >50µs auf High gezogen (ist nötig laut 
www.marjorie.de).

Wenn dann mittels Timer alle 40µs in den Interrupt gesprungen werden, 
warte ich hier 12µs, setze dann das entsprechende Bit am Dataport 
(dauert 8µs = 20µs), nach weiteren 20µs fällt die Taktflanke wieder und 
der Host kann das entsprechende Bit holen.


Leider gibts immer noch die gleiche Reaktion (evtl. mit dem Unterschied, 
dass es nicht mehr so viele "Anlauf" versuche braucht).

Für die Taste "q" muss ich 33 Bits anlegen (3 Frames). Nach 1-10x 
Starten des Programms werden die ersten 11 Bits richtig erkannt (Befehl 
für "q" wird rausgeschickt), die nächsten 22 Bits, also der Breakcode, 
nicht richtig.

Autor: Otto (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo elzz,

hast Du die Zeiten mal nachgemessen oder verlässt Du Dich auf Deine 
"Delays" ?

Gruss Otto

Autor: Elzz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Auf die Zeiten vertrau ich eigentlich schon. Das ganze ist ja ein 
Schulprojekt, der Lehrer hat mir versichert, dass die Zeiten genau sind.

Womöglich weiß ich aber jetzt woran es liegt:

http://www.marjorie.de/ps2/qscope.jpg

Mein Takt läuft bisher die ganze Zeit. Also wenn keine Angelegen wurden, 
gabs immer wieder den Zustand Data = 1, Clock= 0 -> bedeutet PC ist 
busy, deshalb hats auch oft Startschwierigkeiten gegeben (10mal starten 
bis zur ersten reaktion).

Da hatte ich wohl was falsch verstanden, denn der Takt muss wohl vor 
jedem Frame (11Bits) einmal >50µs High sein. Das heißt ich setze nun das 
Taktsignal auf High (erste mal >50µs), lege da schon das Startbit (0) 
an, sodass bei der ersten Lowflanke (max 25µs später) schon das Startbit 
anliegt.


Irgendwo hab ich jetzt vermutlich noch ein Programmfehler, das erste 
Frame (Makecode) wird jetzt immer aufs erste Mal erkannt, die anderen 
beiden nicht.
Ich will für jede Taste (Make + Breakcode) eine Tabelle anlegen, dich 
ich dann in verschiedenen Interruptroutinen in den DPTR lade. Hab noch 
wenig wenig Programmier/Assembler Erfahrung, dauert also n bisschen bis 
es fertig ist ;)

Nur so, als Zwischenbericht :)

lg

Autor: Elzz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kennt einer von euch die minimale Pause, die zwischen 2 Frames sein 
muss, bevor sie gesendet werden dürfen?

Also einmal die Pause zwischen dem Makecode und dem ersten Frame (11bit) 
vom Breakcode, und die Pause zwischen den zwei Frames des Breakcodes (F0 
+ E0 .. z.B.)


Elzz

Autor: Elzz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hmm hier ich nochmal^^ das Projekt hat grad wegem Abistress pause, 
danach soll es aber schnell Fertiggestellt werden.

Ich hatte bisher ja immer einen PS/2 - USB Konverter dazwischen, den hab 
ich mal rausgenommen und bin direkt an den PS/2 anschluss gegangen.
Resultat:

Ich drücke die Test-Taste für Q (am Programm nichts geändert): ein 
einzelnes Q erscheint, der Rechner piepst einmal und fertig.

Eigentlich ganz schön, es ist fast das resultat das ich haben will, aber 
unschön ist, dass wenn ich nur den Makecode sende (sodass er Theoretisch 
ewig viele Q's schreiben sollte), hab ich das gleiche Ergebnis: Es 
erscheint 1 Q, dann Piepst der Rechner und fertig.

Nach wie vor kommt also nur das erste Datenframe an (Make-Code), danach 
passiert irgendwas komisches (Synchronisationsfehler ist das einzige was 
mir einfällt, aber den kann ich nicht finden).

Gibts jemand, der mit dem Piepsen vom PC mehr anfangen kann als ich?

Interessant wär noch ein Programm für den PC der meine Datenframes 
empfängt/ abspeichert. Kennt ihr sowas? Hab auf die schnelle nichts 
gefunden, dass meinen Erwartungen entspricht.

Gruß, Elzz

Autor: Elzz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
push :(

mfg

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.