Warum werden USB-Ports manchmal als serielle Ports bezeichnet und COM genannt?

Dies sind keine USB-Ports, die als serielle Ports bezeichnet werden. In Ihrem Beispiel verfügt der Arduino über ein USB-zu-serielles Gerät (entweder in Form eines zweiten Mikrocontrollers oder eines FTDI-Chips). Dies verwendet USB, um mit dem Computer zu kommunizieren und eine tatsächliche serielle Schnittstelle zur Außenwelt zu bilden - ähnlich wie USB-Wi-Fi-Dongles oder USB-LAN-Adapter, USB-SATA-Adapter usw.

Der Schlüssel ist, dass in vielen Fällen die serielle Schnittstelle nicht direkt für den Benutzer verfügbar ist, da sie im Gerät" fest verdrahtet " ist (in dieser Fall ist direkt mit dem Mikrocontroller verbunden, den Sie programmieren).

In der strengen Theorie ist jeder Port, der serielle Kommunikation verwendet (fast jeder moderne Bus - einschließlich USB, der für "Universal Serial Bus" steht, wenn mein Speicher mir dient), ein "serieller Port". In den meisten Fällen beziehen sich die Benutzer jedoch auf "die serielle Schnittstelle" und beziehen sich tatsächlich auf einen Port, der RS-232 entspricht.

Es ist verwirrend, weil Windows COM: Ports von einem Benennungssystem stammen, das in MS-DOS (*1980) definiert wurde. Dies wurde ziemlich viel von CP/M kopiert (b. 1974) mit einigen Ideen aus Unix. Sie hatten nicht mit der Hinzufügung eines Zwischentransportbusses wie USB gerechnet.

Einige Dinge in Windows sind von der CP/M->MS-DOS-Entwicklung entfernt, z. B. Festplattenlaufwerke mit Buchstabennamen, Dateinamenerweiterungen mit 3 Buchstaben .EXE-und. COM-Dateien und der Befehl Eingabeaufforderung Schnittstelle.

Ein anderer ist Gerätenamen: im Allgemeinen drei Buchstaben, die immer mit einem Doppelpunkt enden. COM: ist ein serieller "Kommunikationsport", LPT: ein "Liniendrucker" (normalerweise hängt er an einem Centronics-Port), NUL: Dumps, was an ihn gesendet wird, CON: ist die "Konsole" (Tastatur und Bildschirm). Einige, von denen Sie mehrere haben könnten, werden nummeriert, um zwischen ihnen zu unterscheiden. COM: Ports tun, wie LPT: Ports, immer COM1: und LPT1: und so weiter.

Ein COM: port ist ein 'Endpunkt': das andere Ende des kommunikationsverbindung aus Sicht eines Windows-PCS. Wie viele Dinge im Computing wird die Brücke dort ignoriert und es ist die Far-End-Komponente, an die Sie denken, nicht USB. Dies gilt auch für eine PC-Tastatur (verbunden als CPU-PCIe-USB-kbd) oder ein Netzwerklaufwerk (verbunden als CPU-PCIe-LAN-LAN-PCIe-CPU-PCIe-SATA oder ähnliches).

USB verwendet auch die Idee von Endpunkten. Ein USB-Controller kann einen Host-PC an alle Arten von Hardware anschließen und diese als Ressourcen bereitstellen. Also, wenn Sie die Hardware sehen über USB angeschlossen, sehen Sie diese Endpunkte. Ein virtueller COM: - Port in einem USB-Gerät ist einfach eine serielle Schnittstelle, die als Endpunkt von diesem USB-Slave-Gerät ausgeht. Windows gibt ihm eine Nummer (COM1:, COM27: usw.) und diese serielle Schnittstelle kann von jedem Programm erkannt und verwendet werden, das die Standard-Windows-API für COM: ports verwendet.

