Ich versuche sowohl Maus, als auch Tastatur über einen PS/2 Anschluss im FPGA zu interpretiere und habe mit dem VHDL Code von Lotar Miller begonnen. Leider wurde nichts empfangen, daher habe ich die Daten mal direkt angesehen und nichts vorgefunden. Die Leitungen scheinen gar nicht bedient zu werden. Ich habe zwei Tastaturen und zwei verschiedene Mäuse probiert. Frage: Muss die Maus oder die Tastatur irgendwie initialisiert werden? In Wikipedia habe ich sowas gefunden: http://de.wikipedia.org/wiki/PS/2-Schnittstelle In der VHDL von LM ist das aber nicht ersichtlich. auch eine Recherche im Forum bringt kein Ergebnis: Beitrag "PS2 Maus Bewegung auf VGA Bildschirm darstellen" Beitrag "PS2-Tastatur Wiederholrate" Beitrag "Spartan-3A DSP nachträglich mit PS/2 Anschluss bestücken" Beitrag "PS/2 Interface in VHDL"
Norbert schrieb: > Ich versuche sowohl Maus, als auch Tastatur über einen PS/2 Anschluss im > FPGA zu interpretiere Über 1 einzigen? Also Maus+Tastatur am selben Anschluss? > Lotar Miller Jetzt aber... > Leider wurde nichts empfangen, daher habe ich die Daten mal > direkt angesehen und nichts vorgefunden. Womit angesehen? Wo nichts gefunden? > Frage: Muss die Maus oder die Tastatur irgendwie initialisiert werden? Die Tastatur nicht, die Maus schon...
Ok, ab jetzt Lothar mit "h" ... - ich habe 2x zwei PS/2 Anschlüsse vorgesehen für 4 Geräte. In der Regel werden es 2 Tastaturen sein, eine davon mit Sonderfunktion. - die Schaltung ist jeweils, wie im Anhang oben - korrekt? - "nichts gefunden" meint, es kommen keine Daten vom Gerät, die Signale sind aber geroutet, weil ich es inzwischen manuell triggere, mit Funktionsgeneratoreinspeisung - der FPGA sieht "tooglen" - ich werde jetzt eine andere Tastatur suchen, wenn die keine Config braucht, könnte sie kaputt sein - zur Maus: Wie muss die konfiguriert werden? Reicht es, einen Reset / Start zu machen, wie Wiki das beschreibt?
Norbert schrieb: > - zur Maus: Wie muss die konfiguriert werden? Keine Ahnung, habe ich noch nie gebraucht... ;-) > - die Schaltung ist jeweils, wie im Anhang oben - korrekt? Ja, die wird schon tun. Soooo sensibel ist PS/2 nun auch nicht... Hast du einfach mal ein Oszi an die D und C Leitung gehängt? Was siehst du da, wenn du eine Taste drückst?
Ich habe nun die Signale im FPGA. Aus welchen Gründen auch immer war es vorher nicht zu sampeln. Ich kann sie nun sehen. Zu Beginn ist alles high, ab dem ersten Tastendruck sieht es dann so aus: __ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _______________________________ wenn ich eine Taste drücke, sehe ich: __ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ ______________________ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Es kommen also Daten. Nur: Das Miller-modul mag sie nicht empfangen. Leider habe ich kein ChipScope, um es anschauen zu können. Ich muss jetzt wohl eine Komlettsimulation machen und schauen, woran es liegt. Fehlsynch schliesse ich eigentlich aus, die Signale sind sehr stabil und super sauber. (Ich taste sie ab und schieb sie in ein RAM). Und dann wäre noch das Mausproblem...
Mist. oben sieht man die Zwischenräume in den Takten nicht! Ich schreibe es mal hin: Ohne Tastendruck kommt: 0101010101010101111111111111111111111111111111 wobei das auch das letzte Signal sein kann, dass einfach nicht mehr überschrieben wird. Ich lösche den Speicher nicht, sondern triggere auf negative Flanke. Im Berieb sehe ich: 010101010101010111111111111010101010101010101011111111111111111111111 Ich erkenne noch nicht, ob es auch wirklich die 11 Bits sind, aber das wird ja wohl stimmen!
Norbert schrieb: > Mist. oben sieht man die Zwischenräume in den Takten nicht! Das liegt am Unterstrich. Der sorgt hier im Forum für einen unterstrichenen Text: aus
1 | _hallo_ |
wird hallo Schreib also einfach deinen Text zwischen die Tokens [pre ] und [/pre ] (ohne Leerzeichen). Dann sieht das hier: [pre ] _ ___ __ ______ ______ [/pre ] so aus:
1 | __ ___ ___ |
2 | _______ _______ |
Norbert schrieb: > Ohne Tastendruck kommt: > 010101010101010111 Sieht nach Taktleitung aus. Und was tut die Datenleitung? BTW: du könntest auch mal deinen Code als Anhang posten. (mit Dateiendung *.vhd!)
Meinen Code? Ich versuche, Deinen zum Laufen zu kriegen :-)
Norbert schrieb: > Meinen Code? > Ich versuche, Deinen zum Laufen zu kriegen :-) Norbert schrieb: > (Ich taste sie ab und schieb sie in ein RAM). Ich habe da kein RAM drin, und keine serielle Schnitte... :-o Also, irgendwas machst du anders... Welche Frequenz hat dein clk?
50 MHz. Das RAm liegt parallel zu dem Interpreter des PS/2, zeichnet den Input an den Pins auf sowie den output des PS/2 Moduls.
Ich widme mich nun wieder dem PS/2 Lesen. Ich habe nun ModelSim angeworfen und gefunden, dass es einen Timeout error gibt. RXTimeOut geht ins Negative! Ich habe das aber behoben, dazu habe ich als Initwert das RXtimeout schocn mal auf 50000 gesetzt, damit nicht sofort ein Unterlauf stattfindet. Damit lief es dann. Wozu ist eigentlich PS2_Clk_period? Das wird nirgends verwendet. Ich habe dann noch gesehen, dass die PS2CLK nicht kontinuierlich läuft. Ich sehe aber noch nicht, wo ich das ändern kann. Ich denke, es liegt daran, dass ich im VHDL die Antwort sofort nach 2 Takten bestätige, während die original Testbench 10ms verzögert. Im Grunde sollte es aber kein Problem sein, da die state machine ja reagiert. Wie die Simulation zeigt, wird der von mir erzeugte Buffer kb_input (31...0) = 4 Zeichen mit dem neuen Wert beschrieben und weitergeschoben. Real kommt aber nichts. Die einzige Schlussfolgerung: Die Tastatur sendet andere, als die TB annimmt, also das Timing stimmt nicht, wie angenommen. Ich simuliere und rechne mit 50MHz Taktfrequenz, wie in der Testbench. Eine Idee: Könnte gfs etwas mit dem Parity passieren?
update: Der buffer funktioniert sichtbar: Je tastendruck kommen 2 Werte an: Beide sind Null,
Bitte 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.