An die Bastler: PS2 Controller Protokoll

Perfect007 · Beitrag von **Perfect007** » Mo 3. Apr 2006, 12:50

@themartin:

Hab da mal eine ganz dumme Frage, denn deine BEschreibung bezüglich High und Low-Active will mir noch nicht ganz in den Kopf gehen. Wir haben hier das komplette Protokoll mal gemessen gehabt und da wurde definitiv ein Byte von 0x01 gesendet. Ich kapiere das mit deiner Invertierung nicht, warum sollte man ein 0xFE senden? Siehe auch folgendes Bild - ist das Datagramm vom ersten Byte ...

http://www.dfsclan.de/upload/Bilder/tommy/fh/byte1.bmp

Wichtig: LSB wird zuerst gesendet!

themartin · Beitrag von **themartin** » Mo 3. Apr 2006, 13:30

Ich versteh schon was du meinst.

Guck dir mal die CMD Leitung nach den 8 Bits an. Dort ist sie dauerhaft auf High (inaktiv). Das bedeutet, das die Leitung Low-Aktiv ist. Somit wäre der Wert eigentlich 0xFE weil 1 = Low und 0 = High.

Bei der SPI Schnittstelle bedeutet aber ein High eine 1 und ein Low eine 0, weil sie High Aktiv ist. Also würdest du im SPI Datenregister eine 0x01 lesen.

Auf den Seiten über das PSX Protokoll steht dann auch immer: "All Buttons are Low-Active". Es würde eigentlich reichen, am Anfang zu sagen: "Alle Leitungen sind Low Aktiv". Dann müsste man allerdings die Werte ändern.

Ist eigentlich nur ne Schönheitssache, an der man sich nicht stören sollte, habs nur mal erwähnt.

mfg, Martin

Perfect007 · Beitrag von **Perfect007** » Mo 3. Apr 2006, 14:23

Bin grad am Überlegen, ich weiß nämlich noch rein gar nichts über eine SPI-Schnittstelle und muss mich im Datenblatt zu meinem MSP dazu erst noch einlesen. Aber wenn SPI ständig Low ist (also High-Active) - sprich die Leitungen müssten alle Low sein, wenn keine Daten gesendet werden (dann ist ja auch kein Takt vorhanden, weil der ja nur mit Daten mitgesendet wird) - dann müsste ich doch meine gesamten Sendeleitungen und CLK-Leitung nach der SPI-Schnittstelle für die Playstation nochmals mit einem Inverter invertieren, oder liege ich da nun falsch?

themartin · Beitrag von **themartin** » Mo 3. Apr 2006, 14:36

Die Clock Leitung kannst du garnicht verändern, da sie vom Master vorgegeben wird (Playstation oder Converter)

Die Sendeleitung musst du auch nicht invertieren, wenn du die Werte benutzt wie z.B. 0x5A für "ready" usw. Diese Werte sind schon invertiert.

Bei den Buttons musst du aufpassen, denn wenn ein Button gedrückt ist, musst du ein Low am entprechenden Bit senden und kein High.

kein Button gedrückt sieht dann so aus:

0xFF oder 0b11111111

Wenn der Left Button gedrückt wird dann siehts so aus:

0x7F oder 0b01111111

Perfect007 · Beitrag von **Perfect007** » Mo 3. Apr 2006, 14:41

Oki, das ist ja vollkommen klar, mir geht es eher um die Zeiten, wo KEINE Kommunikation stattfindet. Da liegt ja eigentlich ständig ein High-Signal an, da die ganze Kommunikation Low-Activ ist.

SPI arbeitet anscheinend aber anders herum und somit müsste zwischen den Bytes die Leitungen ja Low sein - entspräche aber nicht dem von mir gemessenen Signalen!

Und wenn ich dann oben das CMD anschaue, dann kommt dies wirklich auch als 0x01 rein - einzig allein bei den Buttons muss ich ja noch darauf achten, das ich da alles bis auf die gedrücken High halte!

themartin · Beitrag von **themartin** » Mo 3. Apr 2006, 16:06

Hi!

Die richtigen PS Gamepads nutzen ja auch nicht ein SPI Interface von einem Microcontroller sondern ein eigenes Protokoll, welches auch 8Bit seriell ist. Und dieses ist Low Activ.

Man kann aber das eingebaute SPI Interface von einem MC so umbiegen, dass es so wie das PSX Protokoll arbeitet. Wenn ich bei mir jetzt messen würde sieht es so aus:

Die obere Linie ist Clock, die untere ist Data

Hier ist ein Bild vom 2ten Byte, dieses 0x5A
Bild

davor und danach ist Low Pegel von SPI

Hier ist ein Bild vom 3ten Byte mit einem Button gedrückt
Bild

davor ist ein Low Pegel, danach bleibt der High Pegel.

Man sieht also, die SPI behält ihren letzen Pegel. Aber da kein Clock Signal anliegt, musst du dir keine Gedanken über das Signal im Ruhezustand machen.

mfg, Martin

Perfect007 · Beitrag von **Perfect007** » Mo 3. Apr 2006, 16:24

Hehe danke - das hat nun all meine Bedenken vorerst ausgeräumt

In dem Fall werde ich mich auch auf die SPI-Schnittstelle einschießen, muss halt ATT über einen Interrupt-fähigen Eingang noch auswerten und über nen zweiten Extrapin das ACK senden. Habe bei meiner SPI wohl nur CLK, SOMI und SIMO.

Da ich aber noch keine Testplatine aufgebaut habe, ist alles nur Theorie

, aber deine Ausführungen sind äußerst hilfreich.

