www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik PS2 Maus


Autor: Wolfram Hildebrandt (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo

Ich versuche, mit einem µC eine Ps2-Maus auszulesen.
Das lesen von der Maus funktioniert: die Maus macht dem selbstest,
sendet 0xAA für erfolfreich an den µC und dann 0x00 als Device-ID für
eine PS2-Maus.
Die Maus sendet die x,y,z und Button-Daten erst an den µC, wenn das
Commando 0xF4 gesendet wird.
Das funktioniert noch nicht.

Ich habe mich auf die Seiten konzentriert:
http://panda.cs.ndsu.nodak.edu/~achapwes/PICmicro/...
http://panda.cs.ndsu.nodak.edu/%7Eachapwes/PICmicr...
http://www.networktechinc.com/ps2-prots.html

Das Problem liegt darin, dass das Comando-byte gar nicht erst zur maus
gelangt.
Nach dem Inhibit und Request-to-send soll die maus erkennen, dass der
µC Daten senden will. die maus soll dann takte auf der clockleitung
erzeugen, um die datenbits einzeln einzutakten.
mein code hängt in einer schleife, in der er auf low an clock wartet,
also auf den takt von der maus.
dieser takt kommt jedoch nur solage, wie die datenleitung auf Null
liegt.
wenn ich so z.b 0x00 senden will, werden alle 8 schleifen durchlaufen.
wenn ich 0xF4 (11110100b) sende, so hängt der µC wieder in der
clock-low-warteschleife fest, sobald er die erste 1 erreicht hat und
somit data auf 1 liegt.

eine 1 auf der datenleitung sorgt also dafür, dass die maus nicht mehr
eintaktet.
den code für den PIC16F84 habe ich mal angehängt.


mfg   Wolfram Hildebrandt

Autor: eugen dischke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ja hallo,
also ich hab mir ne maus routine geschrieben die asynchron läuft, und
für nen avr ist ( ich benutze den externen interrupt der an der
cklockleitung hängt), ist aber in c.
prinzipiell, müsste es möglich sein mit dem usart die maus lesen zu
können.
wenn du interesse hast schick ich dir mein code
MfG
eugen d

Autor: Wolfram Hildebrandt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ja, das wäre sicher hilfreich.

Autor: Wolfram Hildebrandt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
was ich mir vorstellen könnte ist, dass die Maus nicht richtig in den
Empfangsmodus umgeschaltet wird.
Das ist ja auch die einzigste Timing-Möglichkeit.
Den Rest der Timing-Geschichte, übernimmt ja die Maus.
Sonderbar finde ich auch den Fehler. Wenn die Datenleitung auf High
geht, stellt die Maus sofort den Takt ein.
Aber wenn die Maus z.b. zwei Null-bits eintaktet, darf doch die
Datenleitung auf High gehen und das sollte dann doch auch als Datenbit
identifiziert werden.

Autor: Dingens (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
kann es sein, dass du die minimale pull-down-länge der clock line nicht
eingehalten hast?

Autor: Wolfram Hildebrandt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
movlw  .40
    movwf  temp1
inhib1b
    decfsz  temp1,f
    goto  inhib1b

der decfsz befehl dauert normalerweise 1 Zyklus, der goto 2 zyklen.
damit kommt man auf 40*3=120µs Low für clock

Autor: Dingens (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
und setzt du auch die datenleitung auf low? also folgst dem timing auf
der ps/2 seite ganz unten? weil is haltn seltsamer zufall, dass er
nullen nimmt, aber bei einer führenden 1 abbricht. du musst die
datenleitung zu beginn auf jeden fall erstmal low ziehen, egal was für
daten anschliessend noch kommen.

Autor: Wolfram Hildebrandt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
die datenleitung lege ich solange auf low, bis der erste low-impuls am
clock ankommmt.

Autor: Wolfram Hildebrandt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich habe jetzt etwas getrickst.
problem ist ja, dass der datenpin während der abrfrage nach low an
clock nicht high sein darf.
ich habe jetzt in dieser abfrage data auf low gezogen.
wenn dann der low clock kommt, wird das datenbit evtl. auf high
angepasst oder bleobt so, und steht dann nach 15µs mittels nop am
datenpin an.
ob ich jetzt so daten übertragen kann, weiss ich nicht.

Autor: Wolfram Hildebrandt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich erhalte jetzt durch dieses tricksen nach dem vermuteten senden von
0xF4 für die datenübertragung den Wert 127dezimal zwei mal.
danach sendet die maus nichts mehr.
drücke ich dann auf eien der drei mausbuttons, so erhalte ich wieder
0xAA vom selbsttest und 0x00 device id.
kehrt die maus wegen einem fehler in den reset zurück?

Autor: Wolfram Hildebrandt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich habe hier zunächst nur das parity bit falsch.
deswegen macht die maus wohl einen reset.
jetzt bekomme ich 255 und 254 gesendet.
wenn ich jetzt auf den linken button drücke bekomme ich machmal 128,
was bei dem ersten mausbyte bedeutet, dass die linke maustaste gedrückt
wurde.
die anderen buttons und auch die gabelreflexlichtschranken reagieren
aber nicht.

Autor: Wolfram Hildebrandt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Um das ganze mal zusammenzufassen:

es haben sich in der Ansteuerung der Maus für mich eingige Probleme
ergeben.

- die Maus hört auf, Takte beim schreiben eines Commandobytes zu
senden, sobald einmal High im zu sendenden Commando auftritt.
High am SDA sorgt dafür, dass SCL nicht mehr auf Low geht.
ich habe das ganze momentan derart ausgetrickst, dass ich während der
SCL-Low-Abfrage (=warten auf Takt) einfach die Datenleitung auf Low
lege. Vorher habe ich ca. 20µs anliegendes Datenbyte, das für die Maus
bestimmt ist.
Die Maus taktet dann meißt alle 8 Datenbits ein. Das Startbit ist schon
vorher gesendet geworden. Parity setzte ich manuell, passend zum
Commandobyte.

Es kümmert die Maus recht wenig, welches Commando ich sende. Ob die
Parity richtig gesetzt wurde, ändert auch nichts.

- die maus macht ja nach dem hardwarereset einen selftest. diesen
besteht die maus nur, wenn die dritte lichtschranke (scrollrad) licht
bekommt. dann hängt die Maus manchmal nach dem 8. Datenbit, machnmal
erhält sie danch 255 oder 254 von der Maus.

- wenn die dritte lichtschranke zugedeckt, oder durch die
gabelreflexscheibe verdeckt ist, dann besteht die maus den selbstest
nicht und sendet 2 mal 0x00 an den µC.
wenn die dritte lichtschranke kein licht bekommt, dann laufen tausende
takte über SCL. auch, wenn man nichts bewegt bzw. drückt.
das, was ich von der maus erhalte, stellt der PIC auf einem Lcd dar.
es wird dann meißt 0x00 dargestellt.
das beste kommt aber noch: wenn ich jetzt die maus bewege, dann zeigt
das display zumindest von Null verschiedene Zahlen, meißt solange, bis
ich nichts mehr drücke oder bewege. wohl bewegungsdatenbytes von der
maus.

da frage ich mich natürlich, wie das sein kann. besteht die maus den
selbsttest, gibt sie 0xAA, 0x00 und nach dem senden des Commandos 255
oder 254 aus. dannach zeigt sich nur 0xAA und 0x00 oder 0xAA und
128dezimal, wenn ich auf einen der taster etwas länger drücke und
weider loslasse.
ist der selbstest nicht erfolgreich, so sendet die maus anscheinend
bewegungsdaten.

der ps2-controller-ic in der maus erwartet etwas anders, als andere
ps2-mäuse. er erwartet die befehle 0xF3,0x00 0xF3,0x00 0xF3, 0x00 um in
den intellimode zu schalten.
ich weiss jetzt nicht, ob die probleme mit dem dritten mausrad zu tun
haben.
laut datenblatt kann man die beiden z-pins auf masse legen und hat dann
eine 2d-ps-maus.
dann sollte ja zumindest der selftest immer gehen.
das habe ich aber noch nicht getestet.


mit diesen fehlermeldungen könnt ihr sicher nicht viel anfangen.
es würde mir aber sehr helfen, wenn ihr einfach mal eure erfahrungen
mit dem auslesen von ps2 mäusen postet.
prinzipielle beschreibungen zu ps2 (Timing etc.) und
codebeispiele für PIC und AVR würden mir auch sehr helfen.


mfg    Wolfram Hildebrandt

Autor: Wolfram Hildebrandt (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
hier ist noch das datenblatt meines ps2-controllers.

Autor: Eugen Dischke (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
hier mein code beispiel in c, asynchron, braucht aber externen
interrupt. der code läuft auf nem 8515
bitte keine zu derbe kritik über den code (eventuelle
rechtschreibfehler) ich bin noch nicht grade sehr erfahren und mache
alles erst seit kurzem.
MfG eugen d

Autor: Wolfram Hildebrandt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
warum ist das denn eine *.exe datei?

Autor: Wolfram Hildebrandt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ach so. ist ein zip-archiv.

Autor: Nik Bamert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi!

weil es, wie es aus sieht ne mit winrar erstellte installationsdatei
ist. Dies wahrscheinlich desshalb das man das im exe integrierte zip
oder rar auch anschauen kann ohne winrar winzip oder so zu haben.

Denke ich zumindest ;-)


Mfg

Autor: Eugen Dischke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
jop so iss es mit winrar erstelltes selbsentpackendes archiv

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.