universal.adapter

In letzter Zeit mehrt sich das Auftreten von Geräten, welche sich unter Windows per virtuellem seriellen Port integrieren. In vielen Fällen benutzen diese Geräte einen Chipsatz von FTDI, um die serielle Kommunikation über den USB-Port zu realisieren. Der Mac OS-Benutzer stellt überrascht fest, daß für diesen Chipsatz sogar ein generischer Treiber für Mac OS X (und das auch noch für Intel Prozessoren!) zur Verfügung steht. Auf die erste Installation folgte bei mir Verwunderung: nix passierte.

In meinem Fall handelte es sich bei dem nicht erkannten Gerät um das oben gezeigte NZR SEM LOG16, ein Meßgerät für das sogenannte Energy Monitoring. Die erste Idee, daß der Treiber die Vendor- bzw. Product-ID des Gerätes nicht kannte, führte zur richtigen Lösung. Die Unterstützung des Gerätes läßt sich leicht nachrüsten. Als erstes sollte man sich als root einloggen. Hernach nimmt man sich mittels des Editors seiner Wahl die Datei /System/Library/Extensions/FTDIUSBSerialDriver.kext/Contents/Info.plist vor. Als Mac OS X-Newbie bin ich immer wieder überrascht, daß der Inhalt dieser Property-Files als XML vorliegt (und für mich als XML-Fan ist es natürlich eine positive Überraschung . Für das erwähnte Gerät nimmt man folgende Eintragung vor:

<key>NZR SEM16 USB</key> <dict>     <key>CFBundleIdentifier</key>     <string>com.FTDI.driver.FTDIUSBSerialDriver</string>     <key>ConfigData</key>     <dict>         <key>PortName</key>         <string>SemLog16</string>     </dict>     <key>IOClass</key>     <string>FTDIUSBSerialDriver</string>     <key>IOProviderClass</key>     <string>IOUSBInterface</string>     <key>bConfigurationValue</key>     <integer>1</integer>     <key>bInterfaceNumber</key>     <integer>0</integer>     <key>idProduct</key>     <integer>49632</integer>     <key>idVendor</key>     <integer>1027</integer> </dict>

Wesentliche Elemente, welche man sinnvoll beeinflussen kann, sind folgende:

• der Name des Eintrages (hier NZR SEM16 USB),
• der Inhalt des string Elements, welches dem Element <key>PortName</key> folgt und welches Teil des Namens des virtuellen seriellen Gerätes wird, sowie
• die Inhalte der integer Elemente, welche auf die <key>-Elemente mit den Inhalten idProduct und idVendor folgen und welche die Vendor- und Product-ID des Gerätes enthalten müssen.

Vendor- und Product-ID habe ich übrigens unter Windows ermittelt. Man sollte das Editieren wirklich mit root-Rechten vornehmen und nicht etwa die Rechte des Files selbst ändern, letzteres führt nämlich beim Restart des Treibers zu einer Fehlermeldung und zum Mißerfolg. Der Restart des Treibers (eine sogenannte Kernel-Extension) erfolgt mit den folgenden Kommandes, für deren Ausführung man wiederum root-Rechte benötigt.

kextunload /System/Library/Extensions/FTDIUSBSerialDriver.kext kextload /System/Library/Extensions/FTDIUSBSerialDriver.kext

Nach den Aktionen sollte bei angeschlossenem Gerät ein virtueller serieller Port zu finden sein, bei mir heißt das Ergebnis der Mühen /dev/cu.SemLog16-08002600. Man sieht schön, daß der Name sich durch die Konfiguration beeinflussen läßt, was die Gerät/Port-Zuordnung erheblich vereinfacht, unter Windows rätselt man im Falle mehrerer auf dem FTDI-Treiber beruhender Geräte stattdessen, welcher Port welchem Gerät zugewiesen ist.