Die perfekte USB-I2C-Bridge

TL;DR: Ich habe sie noch nicht gefunden und mich beschleicht das Gefühl, dass ich selbst eine (weitere, nicht perfekte) bauen muss.

Aber erst einmal auf Anfange: Mangels halbwegs flotter Alternative habe ich Libs in Python und C# (ein paar fixes stehen noch aus) um mit dem MCP2221 von Microchip zu sprechen.

Der Chip ist einfach und macht auch ungefähr, was er soll. Nur leider ist er – nicht nur aufgrund der natürlichen Beschränkung von USB HID – verdammt langsam. Speziell wenn es um Standardaufgaben wie Register lesen geht. Das ist ein richtig großer Zeit- und Performancefresser, denn: man muss es „kleinteilig“ durchführen: Register an den Controller schicken ist ein Befehl, auf den geantwortet wird, dann muss man den Lesebefehl senden (auf den auch wieder geantwortet wird) und anschließend muss man für jeden 60-Byte-Chunk der gelesenen Daten auch wieder lesen und auf die Antwort warten. Ich bin mir nicht ganz sicher, ob die Antwort im gleichen oder nächsten USB-Interrupt-Zeitschlitz kommt, aber im dümmsten Fall würde das bei einer ein Chunk großen Leseanforderung 2+2+2 ms bedeuten. Bei 20 Registern (manche Chips lassen das Lesen im Block nicht zu, durchaus aus guten Gründen) wären das 120 ms. Dann war’s das mit 10 Refreshes pro Sekunde – zugleich stottert das UI, wenn man die Kommunikation nicht in einen anderen Thread auslagert. Alles großer Mist. Im Datenblatt sind zudem Fehler u. a. in der Protokollbeschreibung und der einzige Kontakt bei Microchip (immerhin, sie haben geantwortet, was ich nicht erwartet hätte) hat sich hinter seiner NDA versteckt – obwohl die erfragten Infos teilweise schon im (von Microchip geschriebenen) Treiber für Linux stecken.

In der Hoffnung, dass es andere Hersteller besser machen, habe ich mir einen CP2112 von Silicon Labs geholt. Silabs hat einige Dinge deutlich besser gemacht – neben den deutlich höheren Bustakten (> 1 MHz) es gibt einen Befehl (und Konfiguration), der Leseanfragen deutlich verkürzt. Mit aktiviertem „Automatically send read response“ lässt sich ein Register mit n byte Länge am Chip mit Adresse a wählen und die Antwort der Länge l wird ohne weitere WriteReports an den Controller zurückgesendet. Im Schlimmsten Fall dauert der Lesen eines Chunks 2 ms. Beide Baumen Hoch!

Tja, wenn sie nicht in anderen Situationen ziemlich verkackt hätten. Hat man den auto read response an und möchte mit einer I2C-Adresse sprechen, die es auf dem Bus nicht gibt, läuft man ohne Threading in einen Deadlock, da es einfach keine Antwort vom Controller gibt und die ReadReport-Methode blocking ist (auch das Setzen des read timeout und retry count bringt nichts). Gerade beim I2C-Detect ist das ziemlich bescheiden. Richtig bescheiden ist an dieser Stelle auch, dass man keinen „Klingelstreich“ (Start, Adresse auswählen, Stop und einfach nur Auswerten, ob ein oder kein ACK kam) machen kann. Man muss immer mindestens ein Byte lesen. Das kann bei manchen Devices für Ärger sorgen. Gleichzeitig habe ich es nicht geschafft, bei Adresse 0 zu „klingeln“. Obwohl diese, gerade wenn man einen SMBus auf dem Tisch hat, wichtig ist.

Ja, das kann man alles umschiffen, aber wiederum zulasten der Performance. Dabei wäre alles super einfach in der Firmware zu implementieren. Anderes Manko des Chips: Man kann höchstens 512 Byte am Stück lesen und nur 61 (?) Byte am Stück schreiben. Warum nur?

