Hallo. Angenommen man hat einen PC mit echtem COM-Anschluss und USB-Anschlüssen und möchte mit einem μC schnellstmöglich über die serielle Schnittstelle kommunizieren. Der μC hat ein UART-Modul und einen Mini-USB Anschluss welcher ebenfalls UART-fähig ist. Macht es dann Sinn ein MAX232-Modul an den μC anzuschließen und den μC mit dem PC mit einem D-SUB-9 Kabel zu verbinden und somit eine echte serielle Schnittstelle zu haben? Oder macht es keinen Unterschied in der Übertragungsgeschwindigkeit im Vergleich zu einer virtuellen COM-Schnittstelle per USB-Kabel? Ist das Signal in der echten seriellen Schnittstelle (RS232) weniger störanfällig als über die virtuelle? Über USB-Anschluss müsste der PC die virtuelle Schnittstelle doch per Bit-Banging simulieren, wenn ich das richtig verstanden habe. Gilt das auch für den μC?
:
Verschoben durch User
USB über 1200 Meter? RS232C, als Bus? Es gibt gefühlt 1000 verschiedene Methoden, um 2 EDV Partner zu verbinden. Ohne die Rahmenbedingungen zu setzen, keine Chance da einen Schwanzvergleich zu entscheiden. messender schrieb: > Macht es dann Sinn ein MAX232-Modul an den μC anzuschließen und den μC > mit dem PC mit einem D-SUB-9 Kabel zu verbinden und somit eine echte > serielle Schnittstelle zu haben? Natürlich macht das Sinn, wenn die Gegenstelle kein USB kann. Auch das Gegenteil ist ok, wenn die Gegenstelle kein RS232C kann. messender schrieb: > Ist das Signal in der echten seriellen Schnittstelle (RS232) weniger > störanfällig als über die virtuelle? Interessante Frage.... Dürfte an der Art der Störung liegen. Und natürlich an dem Aufbau, in wieweit diese Störung sich auswirken kann. Übrigens, in der Industrie, bei Steuerungsaufgaben, versucht man USB schon zu vermeiden. Da ist ModBus oder CAN etwas verbreiteter. messender schrieb: > Oder macht es keinen Unterschied in der Übertragungsgeschwindigkeit im > Vergleich zu einer virtuellen COM-Schnittstelle per USB-Kabel? Ein USB-Serial Wandler kann nur so schnell sein, wie seine Baudrate erlaubt. Ansonsten ist die auch die Baudrate Virtuell, quasi nicht vorhanden. Ein Parameter ohne Wirkung.
messender schrieb: > Angenommen man hat einen PC mit echtem COM-Anschluss und USB-Anschlüssen > und möchte mit einem μC schnellstmöglich über die serielle Schnittstelle > kommunizieren. Wie schnell kann denn dein µC, inklusive Bereitstellung/Verarbeitung der Daten, kommunizieren, nur um da mal den vermutlich schwächeren Partner abzuklopfen.
messender schrieb: > Der μC hat ein UART-Modul und einen Mini-USB Anschluss welcher ebenfalls > UART-fähig ist. Die Pegel und der Störabstand maximale USB Länge? https://www.sir-apfelot.de/geloest-wie-gross-ist-die-maximale-kabellaenge-von-einem-usb-kabel-1491/ maximale RS232 Länge https://www.lammertbies.nl/comm/info/de_RS-232_specs.html RS232 hat viel mehr Signale RTS CTS DTR DSR RTR DCD RI nicht alle werden von USB bedient https://de.wikipedia.org/wiki/RS-232
Arduino Fanboy D. schrieb: > messender schrieb: >> Macht es dann Sinn ein MAX232-Modul an den μC anzuschließen und den μC >> mit dem PC mit einem D-SUB-9 Kabel zu verbinden und somit eine echte >> serielle Schnittstelle zu haben? > Natürlich macht das Sinn, wenn die Gegenstelle kein USB kann. > Auch das Gegenteil ist ok, wenn die Gegenstelle kein RS232C kann. Vergessen, den ersten Satz zu lesen? Da steht ausdrücklich, dass beide beides können. messender schrieb: > Über USB-Anschluss müsste der PC die virtuelle Schnittstelle doch per > Bit-Banging simulieren, wenn ich das richtig verstanden habe. Nein, es sei denn, die serielle Schnittstelle wird eben für Bitbanging missbraucht.
messender schrieb: > Macht es dann Sinn ein MAX232-Modul an den μC anzuschließen und den μC > mit dem PC mit einem D-SUB-9 Kabel zu verbinden und somit eine echte > serielle Schnittstelle zu haben? Dieser Weg könnte unter Umständen einfacher zu programmieren sein. Sowohl auf der Seite des µC (USB-Deskriptoren, USB-Stack,Vendor-ID,...), als auch auf der Seite des PC (Treiber, OS-Unabhängigkeit,...). > Oder macht es keinen Unterschied in der Übertragungsgeschwindigkeit im > Vergleich zu einer virtuellen COM-Schnittstelle per USB-Kabel? Wenn Du die virtuelle, USB-basierte serielle Schnittstelle auf beiden Seiten richtig programmierst, dürfte sie schneller, was die Übertragungsgeschwindigkeit angeht, sein. Die klassische serielle Schnittstelle hat dagegen eine niedrigere Latenz, da sie nicht paketorientiert arbeitet und Übertragungen vom µC aus nicht auf den nächsten USB SOF vom Host warten müssen. > Über USB-Anschluss müsste der PC die virtuelle Schnittstelle doch per > Bit-Banging simulieren, wenn ich das richtig verstanden habe. Nein. Er sendet die Daten in USB-Paketen die dann auf der Gegenseite ausgepackt und ausgewertet werden.
messender schrieb: > Macht es dann Sinn ein MAX232-Modul an den μC anzuschließen und den μC > mit dem PC mit einem D-SUB-9 Kabel zu verbinden und somit eine echte > serielle Schnittstelle zu haben? Welchen MAX232 genau? Die originalen MAX232 waren IIRC nur für bis ungefähr 115200 Baud zu gebrauchen - moderne USB2UART laufen auch noch mit 1 MBaud zufriedenstellen (wenn das die Gegenstelle unterstützt). Die Antwort lautet also auch hier: Kommt darauf an(tm). Wir kennen die Einsatzbedingungen nicht und können leider nicht hellsehen.
messender schrieb: > Angenommen man hat einen PC mit echtem COM-Anschluss und USB-Anschlüssen > und möchte mit einem μC schnellstmöglich über die serielle Schnittstelle > kommunizieren. "Schnellstmöglich" läßt mehrere Interpretationen zu. Hoher Durchsatz oder geringe Latenz. Genau dies wäre aber eine der Kriterien zur Wahl der Schnittstelle. Mit einem echten COM kann man deutlich geringere Latenzen erreichen als bei dem Umweg über den gesamten USB-Stack. Dafür kann man über USB einen deutlich höheren Durchsatz erreichen, wenn die Verbindung nicht gerade nur ein paar Millimeter bis Zentimeter lang ist, sondern einige (wenige) Meter. Bei noch längeren Verbindungen ist dann wieder die echte COM-Schnittstelle im Vorteil. Geht bei USB schon lange garnix mehr, ist mit RS232 immer noch eine Verbindung möglich, wenn auch nur bei zunehmend bescheidenerem Durchsatz. > Über USB-Anschluss müsste der PC die virtuelle Schnittstelle doch per > Bit-Banging simulieren, wenn ich das richtig verstanden habe. Das hast du nicht richtig verstanden.
my2ct schrieb: > messender schrieb: >> Angenommen man hat einen PC mit echtem COM-Anschluss und USB-Anschlüssen >> und möchte mit einem μC schnellstmöglich über die serielle Schnittstelle >> kommunizieren. > > Wie schnell kann denn dein µC, inklusive Bereitstellung/Verarbeitung der > Daten, kommunizieren, nur um da mal den vermutlich schwächeren Partner > abzuklopfen. Es handelt sich um keinen speziellen µC, ich versuche nur besser zu verstehen wie man die serielle COM-Schnittstelle mit der virtuellen COM-Schnittstelle abwägen kann. Ich habe selbstverständlich auch selbst davor recherchiert aber ganz durchdrungen habe ich den Unterschied noch nicht.
Angehängte Dateien:
-
V24_00_.jpg
80 KB -
V24_hexFF.jpg
49 KB
Hi, kommt auf die Hardware an: "...Supports RS232, RS485 and RS422 modes Bi-directional speeds from 50 bps to 16Mbps/Port.." https://sewelldirect.com/pci-express-rs-232-serial-4-port-card-moschip-9845-chipset Also, meine MOS-Chip blockiert einen PCI Steckplatz hat aber noch einen Slot für Buchsenpanel nötig. Also 2 Slots. Mit reinem RS232 bzw. V24 konnte bei uns einmal eine Distanz von 50 m überbrückt werden ohne merkliche Bitfehlerrate. Aber jede Signalader noch mit GND verdrillt und extra abgeschirmt. Prinzipiell gibt es mehr Bitfehler, wenn Nullen oder FF übertragen wird. Bei asynchron wäre es besser, einen anderen Code zu nehmen. ciao gustav
:
Bearbeitet durch User
messender schrieb: > Es handelt sich um keinen speziellen µC, ich versuche nur besser zu > verstehen wie man die serielle COM-Schnittstelle mit der virtuellen > COM-Schnittstelle abwägen kann. Gibt mehrere Gründe. Das ganze ist aber in erster Linie sehr robust und die wohl am längsten laufende und am besten getestete Schnittstelle. Dann läuft es von jedem Betriebssystem und teilweise sogar aus dem BIOS (z.B. bei Servern). Bei Linux etc kannst du mit minimalen mitteln eine Konsole draus machen. Meiner einer hat das viel in der Industrie benutzt weil die Schnittstellen verschraubt werden können und keiner auf die Idee kommt mal eben den USB seriell Konverter zu tauschen. Profi Systeme haben auch den vollen Spannungshub (+/-12V - statt +/-5V bei den USB Wandlern) damit einen besseren Störabstand. Galvanisch trennen ist einfach und Diagnose mit einer LED bzw Prüfstecker ebenso. Die Länge lässt sich via RS422 Konverter auf Kilometer ausdehnen, über Glasfaser ist es auch kein Problem usw. usf. Du hast weniger Software Schichten zwischen Schnittstelle und Anwendung und kannst selbst mit nem Smartphone (mit entsprechendem Adapter) testen . Im Netzwerk geht die Übertragung mittels COM-Server auch weltweit Meine Geräte haben alle eine serielle mindestens zur Diagnose eingebaut. Das ist einfach zu machen,fast jeder Controller hat mindestens eine oder man macht es über Software.
messender schrieb: > ich versuche nur besser zu > verstehen wie man die serielle COM-Schnittstelle mit der virtuellen > COM-Schnittstelle abwägen kann. Wenn du seriell stabil über Jahre brauchst lässt du die USB Arie weg. Für mal so eben (sozusagen wenn du daneben stehst) ist die USB Lösung einfacher und auch günstiger.
Bei 9600 Baud braucht ein Zeichen ca. 1ms für die serialisierung. So lange dauert die Übertragung bei einer "echten" UART Schnittstelle. Bei USB kann es wegen der paket-orientierten Übertragung im 1 ms Raster bis zu 2ms dauern. Da die Pakete jedoch größer sein können, ist die Übertragungsrate bei kontinuierlichem Datenstrom nicht beeinträchtigt.
Stefanus F. schrieb: > Bei 9600 Baud braucht ein Zeichen ca. 1ms für die serialisierung. So > lange dauert die Übertragung bei einer "echten" UART Schnittstelle. Da du in der Regel ein Betriebssystem hast das auch Zeitscheiben vergibt wird das von der Anwendung her gesehen aber auch nicht besser.
COMmoran schrieb: > Da du in der Regel ein Betriebssystem hast das auch Zeitscheiben vergibt > wird das von der Anwendung her gesehen aber auch nicht besser. Doch, natürlich kann das besser werden. Z.B. dauert das vollständige Programmieren eines ATMega1284P über Ponyprog Tage, wenn man eine USB-UART verwendet. Über einen echten COM-Port aber unter zwei Minuten. Das ist so, weil hier nur "mit Beinchen gewackelt" wird (also Bitbanging über RS232-Steuerleitungen), der Latenznachteil von USB also hier maximal schädlich durchschlägt. Und nein, das ist so bei einer ganz normalen Anwendung als Programmer, unter einem ganz normalen OS. Und das ist deswegen so, weil die Anwendung während ihrer Zeitscheibe durchaus mehrmals mit dem COM-Beinchen wackeln kann. Bei dem Weg über USB kann sie aber immer nur einmal den Wunsch loswerden, das etwas wackeln möge, muss die eigentliche Arbeit aber anderen Threads überlassen, d.h.: wäherend des Rests ihrer Zeitscheibe macht die Anwendung erstmal nix Nützliches mehr. Aber auch wenn sie den Rest ihrer Zeitscheibe freiwillig freigibt, wird's nicht viel besser. Die USB-Threads des OS können nämlich auch nicht machen, was sie wollen, sondern müssen sich dem Regime der USB-Frames unterwerfen.
Joachim B. schrieb: > RTS CTS DTR DSR RTR DCD RI nicht alle werden von USB bedient > https://de.wikipedia.org/wiki/RS-232 Das hat nichts mit USB zu tun, es gibt simple Adapter, bei denen die Hersteller des Adapters drauf verzichten. Die meisten USB-Seriell-Bridges wie z.B. der altbekannte FT232 enthalten eine vollständige UART, d.h. sämtliche von Dir aufgezählten Hansdhakeleitungen.
Rufus Τ. F. schrieb: > Das hat nichts mit USB zu tun darf ich an die Frage vom TO erinnern? messender schrieb: > Der μC hat ein UART-Modul und einen Mini-USB Anschluss welcher ebenfalls > UART-fähig ist. Kein RI, kein DCD, uvam. zeige mir einen µC mit miniUSB wo das ausgewertet wird!
Joachim B. schrieb: > Kein RI, kein DCD, uvam. > zeige mir einen µC mit miniUSB wo das ausgewertet wird! Das ist doch Unsinn. Wenn man die entsprechenden Steuerleitungen benötigt, leitet man sie natürlich über irgendwelche GPIOs des µC. Was soll überhaupt "miniUSB" sein? Ich kenn da nur die entsprechende Konnektor-Bauform. Und klar: darüber geht USB-CDC wie über jeden anderen USB-Konnektor auch. Also inclusive der Signalisierung von Steuerleitungen.
c-hater schrieb: > Was soll überhaupt "miniUSB" sein? soll ich wirklich den µC benennen der mit miniUSB geliefert wird... ich habe da eine Idee welchen der TO gemeint hat! c-hater schrieb: > Das ist doch Unsinn. Wenn man die entsprechenden Steuerleitungen > benötigt, leitet man sie natürlich über irgendwelche GPIOs des µC. klar kann man eine 2te Strippe legen, aber das war nicht die Frage!
Eine echte RS232-Schnittstelle (Achtung: Nicht, daß das PC-intern über USB läuft) hat den Vorteil, daß die bei USB gegebene Latenzzeit wegfällt - die kann schon mal 10ms und mehr ausmachen. Bei größeren Datenpaketen kann da schon mal der FIFO-Puffer voll sein, bevor der PC die Daten ausliest. Selbst schon in der Form gehabt: USB über RS232-Konverter an einen PIC-Controller verbunden; der Controller hat die Daten ohne Berücksichtigung der Puffergröße übertragen - bei einem "richtigen" PC kein Problem, das Netbook war aber damals zu langsam. Wenn o.a. Latenzzeit aber kein Problem ist: Warum auf alten Techniken bleiben? Es hat schon seinen Sinn, daß zumindest im Hausgebrauch RS232 weg ist - für die Industrie gibt's noch RS485 und Glasfaser. Am uC hat man entweder ein USB-Interface oder nimmt einen FTDI-Chip und mit dem PC-Treiber kann man ein virtuelles COM-Port öffnen. Das funktioniert und reicht völlig aus. Aber wie gesagt: FIFO-Puffergrößen nicht vergessen.
Ok danke, jetzt fühle ich mich schon schlauer :) Im Prinzip hängt die Übertragungsrate bei einer COM-Schnittstelle vom schwächsten Glied in der Kette ab, z.B. einem alten "originalen" MAX232. Die Latenz ist bei einer echten seriellen Schnittstelle niedriger als bei einer virtuellen und man muss bei der virtuellen COM darauf achten, dass der PC genügend Zeit hat die Daten aus dem Puffer auszulesen bevor neue kommen. Wenn man also Messwerte loggen will die z.B. im μC per Timerinterrupt periodisch gemessen werden und diese per virtueller COM an den PC leitet, muss man darauf achten, dass der PC auch alle eingehenden Messwerte dem richtigen Zeitpunkt zuordnet und keine verschluckt.
messender schrieb: > z.B. einem alten "originalen" MAX232. Nee, der hat gar keinen Einfluss auf Latenz und Übertragungsrate. Der MX232 ist nur ein dummer Pegelwandler. > und man muss bei der virtuellen COM darauf achten, dass > der PC genügend Zeit hat die Daten aus dem Puffer auszulesen Das gilt auch für "echte" serielle Schnittstellen. Stichwort: Handshake
messender schrieb: > richtigen Zeitpunkt Da wäre wohl eine echte RS232 Schnittstelle besser wegen obengenannter Latenz. Besser der Kontroller kümmert sich selbst um die Zeitstempel
Gurgl schrieb: > messender schrieb: >> richtigen Zeitpunkt > > Da wäre wohl eine echte RS232 Schnittstelle besser wegen obengenannter > Latenz. Besser der Kontroller kümmert sich selbst um die Zeitstempel Also in dem Fall würde ich eine fortlaufende Nummer + Messwert bzw. array[fortlaufende Nummer, Messwert] seriell vom μC aus schicken und der PC errechnet anhand der Nummer und dem Abtastintervall den Zeitstempel und speichert die Werte ab. Was ich allerdings nicht verstehe ist warum es besser ist wenn der Controller sich selbst um die Zeitstempel kümmert, wenn es dann letztendlich e über RS232 (mit weniger Latenz) gesendet wird?
messender schrieb: > Was ich allerdings nicht verstehe ist warum es besser ist wenn der > Controller sich selbst um die Zeitstempel kümmert Weil die Übertragung zum PC unregelmäßig stattfindet. Der PC kann nie ganz genau wissen, von welchem Zeitpunkt der gemessene Wert stammt. Wobei dieses "bisschen" Latenz je nach Anwendung durchaus vollkommen egal sein kann. Bei der Regelung der Zimmertemperatur und bei der Erfassung von Arbeitszeiten interessiert sich z.B. kein Schwein für Millisekunden.
c-hater schrieb: > Doch, natürlich kann das besser werden. Z.B. dauert das vollständige > Programmieren eines ATMega1284P über Ponyprog Tage, wenn man eine > USB-UART verwendet. Über einen echten COM-Port aber unter zwei Minuten. Ponyprog fährt ja auch kein UART/RS232 sondern vergewaltigt den COM-Port (Bitbanging). Das Problem dass du beschreibst rührt also daher dass sich USB nicht so leicht vergewaltigen lässt wie die UART.
Bei ungeschickten* Protokollen, bei denen es auf Latenzen ankommt, ist die "Hardware-UART" im Vorteil, sonst aber nicht, insbesondere wenn es um Datenrate geht. Die Standard-Schnittstelle im PC kann nämlich maximal 115200 Baud, mehr erlaubt deren Baudratengenerator nicht. Im 8250 und den diversen Nachfolgern 16450, 16550 etc. wird der Baudratengenerator aus einem externen Taktsignal gespeist, das im PC 1.8432 MHz hat. Teilt man das durch 16, hat man die altbekannten 115200 Baud, und das Teilen durch 16 ist durch die UART-Hardware bedingt, bei der jedes einzelne Bild mit 16facher Rate abgetastet wird. Zwar könnte man den Baustein auch mit einer höheren Taktfrequenz betreiben, aber das weiß keines der Betriebssysteme, deren Devicetreiber mit dem Baustein zu tun bekommen. *) Ich nenne solche Protokolle bewusst ungeschickt, da sie auch bei neueren PC-Uarts durchaus zu Problemen führen können, sofern man nicht dafür sorgt, daß deren Hardware-Fifos deaktiviert werden. Das liegt daran, daß der Empfangs-Interrupt im Fifo-Betrieb nicht für jedes einzelne empfangene Byte, sondern nur unter zwei Bedingungen erzeugt wird: Fifo-Triggerpegel erreicht oder Timeout verstrichen. Solange die übertragenen Datenmengen unter der Höhe des Fifo-Triggerpegels liegen (Extremfall: Einzel-Byte-Ping-Pong), vergeht vor dem Auslösen des Empfangsinterrupts also zwangsweise das Fifo-Timeout, was sich ungünstig auf die Latenz auswirkt. Dieses Timeout beträgt beim 16550 (dem dieses Verhalten definierenden Baustein) vier Bytezeiten, bei 115200 Baud also knapp 350 µsec, bei 9600 Baud entsprechend knapp 42 msec. (Siehe Datenblatt http://www.ti.com/lit/ds/symlink/pc16550d.pdf, S.16, Abschnitt 8.4.1)
Rufus Τ. F. schrieb: > Bei ungeschickten* Protokollen, bei denen es auf Latenzen ankommt, ist > die "Hardware-UART" im Vorteil, sonst aber nicht, insbesondere wenn es > um Datenrate geht. Die Standard-Schnittstelle im PC kann nämlich > maximal 115200 Baud, mehr erlaubt deren Baudratengenerator nicht. Das stimmt weder heute noch für einen weiten Zeitraum in der Vergangenheit. Es gab und gibt nämlich schon jahrzehntelang UARTs mit mehr Möglichkeiten. Teilweise sogar in den SuperIO-Bausteinen bzw. in der Southbridge. Bloß nicht bei Intel, denn die haben ja verfügt, dass "legacy"-Schnittstellen zu sterben hätten (was allerdings bis heute nicht wirklich passiert ist...) Typisch gehen mit solchen UARTs dann knapp 1MBit/s (921,6kbps), sie sind aber trotzdem weitgehend 16550-kompatibel (erreichen halt mit einem "dummen" 16550-Treiber natürlich auch nur 16550-Leistungen). Darüber hinaus gab und gibt es auch welche mit noch sehr viel mehr Möglichkeiten, die sind dann allerdings nicht mal ansatzweise 16550-kompatibel, brauchen also zwingend einen spezialisierten Treiber, um überhaupt irgendwas was zu machen. Sowas fand man allerdings eher nicht in SuperIO oder Southbridge, sondern eigentlich nur auf Zusatzkarten. Das zur Hardware. Und was nun die "ungeschickten" Protokolle betrifft: Sobald ein Protokoll eine Antwort vom Peer erfordert, um überhaupt logisch funktionieren zu können, kommen ganz automatisch die Latenzen in's Spiel. Das gilt völlig unabhängig von irgendeiner "Geschicklichkeit", sondern ist Folge eines Grundgesetzes der Informatik, der Kausalität. Du kannst halt die Antwort nicht versenden, bevor du den Inhalt der Frage kennst...
c-hater schrieb: > Du kannst halt die Antwort nicht versenden, bevor du den Inhalt > der Frage kennst... 42. Geht immer.
Karl B. schrieb: > Mit reinem RS232 bzw. V24 konnte bei uns einmal eine Distanz von 50 m > überbrückt werden ohne merkliche Bitfehlerrate. Für längere Strecken gibt es auf dem physical Layer nun wirklich geeigneteres als RS232. Gegen Störungen wäre ein differentielle Übertragung (z.B. RS422) schon mal ein Schritt in die richtige Richtung.
c-hater schrieb: > Das stimmt weder heute noch für einen weiten Zeitraum in der > Vergangenheit. Es gab und gibt nämlich schon jahrzehntelang UARTs mit > mehr Möglichkeiten. Du kennst aber den Unterschied zwischen Rufus Τ. F. schrieb: > Standard-Schnittstelle im PC und: c-hater schrieb: > die sind dann allerdings nicht mal ansatzweise 16550-kompatibel, brauchen > also zwingend einen spezialisierten Treiber, um überhaupt irgendwas was > zu machen. Sowas fand man allerdings eher nicht in SuperIO oder > Southbridge, sondern eigentlich nur auf Zusatzkarten. ?
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.