Frage zu USB auf RS232C Adaptern

Ja. Daß es überhaupt einen FIFO geben mußte und dessen Größe eine gewisse Rolle spielte, ist allein dem unsäglich miesen Design des "IBM-kompatiblen" PCs zu verdanken und den grenzdebilen OS, die da meist drauf liefen.

Du kannst davon ausgehen, daß alle USB-RS23-Adapter mehr als genug FIFO haben, damit bei allen RS232-üblichen Datenraten nix verloren geht.

Du koenntest dir ja das Datenblatt der Chips darin durchlesen.

In geschaetzten 80% aller Adapter duerfte Prolific sein. In 15% FTDI, die restlichen 5% teilen sich zwei Exoten deren Namem mir gerade nicht einfallen will.

Ich habe nicht den Eindruck das dies von Bedeutung ist. Nicht das es mit den Adaptern keine Probleme gaebe (hoehoe) aber das kommt dann nicht von der Fifo.

Am besten waeren welche die sich korrekt mit einer ID identifizieren koennen. Das sorgt dafuer das du nicht bei jedem reinstecken an einem anderen USB-Port einen neuen Comport bekommst. Das koennen sowohl FTDI wie auch Prolific. Bei letzerem habe ich es aber in der Praxis noch nie gesehen weil Prolific immer in moeglichst billigen Adaptern verbaut wird.

Wenn du vor dem kauf wissen willst was du bekommst dann lade dir vorher beim Hersteller des Adapters die Treiber runter und schau mal rein.

Olaf

Hallo Olaf

bei den billigen Dingern für 3.- bei ebay stehen solche Sachen nicht im Angebotstext.

ich wollte 4 Stück davon in einen USB-Hub stecken und den dann zwischen den verschiedenen Rechnern umstecken damit man nicht jedesmal die Sub-D-Stecker hin- und herstecken muß.

du sprichst in Rätseln: was für Probleme sind denn bekannt?

das verstehe ich jetzt nicht: wenn es beide doch können wie du schreibst!?

bei den billigen Dingern für 3.- bei ebay stehen solche Sachen nicht im Angebotstext.

Gruß

Jürgen

Man kann es auch anders sehen. .-)

Es gibt sicher genug Fifo bei den USB-RS232 Adaptern einfach deshalb weil auf dem USB-Bus die Daten immer in Bloecken und nicht in Einzelbytes uebertragen werden. Und vor diesem Hintergrund muss man geradezu dankbar sein das es auch frueher schon Fifos gab und sie hoffentlich reichlich benutzt wurden. Weil man so immerhin die Hoffnung haben kann das alte Anwendung/Protokolle intelligent genug programmiert wurden um Fifos auszunutzen und nicht mit Einzelbytes Ping-Pong gespielt haben.

Olaf

Du weisst das es auch 4xRS232-USB in einem Gehaeuse gibt?

Noe, eigentlich spreche ich von altbekannten Dingen die schon jeder weiss. :-P

USB ist bLockorientiert mit 1ms Uebertragungszeit. Ausserdem kann ein Slavedevice nichts an den Host senden wenn es Daten hat. Die muessen vom Host abgeholt werden. Das fuehrt zu enormen Timingproblemen bei Anwendungen die einzeln mit den Steuerleitungen der RS232 geklappert haben, und es macht Probleme bei Protokollen wo einzelne Bytes in bestimmten kurzen Zeiten gesendet/erwartet wurden.

Ich der Praxis bedeutet es das viele Dinge problemlos laufen, manche laufen, aber total langsam, und wieder andere gehen garnicht. Manchmal (haengt vom Treiber ab) installieren sich die Adapter auch immer erst ab Com5. Das ist nicht so doll wenn du eine alte Anwendung nutzen willst die nur Com1-4 kennt.

Ach...so und ein Kollege hat mir letztens erzaehlt es gibt wohl jetzt auch ADapter die koennen USB2 (FTDI) und sind dann manchmal schneller. Je nachdem ob sie von deinem Windows als USB2 oder USB1 erkannt werden. Aber noch so schnell wie original RS232.

Die ICs koennen es. Aber nicht unbedingt die Adapter. ES ist dafuer bei manchen Chips ein externes EEPROM notwendig. Das kostet halt ein paar Pfennig.

Da kannst du automatisch davon ausgehen das es sich um Prolific mit Comportproblematik handelt. Wer billig kauft bekommt auch billig.

Das bedeutet uebrigens nicht unbedingt das die nicht funktionieren. Aber wenn du das in den ersten USB-Port deines Rechers steckst dann tauchen COM5-8 auf. Steckst du es in einen anderen Port gibt es COM9-12 usw. Das nervt natuerlich ein wenig.

Olaf

Juergen Kanuff ( snipped-for-privacy@justmail.de):