FTDI FT232H (und andere). Kein HID, also muss man sich entweder mit einer DLL von FTDI herumschlagen oder mit LibUSB/WinUSB herumbasteln (Tolle Projekte aber da man Zadig verwenden muss, ist es kein wirkliches Plug & Play mehr. Was mir an der Sache überhaupt nicht gefällt: Obwohl man für das beste Benutzererlebnis die DLL von FTDI benutzten muss, ist es nötig, die MPSSE-Pakete selbst zusammenbasteln. Gleichzeitig gibt es beim Initialisieren anscheinend Glitches auf den Busleitungen und zwischen Start condition, Adressierung und Stop condition habe ich bei ersten Tests wahnsinnig große Zeitlücken gesehen. Ich habe mich nicht wirklich intensiv damit auseinandergesetzt, aber bis jetzt hat mich das elendige Treibergeschwurbel aktiv davon abgehalten, Code dafür zu schreiben.

WCH CH341A: Ein Kit liegt hier und ich habe aus Anwendersicht erste Tests (mit einem EEProm) durchgeführt. Sieht nicht ganz schlecht aus. Wie der FT232H ist es kein USB-HID und man darf wieder mit der bereitgestellten DLL oder anderen Libs basteln. Ein Bastelkollege hat sich der Sache schon angenommen. Großes Problem: Alles aus erster Hand ist nur auf chinesisch. Da ich auf der Website nix lesen kann, ist sie auch nicht verlinkt. Englische Dokus kommen m. W. nur aus der Community. Muss nicht schlecht sein, aber es riecht halt alles ein bisschen arg bastelig.

Von Cypress habe ich mal ein PSoc4-Devkit (so ein Stick) mit Kitprog USB bekommen, der auch sehr schnell I2C sprechen kann. Das Teil hat sich aber durch mehrere Dinge sehr schnell disqualifiziert: Den Treiber gab’s nicht einzeln, eine Doku zum Protokoll glaube ich auch nicht und das Teil hat sich extrem schnell so stark verschluckt, dass man die Hardware neu starten musste.
Es gibt noch z. B. den CY7C65211, allerdings ist mir in freier Wildbahn noch kein Devkit über den Weg gelaufen und ich hatte mit einem anderen USB-Chipsatz schon ein bisschen Probleme, was Treiberstabilität (irgendein USB-UART-Wandler, man konnte den Port öffnen, aber es gingen keine Daten durch). Ein paar haben sich auch ziemlich empfindlich gegenüber Störungen von außen gezeigt. Ob es der Chip oder die externe Beschaltung war, ließ sich nicht mehr richtig rekonstruieren, aber da haben doch ein paar Bauteile dicke Backen gemacht.

Alternativen? Da gäbe es noch den Buspirate von Dangerous Prototypes. Für den Entwickler-Tisch ok, aber für den ganzen Rest einfach zu groß. Zudem bis jetzt keine Single-Chip-Lösung eher ein USB <> UART <> irgendwas-Wandler

Ok, wenn wir schon beim Entwicklertisch sind – Aardvark von TotalPhase. Macht man da einmal den Deckel auf (zumindest den, den ich mal auf dem Tisch hatte), sieht man nix anderes als einen USB <> UART + AVR. Zugleich konnte man ihn nicht standalone verwenden, sondern braucht(e) eigentlich immer den ziemlich klobigen Levelshifter. Die Software ist fummelig und instabil, wobei ich nicht herausgefunden hab, ob es nicht vielleicht auch die Hardware war. Hab das Teil auf jeden Fall sehr schnell wieder zur Seite gelegt. Für meine Begriffe ist das Teil nicht seinen Kosten gerecht.

Was wäre da sonst noch? TI? Die hatten IIRC mal etwas im Programm aber das war entweder ziemlich lausig oder zumindest für Normalsterbliche faktisch nicht verfügbar.

Sonst fällt mir nicht mehr viel ein. Außer, dass ich schon vor längerer Zeit die Idee hatte, selbst einen USB<>irgendwas-Wandler zu bauen. Leider ist es bis jetzt in der Planungs-Featuritis hängen geblieben. Mal grob, was ich mir vorgestellt habe, was es können muss^Wsoll:

  • GPIOs + IRQs, PWM, …
  • ADCs
  • SPI
  • I2C
  • OneWire
  • SMI/MDIO (clause 22/45)
  • UART + RS485

Wir brauchen mehr Cyber!

Was für ein Skandal. Kaum werden Daten von Politikern „gecybert“, „doxed“ und ins Netz geblasen, ist es ein Angriff auf die Demokratie und es müssen Gesetze gemacht, Behörden vergrößert und Qualitätssiegel eingeführt werden.

Was war bei den Datenskandalen zuvor, bei denen primär „normalsterbliche“ betroffen waren? Da hat es offenbar keinen gejuckt, weil einfach niemand von den „wichtigen“ betroffen war!?

Oder was war mit der mehrfach zerlegten Wahlmeldesoftware? War die lausige Security dort nicht viel mehr der Wegbereiter für Angriffe auf die Demokratie? Wo war Cyberhorst da, um Leute einzustellen, die es besser machen und auch noch ein Siegel draufkleben?

Aus dem aktuellen Fall sind nur wenige Details bekannt und werden es wahrscheinlich auch nicht viel mehr werden. Für mich hört es sich aber am ehesten danach an, als hätten viele der betroffenen ihren persönlichen Datenschutz nicht im Griff. Schlechte Passwörter, jeden Mist anklicken und empfindliche Daten auf den Computern anderer Leute (vulgo in der Cloud).

Was helfen uns Gesetze, wenn die Leute noch immer zu blöd sind, sichere und vor allem unterschiedliche Passwörter für unterschiedliche Dienste zu verwenden? Was bringt stärkere Behörden, wenn die Cracker unterm Radar fliegen (well, hackers gonna hack)? Was bringen uns irgendwelche teuren Qualitätssiegel, wenn diese nur Momentaufnahmen sind und man als User keine Chance hat, die Integrität und Unterschiede der untersuchten und präsentierten Software zu prüfen?

Für mich ist alles nur ein verdammtes Strohfeuer, das unser Politiker da gerade anzünden. Und Geldverschwendung obendrein.

Da wäre es vermutlich sinnvoller, einen Internetführerschein und Grundkurse in Sachen Internet- und Datensicherheit einzuführen.

Ich meine klar, jeden kann es mal erwischen – nur wenn man sieht, wie blind manche herumrennen, muss man Angst und Bange sein.

Hierzu eine kleine Anekdote aus meiner Hochschulzeit: eines Tages kam eine Mail vom Rechenzentrum, dass gerade Phishing-Attacken auf Mitglieder der Hochschule liefen, die durch eine fremde gekaperte WordPress-Installation durchgeführt wurde und man auf keinen Fall den Link klicken solle und sich schon gleich gar nicht dort einloggen solle. Auch war ein Muster einer solchen Mail angehängt. Soweit, so gut. Nur war das kein Bild, kein CopyPasta, sondern die Originalmail. Mit funktionierenden Links.

Auf freundlichen Hinweis hat der Admin die Mail dann zurückgezogen und erneut „sauber“ geschickt. Es ist nicht bekannt, wie viele zumindest auf den Link geklickt haben…

Um nun für User einen Unterschied zu machen: Wo es früher noch hieß, dass Passwörter oft geändert werden sollten und kryptisch sein müssen, zum Beispiel, indem man Sätze verendet und Leetspeak o. ä. appliziert – so wird aus dem Satz „Das ist das Haus vom Nikolaus“ das Passwort „DidHvN“ oder „D!d4vN“, hat einer der alt eingesessenen Passwortevangelisten (mir fällt der Name gerade nicht ein) seine damalige Empfehlung korrigiert. Wenn ich mich richtig erinnere ist es besser, einfach den kompletten Satz zu verwenden, „Das ist das Haus vom Nikolaus“. Denn: So ein Passwortcheck ist mein Mastermind, das sagt „Zeichen ist vorhanden aber an der falschen Stelle“, sondern einfach nur „true“ oder „false“. Klar, mit Wörterbuchattacken kann man immer noch arbeiten, aber auch die werden bei langen Passwörtern langsam schwierig; und ja, ein Beobachter hat es bei „korrigierbaren“ Passwörtern auch einfacher und kann sich den Sinn erschließen. Aber da gilt die Regel: Lass dir nicht über die Schulter schauen!

Das Problem an häufigen Passwortänderungen ist, dass sie dann entweder trivial oder unter die Tastatur geklebt werden. Lieber ein anständiges Passwort, das zwar nicht so oft geändert wird aber dafür auch nicht irgendwo notiert wird.

Zum Thema Cloud bin ich immer noch der Meinung: „(wenn überhaupt:) Traue nur einem Computer, den du aus dem Fenster werfen kannst“ und: „Es gibt keine Cloud, es gibt nur Computer anderer Leute“ (ok, war schon oben). Sprich: Man kann nur die Kontrolle über die Daten haben, die man bei sich hat. Seid Datensparsam, lagert Daten im öffentlichen Raum, die auch jeder sehen darf.

Auch müssen sich die Firmen – und da schweife ich mal in Richtung Hacking und Datenlecks ab – endlich mal ändern. Ich hatte es bis jetzt nicht nur einmal, dass auf eine Meldung einer Sicherheitslücke entweder gar nicht oder mit „kann gar nicht sein“ reagiert wurde. Teilweise wurde erst nach einem Proof of Concept Initiative ergriffen. Und dann nicht mit „ja, wir haben ein Problem, wir analysieren es“, sonder mit „wie haben Sie das gemacht??ß?sz?“. Denen hat also nicht der Hinweis „ihr habt da und da ein Problem“ gereicht, sondern brauchten auch noch eine Erklärung.

Das dreisteste, was ich dabei erlebt hatte war dann ein Admin, der mich nach der „Sicherheitsberatung“ und dem Schließen der Lücke durch deren Enwicklungsdienstleister bat, den Fix zu verifizieren. Anhand der Blackbox. Auf meine Antwort, dass das ohne Einblick in die Quellen sinnlos wäre und dass ich ihm keinen Code-Review schenken werde, kam nichts mehr zurück.

Liebe Firmen, nehmt bitte endlich Meldungen zu Bugs und Vulnerabilities ernst und schaut erst einmal selbst nach, wenn ihr Hinweise bekommt! Viele, die etwas entdecken, erwarten keine Gegenleistung, dafür dürft ihr aber nicht erwarten, den A… hinterhergetragen zu bekommen.