Hallo NG,
mal eine Frage an die Systemprogrammierer unter Euch:
Laptops mit serieller Schnittstelle sind mittlerweile ja schon schwirig
zu bekommen, trotzdem setzen die Hersteller von
Automatisierungskomponenten weiterhin fleißig auf die serielle
Schnittstellen zu Programmieren ihrer Geräte.
Konnte schon jemand Erfahrungen mit einem USB/Seriell-Konverter
(z.B. ALLNET ALL0178 - USB-Adapter) sammeln?
Wie vertägt sich eine solche Komponente mit der Software?
--
Mit freundlichen Grüßen
Mark Schaffrath
On Wed, 1 Dec 2004 22:59:42 +0100, in de.sci.ing.elektrotechnik you
wrote:
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
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
--
Alle konkreten Aussagen sind rein fiktiv. Alle Tatsachenbehaupungen
entspringen der Phantasie. Alle faktischen Aussagen bedürfen der
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:
http://masl.gnomehack.com/?N22621CE9
Gruß Andy
Polytechforum.com is a website by engineers for engineers. It is not affiliated with any of manufacturers or vendors discussed here.
All logos and trade names are the property of their respective owners.