Probleme treten meist mit spezieller Ansteuerung auf, z.B. DTR als Schaltsignal missbrauchen (PTT beim Funkgerät über DTR steuern) oder aber mit manchen Entwicklungsboards für Microcontroller.

Manche Adapter sind aber auch so schrottig, dass höhere Übertragungs- raten zu Fehlern führen.

Die können es wohl laut Datenblatt aber nicht in der Praxis. Ich habe sehr gute Erfahrungen mit USB2 SERIELL von Reichelt.

Jain, Bei der Geschwindigkeit von USB2 wirst Du bei EIA232 üblichen Bitraten nie in Bedrängnis geraten. Die FTDI-Dinger können aber, ausserhalb der Spezifikation, sogar mehrere MBit/s und da braucht es dann schon größere FIFOs.

Aus Erfahrung kann ich FDTI und Keyspan-Chipsätze empfehlen. Keyspan ist allerdings selten geworden, dafür sind die sehr robust. Prolific funktionieren gut unter sauberen Bedingungen. EMI können die aber nicht ab.

Bei meinem Roboter-Projekt hatte ich den GPS-Empfänger zuerst per Prolific- Adapter angeschlossen (alle echten seriellen Schnittstellen waren schon belegt) und die EMI vom Motor hat den Adapter ständig USB-Resets ausführen lassen, womit natürlich jedes mal die Verbindung zum GPS-Empfänger flöten gibt. Mit meinem guten alten Keyspan-Adapter funktionierte es einwandfrei. Den Prolific hatte ich verwendet, da dieser so ein schön kurzes Kabel dranhängen hatte, da ich nicht groß im Roboter irgendwo unterbringen musste.

Mittlerweile habe ich mir einen Adapterstecker mit FTDI-Chip gebaut (die FTDIs gibt's ja auch einzeln als Chip zu kaufen): Praktischerweise gibt nämlich der GPS-Empfänger seine Daten auch als 5V-Logik aus, neben den üblichen +/-15V (Naja, bei dem Teil eigentlich +/-11,irgendwasV).

Wolfgang

Das kommt darauf an. Wenn da noch HW handshake benutzt wird, biste mit USB jenseits 9600Bd schnell im Gebiet der may-be-Logik.

Das nutzt nix, da USB ohne IR arbeitet und im 1ms Raster (bestenfalls) gepollt wird.

recycled :-)

Saludos Wolfgang

So einen habe ich letztens bestellt - in meinem steckt FTDI:

Bus 001 Device 047: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC bcdUSB 1.10 idVendor 0x0403 Future Technology Devices International, Ltd idProduct 0x6001 FT232 USB-Serial (UART) IC bcdDevice 4.00 iManufacturer 1 ftdi iProduct 2 test iSerial 3 ftE21WML MaxPower 44mA

Also mit Seriennummer, laut Deskriptor USB 1.1, der Produktname "test" spricht allerdings nicht für überzogene Sorgfalt beim Erstellen des EEPROM-Inhalts.

cu Michael

Das kommt auf den Adapter-Controller an. Der FTDI2232 z.B. kann so konfiguriert werden, dass er den kompletten Handshake abwickelt, wenigstens Hardware und X-On/X-Off sind kein Problem. Dessen State Machine ist aber ziemlich flexibel, d.h. komplexere Handshake-Protokolle dürften auch machbar sein.

Das ist egal, da der Controller die komplette Kommunikation, incl. Handshake usw. abwickelt. Wenn man natürlich noch aus DOS-Zeiten wildes Bit Banging auf die Ports der UARTs gewohnt ist, wird das nix. Das was über USB läuft sind nur noch die Inhalte der Puffer. Betrachte die Verbindung über einen USBSeriell-Adapter eher wie eine TCP-Verbindung: Kein exaktes Zeitverhalten, die Übertragung aller Daten in der richtigen Reihenfolge wird schnellstmöglich durchgeführt.

USB ist deshalb nur dann problematisch, wenn man ein definiertes Zeitverhalten braucht.

Wolfgang

Aber wenn ich soweit zugriff auf die Software habe dann kann ich den USB-RS232 Adapter auch gleich in die Tonne treten und im Slave eine vernuenftigen USB-anbindung designen.

Die meisten Leute werden aber solche Konverter kaufen um lange vorhandene Software mit irgendwelchen alten Geraeten zu nutzen, und da steckt durchaus konfliktpotential drin.

Olaf

X-On/Off sollte kein Problem sein, bei HW-HS gibt es noch einige nette Schweinereien.

Ich bin heute mal die Unke:

Und genau da fangen die Probleme an, wenn Du ein bestimmtes RS232 Protokoll fahren musst. HART und 3964R sind so 2 Kandidaten, wo ich Ärger erwarte.

HART geht vermutlich, wenn überhaupt nur schwierig, da da HW Signale auch zum umschalten der Modems verwendet werden.

