 Okay, ich glaube, dann fangen wir an. Herzlich willkommen zu meinem Vortrag. Mein Name ist Michael Stabelberg und das Thema dieses Vortrags lautet Kinex. Das ist der Überbegriffstitel für die ganzen Modifikationen an meiner Kinesistastatur, die ich in den letzten Monaten vorgenommen habe. Zuerst möchte ich euch erzählen, was in meinem Vortrag vorkommt. Der ist in drei große Teile aufgeteilt. Zum einen habe ich einen eigenen Keyboard-Controller entwickelt. Dann habe ich dazu passend einen eigenen USB-Hub entwickelt. Und zu guter Letzt habe ich dann die Arbeit, die ich mir gemacht habe, genutzt, um damit Input-Latency-Messungen durchzuführen. Ich werde euch in jedem dieser Teile noch genauer motivieren, was da genau passiert und wieso und weshalb und was ich daraus gelernt habe. Am Ende des Vortrags werden wir noch ein paar Minuten Zeit haben für Fragen und Antworten. Wenn ihr allerdings Fragen habt, bei denen ihr denkt, dass ihr das unmittelbare Verständnis des Vortrags behindert, wenn die nicht beantwortet werden, dann meldet euch bitte und dann können wir das auch zwischendurch machen. Gut, fangen wir an mit dem eigenen Keyboard-Controller. Was ist die Motivation dafür? Ich benutze die Kinesis Advantage-Tastatur seit 2008, das heißt mittlerweile zehn Jahre und es ist eine Super-Tastatur, die beste Tastatur, die ich je hatte. Sie kostet auch entsprechend viel, aber wenn man das mal investiert hat, dann ist man damit üblicherweise zufrieden. Zwei Sachen haben mich allerdings daran gestört. Das eine ist, dass die Tastatur mit den braunen Cherry-MX-Tasten-Modulen kommt, standardmäßig, und das andere ist der Stack-Modifier-Bug. Ich erkläre euch jetzt noch genauer, was das bedeutet. Wenn man auf der Cherry-Seite schaut, das ist die Firma, die die allermeisten Tastemodule herstellt, dann sieht man diese Auflistung hier. Die haben verschiedene farbige Tastemodule, damit man auch erkennen kann, welchen man da gerade vor sich hat. Und die Kinesistastatur kommt eben mit dem Soft-Tactile, also die braune Variante. Ich persönlich habe lieber die blaue Variante, ich habe die schon viele Jahre vorher benutzt und ich wollte die gerne weiter benutzen. Ich habe mich dann erkundigt, ich habe bei Kinesis angefragt, Kinesis ist übrigens eine Firma, die sehr freundlich ist gegenüber Baslern, und habe die gefragt, hey, gibt es irgendeine Möglichkeit, dass ihr mir eine Kinesistastatur verkaufen könntet, die blaue Cherry-MX-Tastemodule hat? Dann meinten sie, ja, nee, können wir leider nicht machen, aber hey, wie wär's denn, wenn wir die einfach die PCBs schicken? Und dann habe ich gesagt, ja, gerne. Und das kam dann ein bisschen später in der Post. Und was man hier sieht auf der linken Seite, die Kinesistastatur ist eben so gewölbt, also ich habe hier sie auch dabei, das ist eben einfach dafür, dass man so quasi mit der Hand so reingreifen kann, und das ist dann ergonomisch damit zu tippen. Und wie die das machen, eigentlich mechanisch ist interessant, dieses PCB ist nämlich einfach ein bisschen dünner, als die normalen Leiterplatten. Und dadurch kann man das dann so biegen, das seht ihr auf dem rechten Bild. Das ist relativ einfach, oder? Man kauft sich seine Lieblingstastemodule, bestellt sich die PCBs bei Kinesis, löte das alles zusammen, und schon hat man seine Lieblingstastemodule in der Tastatur. Eine Sache gibt's noch zu beachten. Was ihr hier abgebildet seht, ist eine sogenannte Tastaturmatrix. Bei einer Tastatur ist es nämlich nicht so, dass jede einzelne Taste mit einem Mikrocontroller verkabelt ist, sondern um Kontakte zu sparen, benutzt man eben so eine Matrix-Verkabelung. Das heißt, man teilt die Tasten in Reihen und Spalten auf, und dann kann man die so nacheinander abscannen. Und was man jetzt hier sieht, ist, dass drei der Schalter geschlossen sind, der vierte aber nicht, aber was hier passiert ist, aufgrund deswegen, wie die Matrix verkabelt ist, wird der vierte Schalter auch als geschlossen eingelesen. Und diesen Effekt, den nennt man Ghosting. Das heißt, man drückt drei Tasten gleichzeitig, und eine vierte wird erzeugt, ohne dass man es eigentlich machen wollte. Das ist natürlich ein Effekt, der nicht gewünscht ist. Man möchte natürlich nur das Tasten erkannt werden, die man auch tatsächlich gedrückt hat. Und da gibt's mehrere Methoden, um dieses Problem jetzt zu lösen. Die Methode, für die sich Kinesis entschieden hat, ist, Dioden zu verwenden, damit der Strom eben nicht auf diese ungünstige Art und Weise durch die Schaltung fließen kann. Jetzt ist es so, dass Cherry also die blauen Tastemodule auch hat mit der Variante, in der eine Diode eingebaut ist. Allerdings ist es so, dass diese spezifische Variante schwierig zu bekommen ist. Wenn man also in den großen Elektronik-Shops nachschaut, also bei Digi-Key oder Mauser oder wo auch immer, dann findet man üblicherweise die Cherry-Tastemodule in allen möglichen Varianten, aber eben nicht mit Dioden. Wie kommt man jetzt an die Variante mit Dioden? Es gibt drei Varianten, die ich alle ausprobiert habe, die also alle funktionieren. Die erste ist, man fragt mal freundlich bei Cherry nach. Könnte man von den Samples haben. Wenn man gerade an so einem eigenen Projekt arbeitet, dann wollen die einen vielleicht unterstützen. Das ist auch super komfortabel, wenn man da jemanden tatsächlich erreicht, dann schicken die einem per Express das zu und am nächsten Tag hat man sie schon, kann ich empfehlen. Kann man aber moralisch gesehen nicht zu häufig machen. Dann die zweite Variante ist im Desk Authority Forum, in dem sich ganz viele Keyboard-Nurz treffen, gibt es Gruppenbestellungen. Mittlerweile ist es so weit automatisiert, dass es dort einen Nutzer gibt, das ist ein Bot und dem schickt man eine PM und sagt, ich möchte gerne folgende Tastemodule bestellen und dann schickt er eine Rechnung, man bezahlt es und irgendwann kriegt man die Module. Allerdings dauert es recht lang, also ich habe irgendwie zwei Monate auf meine Tasten warten müssen. Das könnte aber auch daran legen, dass ich sie in die Schweiz habe bestellt und vielleicht hat das die ganze Sache verkompliziert. Die dritte und langwierigste Methode ist, man kauft sich einfach nicht nur die Tastemodule, sondern auch ein Haufen Dioden, macht alle Tasten auf und steckt die Dioden rein. Funktioniert genauso gut. Man sollte darauf achten, in welche Richtung man sie reinsteckt. Ja bitte. Die Frage war hier, müssen die Dioden unbedingt in die Taste rein oder kann man das oft als Platine machen? Könnte man theoretisch auch auf der Platine machen. Ich sehe eigentlich im Moment keinen Grund, wieso man es in die Taste rein ausser, dass das halt so ist, wie es vorgesehen war. Aber ja, gute Anmerkung, vielleicht ist das dann Methode Nummer 4. Habe ich allerdings noch nicht ausprobiert, aber ich habe noch nicht ausprobiert. Gut, das zu den Tasten. Jetzt kommen wir zu dem zweiten Problem, dem Stack-Modifier-Bug. Was passiert also? Angenommen, man drückt Shift, man drückt A, man lässt A los, man lässt Shift los, aber die Tastatur verwirft den Shift-Los-Lassen-Event. Das heißt, Shift bleibt gedrückt und man schreibt weiterhin groß, obwohl man es nicht wollte. Das betrifft nicht nur Shift, sondern auch alle anderen Modifier. Das heißt zum Beispiel im Neolayout, den Capslock-Modifier, der da sehr wichtig ist und die Leute online an. Im schlimmsten Fall zerstört man sich seine komplette Inbox, weil man die falschen Tastenkombinationen verwendet. Das ist also ein nerviges Problem, was ich unbedingt auch beheben wollte. Das ist nämlich mehrfach in der Woche passiert, also durchaus über der Schmerzgrenze. Ich habe mich dann ein bisschen umgeschaut und laut den verschiedenen Internetfordern weiß Kinesis auch von diesem Problem. Da habe ich mir natürlich gedacht, okay, aber wenn die davon wissen, wieso korrigieren die das nicht einfach. In den Fordern hieß es auch, ich habe mich schon angeschrieben und dann meinten die so, ja, okay. Könntest du nicht mal alle diese Debugprozeduren durchmachen? Die Tastatur hat im Originalzustand einen eigenen Speicher drin, den kann man resetten, wieder auf Factory reset und defaults und so weiter. Und dann gibt es ja so ein paar Prozeduren. Habe ich alles gemacht, habe den geschrieben, ja, ist immer noch das Problem da, könnt ihr mir bitte einfach das Firmware-Update schicken. Das kann doch nicht so schwer sein, oder? Und dann meinten die, ja, okay, ist in Ordnung. Und eine Woche später bekam ich per Post einen neuen Mikrocontroller. Der Mikrocontroller ist nämlich auf dem Originalboard gesockelt. Da kann man ihn einfach runternehmen und die neue Version aufspielen sozusagen. Die gute Nachricht ist, dass der Shift-Modifier seltener davon betroffen war, aber Caps Lock immer noch genauso häufig. Das heißt, so richtig haben sie das Problem irgendwie nicht lösen können. Und dann dachte ich auch, okay, vielleicht kann ich da jetzt nicht darauf warten, dass die sich das tatsächlich nochmal anschauen und fixen und mir dann nochmal einen neuen Mikrocontroller schicken. So, vielleicht muss ich selber aktiv werden. Was ich dann gefunden habe, ist eine Serie von Blockposts von einem Blockmarms Humble Hacker. Ihr kennt vielleicht das Humble Hacker Keyboard, das ist dieselbe Person. Und angefangen hat dieses ganze Humble Hacker Keyboard mit dem Reverse-Engineering von einer älteren Version von der Kinesis-Tastatur. Und die Posts kann ich sehr empfehlen, denn die sind wirklich sehr detailliert. Man sieht dort wirklich auch genaue Aufzeichnungen, also wie die Platinen belegt sind und so. Da hat es da wirklich sehr viel Mühe gegeben. Und mit dieser Serie von Blockposts kommt eben nicht nur die Beschreibung davon, wie die Kinesis funktioniert, sondern eben auch ein eigener Keyboard Controller mit eigener Firmware, der so, wie ich damals dachte, eben nicht von dem Stack Modifier Problem betroffen war. Und dann habe ich kurzerhand gesagt, ich habe das Projekt einfach mal versucht nachzubauen. Ich musste es nachbauen und konnte es nicht einfach eins zu eins replizieren, weil das eben eine ältere Version von der Kinesis war. Ich hatte eine neue Revision, also ein bisschen was hat sich jeweils geändert. Aber im Großen und Ganzen habe ich einfach das vom Humble Hacker nachgebaut. Das sieht dann so aus. Das sieht dann so aus. Von dem Eagle-Programm, das Layout, was ich hier gemacht habe, zusammen mit einem Freund von mir. Im Wesentlichen in der Mitte der Platine seht ihr eine Stiftleiste, also einen Sockel sozusagen, für den Tinsi Microcontroller. Zeige ich gleich noch genau, was es damit auf sich hat. Aber ansonsten ist aus und drum nicht mehr so viel Zeug. An allen vier Ecken seht ihr jeweils einen Connector, der sich mit den Modulen von der Tastatur verbindet. Also da sind dann die ganzen Tasten angeschlossen. Das war es dann auch schon. Also die Platine ist relativ schnell gemacht gewesen und relativ schnell gefertigt. Und dann steckt man das da so drauf und programmiert den Microcontroller mit der Firmware und dann funktioniert es auch. Ich bin eben sehr vorsichtig vorgegangen in diesem Projekt, weil ich wirklich darauf bedacht war, dass ich eine funktionierende Tastatur hinterher habe. Das war zu dem Zeitpunkt meiner einzige Kinesistastatur. Ich habe also einfach den Tinsi Plus Plus genommen, wie der Humble Hacker auch, mit der Humble Hacker Firmware bespielt und für vier Jahre lang hat das Ganze gut funktioniert. Und dann habe ich mich gefragt, warum habe ich jetzt überhaupt was daran geändert, wenn es ja funktioniert hat. Und der Grund dafür ist Input Lay-in-See. Leute haben angefangen, über Input Lay-in-See zu schreiben. Und da gibt es wirklich sehr gute Artikel darüber. Unter anderem einen, den ich sehr empfehlen kann, von Pavel Fartin. Der heißt Typing with Pleasure. Der selbe Autor hat auch einen Post namens Scrolling with Pleasure. Und die beiden Posts sind wirklich die besten Artikel, die ich seit langer Zeit gelesen habe. Also kann ich euch wirklich ans Herz lesen, und dann habe ich mich natürlich nach der Lektüre dieses Artikel gefragt, was ist denn eigentlich die Input Lay-in-See von meiner Tastatur, auf der ich Tag ein Tag aus tippe. Und das Problem, wenn man sich so einen eigenen Keyboard Controller baut, ist, niemand kann einem das beantworten. Man muss es selber rausfinden. Und die nachfolgenden Fragen sind dann natürlich selbst, wenn ich es dann wüsste, was kann ich daran ändern, kann ich irgendwas daran ändern, und wie weit kann ich gehen mit meinen Änderungen. Das war also quasi so ein bisschen der Einstieg. Schauen wir uns mal an, schematisch, ganz grob nur, wo kommt denn eigentlich Input Lay-in-See her? Was macht denn so einen Keyboard Controller konzeptionell? Was ich hier abgebildet habe, ist, was könnte passieren im schlimmsten Fall, wenn man eine Taste drückt? Der erste Schritt, den so einen Keyboard Controller macht, ist der sogenannte Matrix Scan. Ich hatte vorhin schon angedeutet, die Tastatur ist in so einer Art Matrix verkabelt, und da muss eben jede Reihe oder jede Zeile, je nachdem, wie rum man diese Matrix hält, einzeln beschaltet werden und dann einzeln gemessen werden. Das braucht natürlich eine gewisse Zeit, und das muss natürlich für alle Reihen gemacht werden. Und dann wird es auch noch üblicherweise so schnell gemacht. Es könnte also sein, dass in Keyboard Controller alle 10 Millisekunden nur diese Matrix Scannt. Das heißt, wenn ihr die Taste drückt und das genau nach einem Matrix Scannt passiert, dann müsst ihr bis zu 10 Millisekunden warten, bis die Tastatur überhaupt erkennt, dass da sich was geändert hat. Was danach passiert und was genau nochmal so lange dauern kann, ist das sogenannte Deep Bouncing. Das ist ein Verfahren, mit dem man den mechanischen Effekt, dass wenn man ein Taster betätigt, der erstmal so ein bisschen hin und her wobbelt, und ich zeige das nachher noch genauer, damit man einen sauberen Übergang von gedrückt auf nicht gedrückt oder umgekehrt hat, und nicht so einen hin und her, indem man mehrere Tastendrücke auf einmal bekommt. Und zu guter Letzt werden quasi alle Tastaturen heutzutage über USB angeschlossen. Und USB ist ein Verfahren, welches zumindest in den Versionen, die üblicherweise in Tastaturen zum Einsatz kommen, keine Interrupt-Fähigkeit hat. Das heißt, hier wird ein Polling-Verfahren benutzt. Das heißt, auch wieder in einem bestimmten Intervall wird jeweils geschaut, ob die Tastatur neue Daten an den Computers senden möchte. Das heißt, das sind so die drei Hauptquellen von Input Latency, die eigentlich jeder Tastatur-Controller irgendwie bekämpfen oder machen muss. Jetzt ist die Frage, wie schlägt sich die Humble-Hacker-Firmware in Bezug auf Input Latency? Es ist so, dass die Humble-Hacker-Firmware soweit ich das verstehe, und ich will mich da jetzt nicht so sehr aus dem Fenster lehnen, aber so verstehe ich das, die Matrix nach jedem USB-Poll scannt. Ich weiß nicht genau, wieso sie nicht häufiger scannt. Meine generelle Theorie ist, wenn wir auf Stromsparen optimiert werden, wenn es um Tastaturen geht, die auch an Mobilgeräten eingesetzt werden können, zum Beispiel an einem Laptop, da gibt es ja Sinn, dass die nicht zu viel Strom frisst, oder dass sie einfach auf Robustheit bzw. einfaches Programmierverfahren optimiert werden, oder dass sich einfach niemand Gedanken macht. Bei den Billigen ist das sicherlich der Fall. Und nach dem Scan, was also nach jedem USB-Poll passiert, kommt dann das D-Bouncing, da wird bis zu acht Zyklen hintereinander gewartet, also noch mal bis zu acht Mal Pollen hintereinander. Ich muss gestehen, dass D-Bouncing in der Humble-Hacker-Firmware damals implementiert, damals wusste ich noch nicht, was das für Auswirkungen haben könnte. Und wenn ihr euch die Comet-Message anschaut, dann werdet ihr sehen, dass da literally drin steht. Ich habe hier einfach mal acht Reihen geschrieben und es hat funktioniert. Ich habe es seither nicht mehr angefasst. Da gibt es also wirklich keinen Gedankengang dahinter, wieso das acht sein sollte. Es hat einfach funktioniert. Dann dachte ich, das ist gut genug. Mittlerweile weiß ich es besser. Dann könnt ihr das nämlich einstellen, einfach im USB-Device-Descriptor. Das ist einfach eine Zahl. Ihr könnt einfach die Zehen ersetzen durch ein Eins und dann wird sie häufiger gepollt, sofern eben die Bandbreite auf dem USB verfügbar ist. Das habe ich dann erst mal gemacht, weil so ein zehnfach schnelleres Polling klingt eigentlich gut. Insbesondere auch, wenn das D-Bouncing an den Poll-Zyklen ausgerichtet ist. Und dann habe ich aber noch probiert, das D-Bouncing besser zu machen. Das werde ich euch gleich noch erklären, wie man das verschiedenen implementieren kann. Was meine ich jetzt damit? Naja, ich hatte eben diese eine Tastatur und auf der konnte ich die Firmware ändern. Und wenn ich die Firmware aber hochgeladen habe, hatte ich keinerlei Möglichkeit, irgendwie eine D-Bug-Ausgabe zu bekommen oder eine D-Bug anzuschließen oder so, weil es einfach in der Hardware nicht vorgesehen war. Das heißt, ich musste quasi blind arbeiten und wenn irgendwas nicht geklappt hat, dann hat einfach meine Tastatur nicht mehr funktioniert. Das ist natürlich nicht gut zum arbeiten. Das ist halt super frustrierend. Ihr macht einen Fehler und auf einmal könnt ihr nicht mehr tippen. Und mein Take-away davon war dann, okay, offenbar muss ich deutlich mehr über dieses Thema lernen. Und wie lernt man am besten? Naja, man baut es einfach nochmal komplett neu. Und wenn ich mir dann gedacht habe, ja, dann baue ich eine komplett eigene Firmware, dann baue ich sie doch auch für einen neueren Teensie, damit das Design dann nicht so schnell absolviert wird. Ich habe es schon mehrfach von dem Teensie gesprochen. Jetzt wird es Zeit, das zu erklären. Hier oben seht ihr den Teensie++. Das ist ein recht beliebtes, ich sage mal Microcontroller Development Board. Das ist ein sehr kleines Development Board. Oben in der Reihe und unten in der Reihe seht ihr ganz viele GPRO Pins, also ganz viele Pins, über die ihr frei verfügen könnt, wenn ihr was basteln wollt. Auf der linken Seite seht ihr einen USB Anschluss und auf der rechten Seite seht ihr einen Programmierknopf. Und der Clou an diesem Teensie ist eben, dass ihr ihn immer einfach über USB programmieren könnt. Ihr braucht keinen separaten Programmieradapter. Ihr könnt einfach diesen Knopf drücken und egal, was ihr vorher gemacht habt, wie fehlerhaft vorher die Firmware war, der wird sich dann eine neue Firmware über USB einspielen lassen. Und das ist auch ohne komplizierte Programme und deswegen ist dieser Chip eben sehr beliebt bei Bastlern. Also der wird auch in der Modding-Szene und Do-It-Yourself-Szene sehr viel verwendet. Das oben ist wie gesagt der Teensie++. Das ist von Atmel, einen AVR Microcontroller. Der läuft mit 16 MHz und unten drunter seht ihr den aktuellen Teensie. Das ist der Teensie 3.6. Der läuft mit 180 MHz und ist in einem ARM Cortex M4 Micro Prozessor. Und ich habe mir dann gedacht, ich nehme den unteren, weil der ist aktueller. Der Wiese war, bauen wir uns doch einen eigenen Keyboard-Controller. Wie fängt man damit an? Ich habe hier diese gezte Platine aus dem Strand geholt. Das ist quasi ein Breakout-Board für die Chinesis. Ihr seht, da sind wieder diese ganzen Anschlüsse an den Seiten dran. Und dann habe ich die einfach mal mit so Jumper-Wires verkabelt an den Teensie 3.6, den ihr unten auf dem Bild sehen könnt und getestet, ob die Belegung, wie ich sie so im Sinne hatte, funktioniert. Natürlich habe ich bei der Belegung ein paar Sachen verbessern wollen, zum Beispiel eine seriale Schnittstelle rausführen, damit ich das mal eben auch Ausgaben haben kann und eine Details. Wenn ich dann eh schon dabei war, kann man auch den Schaltplan und das Layout ein bisschen aufräumen. Ich habe nämlich früher, also damals, als ich 2013 die Humble-Hacker-Firmware nachgebaut habe, einfach so lange an dieser Datei gearbeitet, bis es funktioniert hat und sie dann direkt einfach so gelassen, online gestellt, ist schon gut genug. Aber in ein paar Sachen könnte man tatsächlich verbessern. Unter anderem, das Namensschema hat nicht übereingestimmt, mit den Namen, die auf den Chinesis-Platinen standen. Und das macht es ein bisschen kompliziert, weil man nicht so genau weiß, wie es zusammengesteckt werden. Das habe ich verbessert. Es gab eine Platzierungsprobleme. Der Keyboard-Controller hat eigentlich in der Mitte noch mal eine Schraube, mit der er festgemacht werden kann. Die hat bei mir nicht richtig gepasst. Der hält auch so, aber schöner wäre es doch, wenn man ihn auch wirklich festschrauben könnte. Und zu guter Letzt habe ich die Keyboard-Matrix umgelegt. Ich hatte nämlich damals einfach die von Humble-Hacker verwendet, was dazu geführt hat, dass ich einen Design hatte, was ein bisschen unvorteilhaft war. Und diesmal habe ich so gemacht, dass sich das Design bequem verlegen lassen kann, dass es dann noch ein bisschen besser ankommt. Gut, so sieht dann das fertige Resultat aus. Auf der linken Seite seht ihr die Platine. Diesmal ist sie purple und nicht green, weil ich sie bei Osh Park hab fertigen lassen. Es ist so ein Leiterbahnfertigungs-Shop aus den USA. Super bequem. Ihr könnt da einfach eine Igel-Datei hochladen und die Rändern, die dann in ganz viele verschiedene Layer und zeigen euch das. Ihr klickt auf bestellen und dann kommt die ein bisschen später in der Post an. Also bequemer als das geht es eigentlich gar nicht. Die haben auch die ganzen Design-Rule, die sind alles, was ihr braucht, um mit Igel zu arbeiten. Also das ist wirklich von vorne bis hinten eine sehr gute Erfahrung. Ihr seht wieder, wie die Platine aufgebaut ist. In der Mitte ist wieder ganz viele Pins und dann kommt so ein Tinsi drauf und an den Seiten habt ihr wieder diese Ausgänge. Auf der rechten Seite seht ihr wieder, wie es in die Tastatur eingebaut ist. Diesmal geht nicht nur in den USB-Kabel von der linken Seite dran, sondern eben auch die verschiedenen Pins auf der rechten Seite sind auch angeschlossen fürs Debugging. Gut, zur Firmware. Ich habe gesagt, die Firmware bauen wir von Grund auf und das nennt sich dann Bear Metal. Also ohne irgendwie einen Betriebssystem oder sonstige Abstraktionen dazwischen habe ich direkt mit diesem Mikrocontroller gearbeitet. Was ich verwendet habe an Tools, ist der GCC ARM Cross Compiler und die LibNewLib, damit man einfach so eine grundlegende Umgebung hat. Vom Tinsi 3 Projekt habe ich das Linkerskript wiederverwendet, weil das sonst einfach bei mir zu viel Fricke leid, das auch noch selber zu machen, insbesondere weil es auch nicht so gut dokumentiert ist. Aber dann habe ich einen eigenen Start-up Code dafür geschrieben, den USB-Stack selbst integriert und einen komplett eigenen Keyboardcode dafür geschrieben. Und die Idee ist eben, Bear Metal zu gehen, damit einem wirklich nichts dazwischenfunkt. Also damit man wirklich weiß, jede einzelne Instruktion, die gehört dahin, weil ich sie dahin geschrieben habe und dass man wirklich das alles gut durchmessen kann, ohne dass irgendetwas dazwischenkommt, von dem man nicht weiß, was es ist. So, wie schlägt sich jetzt also diese neue Firmware? Das Scanning hat insgesamt einen Delay von bis zu 0,1 Millisekunde. Das kommt jetzt daher, weil wir den Tinsi 3.6 auf seinen vollen 180 MHz betreiben, weil wieso nicht, wir haben es ja. Und wir rufen diesmal die Scan-Funktion einfach in der Schleife auf hintereinander, ohne dass wir warten auf den USB-Poll, sondern wir sagen einfach Scan die ganze Zeit. Und eine kleine Optimierung habe ich noch gemacht, nämlich werden alle Spalten von dieser Matrix mit einem einzigen Speicherzugriff eingelesen. Dazu müssen sie alle an einen GPIO-Pod verkabelt werden. Und darauf habe ich eben in meinem Layout geachtet. Und das ist im Wesentlichen so das Einzige, was mir einfällt, was man in diesem Teil optimieren kann. Aber ich dachte, wenn schon, dann schon. So, das D-Bouncing habe ich ja jetzt schon ein paar Mal erwähnt. Hier ist, wie man, also hier kann man sehen, wie das auf einem Oszilloskop aussieht. Auf der linken Seite sieht man, wie die Taste im Normalzustand ist. Also da ist eben ein Pullup, das heißt, die ist auf einem hohen Pegel. Und wenn sie dann gedrückt wird, geht sie auf einen niedrigen Pegel. Und auf der rechten Seite, also auf dem rechten Bild, sieht man, wie sie wieder losgelassen wird. Aber was man jetzt eben sieht, ist, dass sie nicht quasi gerade ist und dann direkt runter fällt und dann gerade bleibt, die geht eben runter und dann schwingt die noch so ein paar Mal und dann geht sie wieder hoch und wieder runter und so weiter. Und diesen Prozess, das sie da so schwingt, das nennt sich Bouncing. Und wie man jetzt die Bouncing implementieren kann, also dieses Schwingen ignorieren kann, ist zum einen, man könnte eine recht langsame Scan Rate verwenden. Das heißt, wenn man nur alle 5 Millisekunden scannt, dann ist das langsamer, als das Bouncing dauert. Im Datenblatt von Cherry wird die Bounce-Zeit als 5 Millisekunden angegeben für die MX-Tasten-Module. Es stellt sich raus in der Praxis, nutzen sich die Tasten-Module auch ab. Das heißt, nach den 10 Jahren, die ich auf diesen Tasten-Modulen getippt hab, brauchen die deutlich länger. Ich musste das auf 10 Millisekunden hochstellen, damit das wirklich sauber funktioniert. Aber das nur als Detail am Drande. Das heißt, mit der langsamen Scan Rate, ihr seht, bei dem ersten Fall wird ein Wert eingelesen, beim zweiten Fall wird ein anderer Wert eingelesen und das Schwingen ist einfach gar nicht erkannt worden. Und was passiert ist aber, wenn man quasi dort liest, wo der Pegel unten ist, das wäre dann quasi der Worst Case. Das heißt, man liest gerade, bevor er noch mal nach oben schwingt, sieht dann also, die Taste ist nicht gedrückt oder nicht losgelassen in diesem Fall und muss dann noch mal 5 Millisekunden warten, bis man den eigentlichen Tastenzustand liest. Das heißt, hier bekommt man eine Input-Latency von 5 Millisekunden allein durchs Bouncing. Eine andere Möglichkeit ist, wenn man eine höhere Scan Rate hat, also wenn man nicht nur alle 5 Millisekunden scannen will, dann gibt es beliebte Implementationen, die man auch häufig findet, wenn man nach dem Thema sucht, das heißt, wenn man eine Taste als gedrückt erkennt, startet man eine Zähler und zählt sie mit jedem Scan eins hoch und sobald 5 Millisekunden vergangen sind, sagt man, okay, jetzt kann ich mir sicher sein, dass diese Taste gedrückt ist und dann wird eben der Tastendruck registriert. Das Problem damit ist eben auch, damit hat man auch nochmal 5 Millisekunden Delay. Die bessere Variante ist jetzt, dass man sagt, okay, sobald ich eine Änderung bemerke, registriere ich direkt diesen Tastendruck und danach warte ich. Das hat letztendlich denselben Effekt, das Bouncing wird übersprungen, und damit hat man gar keine Verzögerung mehr in diesem Prozess. Beim Tastendruck funktioniert das Ganze genauso. Fazit zu dieser Firmware. Wir haben eine Scan Latency von bis zu 0,1 Millisekunde. Die Debounce Latency konnten wir komplett eliminieren und die USB Poll Latency haben wir auf dem niedrigstmöglichen Wert gestellt, also bis zu 1 Millisekunde. Das heißt, die Input Latency von der Tastatur in dieser Revision, wie ich sie gerade vorgestellt habe, bewegt sich im Intervall von 0 Millisekunden, im Idealfall, wenn man gerade so drückt, dass alles direkt passiert, bis hin zu 1,1 Millisekunde im schlimmsten Fall. Die Frage ist natürlich, jetzt können wir das weiter reduzieren und wenn ja, wie? Schauen wir uns mal die USB-Standards an. Ihr seid sicherlich alle vertraut mit USB 1, 2 und 3. Ihr wisst bestimmt alle, dass sich die Geschwindigkeiten unterscheiden von 12 MBit auf 480 auf 5 Gigabit. Aber was mir neu war, ist, dass die USB-Versionen auch sogenannte Microframes festlegen und die bestimmen eben das Poll-Intervall. Und das Microframe war bei USB 1 auf 1 Millisekunde limitiert und bei USB 2 ja 125 Mikrosekunden. Und bei USB 3 sind sie tatsächlich auf Interrupts gegangen. Das heißt, man hat da überhaupt kein Polling mehr, sondern kann auch sagen, ich möchte jetzt direkt Daten übertragen. Die allermeisten Tastaturen benutzen eine Variante von USB 1. Entweder USB 1.0 Low-Speed sogar oder USB 1.1 Full-Speed, aber die sind eben alle auf das 1 Millisekunde limitiert. Ich habe mir jetzt angeschaut, was ist eigentlich für ein Mikrocontroller USB 3.6 drauf. Und das ist von der Firma NXP von der Kinetis-Serie. Ganz ähnlicher Namen, aber was anderes als die Kinetis-Tastatur gibt kein Bezug. Der MK66F, genau diese Modellvariante, der hat zwei USB-Ports drin. Der hat einen USB FS-Port und einen USB HS. Das FS steht für Full-Speed, das HS für High-Speed. Das heißt, der FS ist auf 1.1 beschränkt und der HS ist USB 2.0. Diese beiden Ports benutzen komplett separate Software-Stacks. Der USB FS war halt damals drin, den haben die selbst entwickelt und dann haben sie irgendwann einen High-Speed-Port hinzufügen müssen und haben sich gedacht, ah, wir benutzen von Intel das Referenz-Design, haben den dazu gepackt und den alten einfach drin gelassen für Kompatibilität. Der Tinsi nutzt jetzt den USB FS-Port, wahrscheinlich einfach, weil es den halt schon immer gab und der HS-Port ist später dazu gekommen ist. Der Tinsi kann optional aber den HS-Port auch benutzen für den Host-Mode. Das bedeutet, wenn man eine Tastatur oder eine Maus an seinen Mikrocontroller anschließen will, ich möchte den aber im Device-Mode verwenden, weil ich ja meine Mikrocontroller an den Computer anschließen möchte. Und außerdem ist die Software noch ganz in den Kinderschuhen gewesen für den Host-Mode vom Device-Mode mal überhaupt noch gar nicht zu reden. Dann habe ich mich direkt beim Hersteller umgeschaut. Von NXP gibt es auch einen SDK, also einen Software Development Kit, mit verschiedenen Beispielen, inklusive einem Beispiel dafür, wie man diesen USB HS-Port verwenden kann. Leider funktionieren diese Beispiele nicht direkt auf dem Tinsi, denn der Tinsi unterscheidet sich mit dem USB HS-Port, was NXP hat und für das NXP seine Beispiele auslegt, darin, dass er eine andere Clock-Konfiguration verwendet. Also der benutzt einen 12 MHz statt einen 16 MHz Crystal. Und dann muss man eben die Beispiele erst mal portieren, sozusagen. Außerdem hatte ich im Serial in Setup-Code noch ein Problem gesehen, was ich dann auch noch beheben musste, bevor ich eine Ausgabe auf der Serialen Schnittstelle erlangt habe. Leider hat es dann bei mir nicht geklappt, den USB HS-Port auf dem Tinsi mit diesen Beispielen direkt zu verwenden. Und ich weiß im Nachhinein nicht wieso, dass ich irgendwas übersehen habe bei dem ganzen Portieren. Die Frage war, ob ich nicht einfach mal einen 12 MHz Quartz in den Tinsi packen könnte. Wahrscheinlich ja, aber das ist echt kleine SMD-Fummelarbeit und zu dem Zeitpunkt hatte ich mich noch nicht in der Lage gefühlt, das zu machen. Später habe ich dann mit den Reflow-Geräten gearbeitet und dann hätte ich es auch machen können, aber damals eben nicht. Im Nachhinein könnte man viele Sachen anders machen, da werde ich auch noch ein bisschen zu erzählen. Ich habe eine Firma gefunden, namens U-Tasker. Die läuft auch auf dem Tinsi, also der Tinsi ist eine unterstützte Plattform davon und die benutzt den USB HS-Port. Die ist aber relativ schwergewichtig. Die kann man also quasi wie ein eigenes Betriebssystem wahrnehmen. Die hat also auch wirklich so ein Scheduler drin und mehrere Tasks und alles Mögliche. Üblicherweise ist das wahrscheinlich schon okay, aber wir wollten bei dem Projekt ja möglichst bare Metal bleiben, damit wir wirklich Kontrolle über alles haben. Dann habe ich gesagt, okay, das ist gut, als Bestätigung, dass der USB HS-Port im Prinzip funktioniert, aber ich möchte es trotzdem lieber anders machen. Zu dem HS-Port nochmal. Der ist optional auf dem Tinsi und optional bedeutet in dem Fall, dass der noch nicht mal bestückt ist. Also da ist kein USB-Buchse dran oder so, sondern das ist wirklich einfach die Pins, die ich hier rot markiert habe. Man braucht also einen Breakout-Board dafür, damit man da eine USB-Buchse bekommt, aber leider ist in der Tastatur nicht genug Platz an der Stelle, an der dieser Mikrocontroller sitzt. Das heißt, selbst wenn man das eben so aufbauen würde und einen Breakout-Board anlöten würde, wird das nicht reinpassen in die Tastatur. Jetzt bauen wir noch einen Keyboard-Controller. Diesmal benutzen wir also direkt den NXP Mikrocontroller statt einen gesorkelten Tinsi und dann haben wir auch maximale Freiheit darüber, wie das alles vom Layout her ist und wo die Platzverhältnisse passen. Eine Sache habe ich gleich gelassen, da mich den Tinsi Bootloader Chip. Ich hatte vorhin angedeutet, dass man beim Tinsi mit einem Tastendruck direkt wieder neue Firmenware programmieren kann und das war ein Feature, was ich beibehalten wollte. Unter anderem auch, weil ich minimale Änderungen zwischen den verschiedenen Hardware-Revisionen haben wollte, dass man das auf der anderen Seite einfacher macht, gerade wenn man, wie ich, nicht so viel mit Hardware macht. Damit haben wir also den gleichen Programmiermechanismus und man kann sich den einfach im Shop kaufen, dort wo man auch den Tinsi bestellen kann, für eigene Projekte, das ist wirklich so gedacht. Find ich ein sehr gutes Angebot. Hier ist dann das fertige Ergebnis. Auf der linken Seite seht ihr wieder die gefertigte Platine. Auf der rechten Seite seht ihr die bestückte Platine. Diesmal ist schon deutlich mehr auf dieser Platine zu sehen. Aber im Wesentlichen ist der ganz große Chip eher so auf der linken Seite von der Mitte, ist der Microcontroller. Der ist jetzt ein bisschen größer als der Tinsi vorhin, weil der Tinsi eben maschinell gefertigt wird und sich deswegen erlauben kann, die kleinste Bauform von diesem Chip zu verwenden, aber hier ich die etwas größere Bauform gewählt habe, damit ich das noch von Hand löten kann. Im Nachhinein betrachtet, auch wieder könnte man das anders machen, mit besseren Maschinen und so weiter, aber zu dem Zeitpunkt wollte ich es halt so machen. Auf der linken Seite von dem Microcontroller seht ihr den Tinsi Bootloader Chip und oben drüber den Programmierknopf. Dann sieht man oben den USB-H-Sport und den anderen USB-Port, den USB-FS. Und beim USB-FS ist auch noch die paar Komponenten dabei für die Stromversorgung von dem ganzen Ding. Das war es im Großen und Ganzen auch schon. Eine Sache, zwei Sachen gibt es noch zu erwähnen, zum einen den seriellen Port, der jetzt auf dieser Stiftleiste rechts von der Mitte rausgeführt wird und dann unten drunter ist nochmal genau so eine Stiftleiste für den Programmierport. Das heißt, ich kann nicht nur diesen Programmierknopf mechanisch manuell mit meiner Hand drücken, sondern ich kann auch programmatisch über einen anderen Microcontroller den Programmiermodus einleiten. Schon habe ich dann auch Gebrauch gemacht. Ich habe mir also eine Entwicklungsumgebung aufgebaut, sozusagen. Auf der linken Seite seht ihr, wie aus der Tastatur einen USB-to-Serial-Adapter rausgeführt wurde. Auf der rechten Seite seht ihr den sogenannten Rebootor. Das ist tatsächlich ein Fachbegriff aus der Tinsi-Community. Was man darunter versteht, ist einen zweiten Tinsi anzuschließen, der eine spezielle Firmware hat und wenn man dann den Tinsi-Loader startet, um die neue Firmware auf das Gerät zu laden, dann triggert er erst mal den Programmiermodus. Das heißt, man kann sich wirklich nicht nur den Kompilbefehl einstellen, sondern den Kompilbefehl verknüpfen mit. Wenn die Firmware kompilt, dann installiere sie doch gleich mal auf der angeschlossenen Tastatur. Das macht es natürlich sehr angenehm. Nicht nur habe ich also mir so eine Entwicklungsumgebung aufgebaut, sondern ich sollte auch dazu sagen, dass ich diesmal nicht den gleichen Fehler gemacht habe, wie beim Anfang, also ich mir also meine einzige Tastatur quasi zerschossen habe. Sondern diesmal hatte ich eine alte Chinesis-Tastatur von einem Arbeitskollegen von mir bekommen. Der meinte, ja, die ist mir kaputt gegangen, manche Tasten funktionieren nicht mehr so richtig zu e-eigene Elektronik rein. Gib mir die doch mal, ich kann damit was anfangen. Und dann habe ich die eben umgebaut und habe mir quasi eine Entwicklungstastatur gebaut. Das ist jetzt auch die, die ich hier dabei habe. Das heißt, ich habe jetzt eine zu Hause, eine auf Arbeit und die da. Und das ist dann gut zu entwickeln. Gut, Firmware für diese Controller-Revision basiert auf dem NXP SDK, was ich vorhin schon erwähnt habe. Der USB-HS-Port läuft auf meiner eigenen Hardware ohne Probleme. Das ist sehr gut, denn das bedeutet, dass wir sofort nicht mehr um die Bermetel-Firmware kümmern müssen. Die NXP basierte Firmware ist auch noch Bermetel, aber nicht mehr selbst entwickeln, sondern die benutzt einfach den USB-HS-Stack, der von NXP mitgeliefert wird. Meine Hoffnung ist, dass dieser Stack ein bisschen fehlerfrei ist, als alles, was ich in meiner limitierten Freizeit hätte entwickeln können. Und insbesondere, wenn NXP bei anderen Kunden Probleme findet, dann fließen diese Änderungen da eben wieder mit ein. Das heißt, meine Hoffnung ist so ein bisschen, dass ich dadurch jetzt meine Firmware auf neuere Revisionen von diesem SDK habe, wenn wir mal sehen, wie sich das in der Praxis bewährt. Aber das war eben die Idee. Ich habe diese Firmware auch komplett mit der MCU-Expresso IDE implementiert. Das ist vor Beherrschsteller, eine mitgelieferte IDE. Und mein Fazit zu dieser IDE ist, die erleichtert den Start in das Projekt. Also man hat grafische Tools, um die ganze Clock-Konfigurationen und um die Pin-Belegungen einzustellen. Aber abgesehen davon ist sie einfach das nicht besonders gut integriert und konfiguriert ist. Das heißt, mein persönliches Fazit wäre, wenn ich noch mal so was machen würde, würde ich mit der MCU-Expresso IDE anfangen, um die Clock-Konfig und die Pin-Konfig zu machen und dann sofort in den Editor wechseln, der mir besser gefällt. Aber ich dachte mal ausprobieren, um es ausprobiert zu haben. Fazit zu dieser Firmware. Die Werte sind jetzt wieder gleich wie vorher. Scan latency bis zu 0,1 Millisekunde, die bei uns keine. Erstmal können wir USB 2.0 High-Speed verwenden mit nur noch 125 Mikrosekunden USB Paul Latency. Damit ist die komplette Input Latency im Rahmen von 0 Millisekunden im Bestfall bis zu 0,225 Millisekunden im schlimmsten Fall. So, was haben wir daraus gelernt? Die NXP Microcontroller-Dokumentation ist leider eher sperrlich. Ich war dann ein bisschen negativ überrascht, weil ich eben früher mehr mit den ADMEL AVR-Controllern gemacht habe, die wirklich sehr vorbildlich dokumentiert waren. Am Mikrokontrollern ist das wohl leider normal, habe ich mir sagen lassen, dass da einfach alles nicht so gut dokumentiert ist. Ein bisschen schade. Im Nachhinein würde ich auch nicht mehr mit dem Tinsy anfangen. Das habe ich einfach deswegen gemacht, weil das historisch gut gepasst hat. Das war eben die natürliche Entwicklung von diesem Projekt. Aber eigentlich wäre es besser gewesen mit dem Development Board anzufangen. Das heißt Freedom K666F von NXP. Und dort hat man dann integriertes JTag-Debugging ohne weitere Anpassungen. Und damit hätte ich dann wahrscheinlich einige Fallstrecke direkt übersprungen in dem Projekt. Gut, so viel zum ersten großen Teil von dem Vortrag. Jetzt möchte ich noch motivieren, warum mit dem eigenen Keyboard-Controller wir jetzt auch einen eigenen USB Hub brauchen. Es ist so, dass in der Kinesistastatur schon einen Hub mitkommt, standardmäßig. Den seht ihr hier abgebildet auf der Folie. Was ihr hier auch seht, ist, dass wir das USB-Kabel in die Kabel in den Stecke leisten. Und die sind eine problematäre Belegung. Auf dem einen Stecke wird ein USB-Kabel entgegengenommen, was in die Tastatur reingeht. Und auf dem anderen Stecke wird mit dem Keyboard-Controller gesprochen, der sich da drinnen befindet. Allerdings ist es so, dass diese Platine USB nach PS2 konvertiert. Weil der Keyboard-Controller eben schon recht alt ist. Der benutzt auch noch alte Through-Hole-Komponenten und noch keine SMD-Komponenten. Der ist wirklich sehr alt. Und wenn wir das USB-Kabel in die Kabel entgegenommen haben, könnten wir es nicht, weil wir sprechen der USB und nicht PS2. Außerdem ist es so, dass diese Hub eine USB 1.1 kann und ihr habt ihr gerade aufgepasst und bemerkt, dass wir USB 2.0 High-Speed brauchen und deswegen können wir den leider nicht verwenden. Außerdem ist es so, dass manche Geräte an diesem Hub nicht funktionieren und ich habe mich immer gewundert, warum das so ist. In der Praxis verwende ich den deswegen eigentlich gar nicht. Aber es wäre doch interessant rauszufinden, dass ich den USB 2.0 High-Speed-Design gefunden habe und habe deswegen einfach kurzerhand mich selbst ein bisschen informiert. Ich habe mir von fünf verschiedenen Herstellern USB Hub Chips angeschaut und mich dann relativ schnell entschieden, dass ich USB 2.0 benutzen möchte statt USB 3.0. Denn bei USB 3.0 sind die Checklisten deutlich länger und es gibt deutlich mehr Sachen, die man beachten muss. Sonst hat man am Ende ein Design, was nicht richtig funktioniert. Das ist für Bastler einfach, also für Bastler auf meinem Niveau muss man einfach mit USB 2.0 vorliebt nehmen im Moment. Der Abschluss dieser ganzen Vergleichsarbeit mit dem Hersteller Cypress, die HX2-VL-Serie die beste Doku hat. Dort kann man nicht nur ausführliche Datenblätter finden, sondern auch einen Referenzdesign, also einen Evaluation Board, dessen Layout man bekommt, dessen Bill of Materials man bekommt, man bekommt eine Design-Checkliste, es gibt einen Forderung mit Community usw. Also die hatten auf jeden Fall die besten Ressourcen. Dann habe ich gesagt, okay, dann nehme ich auf jeden Fall die. Das Resultat davon seht ihr dann hier. Auf der linken Seite wieder das Platinen-Layout aus Igel. Auf der rechten Seite die bestückte Hub-Platine. In der Mitte ist es ein bisschen schwer zu erkennen, weil so viel passiert auf dieser Platine, aber in der Mitte sitzt der USB Hub-Chip. Alles weitere außen drum ist eigentlich nur für die Stromversorgung von diesem Hub-Chip und von den USB-Ports. Die USB-Ports brauchen nämlich diese fetten runden Kondensatoren, damit man das Hot Plug machen kann, ohne dass da alles kaputt geht. Dann ist noch ein paar Komponenten noch drauf, um den Überspannungsschutz für die einzelnen USB-Ports zu realisieren. Denn wenn ihr den Gerät einsteckt, was sich nicht ordentlich verhält, wird der USB-Port abgeschaltet werden und nicht der ganze Hub nicht mehr funktionieren. Ja, bitte. Ah, sorry, das hätte ich noch sagen sollen. Die Frage war, was war die Motivation, einen eigenen Hub zu nehmen, statt was Fertiges auszuschlachten. Der Grund ist eben zweierlei. Zum einen ist es so, dass dieser Hub eben hier sitzt und diese zwei USB-Ports hier rausgeführt sind. Das heißt, wenn man den Hub baut, dass in Größenverhältnisse genau so sind, dass er in diese Tastatur reinpasst, dass man jetzt noch eine bekäme, was immer, so ändern könnte, dass man also nichts weiter machen muss, als die aufzumachen, die beiden Boards raus, die eigenen Boards rein wieder zu. Das ist natürlich ein sehr eleganter Mod, ohne dass man da an das Gehäuse dran gehen muss, sich was überlegen muss, abmessen muss und so weiter. Macht es also ein bisschen einfacher auf der Ebene. Der andere Grund ist, auf der Folie seht ihr es, dass da unten zwei USB-Kabel reingehen in den internen Teil von diesem Hub. Das liegt daran, dass der USB-HS-Port der HS-Port High-Speed wird nur für die Datenübertragung verwendet. Über den FS-Port geht die Stromversorgung. Da könnte man jetzt sagen, warum hast du nicht die Stromversorgung so gebaut, dass sie mit einem von den beiden Boards gehen? Das ging theoretisch, habe ich aber nicht gemacht, weil ich den FS-Port ohnehin zum Programmieren brauche, weil, wie gesagt, der Teensiebutler nur den FS-Port ansteuern kann. Deswegen dachte ich, wenn man effektiv beide angeschlossen haben muss, dann brauche ich jetzt auf jeden Fall auch einen Hub, der sollte auch intern sein und gut passen. Deswegen habe ich gesagt, da mache ich einen, der die gleichen Dimensionen hat. Dann habe ich auch noch was beigelernt. Das so im Großen und Ganzen. Der Einwurf hier war, warum dann überhaupt USB? Weil die Gamerkreise z.B. schwören auf PS2. Wenn du dir diesen Computer anschaust, der hat USB und kein PS2. Ich möchte hier die Tastatur verwenden können. Ganz pragmatischer Entschluss. Es führt langfristig immer zu Problemen. Deswegen habe ich auch den neuen Teensie genommen, weil ich eben nicht ... Der Alter hatte zum Beispiel ein Mini-USB, dafür habe ich mittlerweile kaum noch Kabel rumfliegen. Der neue hat Mikro-USB, das ist schon mal ein bisschen besser. Es ist immer so ein bisschen ein Hinterherren der aktuellen Technik gegenüber. Aber okay, das können wir gerne auch noch später in der Frage drunter genauer diskutieren. Jetzt machen wir erst mal weiter mit dem USB Hub. In der ersten Revision von diesem Hub hatte ich die Stromversorgung so konfiguriert, dass sich der Hub als Bus-Powered ausgibt und es korrekt. Denn Bus-Powered bedeutet, dass er seinen kompletten Strom über das USB-Kabel bekommt. Im Gegensatz zu zum Beispiel Self-Powered, wo man ein aktives Netzteil noch an den Hub anschließen müsste. Habt ihr bestimmt schon mal alle gesehen, ein aktives USB Hub, das wäre Self-Powered. Aber ich habe eben Bus-Powered, weil ich will jetzt nicht noch ein Netzteil mitschleppen für meine Tastatur. Das war ja affig. Dann habe ich also meine Geräte angeschlossen in die fertig bestückte Platine und gesehen, das geht mit dem Logitech-Receiver und dann habe ich das Gekämpfer über den USB-Kabel. Ich habe das Gekämpfer schon mal mitgeschlossen. Das ist meine externe Festplatte. Die braucht vielleicht viel Strom, aber es geht auch noch nicht mal in mein USB-Stick. Das kann ja jetzt schon nicht sein. Ich habe dann in das SysLock geschaut und der Linux-Königthalt mehr hiermit, dass er eine USB-Konfiguration verworfen hat oder zurückgewiesen hat, weil nicht genügend Strom verfügbar ist über diesen Bus-Powered-Weg hin zum Gerät. Aber die Geräte gehen doch an anderen USB-Hubs, die auch Bus-Powered sind. Da habe ich alle gekauften Hubs, die wir zu Hause hatten, untersucht und festgestellt, dass alle von sich behaupten, Self-Powered zu sein, obwohl sie es gar nicht sind. Das liegt einfach daran, dass man damit die Power-Calculation im Kernel umgeht und Self-Powered laut Standard 500 mA über alle Ports zulässt statt bei Bus-Powered nur 100 mA pro Port. Solange die Endkunden dann nicht zu viele stromhungrige Geräte gleichzeitig anschließen, funktioniert es schon irgendwie in der Praxis, aber es ist halt nicht korrekt. Und dann dachte ich, okay, da sollte ich dann eben wohl an der Stromkonfiguration das so ändern, dass der Kernel versteht, wie viel Strom ich hier wirklich brauche. Also ich wollte es auch so ein bisschen tricksen, wie die gekauften Hubs, weil das soll schon genauso angenehm funktionieren und habe dann also einen E-Prom auf die Platine gelötet. Das hatte ich am Anfang in der ersten Revision nicht. Das heißt, ich habe noch eine Revision fertigen müssen mit einem E-Prom, in der ich dann den Max-Power-Wert konfigurieren konnte. Stellt sich hinterher raus, das war unnötig, weil ich Max-Power falsch verstanden hatte. Den der Hub an sich braucht und den er weitergeben kann, das war aber falsch. Sondern Max-Power ist nur der Strom, den der Hub für sich braucht. Und für die eigentliche Stromproblematik hier muss man wirklich nur Self-Power auf Bus-Power umstellen und Max-Power ist egal. Aber nachdem ich das E-Prom schon hatte, konnte ich eben auch den Manufacturer und den Product Name und die Serienummer ändern, was vorher eben nicht möglich war. Das heißt, vorher hat sich der Hub gemeldet als einen Standard Cypress USB Hub und hinterher kann ich dem jetzt auch einen E-Prom vergeben. Doch dich ja, dann behalte ich doch das E-Prom, das ist doch schön. Das E-Prom ist programmierbar nicht nur bevor man es auf die Platine löte, sondern auch hinterher, weil der Cypress-Chip eben die Funktionalität hat, dieses E-Prom auch zu beschreiben. Und Cypress liefert dafür einen Programm mit, das nennt sich Blaster. Und das Programm gibt es nur für Windows und es ist leider recht schwer zu installieren. Also auf dem aktuellen Windows 10 ist es schwierig, weil es gibt irgendwie nur alte Treiber und dann das irgendwie richtig hinzufummeln, weil es sehr viel kostet. Es gibt auch eine Linux-Version für USB3-Chips von Cypress, aber eben nicht für die älteren USB2-Chips. Da konnte ich es mir also nicht abschauen, wie es funktioniert. Aber ich habe dann also unter Windows, nachdem ich das alles aufgesetzt hatte, mir mal genauer angeschaut, was da passiert. Und das ist auch gar nicht schwer. Ich habe das hier in 4-Zeilen Go-Code auf die Folie gepackt. Man öffnet das USB-Gerät und schickt dann den herstellerspezifischen Request mit der Nummer 14 hin. Hier kann sich zwischen 0 und 63 bewegen, um die ganzen 128 bytes von dem E-Prom anzusteuern und kann dann entweder 2 bytes lesen oder 2 bytes schicken, je nachdem, welche Transportrichtung man für den Request setzt. Also das Programmieren und Auslesen von diesem E-Prom ist damit denkbar einfach und ich habe auch ein kleines Tool veröffentlicht, mit dem man das von vorne bis hinten machen kann. So, nochmal um zur Stromversorgung zurückzukommen, nachdem ich dann das ganze E-Prom-Zeug gemacht hatte, habe ich eben gesehen, dass man Self-Powered versus Bus-Powered an dem Chip nicht im E-Prom umstellen kann, also man musste eins statt auf High auf Ground setzen. Und das habe ich dann gemacht und vorgegeben effektiv, dass dieser Hub eben auch Self-Powered ist und da der USB-Stick funktioniert auf einmal zuverlässig und die externe Festplatte funktioniert auch, zumindest so lange man sie als erstes oder einziges Gerät an diesen Hub anschließt, weil die eben viel Strom braucht zum Anlaufen. Aber das war so quasi der Punkt, wo ich gesagt habe, okay, jetzt funktioniert er deutlich besser, als der Original Hub. Gut, kommen wir zum dritten und letzten Teil des Vortrags und dann gibt es noch die Fragerunde. Hier möchte ich auf die Input Latency Messungen eingehen. Ich hatte mir dann gedacht, jetzt, wo ich eine eigene Tastatur habe, in der ich weiß, wie hoch die Input Latency ist und in der ich sie auch nachmessen konnte, experimentell, um das zu bestätigen, wäre es doch auch schön, wenn andere Leute auch davon profitieren können und auch Input Latency Messungen anstellen könnten. Und dann habe ich mir gedacht, das ist ein bisschen unkomfortabel, wenn andere Leute dafür erstmal einen Tastatur-Controller bauen müssen, den sie ja vielleicht gar nicht brauchen und wollen. Und deswegen habe ich mich entschlossen, einen E-Variation Board zu portieren, das CD hier abgebildet. Man kann das für ca. 60 US-Dollar in jedem größeren Electronics Shop kaufen und unten rechts auf der Folie seht ihr, der hat einen Debuganschluss, das ist das, über den man über diesen Anschluss kann man das J-Tech betreiben und der Anschluss oben drüber ist eben USB High Speed für an den Computer anschließen. Dieses Board hat dann noch drei Taster. Ich habe mich für den Switch 3 entschieden, aber es ist egal, die sind alle gleich gut und wenn man den Switch 3 betätigt, die Messfirma ist fast wie die Keyboardfirma mit ein paar kleinen Anpassungen. Und konzeptionell, was hier gemacht wird, also wie die Messmethodik funktioniert ist, wenn man den Switch 3 drückt, dann wird ein Caps Lock-Tastendruck an den Computer geschickt. Warum Caps Lock? Weil das der einzige Tastendruck ist, der eine Bestätigung vom Computer erhält, wenn er verarbeitet wurde. Der Computer schickt nämlich, ganz rechts seht ihr das, ein Hit Report, also ein Human Interface-Device-Report zurück, in dem er sagt, okay, Tastatur, schalte jetzt mal die Caps Lock LED und das nutzen wir aus, in dem wir von Caps Lock schicken, bis hin zu Caps Lock Hit Report Empfang messen. Was wir noch rausrechnen müssen, ist die USB-Poll Latents. Das ist hier am Anfang eben die 125 Mikrosekunden, wenn wir USB 2.0 High-Speed verwenden. Und am Ende findet noch mal eine USB-Transaction statt, einfach weil der Hit Report ja auch vom Host anders gerade übertragen werden muss. Aber das zwischen drin ist dann eben die Processing Latency. Also man unterscheidet bei der Ende-zu-Ende-Latents zwischen Input Latency, alles was die Tastatur verursacht, die Processing Latency, alles was der Computer braucht, zum Verarbeiten und Output Latency, alles was der Monitor braucht, um das dann auch wirklich anzuzeigen, was sich geändert hat. Gut, auf dem Host, wie gehen wir hier vor? Die Messmethodik ist, wir müssen folgende Komponenten auf jeden Fall messen, weil wir quasi nicht höher rankommen, ohne eigene Kernelmodule zu schreiben. Wir vermessen den USB Host Controller, das ist so ein Chip auf eurem Mainboard. Dann vermessen wir den Linux Kernel, speziell hat er einen USB-Triper drin und einen Input-Triper. Dann vermessen wir noch die Input-Event-API, das heißt FDF unter Linux. Was wir aber nicht messen, ist X11 oder Wayland oder sonstige grafische Komponenten, sondern wir haben, wie auf der rechten Seite der Folie abgebildet, einfach ein kleines Programm, welches direkt mit dem Linux Kernel spricht, über die FDF-API und Tastendröcke entgegen nimmt. Und wann immer es einen Capslock-Tastendruck entgegen nimmt, dann setzt es direkt die Capslock LED. Damit kriegen wir also die geringst mögliche Latents auf der Host Processing Seite und können das benutzen, um Messungen anzustellen. Ich habe jetzt diese Processing Latency auch nochmal mit WireShark bestätigt. WireShark hat nämlich einen USB-Modul, mit dem man auch den USB-Datenverkehr von der Host-Perspektive messen kann. Dass ihr die hier rechts abgebildet. Was dann natürlich nicht drinsteckt, ist die USB-Pollzeit und die USB-Transaction-Time, weil das ja zum Gerät hin nur passiert. Ich habe dann ein Ubuntu 17.10 genommen, einfach weil es eine sauber durchversionierte Linux-Distribution ist, die auch den meisten Leuten geläufig ist. Und die Processing Latency, die ich im Mittel messen konnte, betrug 152 Mikrosekunden. Also wirklich recht gering. Mich hat es dann auch noch interessiert, wie ist denn die Processing Latency von einem typischen Text-Editor. Dann habe ich ein bisschen E-Max-Lisp-Code geschrieben, den ihr auf der rechten Seite seht. Was der macht, ist, wann immer man eine Taste drückt und der Tastendruck in diesem Buffer verarbeitet wird, wird die Capslock LED eingeschaltet. Das heißt, damit kann man sich die Capslock-Taste vorher umdefinieren und sobald der E-Max dann die Taste erhält, wurde sie nicht mehr vom Betriebssystem verarbeitet, sondern wird von E-Max verarbeitet. Und was ich hier dann gemessen habe, auch wieder mit dem Ubuntu 17.10 und dem E-Max 25.222, ist eine Verarbeitungslatency von inmittels 278 Mikrosekunden. Da ist jetzt die Baseline nicht drin, also die 152, die wir vorhalten, müssen da noch mal draupferdert werden. Machen wir das doch mal schnell. Hier haben wir die Ende-zu-Ende-Input-Latency. Wie gesagt, Matrix Scan in unserer Tastatur ist B-Poll 125, Linux 152, E-Max 278 und im Total kommen wir dann auf 655 Mikrosekunden. Da kommt dann natürlich noch mal die Output-Latency dazu, weil wir Monitor üblicherweise mit 60 Hz Bild-Wiederholtrate betreiben. Das bedeutet noch mal zwischen 0 und 16 Millisekunden. Aber 0 und 16 Millisekunden okay und darauf dann noch mal die 655 Mikro, das ist ja dann quasi nicht mehr der Rede wert. Jetzt ist die offensichtliche Frage okay, aber wozu das Ganze, wozu es eigentlich schon überhaupt diese Input-Latency war? Und diese Frage wollte ich ein bisschen empirisch beantworten, weil mir eben keine Studien dazu bekannt sind und dann habe ich kurzerhand das Latency-Spiel entwickelt. Das Spiel spielt man mit eben dieser Tastatur und wie das funktioniert ist, das Spiel stellt zusätzliche Eingabellatents in der Tastatur ein. Das heißt, die Tastatur tut langsamer als sie ist, je nachdem, ob das Spiel vorher gesagt hat, dass sie langsam sein soll oder nicht. Und der Spieler muss dann ein bisschen tippen und sich dann entscheiden, habe ich hier Latents gespürt oder nicht. Und in den höheren Levels wird die Zusatzlatents immer niedriger. Das heißt, es wird immer quasi geschaut, wie sensitiv ist man auf diese zusätzliche Eingabellatents. Jetzt muss man nochmal betonen, es ist nicht die totale Latents, die wir hier kontrollieren können, sondern nur zusätzliche Latents. Es gibt uns also nicht wirklich superkorekt wissenschaftlich gesehen, was wir hier machen, aber es ist zumindest ein gutes Indiz. Ich habe dann auf dem letzten Congress 17 Leute das spielen lassen. Der beste Spieler, den wir hatten, konnte 15 Millisekunden zusätzlich in Eingabellatents zuverlässig unterscheiden, aber einige Spieler konnten bereits 75 Millisekunden nicht mehr unterscheiden. Das heißt, was nehme ich davon als Takeaway? Na ja, es gibt Leute, für die ist es relativ wichtig oder die können das wirklich wahrnehmen und dann gibt es ganz viele Leute, denen es ist total egal. Und das beantwortet dann auch die offensichtliche Frage, wenn du jetzt eine Tastatur bauen kannst, die so viel besser ist, als die anderen Tastaturen, die es auf dem Markt gibt, warum machen die großen Hersteller das dann nicht und die Antwort ist, weil es die meisten Leute nicht interessiert. Das ist also wirklich ein sehr annieschen Projekt hier. Okay, Fazit zu alledem. Nummer 1, ich habe eine sehr schnelle Tastatur. Das fühlt sich gut an, darauf zu tippen, aber ich gebe vollkommen zu, dass ich da einen Bias habe, weil ich sie auch selbst gebaut habe und dann fühlt sich das ohnehin gut an. Nummer 2, ich habe viel gelernt über PCB-Design, über ARM Microcontroller, mit dem ich vorher noch nichts zu tun hatte, über USB, wie es funktioniert, Human Interface, Devices und so weiter und so fort. Und zu guter Letzt, einige von euch haben sicherlich Blockposts gelesen, die vor einer ganzen Weile durch die Computer-Medien gegangen sind, von wegen, dass Damals alles besser war und der Apple II hatte die beste Eingabe-Latents und moderne Computer sind alle so schlecht. Das stimmt offensichtlich alles gar nicht, sondern moderne Computer haben eine sehr niedrige Processing-Latency und solange ihr gut per Referien nutzt, also nicht die schlechteste Tastatur für das wenigste Geld, die ihr finden konntet und den schlechtesten Monitor, der die höchste Verzögerung hat, seid ihr wahrscheinlich gut aufgestellt. Eine Sache möchte ich noch dazu sagen, je mehr man an der Input-Latenz optimiert, desto mehr Latents kann man sich natürlich an anderen Layern im Stack leisten. Das heißt, grob gesagt, wenn ich meine Tastatur sehr schnell habe, kann ich in meinem Text-Editor sehr viel Unsinn machen und nehme trotzdem noch keine Latents wahr. Ich könnte zum Beispiel das anfangen, Atom zu benutzen oder so. Gut, kommen wir ans Ende meiner Folien. Wie gesagt, gleich habt ihr noch Gelegenheit, Fragen zu stellen. Dafür wird es dann bestimmt auch ein Mikrofon geben. Ich möchte euch noch bitten, mir Feedback zu geben zu dem Vortrag. Ihr könnt dazu entweder jetzt direkt diesen QR-Code scannen oder nachher auf den Folien in dem Link klicken. Und bevor wir die Frage einleiten, bleibt mir noch zu sagen. Vielen Dank für eure Aufmerksamkeit. Fragen. Vielen Dank für diesen sehr informativen und interessanten Vortrag. Wir haben noch genau 10 Minuten, also noch perfekt, um Fragen zu stellen. Ich habe nur eine Anmerkung, wie man an Taster mit Diode dran kommt. Und zwar gibt es von Cherry das MX-Bot 3.0. Das kostet 65 Euro und da sind über 100 Taster drin. Man muss ja nur noch auslöten. Aber das geht es ja einfach, habe ich selber schon gemacht. Okay, vielleicht bist du einfach sehr gut im Auslöten. Meine Observation ist, dass es wahrscheinlich für mich schneller geht, Tasten aufzumachen und Diode reinzutun, als Tasten auszulöten. Aber je nachdem, welche Techniken du zur Verfügung hast und wie geübt du bist, ist das ein guter Punkt. Danke. Eine Frage, die ausgelöst wurde davon, dass du vom Neolayout gesprochen hast. Diese Tastatur hat ja Tastenkappen, die sehr unterschiedliche Formen haben, wegen dieser Form von der Tastatur. Das heißt, du kannst sie wahrscheinlich nur im ursprünglich ausgelieferten Layout benutzen. Das heißt, wenn du auf Neo umschaltest, tippst du quasi blind und guckst bloß nicht auf die Tasten. Sehe ich das richtig? Das ist genau richtig, ja. Es gibt tatsächlich auch andere Tastenkappenbeschriftungen. Man kann von Kinesis die Tastatur auch kaufen mit aufgedrucktem Dworderc Layout, auch als Zweitlayout. Ich habe mir auch überlegt, Arbeitskollegen von mir haben quasi so eine Aktion gestartet, wo sie gesagt haben, wir drucken uns mal ein eigenes Set aus den Kappen, wollte irgendwas Spezielles drauf haben. Und ich habe mir dann überlegt, will ich das Neolayout da draufgedruckt haben und habe mich dann dagegen entschieden? Denn Neo ist das Layout, was ich ohnehin schon blind tippen kann. Und da brauche ich die Beschriftung eigentlich nicht. Wohingegen die Beschriftung brauche ich aber dann, wenn ich in irgendeiner Umgebung Neo nicht verwenden kann, zum Beispiel in meinem BIOS oder so, wenn ich irgendwas eingeben muss. Und dann dachte ich, ah, es ist vielleicht doch ganz gut, die Beschriftung zu haben, wie sie tatsächlich ist. Und ab der Betriebssystemebene oder Buddha oder Ebene kann ich ja dann eigentlich schon blind tippen. Ja, das ist richtig so, aber es ist für mich kein Problem in der Praxis. Hast du den Stromverbrauch mal verglichen und gemessen? Mit der Originalen zum Beispiel? Ich habe ihn nicht mit der Originalen verglichen, weil ich glaube ich mittlerweile keine Original-Boards mehr habe. Der Stromverbrauch bewegt sich innerhalb der Spezifikation. Ich glaube, das ist sowas wie 90 mA für diesen Controller unter Last. Und der ist ja permanent ausgelastet, weil er permanent scammed. Also ja, so viel in etwa muss man rechnen, aber das ist ja quasi vernachlässig war für die Umgebungen, in denen ich die Tastatur verwende. Hier vorne noch. Was ich beim debouncing nicht ganz verstehe, ist, warum machen andere Leute eigentlich dieses Ding, wo sie tatsächlich warten, bis das debouncing zu Ende ist? Das ist eine super Frage. Und ich glaube, wenn man mal eben ein bisschen Google, wie man debouncing macht, findet man das zuerst. Und das funktioniert ja. Also ja, ich glaube, da sind die Leute einfach nicht so tief in die Materie eingestiegen. Ich kann es mir auch nicht so richtig erklären, weil es hat abgesehen davon eigentlich kein Vorteil, den ich erkennen kann. Okay. Jetzt bin ich auch noch für was anderes Neugier entbrich, nämlich Emacs kann jetzt so schnell auf die Caps Lock-Taste antworten, aber kann Emacs tatsächlich auch Zeichen malen so schnell? Ja, ich habe das tatsächlich, ich habe das hier nicht im Vortrag angegeben, aber ich habe mit dem iPhone, das hat ja so eine 240 FPS-Kamera, habe ich das auch noch mal optisch nachgemessen und das scheint zu stimmen. Also das Problem einer 240 FPS-Kamera ist natürlich, dass sie nicht fein genug aufgelöst ist, um wirklich solche Aussagen treffen zu können, weil du eben ein Frame ist eben vier Millisekunden wert quasi und vier Millisekunden ist furchtbar viel für die Werte, mit denen wir hier agieren. Das heißt, mit einer 1000 FPS-Kamera könnte ich noch genauere Messungen anstellen, hat aber gerade keine da. Aber es scheint alles so zu passen. Also es scheint wirklich nicht nur die Verarbeitungsletten-C so gering zu sein, dass sie vernachlässig war. Zumindest innerhalb dieser Granularität von den vier Millisekunden, die ich messen konnte. Okay. Okay, hier kam jetzt gerade irgendwie drei Fragen genau gleichzeitig hoch. Will irgendjemand direkt antworten oder soll man einfach rein nachgehen? Ich glaube, hier vorne war eine direkte Antwort. Okay. Ja, eine Anschlussfrage. Wo wir es gerade vom D-Bouncing hatten, es gibt ja auch noch dieses Analog-D-Bouncing, quasi indem man einfach noch einen Teil aus deiner Ansicht nach Vor- oder Nachteile, weil dadurch glättest du ja sozusagen diese Da hast du recht, aber was das effektiv macht ist Warten, nur eben in Hardware. Also ja, der offensichtliche Nachteil, also der Vorteil ist, du musst dich in der Software nicht mehr damit rumschlagen. Es sind irgendwie 40-Zeilen-Code, also, ja, es ist nicht so schwer. Aber der Nachteil ist eben, du verbrauchst deutlich mehr Hardware beim Bauen. Also deine Platine wird deutlich komplizierter und effektiv wartest du damit auch nur. Also es hat keinen Vorteil. Wenn ich es richtig verstanden habe, hast du ja Ghosting ganz eliminiert durch die Dioden. Das ist korrekt, ja. Hast du beim USB-Übertragen des Keystrokes auch die 6-Key-Beschränkungen eliminiert? Nein, hab ich nicht. Das liegt einfach daran, dass ich in meinem persönlichen Anwendungsgebrauch mir nicht vorstellen kann, wie ich jemals mehr als 6 Tasten gleichzeitig drücken müsste. Und außerdem gibt es einen konkreten Vorteil, wenn man quasi das einfache Verfahren macht und das ist nämlich, dass die Implementation deutlich einfacher wird. Denn dein BIOS verwendet den quasi runtergebrochenen, einfachen Subset vom USB-Tastaturstandard und dein Betriebssystem kann den auch. Das ist, woher diese 6 Tastenlimitation kommt, also 6 Tasten und einen Modifierzustand. Und wenn man jetzt wollte, also wenn man die umgehen möchte, dann musst du eben einen separaten USB-Hit-Modus implementieren und dann implementieren, dass die Tastatur zwischen den verschiedenen Konfigurationen wechseln kann. Und wenn man das machen würde, ist beim Buten, hast du am Anfang den limitierten Modus, dann startet dein Betriebssystem und schaltet sie in den vollen Modus. Das hatte für mich so wenig greifbare Vorteile, dass ich mir gesagt habe, den Aufwand mache ich mir nicht. Insbesondere weil es halt deutlich mehr Code auch ist und deutlich mehr Zeug was kaputt gehen kann und was ich auch mit verschiedenen Betriebssystemen hätte testen müssen. Und so ist es halt einfach, ja du nimmst die Referenzimplementation vom Hersteller und die funktioniert im BIOS und dem Betriebssystem, aber sie hat den Anwendungsfall, weil mit 6-N-Key-Roll-Over funktioniert das absolut nicht. Und deswegen würde mich interessieren, ob das noch möglichst nachzumimitieren, weil die Kinesis-Tastatur war bisher sehr interessant für Stinografen, aber eben nicht benutzbar. Also vielleicht können wir uns da noch unterhalten. Ja gerne, das ist super interessant. Da bist du die erste, die mal wirklich in den Anwendungsfall für mehr als 6-Key-Roll-Over hat, der nicht nur Gaming-Leute sind, die das cool finden. Ja, das freut mich. Da können wir uns gerne nachher noch unterhalten, hier vorne noch eine Frage. Ja. Beim Ghosting habe ich jetzt ein Ding konzeptuell nicht verstanden, nämlich der Chip, der hat doch weniger Kabel, die reingehen, als es Tasten gibt. Korrekt, ja. Das heißt, es gibt irgendwelche Tastenkombinationen, die gar nicht an den Chip mitgeteilt werden können, oder? Doch, doch doch. Also, okay, ja, da muss man jetzt ein bisschen ausholen. Die eine Variante, das Ghosting zu eliminieren, schaust und sagst, es gibt Tastenkombinationen, die nie gültig sind, weil sie Ghosting verursachen würden. Und das ist tatsächlich der hardware sparende Ansatz, Ghosting zu vermeiden, indem man sagt, ich designe meine Matrix so, dass die Tastenkombinationen, die Leute selten drücken würden, so darlegen, dass die, diejenigen sind, die ungültig sind. Das muss man sich auch... Ich habe da noch einen Link in der Folie drin stehen, wo ein sehr guter Blogpost beschreibt, wie man so eine Matrix designen würde. Ich würde dir raten, durchzulesen, weil danach ist wirklich auch alles klar. Ich kann das jetzt nicht in halb von einer Minute hier erklären. Aber der Punkt ist eben, mit den Dioden kannst du es wirklich so machen, dass alle Tasten Kombinationen verfügbar sind, ohne dass es Ghosting gibt. Okay, danke. Hier vorne war noch eine Frage. Direkt hinter dir? Wenn ich mir jetzt so eine Modifikation kaufen wollte, oder das... Ich hol mir quasi von dir deine Pläne, schick die irgendwo hin. Was ist denn insgesamt der Preispunkt? Gute Frage. Ich habe alles, was du brauchst, um das zu machen, veröffentlicht. Also es gibt es unter github.com slash kinx-project, ist auch auf den Folien verlinkt natürlich. Ein bisschen das Problem ist, dass man bei Oshpark nur in Multiplen von 3 bestellen kann. Das heißt, du kannst ja nur immer 3 Keyboard Controller bestellen und 3 USB Hubs. 3 Keyboard Controller kosten 162 Dollar. Die USB Hubs kosten irgendwie nur 50 Dollar. Das heißt, das wäre der Platinenpreis, sofern du nicht eine Gruppenbestellung mit anderen Leuten machst. Und der Komponentenpreis bewegt sich für beide Bills jeweils 3 Stück bei ca. 50 Euro. Du brauchst natürlich noch Werkzeuge, also einen guten Lötkolben und so weiter, wenn du das alles noch nicht hast, da muss man noch ein bisschen mehr ausgeben. Aber klar. Okay, für eine letzte Frage haben wir noch Zeit. Hier vorne? Habe ich das richtig verstanden? Das einzige, was verhindert, ist, dass man mehr als 6 Tasten auf einmal drücken kann, Software ist. Das ist korrekt, ja. Gut. Dann, wie immer, das Speaker vermutlich wird nicht sofort weggebieben, sondern ist noch da. Ihr könnt gerne noch mal fragen. Noch ein letztes Mal. Vielen Dank. Das war super informativ.