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?
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.
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.
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
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...
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.
?