Es gibt auch Protokolle, die mit höheren Baudraten fahren, alles jenseits 9600Bd wird dann schnell zum Lotto Generator.

Das schlimmste dabei ist, wenns im Labor einwandfrei klappt und beim Kunden es sporadisch in die Hose geht. Es gibt da niedliche Plätze zum debuggen: im Rollgang, am Hochofen, "Flaschenkeller" in der Brauerei, Coca Cola Abfüllhalle, Glasherstellung, Dampferzeuger im KW, Krackturm in 40m Höhe, 900m unter Tage, Papiermaschine, Druckerei, Klärwerk...

Saludos Wolf(UnkeVomDienst)gang

Also entweder nutzt die Software die Schnittstellen auf vernünftige Weise (Kommunikation ausschließlich über die API, kein BitBanging), oder sie greift auf LowLevel-Ebene auf die Ports zu und der Treiber darf zusehen, wie er das transparent abfängt. Letzteres hat noch nie problemlos funktioniert. Und mit ersterem konnte man schon mit nativen UARTs kein hartes Zeitverhalten erreichen (ausser mit speziellen Echtzeit-OS).

Meiner Erfahrung nach (bezieht sich auf einige alte Messaufbauten in der Uni, die ich von 8086 XT-PC auf Core2 gebracht habe) ist es streßfreier, die Kommunikation mit der alten Hardware mit einem kleinen Mikrocontroller zu erledigen (d.h. das alte Programm darauf zu portieren) und dann mit einem dezidierten USB-Controller die Kommunikation mit diesem µC zu erledigen.

Wolfgang

Auch über das API der gängigen OS ist BitBanging möglich. Das Zeitverhalten ist dabei allerdings sowohl durch das USB-Polling-Intervall als auch durch die Latenzen der Task-Scheduler der gängigen OS eingeschränkt. Olle DOS-Software oder Geräte, die eben solche Software am anderen Ende erwarten, können dabei durchaus auf die Schnauze fallen.

Für diesen Quatsch mit allenfalls historischem Wert ist die beste Lösung: Wegschmeißen. Oder sie mit der historischen Software auf entsprechend historischen Maschinen ansprechen.

Für alles andere gilt: Wenn der Programmierer der Anwendung was getaugt hat, wird es funktionieren, nur u.U. unbrauchbar langsam.

Das ist auch eine Möglichkeit. Das Zeitverhalten auf Maschinen nachbilden, die für Echtzeitanwendungen gedacht sind. Das rettet allerdings nur die Geräte mit der bescheuerten RS232-Nutzung, nicht die zugehörige olle Software...

Dafür gibt es QEmu, das man um eine Emulation der alten Hardware ergänzt. Diese Emulation lässt man dann per USB mit dem Interface-µC sprechen. Alles eine Frage, wieviel Arbeit man in den Erhalt alter Software stecken will. Im Fall der Meßaufbauten in der Uni bestand mein Auftrag auch darin, die Software komplett neu zu entwickeln, da die alten Programme die Leute halb in den Wahnsinn getrieben haben.

In einem der Programme, dass sich "Harmonic Analyzer" schimpfte, wurde die Fourier-Transformation anscheinend von jemandem geschrieben, der noch nie was _Fast_ FT gehört hat. Ich habe den Sourcecode gesehen: Der hat tatsächlich die einzelnen diskreten Frequenzen jeweils komplett durchintegriert, ohne auf ein Butterfly-Schema zur Beschleunigung zurückzugreifen. Dementsprechend langsam lief das Teil dann auch. Die Zeichenroutine war ebenfalls grottenlangsam. Das Programm lief auf einem

Da ich selber mal damit hätte arbeiten müssen, habe ich den Auftrag, das neu zu programmieren gerne angenommen.

Wolfgang

Es gibt da so ein kleines Prgramm von FTDI, genannt MProg, mit dem man all diese Angaben nach Lust und Laune ändern kann.

Wolfgang

Ups! Bei mir haben die alle Prolific. Gerade noch den letzten extra mal ausgepackt. Ich habe die aber schon seit Monaten. Bei Reichelt wechselt das ja häufiger mal.

Ich hab bi Reichelt vor 5 wochen gekauft. Prolific PL2313. Läuft gut, ftdi hätte ich aber lieber.

Olaf Kaluza schrieb:

Und wer teuer kauft, bekommt keinesfalls automatisch gut. Die Einstellung der Controller des dritten Jahrtausends: schlecht, dafür billig ist immer besser als gut, aber teuer.

Krank, aber irgendwie mittlerweile richtig.

Kaufst du billig und es funktioniert, hast du Geld gespart. Kaufst du billig und es funktioniert nicht, hast du nicht viel verloren. Dass das Problem dann aber nicht gelöst ist, fällt nicht weiter auf, da man mittlerweile ohnehin schon beim übernächsten Projekt ist.