Einige USB-angeschlossene Hardware könnte es vorziehen, eine serielle Schnittstelle zu imitieren, weil es die Entwicklung der Windows-Software für sie einfacher macht. Kein Gerätetreiber muss sein geschrieben, die eine Menge Arbeit sparen - das USB-Gerät sagen Windows, dass es eine serielle Schnittstelle ist. Aus Sicht des PCS ist dies in Ordnung, wenn es sich wie eine serielle Schnittstelle verhält (Bytes werden in einem endlosen seriellen Stream gesendet und empfangen, der immer offen ist). Es gibt also Vorteile für den Entwickler.

Um zu Joren Vaes ' Antwort hinzuzufügen: Beachten Sie, dass einige Software-Apps (wie Arduino IDE) einen Windows-Treiber installieren, der "virtuelle COM" - Ports erstellt. Wenn diese Ports aktiviert sind, teilt das Betriebssystem den Programmen mit, dass ein COM-Port verfügbar ist, der wie eine serielle Standardschnittstelle [ * ] aussieht, an die Programme (wie Arduino IDE, aber auch andere) Bits senden und empfangen können wie an jede serielle Schnittstelle. Unter der Haube werden diese Bits jedoch an ein USB-Kabel gesendet. Innerhalb der Arduino-board etwas analoges tritt.

[*] Und, mit" Standard serial Port " hier meinen wir RS-232-Protokoll, die Art, die traditionell über DB-9 oder DB-25-Anschluss trasmitted wurde. In unserem Kontext spielt es überhaupt keine Rolle, dass USB auch "seriell" ist.

Ihr Verständnis des Unterschieds zwischen COM-Port und USB-Port ist korrekt.

Kurze Antwort auf Ihre Frage, warum einige USB-Ports vom Betriebssystem als "COM" - Ports zugeordnet werden, lautet: Es gibt USB-Geräte, die USB CDC (Communication Device Class) implementieren. Diese Geräte bieten eine Brücke von einer schrecklich komplizierten USB-Schnittstelle zu einer Standard-UART/RS-232-Schnittstelle. Aus Gründen der Transparenz für Benutzer lädt das Betriebssystem USB-Treiber, die die Transportschicht als COM-Port nachahmen, einen virtuellen COM-Port. Einige historische Details und Begründungen für diesen Ansatz folgen.

Der COM-Port verwendet DB-9/DB-15-Anschlüsse (auch bekannt als serielle RS-232-oder UART-Anschlüsse), und Controller für diese Ports werden physisch in PC-Hardware an bestimmte Adressen im E/A-Bereich zugeordnet. Dieser COM-Controller wird in modernen PCs veraltet und erloschen.

Gleichzeitig verwenden viele MCU immer noch die serielle RS-232-Kommunikation als Hauptmittel, um mit der Peripheriewelt zu kommunizieren. Der Grund ist, dass die Hardware (und software) für diese Art von Link ist sehr einfach und leicht zu implementieren. Mehr, alle modernen Android-Entwicklung / Debug-Kommunikation erfolgt im COM-Port-Stil. Außerdem verwenden viele "Kommunikations"-Geräte (als Modems, einschließlich 4G LTE und höher) immer noch die UART-Schnittstelle mit ASCII-Steuerungsprotokoll über mehrere "COM" - Ports.

Jetzt haben Entwickler ein Dilemma, wie man mit solchen Mikrocontrollern kommuniziert, wenn der Host-Entwicklungs-PC keine COM-Ports hat? Die Lösung bestand darin, USB-Anschlüsse zu verwenden und spezielle USB-Geräte, die das USB-Protokoll mit COM-Port RS-232-Schnittstelle überbrücken. Es gibt dedizierte USB-Gerät als FTDI-chips und viele andere (Cypress, Microchip, etc.) stellen Sie Geräte her, die diese Brückenfunktion ausführen.

