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!)
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?
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?
