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/PS2/ps2.htm http://panda.cs.ndsu.nodak.edu/%7Eachapwes/PICmicro/mouse/mouse.html 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
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
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.
kann es sein, dass du die minimale pull-down-länge der clock line nicht eingehalten hast?
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
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.
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.
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?
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.
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
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
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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.