Noch eine kleine Anmerkung - Ich glaube, das PS2 Pad reagiert ähnlich, so dass es einen letzten Wert beibehät. Kann mich entsinnen, einen solchen Effekt ebenfalls am Logic-Analyser gesehen zu haben!

themartin · Beitrag von **themartin** » Mo 3. Apr 2006, 16:34

Hat deine SPI Schnittstelle denn keinen SS Anschluss, bei mir gibts sowas, heißt Slave Select. Da kannst du den ATT Anschluss anschließen.

Wenn nicht, kannst du denn Att Anschluss auch weglassen, sobald die SPI ein Byte erkannt hat, kommt ein Interrupt.

_bla_ · Beitrag von **_bla_** » Mo 3. Apr 2006, 18:23

themartin hat geschrieben:Wenn nicht, kannst du denn Att Anschluss auch weglassen, sobald die SPI ein Byte erkannt hat, kommt ein Interrupt.

Das geht nicht. SPI ist keine Punkt zu Punkt Verbindung sondern ein Bus. (Bei dem USB zu PSX Convertern wird es wohl funktionieren, da dort nur ein Slave am Bus hängt) (Deshalb müssen die Ausgänge ja auch auf Z oder Weak High wenn ATT high ist) Über die SS bzw. hier ATT genannte Leitung wird ausgewählt mit welchem Slave gesprochen wird. So kommt der Master halt mit 3 Pins (MISO, MOSI, CLK) und je einem Pin pro Slave aus. Ohne die SS weißt du nicht an welchen Slave die Daten gerichtet sind. Deshalb ignoriert die SPI Hardware des Atmels ja auch alle Bytes die gesendet werden, wenn SS nicht low ist. (Die sind halt für einen anderen Slave gedacht)

Perfect007 · Beitrag von **Perfect007** » Mo 3. Apr 2006, 19:43

Wie gesagt, hab mich noch nicht direkt damit auseinander gesetzt, habe im moment neben dem Projekt (weswegen ich morgen in der Früh aber ein Termin beim Dozenten habe

) auch andere Dinge um die Ohren

Aber so weit ich das nun von heute Mittag in Erinnerung habe, gibt es eine 4-Draht-Technik mit einer zusätzlichen Leitung STE oder so ähnlich - könnte dem ChipEnable gleichkommen.

themartin · Beitrag von **themartin** » Mo 3. Apr 2006, 21:23

Das geht nicht. SPI ist keine Punkt zu Punkt Verbindung sondern ein Bus

Stimmt, daran hatte ich gar nicht gedacht. Aber du hast recht, jetzt versteh ich auch besser, warum es dieses SS überhaupt gibt.

_bla_ · Beitrag von **_bla_** » Mo 3. Apr 2006, 23:33

themartin hat geschrieben:Stimmt, daran hatte ich gar nicht gedacht. Aber du hast recht, jetzt versteh ich auch besser, warum es dieses SS überhaupt gibt.

Auch ohne mehrere Slaves ist es übrigens ganz nützlich, es geht immer nur nach einem ganzen Byte High, die Übertragung kann so ziemlich schnell und einfach wieder synchronisiert werden, wenn irgendwo mal ein Taktimpuls untergegangen ist. Das es sehr einfach in Hardware realisierbar ist, ist eh der riesige Vorteil von SPI. Mit (meistens) deutlich höheren Taktfrequenzen wird es deshalb auch häufig für Sachen wie SD und MMC Speicherkarten (Bei SD Karten sind iirc inzwischen über 50 Mhz Takt erlaubt), Audio DACs, Ethernet Chips, EEPROMS, etc. eingesetzt. (/me fragt sich gerade, warum es eigentlich noch keinen FT245 ähnlichen Chip mit SPI gibt.)

Perfect007 · Beitrag von **Perfect007** » Mo 24. Apr 2006, 18:17

Weit sind wir hier noch nicht, aber die Testplatine mit nen paar Taster fehlt eh auch noch. Während der Kollege die Platine anfertigt, kümmer ich mich um den Code für den µC.

Habe mich heute mal mit der Speicherung und Umsetzug auf das Protokoll der einzelnen Tasten verkopft. Das schwierige daran ist, dass die Tasten für den Aufbau leicht, für die Umsetzung auf das Protokoll aber umständlich auf die Ports gelegt werden. Ist aber kein Umstand, denn hinterher sollen die Tasten eh nach Lust und Laune umkonfigurierbar sein, sprich mittels eines Menüs sollen diese umgemapped werden, so dass X z. B. D-Pad Down ist ...

Hier mein bisheriger Quellcode, wobei das mit den ganzen Tabellen am Schluss sicher wieder anders aussieht (habe heute alte Ideen verworfen und das alles eingebaut). Mehr wie die Arrays für die Datenbytes und dere Definitionen, sowie ein Takt-Test findet ihr im Quellcode aber noch nicht.

http://www.game-quiz.de/temp/main.txt

Perfect007 · Beitrag von **Perfect007** » Fr 12. Mai 2006, 18:07

So, weit sind wir zwar noch nicht (Software ist nicht fertig und auch Hardware), aber so sieht zumindest vorerst das Testboard aus. Einfach ein paar Taster, die entprellt werden, der µC und Kommunikationspfad. Die Tasterplatine ist noch nicht gelötet, wurde aber schon mal oben drauf geschraubt

_bla_ · Beitrag von **_bla_** » Fr 12. Mai 2006, 18:33

Was habt ihr da für ICs verbaut? Nicht genug Eingänge am uC und ihr habt Latches oder Schieberegister verbaut um mehr Tasten abfragen zu können? Oder habt ihr die Entprellung in Hardware gemacht? Bspw. RC-Tiefpass+7414 (8x Schmitt-Trigger Inverter)?