IRMP2Keyboard IR Fernbedienung nach PS2/USB Tastatur Konverter

  • Im Prinzip sieht das Handshaking gut aus. Frage ist was ab da die "write"-Funktion anstellt. Da musst du mit Debug-Meldungen aber vorsichtig sein. PS2 ist sehr zeitkritisch. Meine Vermutung ist das sowohl Data als auch Clock "Low" gezogen wurden. Das BIOS hat den Port also deaktiviert. Irgendwas ist also nicht so beantwortet worden wie das BIOS erwartet hätte. Das kann man aber auch leicht rausmessen. Im "Leerlauf" sollte sowohl "Clock" als auch "Data" auf 5V hochgezogen werden. Wenn die beide 0V haben ist der Port tot und es geht eigentlich gar nichts mehr.


    PS2 ist ein altes Protokoll. Soll heißen das es a) nicht "Hot Plug&Play" ist sondern schon vor dem Einschalten gesteckt sein muss und b) das das BIOS einen nicht unwesentlichen Anteil hat. Ganz im Gegensatz zu modernen Schnittstellen die teilweise vom BIOS gar nicht mehr tangiert werden. Wenn das BIOS beim Booten mit den Antworten vom Keyboard unzufrieden ist, dann zieht es beide Datenpins auf LOW und dann ist Feierabend.


    Entsprechend unwichtig sind aktuell die dmesg-Meldungen. Wir müssen zu allererst mal das BIOS zufriedenstellen. Der Linux-Kernel ist im Gegensatz zum BIOS recht unproblematisch und akzeptiert auch deutlich vom Standard abweichende Signale noch.


    Um das schonmal auszuschließen: Boote mal mit einem ganz normalen PS2-Keyboard und prüfe dann noch kurz das selbiges unter Linux dann auch wirklich geht. Dann im Betrieb tauschen und den Arduino dranhängen. Wenn es ein BIOS-Problem ist, dann geht der Empfänger so. Ist aber natürlich nur zum Test und kein Dauerzustand. So kann man auch feststellen ob der Port prinzipiell funktioniert oder (z.B. weil im BIOS deaktivert) gar nichts tut.


  • nicht "Hot Plug&Play"

    Dann im Betrieb tauschen

    Mit etwas Pech könnte das den PS/2 Port zerstören. Habe ich bei Kunden schon erlebt.

  • Einfach sicherstellen das der Arduino vor dem Stecken "massegleich" gemacht wird um ESD zu vermeiden.


    Die Datenpins sind sowohl am Arduino als auch am PC mit Pull-up hochgezogen. Also relativ sicher.


    Ein Restrisiko bleibt aber bei der ganzen Bastelaktion immer bestehen. USB ist sicherer, weckt aber eben nicht den PC.


    Ich kann mir in dem Fall aber schon vorstellen das auch ein PS2 Keyboard nicht geht. Sieht schon sehr nach deaktiviertem Port aus.

  • Also folgender Stand:


    - na zum Glück ist die alte Tastatur nooch nicht im Müll - PS/2 Tastatur angeschlossen, PC gestartet, funktioniert

    - Empfänger anstelle Tastatur bei laufenden PC angeschlossen, selbiges Problem/selbe Ausgabe wie oben

    - alle Debugausgaben und die LED-Ansteuerung aus dem Code entfernt (Timing?) - geht weiterhin nicht

    - Tastatur wieder im laufen Betrieb angeschlossen => geht


    Ich könnte jetzt nur noch Debugausgaben in den PS/2 Sendezweig einbauen. Ein Oszi habe ich nicht.


    Evtl. finde ich für Arduino nen Beispiel was auch PS/2 ansteuert um es damit zu vergleichen...

    My VDRs:

  • Wundert mich weil ich mit dem Linux-Kernel eigentlich nicht geschafft habe irgendwelche Probleme zu bekommen. Durch's BIOS kommen wir wohl durch. Allerdings weiß ich nicht wie stark da noch der Chipsatz die Kommunikation beeinflusst.


    Denkbar wäre ein Fehler bei der Übergabe von "Empfangsbetrieb" auf "Sendebetrieb". Was erstmal rausgefunden werden müsste, ist, wo sich eigentlich alles aufhängt. Debug-Ausgaben im PS2-Teil einzubauen ist da nicht der schlechteste Weg. Allerdings am besten nicht innerhalb des Blocks wo die Bits rausgepulst werden. Der ist ziemlich zeitkritisch. Eine serielle Ausgabe stört da auf jeden Fall.


    Aktiviere vielleicht auch mal die Debug-Ausgaben hier:

    https://github.com/M-Reimer/ir…oard/PS2Keyboard.cpp#L278


    Wäre schon denkbar das z.B. eine gewisse Kapazität auf den Datenleitungen einen High-Pegel ein kleines bisschen länger anliegen lässt und in irgendeiner dummen Konstellation dann ein Deadlock auftritt. Diese Stelle müsste dann nochmal überdacht werden. Ob ich jedes Timing so 100% beachte weiß ich nämlich auch nicht. Und mit Oszi habe ich da auch nie draufgeschaut. Wäre vermutlich mal ganz spannend aber das Problem von PS2 ist, dass auf den zwei "hochgezogenen" Leitungen eben PC und Tastatur gleichermaßen "schreiben" können. Man müsste das für ein sinnvolles Auswerten also erstmal irgendwie auskoppeln um zu wissen wann eigentlich wer hier am Senden ist...

  • Nachtrag: Könnte durchaus sein das ich im "releaseAll" unsinnigen Datenwust zum PS2 sende. Bei mir hat das nie für Probleme gesorgt, aber schon möglich das dein Mainboard da allergisch reagiert. Ich muss mir da mal bei Gelegenheit einen Testaufbau machen.

  • Nochmal Nachtrag: Ich war richtig gelegen. Es wurde bei "releaseAll" versucht einen ungültigen Code freizugeben. Und das gleich mehrfach in Folge. Mein Keyboard-Controller akzeptiert das, aber das muss ja nicht überall so sein.


    https://github.com/M-Reimer/ir…3b1e8040742a6611b295c3e00


    Bitte mit dem Stand nochmal testen. Es kann durchaus sein das der Keyboard-Controller bei jedem Versuch eine Taste "0000" freizugeben in einen Fehlerstatus gelaufen ist. Mein Code reagiert damit mit "nochmal senden" was im Prinzip auch standardkonform ist (bei Fehler in der Übertragung komplette Sequenz nochmal senden). Von ungültigen Codes steht aber in der Spezifikation nichts :P

    Soll heißen: Prinzipiell kann genau da unser Deadlock sein. Wenn nicht, dann müsstest du aber mal mit mehr Debug-Ausgaben schauen wo es bei dir genau hängt.

  • Hallo - bin erst leider jetzt wieder dazu gekommen.


    Langsam scheint die Lösung näher zu kommen.


    Teilerfolgt: Mit dem Update kann ich zumindest genau eine Taste drücken (die erste die an den IR-Receiver gesendet wird), die wird dann auch am Monitor genauso wie von einer Tastatur angezeigt.

    Nachdem ich einmal die Taste gedrückt habe, hängt er dann aber in der while-Schleife von Keyboard.release() fest. Ich kann dann auf der FB drücken was ich will - es geht nichts mehr.


    gebastelte Debug- Ausgaben aus der while-Schleife:


    Er hängt also in der while-Schleife mit dem if (write(k.bytes[0])) (innerhalb des if (k.bytes[1] != 0xFF)) fest.

    My VDRs:

  • Welche Taste (Bezeichnung oder Code) sendest du? Wenn dein Tastencode mit "0x00" beginnt, dann wird bei "Keyboard.press" nur ein Byte gesendet. Und das geht ja scheinbar ohne große Probleme. Ein "Release" sendet aber immer zwei Bytes. Damit wäre schonmal ein Timing-Problem im Bereich des Möglichen.


    Weil es generell weniger Fehler geben dürfte wenn man möglichst genau ein "handelsübliches" Keyboard nachbildet werde ich jetzt mal schauen wie ich mein "echtes" PS2-Keyboard an den Arduino bekomme um da mal ein paar Timings auszulesen.


    Hier mal ein Branch mit etwas mehr Debug-Meldungen:

    https://github.com/M-Reimer/ir…d/tree/debugging_deadlock


    Interessant ist erstmal a) wieviel erfolgreich gesendet wird (erstes Byte, garnichts, ...) und b) weshalb nicht ohne Unterbrechung gesendet wird. Wenn man das weiß kann man tiefer einsteigen.

  • Nachtrag: Einen Adapter von PS2-Buchse auf Arduino habe ich fertig und die Tastatur liegt auch bereit. Wenn du Zeit hast kannst du meinen Branch von oben gerne schonmal testen. Andernfalls bis morgen warten. Dann nehme ich das Drücken einer Taste auf einer "richtigen" Tastatur mal mit dem Arduino auf und mache das gleiche mit meinem Code. Dann wird das Timing so lange getrimmt das mein Code zumindest so nahe wie möglich am Timing einer "echten" Tastatur liegt.

  • Sehr gut - es geht wieder mehr.


    Also ich kann nun 123456, SPACE, BACKSPACE eingeben, sobald ich aber z.B. LINKS drücke, hängt er wieder.


    Hier den Ausgaben:


    Und hier meine FB-Konfig:


    farblich markierte habe ich getestet: grün geht einwandfrei, rot führt zum Einfrieren des Empfängers.


    EDIT:

    => mhhh, CODE lässt keine Farben zu? In der Vorschau ging es.


    Also alle Buchstaben und Zahlen gehen, wenn ich LINKS oder RECHTS drücke => Einfireren.

    My VDRs:

  • KEY_LEFT ist ein Zwei-Byte-Code. Das spricht alles sehr für ein Timing-Problem. Der Keyboard-Controller hat das erste Byte noch nicht verarbeitet, mein Code sendet aber schon das zweite --> Fehler.


    Auch die Tatsache das das "Release" jetzt geht spricht genau dafür. Die Debug-Messages dazwischen "bremsen stark genug ein" das dein Controller mitkommt.


    So langsam werde ich zuversichtlich das wir das in Kürze gefixt bekommen :D


    Aber alles erstmal nur Mutmaßung.


    Beim "press" hab ich keine Debug-Meldungen reingebaut. Deshalb das "Einfrieren" ohne Feedback.


    Ich baue jetzt mal meinen Testaufbau und prüfe mal wie das Timing einer "echten" Tastatur ist. Dann baue ich das so genau wie möglich nach und dann bin ich selber gespannt ob es dann bei dir hinhaut.

  • So. Jetzt. Siehe "master"-Branch. Mit einfach mal Arduino-Sketch war es dann doch nicht machbar aber mit Oszi an der Clock-Leitung ging es dann doch ganz gut zu messen.


    Ein "echtes" Keyboard "gönnt" sich ganze 2 Millisekunden zwischen den Bytes. Das ist "eigentlich" ziemlich grottig. Wie konnte man mit so gurkigen Reaktionszeiten eigentlich damals zocken. Heute wird um jede Millisekunde gegeizt :D.


    Ich gehe halt man davon aus die Tastatur-Hersteller wissen schon was sie da machen und gerade bei unserem Anwendungsfall würde ich sagen: Lieber auf Sicherheit, denn Reaktionszeit ist eigentlich im gewissen Rahmen nicht so kritisch.

  • Ein "echtes" Keyboard "gönnt" sich ganze 2 Millisekunden zwischen den Bytes. Das ist "eigentlich" ziemlich grottig. Wie konnte man mit so gurkigen Reaktionszeiten eigentlich damals zocken. Heute wird um jede Millisekunde gegeizt .

    Ich dachte immer, dass der PC bei PS/2 signalisiert, wenn er Daten annehmen kann - sich auf künstliche Pausen zu verlassen ist recht wackelig: https://de.wikipedia.org/wiki/PS/2-Schnittstelle#Protokoll

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Vielen Dank - jetzt klappt es auch mit LEFT/RIGHT etc.


    Ein Punkt wäre da noch:

    Wenn ich eine Taste auf der FB gedrückt halte, bekomme ich derzeit keine Wiederholungen. "1" drücken und halten gibt genau eine 1.

    Das macht sich insbesondere bei der Lautstärke nicht gut.

    Kann man da noch was ergänzen? IRMP gibt ja auch die "Wiederholungen" aus.


    @seahawk:

    Soweit ich es verstehe, geht es nicht um diese Pause. Die write Funktion prüft ja, ob der PC die Daten annehmen kann (1 CLK & 1 DATA) - wenn eines davon 0 ist gibt write -1 oder -2 zurück.

    Code
    if (digitalRead(_ps2clk) == LOW) {
        return -1;
      }
    
      if (digitalRead(_ps2data) == LOW) {
        return -2;
      }

    Es geht dann um das Timing (hier wohl das Stopbit) im Wiki-Bild "Diagramm PS/2 Schnittstelle: Daten vom KBD"


    EDIT: Achso - Du meinst sicher Punkt 7? (Zur Bestätigung der empfangenen Daten legt der PC Clock auf low, bis die interne Verarbeitung abgeschlossen ist.)

    My VDRs:

    4 Mal editiert, zuletzt von dad401 ()

  • Das mit dem Bestätigen vom PC ist interessant. Scheint wirklich so zu sein. Bitte den letzten Stand nochmal testen ob es so auch geht. Ich mache jetzt was die Tastatur auch zu machen scheint. Wenn der PC Clock kurz runterzieht warte ich bis sie wieder hoch geht. Nach 2ms Timeout gebe ich aber auf.


    Ich hatte das Timeout testhalber auf 0ms und bin nie ins Timeout gelaufen. Mein Controller hat also in unter 1ms bestätigt.



    Bezüglich der Wiederholung: irmpdump aus meinem Repo in den Arduino und eine FB-Taste gedrückt halten. Dabei wird im seriellen Monitor auch die Wiederholzeit ausgegeben. Die mit in die config.h eintragen (RELEASE_TIME).


    Wenn es so nicht geht, dann wird es komplizierter. Im Prinzip kann eine Tastatur nämlich auch selber wiederholen (Taste mehrfach senden). Bisher ging es aber immer ohne weil der Kernel sich drum kümmert...

  • Bezüglich der Wiederholung: irmpdump aus meinem Repo in den Arduino und eine FB-Taste gedrückt halten. Dabei wird im seriellen Monitor auch die Wiederholzeit ausgegeben. Die mit in die config.h eintragen (RELEASE_TIME).

    Das hatte ich noch vergessen. Habe nun 107 statt der Standard 120 und auch das klappt nun!


    Danke für das Update und nun schaue ich mal, ob in der Live-VDR/Kodi-Bedienung noch etwas auffällt. Leider hat mein PC wohl kein Wake-On-PS/2 Keyboard, aber damit kann ich leben.


    Ich bau jetzt wieder meine LED-Empfangssignalisierung ein - daran lag es ja nun nicht :)


    Hier was zum Ansehen:





    Kennen viele evtl. noch von früher von ihrer Hauppauge WinTV-Karte ;)

    My VDRs:

    Einmal editiert, zuletzt von dad401 () aus folgendem Grund: Bilder ergänzt...

  • Sieht gut aus! :thumbup:


    Nur interessehalber: Hast du die neueste Version verwendet (die bei der ich die Rückantwort vom BIOS abwarte)?


    Natürlich schade das dein PC nicht via Keyboard startet. Das war eigentlich mein Hauptgrund mich überhaupt mit PS2 zu befassen.

  • Das ist ein FUJITSU SIEMENS ESPRIMO E5625 - ich habe da bisher noch nichts im BIOS finden können.


    Stand war eigentlich kurz vor meinem Thread - meine IDE sagt gerade, dass das hier im Quellcode ist:

    #define BYTE_SPACING 2 //ms

    Das war ja die Änderung von vor ca. 2h.


    Wenn ab und an doppelte Tasten empfangen werden, muss ich die RELEASE_TIME etwas erhöhen?

    Manchmal wertet er derzeit 2 Tastendrücke am Anfang.

    My VDRs:

  • Hmmm...neues Problem oder nicht?


    Wenn der PC aus ist und mit dem Empfänger eingeschaltet wird, mag er nicht booten.

    2x konnte ich es reproduzieren, beim 3. und 4. mal nicht mehr.


    Der Arduino meldet beim Einschalten des PC:

    "Got unknown request from PC

    EC"


    Übrigens liegt keine Spannung am PS/2, wenn der Rechner im Standby ist.


    Komisch...auch beim 5. Mal geht es nun - mal weiter beobachten.


    Also mit Debug true kommen folgende Meldungen beim Start. Auch beim 5. WakeOnLAN mit Empfänger dran, bootet er nun.


    My VDRs:

    Einmal editiert, zuletzt von dad401 ()

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!