Schlagwort-Archive: MCP2221

Die perfekte USB-I2C-Bridge

Veröffentlicht am von

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

Nachtrag vom 16.12.2019:
Christoph hat mich auf I2C-MP-USB von Thomas Fischl aufmerksam gemacht – vielen Dank für den Hinweis – das Teil landet auf der Bastelliste und wird sobald wie möglich getestet.

MCP2221 mit C# – aber schnell.

Veröffentlicht am von

Nachdem die Python-Lib ganz gut funktioniert (ein paar Bugs habe ich bereits gefunden, Fixes stehen noch aus), wollte ich die Implementierung auch in C# umsetzen. Zwar gibt es von Microchip schon eine Lib, allerdings ist diese nicht Native und auch nicht open source und dadurch auf bestimmte .NET-Versionen eingeschränkt.

Um das Rad nicht neu erfinden zu müssen, wollte ich zumindest für die USB-HID-Kommunikation eine fertige Bibliothek verwenden. Bei der Suche bin ich auf HidLibrary gestoßen, die zwar nicht mehr so aktiv gepflegt wird – aber das muss nicht unbedingt viel bedeuten. Ja, auch Software kann mal fertig sein 😉

Heruntergeladen und die ersten Funktionsblöcke geschrieben. Als ersten Test habe ich i2c_detect portiert und laufen lassen. Für 127 Adressen dauert der Scan knapp über 17 Sekunden. Mit Microships MCP2221 I2C/SMBus Terminal sind es nicht ganz 11 Sekunden und mit meiner Python-Lib unter 0,7 Sekunden. Was ist da los?

Im ersten Schritt habe ich mit System.Diagnostics.Stopwatch die Schreib und Lesezeiten gemessen – jeweils braucht die Lib im Schnitt 21 ms, für jeden Probe einer Adresse sind zwei Schreib-/Lesezyklen erforderlich, kommt kein ACK für eine Adresse ist ein weiterer Zyklus für ein i2c_cancel erforderlich. Macht für einen Proben einer nicht genutzten Adresse ca. 126 ms, für 127 Adressen sind das bisschen über 16 Sekunden – kommt also hin.

Visual Studio kann Performance-Analysen und der schuldige ist schnell gefunden:

Es hängt also am HidLibrary.HidDevice::IsConnected bzw. EnumerateDevices.

Auf GitHub gibt es (Stand November 2018) auch Bugs zum Thema Performance.

Die Tickets existieren seit 2011, 2014 und 2016 – also besteht offenbar kein Interesse, das zu fixen. Ein User namens kaczart hat eine Lösung gefunden.

Um im ersten Schritt nicht zu viel zu verbasteln, habe ich einfach mal „IsConnected“ ein einstweiliges „return true;“ verpasst. Nun benötigt ein Schreibvorgang um die 3,4 ms und ein Lesevorgang knapp 2,3 ms. Unterm Strich dauert der Scan nun 2,5 Sekunden. Besser aber noch nicht gut genug.

In anderen „Projekten“ hat mir in Sachen Timing gerne mal der Debugger in die Suppe gespuckt, also mal als Release ausgeführt und Tadaa: 0,78 Sekunden. Fast so schnell wie die Python-Implementierung.

Um es nochmal genau zu wissen habe das „return true;“ aus HidDevice::IsConnected wieder entfernt und als Release ausgeführt: 14 Sekunden.

Der Hund liegt also definitiv in der Lib begraben. Workaround, Fixen, nach Alternativen suchen oder selber machen (oder einfach eine Weile abhängen lassen und etwas anderes machen)?

Mal sehen.

Was der MCP2221 sonst noch kann

Veröffentlicht am von

Es gibt Dinge, die Zeit verschwenden, nicht richtig funktionieren und schlussendlich nicht einmal einen Sinn ergeben. Manche nennen das sogar Hobby.

Nachdem mir im Zuge der MCP-USB-Bridges keine Python-Implementierung so richtig gefallen habe, bin ich gerade dabei, selbst eine zu schreiben und mehr oder weniger ausgiebig zu testen.

GPIOs, ADC funktionieren so wie es aussieht genz gut, heute war der DAC dran.
So richtig toll ist er nicht, aber besser als nichts. Um Seine Leidensfähigkeit zu zeigen, musste ein kleines Beispiel her.

Warum nicht einfach so etwas ähnliches wie einen Hellschreiber implementieren? Nur halt extrem ranzig.

In Python geht das ordentlich schnell und einfach:

txt = "Hallo Welt!"

vals = [22,20,18,16,14,12,10,8]

meh = []
for c in txt:
    meh.extend(font[ord(c)-32])
    meh += [0]

for col in meh:
    for reps in range(4):
        curcol = col
        for y in range(8):
            if curcol & 1 == 1:
                dev.dac_setvalue(vals[y])
            else:
                dev.dac_setvalue(0)
            curcol >>= 1
            time.sleep(0.003)

Die Font liegt in als Liste vor, die alle wichtigen Zeichen ab dem Leerzeichen enthält. Vals beinhaltet die Analogwerte der jeweiligen Bits der Zeichen (in der Höhe). Der Text wird sprichwörtlich in eine Bitmap umgewandelt und einfach über den DAC rausgejagt. Damit die Zeichen etwas besser lesbar sind, werden sie 4 mal wiederholt. Die kurze Pause ist nötig, weil sich sonst der MCP verhaspelt.


Ist das nun Kunst oder kann das weg? 😉