Erfahrungen mit USB/seriell-Konverter

Hallo NG,

mal eine Frage an die Systemprogrammierer unter Euch: Laptops mit serieller Schnittstelle sind mittlerweile ja schon schwirig=20 zu bekommen, trotzdem setzen die Hersteller von=20 Automatisierungskomponenten weiterhin flei=DFig auf die serielle=20 Schnittstellen zu Programmieren ihrer Ger=E4te.

Konnte schon jemand Erfahrungen mit einem USB/Seriell-Konverter=20 (z.B. ALLNET ALL0178 - USB-Adapter) sammeln? Wie vert=E4gt sich eine solche Komponente mit der Software?

--=20 Mit freundlichen Gr=FC=DFen Mark Schaffrath

Reply to
Mark Schaffrath
Loading thread data ...

Das dürfte daran liegen, daß Microcontroller mit einer bequem programmierbaren USB-Schnittstelle noch nicht allzu lange am Markt sind, und bei weitem noch nicht die Peripherievielfalt bieten wie Controller mit konventioneller, serieller Schnittstelle. Solange die Anwendung im Vordergrund steht, ist USB daher meist sehr schnell aus dem Rennen. Ein weiterer Hinderungsgrund ist die fehlende bzw. bei USB nur mit erheblichem Zusatzaufwand zu realisierende galvanische Trennung.

Hängt sehr stark von der Programmierung der konkreten Software ab.

Solange diese über die offiziellen Betriebsystemfunktionen auf die Schnittstelle zugreift, ist das weitestgehend transparent. Hier kann Dir nur noch einen Strich durch die Rechnung machen, daß eine Auswahlbox im Konfigurationsdialog fest auf COM1/COM2 verdrahtet ist und den weiter oben eingebundenen USB-Umsetzer einfach nicht anbieten will.

Sobald direktes Ansprechen der seriellen Schnittstellenhardware oder gar spezielle Gerätetreiber ins Spiel kommen, hast Du aber verloren. Dies wird von den USB/seriell-Umsetzern nicht emuliert, sie sind auf dieser Ebene vollkommen anders anzusprechen als eine konventionelle serielle.

Hergen

Reply to
Hergen Lehmann

Ich hab noch nichts gefunden, was dauerhaft und verlässlich läuft. Zum mal gucken/konfigurieren scheinen alle zu taugen, aber um wirklich verlässlich Bedienterminal zu spielen, sind sie wohl kein Ersatz für 'ne echte Serielle.

Ich hab bisher Konverter auf der Basis von Prolific-, FTDI- und Silab- (cygnal)-chips getestet - leider verraten die Hersteller der Konverter nur sehr selten, welchen Chip sie einsetzen. In meiner Testsammlung fehlt mir noch eine Texas-Lösung. Als Testsysteme dienten W98SE-, W2K- und XP-Systeme - ca. gut 10 völlig unerschiedliche Systeme, die im Produktiveinsatz in der Softwareentwicklung für embedded Systeme ohne weitere Probleme genutzt werden. Und einige weitere Notebooks, über deren Konfiguration ich wenig weiss - hauptsächlich Rechner von Kunden, die auch das Problem der fehlenden Seriellen hatten und der Not gehorchend relativ experimentierfreudig waren.

Genutzt hab' ich stets den zum Kovreter gehörenden, mitgelieferten VCP-Treiber (virtual com port), d.h. ich hab die Konverter mit den gleichen API-Funktionen wie eine echte serielle Schnittstelle betrieben.

Aus Softwaresicht am solidesten lief Silab - lediglich einige Default-Parameter des VCP-Treibers sind ungewöhnlich gesetzt. Viele Anwendungen stolpern halt darüber, weil deren Programmierer nicht alle Parameter setzen, sondern sich auf passende Defaults verlassen. Macht ja auch zu viel Arbeit, ggf. noch ein Nutzerinterface für die Betriebsparameter zu erstellen :-) (wie man am Windows-Dialog für die Comport-Eigenschaften sieht: Baudrate, Stopbits,Parity, Handshake, damit erschöpft es sich. Wenn man sich dann den DCB (Windows-API) anguckt, weiss man, dass noch für viele andere Eigenschaften Defaultwerte existieren müssen. Nicht zu reden von weiteren Eigenschaften, wie z.B. Timeouts, die dann selbst von den eigentlich wohlmeinenden Programmiereren gelegentlich übersehen werden).

Leider habe ich nur einen Silab-basierten Adapter gefunden - und der hat wohl ein Hardware-Problem beim Abziehen und erneutem Aufstecken der seriellen Seite. Mehr als gelegentlich - in ca. 30% der Steckvorgänge - scheint der USB-Controler im Konverter dabei abzustürzen. Dann muss man halt das Comport schliessen, den Adapter aus dem USB-Port ziehen und erneut einstecken. Unhandlich, aber für kontinuierlichen, stationären Einsatz vermutlich tauglich.

An zweiter Stelle kommt FTDI - ich kann den Treiber zwar Ruckzuck in einen Deadlock bringen, d.h. Schnittstelle klemmt, Anwendung kann nicht nicht beendet werden, meist hilft noch nicht mal abziehen des Konverters vom PC, sondern nur ein Reboot des PCs - aber wenn man nicht weiss, was man tun muss, um das Problem zu forcieren, zeigt es sich das Problem meistens nicht (toi, toi, toi). Für gelegentliche Einsätze scheint eine FTDI-basierte Lösung tauglich. Geärgert hat mich, das FTDI trotz detaillierter Problembeschreibung kein Interesse an einer Problemlösung hatte.

Prolific hatte ich als ersten Adapter und nur in einer relativ alten Version im Einsatz - und hab' beschlossen, solange die Finger davon zu lassen, bis mir jemand glaubwürdig berichtet, das die Dinger jetzt problemlos laufen. Zugegeben, ich war vielleicht etwas leichtsinnig, schliesslich sollte man unbekannte Software nicht ohne vorhergehende Tests gleich auf Produktivsystemen installieren - aber wer mir mein Entwicklungssystem so abschiesst, dass ich letztlich nur noch eine Neuinstallation als Lösung sehe, der hat nicht gerade einen Vertrauensvorschuss gewonnen. Es schienen gravierende Probleme im Treiber vorzuliegen, die ich auf Grund der Absturzhäufigkeit noch nicht mal ansatzweise auf Betriebszustände der Schnittstelle zurückführen konnte.

Wenn jemand Erfahrung mit einem Adapter auf TI-Basis hat - ich bin sehr interessiert! Sowohl an einer Bezugsquelle (neben dem Eva-Board), als auch an Erfahrungsberichten!

Andreas

Reply to
Andreas Hadler

Andreas Hadler schrieb:

Die USB->seriell Teile haben generell Timingprobleme. Gerade die EIB-Koppler mit serieller Schnittstelle kommen nicht damit zurecht. Es gibt aber auch PCMCIA-seriell Karten. Ich hab eine von Silicom sehr günstig bei ebay gekauft. Hier noch ein google-goups Link aus dse:

formatting link
Andy

Reply to
Andreas Weber

PolyTech Forum website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.