Nun wird die gesamte native Kommunikation zu diesen MCUs immer noch in Bezug auf das RS-232-Protokoll ausgedrückt, und die meisten Anwendungsbeispiele gehen von der Verwendung einiger Terminalanwendungen (TeraTerm, HyperTerminal usw.) aus.) um den Link zu verwenden. Für Benutzerfreundlichkeit sind die USB-zu-UART-Brücken mit Treibern versehen, die den Port als virtuellen COM-Port darstellen. Alle modernen Software verwendet Virtualisierung von COM-Hardware, die einen reibungslosen Übergang zu "COM-less" PCs bietet. Es ist gängige Praxis, entweder eine dedizierte FTDI-Bridge zu den UART-Ports auf einer MCU-Entwicklungsplattform hinzuzufügen (und FTDI-Treiber auf dem Host-PC zu verwenden, damit der USB-Port wie ein COM-Port aussieht) oder den richtigen Bridge-Code in die MCU selbst einzubetten (wenn er über native USB-Funktionalität verfügt).

Der gerade Ansatz ist so verwenden Sie eine externe USB-zu-UART-Karte und verdrahten Sie den UART mit der in Entwicklung befindlichen MCU. Oder wenn eine Platine bereits über den DB-9-Anschluss verfügt, gibt es USB-Dongles, die direkt daran angeschlossen werden können.

In allen Fällen wird das native UART-Steuerelement der MCU auf der Hostseite als virtueller COM-Port angezeigt, wobei alle Zwischensignal - /Protokolltransformationen übersprungen werden. Deshalb überspringen Menschen heutzutage oft die Unterscheidung zwischen USB-zu-UART-Brücken und COM-Ports.

Es ist sehr verwirrend, aber Sie brauchen sich keine Sorgen darüber zu machen. Denken Sie zunächst an einen UART, der selbst ein Oberbegriff ist, aber denken Sie an einen, der ein Protokoll mit einem Startbit, einem oder zwei Stoppbits, 7 oder 8 normalerweise Datenbits und manchmal Parität erzeugt, die gerade oder ungerade ist; es kann von dort variieren, was es so viel schlimmer macht.

Der UART ist auf TTL-Pegeln, was auch immer das bedeutet. Früher waren es 5 V und jetzt 3,3 V, 1,8 V oder was auch immer; vielleicht ist TTL der falsche Begriff. DANN hatten/haben Sie RS-232, RS-422, etc. Dies sind SPANNUNGS-UND PIN-Standards, keine Protokollstandards. Es ist falsch, die Begriffe zu mischen und RS-232 zu sagen, wenn Sie eine Art UART meinen.

Damals war Ihr UART auf Ihren Motherboards und Sie wünschten sich eine Art Anschluss an die Außenwelt mit damals sinnvollen Spannungspegeln und einer Art Standard-Pinbelegung/ - kabel. So wurde oft ein beliebter 25-und 9-Pin-Standard für verschiedene Peripheriegeräte gefunden, und in der Wintel-PC-Welt wurde dies als Kommunikation port oder manchmal serielle port.

Sicher, ein Port, der serielle Daten trägt, kann und wird als serielle Schnittstelle, SPI, I2C, MDIO, UART, HDLC, SDLC usw. bezeichnet., und vielleicht sogar USB und SCSI; Sie könnten damit verrückt werden. Normalerweise bedeutet eine serielle Schnittstelle einige Pins, die Sie bei einem UART erhalten können.

Die Unix / Linux-Welt sagt tty anstelle von com/serial/uart, aber es ist dasselbe.

Jetzt gibt es die IMPLEMENTIERUNG. Sie können kaufen einige UART chip mit einige interface auf es (yep, sie können haben Sie einen SPI-UART, der an beiden Enden seriell ist,oder I2C-UART oder einen dedizierten Bus oder USB usw.). Schon damals hatte der UART auf einer Seite einen Bus, über den letztendlich die CPU kommunizierte. Heute haben wir FTDI und andere Anbieter, die schöne USB-UART-Lösungen machen, macht es nicht anders einige Schichten der Schnittstelle zwischen der Software und dem UART und dann die andere Seite des UART hat einige Schnittstelle, sei es TTL/Chip-Pegel oder RS-232C oder RS-422, etc.

