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
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
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
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
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
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
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.
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
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.
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
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
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
Thread beobachten
Seitenaufteilung abschalten