Liest und schreibt das Konfigurations-EEPROM von FTDI-USB-Serial-Chips über libusb — USB-Kennungen, Descriptor-Strings und die Funktion der CBUS-Pins. Eine Treiberschicht reduziert die Unterstützung eines neuen Chips auf eine Klasse.
Was es tut
Jeder FTDI-USB-Serial-Chip trägt ein kleines Konfigurations-EEPROM mit der
USB-Vendor- und Product-ID, den Strings für Hersteller, Produkt und
Seriennummer, den Einstellungen zur Busversorgung, der Signalinvertierung und
der Funktion der CBUS-Pins. usbprog dekodiert dieses EEPROM, gibt es aus,
schreibt ein Rohabbild zurück oder ändert einzelne Einstellungen über ihren
Namen:
usbprog list # angeschlossene Geräte und der zuständige Treiber
usbprog props # Einstellungen, die das Gerät kennt
usbprog info # aktuelle Konfiguration, dekodiert
usbprog set serial=BENCH-04 # eine Einstellung ändern
usbprog erase # zurück auf die Werkseinstellungen des Chips
Auf einem Prüfstand ist das der Unterschied zwischen einer Schublade voll identischer Adapter und Geräten, die jeweils eine stabile Identität melden — so kann eine udev-Regel einer Vorrichtung bei jedem Anstecken denselben Geräteknoten zuweisen.
Eine Treiberschicht statt einer Neufassung
Das Werkzeug erledigt dieselbe Aufgabe wie das bekannte ft232r_prog, aber in
modernem C++ und hinter einer Treiberschnittstelle: Eine weitere Chipfamilie
bedeutet eine zusätzliche Klasse statt eines Umbaus am Werkzeug. Zwei Treiber
sind derzeit enthalten — ft232r für FT232R und FT245R mit ihrem internen
128-Byte-EEPROM, gegen echte Hardware getestet, und ein experimenteller ftx
für FT230X, FT231X und FT234XD.
Es spricht direkt mit libusb-1.0 und benötigt weder libftdi noch FTDIs
proprietäre D2XX-Bibliothek. Unter Linux hält der Kerneltreiber ftdi_sio die
Schnittstelle belegt, deshalb lässt usbprog sie von libusb für die Dauer eines
Kommandos abhängen; der Kernel bindet sie danach wieder an, und
/dev/ttyUSB0 kommt von selbst zurück.
Nicht raten
Ein falsch geschriebenes Byte im EEPROM macht aus einem funktionierenden Adapter
Elektroschrott. Vor dem Schreiben prüft usbprog deshalb die selbst berechnete
Prüfsumme gegen den aktuellen Inhalt des EEPROMs. Stimmen beide nicht überein,
versteht das Werkzeug das Layout dieses Chips nicht und verweigert den
Schreibvorgang, statt zu hoffen. Genau diese Prüfung macht den experimentellen
FT-X-Treiber neben dem getesteten überhaupt vertretbar.
Tests
Die Unit-Tests decken die EEPROM-Codecs ab und kommen ohne Hardware aus — sie laufen gegen ein Werksabbild, das von einem echten FT232R ausgelesen wurde, und genau das legt Prüfsummenalgorithmus und Bytelayout fest. Die Codecs, bei denen ein Fehler auf dem Chip eines Anwenders landet, liegen über 95 % Line Coverage; der libusb-Transport braucht ein echtes Gerät und das CLI ist über einen Smoke-Test in der CI abgedeckt, beide zählen deshalb nicht in diese Zahl.
Gebaut mit CMake gegen einen C++20-Compiler. Getaggte Releases enthalten Binaries für Linux (x86_64, arm64) und macOS (arm64) mit statisch gelinktem libusb. GPL-2.0.