Frühe Arduinos Sie oft verwendet ein FTDI USB-to-UART-Board, das auch den Arduino mit Strom versorgt. Einige haben diese USB-Stromversorgung und seriell / UART auf dem Arduino-Board selbst und dann ist das über die Platine mit dem UART auf dem AVR-Chip verbunden (dasselbe gilt für einige Prozessor mit einigen Schichten von Bussen, damit Software mit einem UART kommunizieren kann, der eine Schnittstelle auf der anderen Seite davon hat, in diesem Fall die Pins am Rand des AVR, bei Chipspannungspegeln, TTL).

Da sich die UART-Funktionalität nicht geändert hat warum sollte sich in Jahrzehnten die Softwareterminologie oder sogar Softwareanwendungen auf Anwendungsebene ändern? Schreiben Sie eine Linux/Unix-TTY-Anwendung vor 10-15 Jahren gegen einen UART-Chip auf Ihrem Motherboard, und es besteht eine gute Chance, dass sie auch heute noch mit einem USB-zu-TTL-Pegel oder USB-zu-RS-232C-Pegel oder RS-422 oder welcher Pin/Level-Definition funktioniert. Das gleiche gilt für Windows, und ich habe Code, der alt ist und immer noch auf beiden funktioniert. In der Windows-Welt wird der Begriff COM verwendet.

Ich habe die Arduino Sandbox in einer Weile und wenn ja, wäre unter Linux gewesen, aber ich wäre nicht überrascht, wenn das Programm, das Java ist, wenn ich mich richtig erinnere, generisch ist und den Systemnamen so ttyS2 unter Linux und COM2 unter Windows verwendet.

Wenn Sie Ihre Frage erneut lesen, kann dies viel weiter gehen und die bereits vorhandene Menge an Software nutzen, die diese API-Aufrufe verwendet. Auch hier gibt es seit Jahrzehnten keinen Grund, warum Sie in Software, die diese bidirektionalen Daten enthält, keinen virtuellen Port erstellen können so ziemlich alles, was man sich vorstellen kann. UART zu Ethernet ist sehr verbreitet, und in Serverräumen, in denen Server immer noch COM/TTY/RS-232-Ports verwenden, können Sie einen Terminalserver mit einer Reihe von Schnittstellen haben, über die Sie eine Verbindung zu einer Reihe von Servern herstellen können, dann Ethernet auf der anderen Seite, Wenn Sie sich nicht für Telnet entscheiden, können Sie einen virtuellen COM-Port-Treiber installieren.

Dann denkt Ihre Anwendung auf Ihrem Computer, dass sie mit einem COM-Port spricht, aber tatsächlich ist dieser Bytestrom hopping auf Ethernet dann auf den Terminal-Server, dann auf einen UART zu RS-232C Ebene (aber nicht unbedingt Pinout) Kabel an den Server und zurück auf die gleiche Weise.

Manchmal gibt es keinen Grund, es tatsächlich zu einem echten UART zu machen, aus welchem Grund auch immer einen COM-Port virtualisieren, so dass Software, die für diese API-Aufrufe geschrieben wurde, immer noch funktionieren kann. Sie könnten vielleicht über die alte Banking-Software denken wir noch verwenden, dass ein dummes Terminal zu einer UART-Schnittstelle hat, die vielleicht zurück in den Tag war fest verdrahtet oder ging in ein Modem, um einen Server zu verbinden. Sie können es so machen, dass die Software immer noch funktioniert, durch verschiedene Mengen an Emulation, einschließlich eines virtuellen COM-Ports, der heute wahrscheinlich nur Ethernet als serieller Stream (TCP/IP zum Beispiel) zum Server hinuntergeht.