USBポートがシリアルポートと呼ばれ、COMと呼ばれることがあるのはなぜですか？

私のコンピュータポートの理解に関する限り、

1. シリアルポートは、ここに示すような9ピンプラグであり、COMポートとも呼ばれます。
2. USBポートは、シリアルポートとは異なる標準です。

なぜ「シリアルポート」と呼ばれるUSBポートがよく表示され、たとえばArduino IDEでUSBポートがCOMプレフィックスで識別されるのはなぜですか？また、シリアルポートが含まれていない場合に仮想COMポートが必要になることがあるのはなぜですか？（例：Prologix GPIB-USBアダプター。）

同じ名前を2つの異なることを説明するために使用することは、少し混乱を招く可能性があります。

これらは、シリアルポートと呼ばれるUSBポートではありません。あなたの例では、ArduinoにはUSBからシリアルデバイス（2番目のマイクロコントローラーまたはFTDIチップのいずれかの形式）があります。これはUSBを使用してコンピューターと通信し、USB Wi-Fiドングル、USB LANアダプター、USB SATAアダプターなどと同様に、外界への実際のシリアルポートを形成します。

重要なのは、多くの場合、シリアルポートはデバイスに "ハードワイヤード"されているため（この場合、プログラミングしているマイクロコントローラーに直接接続されている）、ユーザーが直接使用できないことです。

厳密な理論では、シリアル通信を使用するポート（ほとんどすべての最新のバス-私のメモリが私をサポートしている場合、「ユニバーサルシリアルバス」を表すUSBを含む）はすべて「シリアルポート」です。ただし、ほとんどの場合、人々が「シリアルポート」と呼ぶ場合、実際にはRS-232に準拠するポートを指します。

Windows COM：ポートはMS-DOS（b。1980）で定義されたネーミングシステムに由来するため、混乱を招きます。これはCP / M（b。1974）からかなりコピーされたもので、Unixからいくつかのアイデアが取り入れられました。彼らは、USBのような中間的な「トランスポート」バスの追加を予期していませんでした。

Windowsの非常に少数のものは、CP / M-> MS-DOSの進化からの生き残りです。たとえば、文字名のディスクドライブ、3文字のファイル名拡張子、.EXEおよび.COMファイル、コマンドプロンプトコマンドインターフェイスなどです。

もう1つはデバイス名です。通常は常にコロンで終わる3文字です。COM：はシリアルの「通信ポート」、LPT：は「ラインプリンター」（通常はセントロニクスポートから切り離されます）、NUL：送信されたものはすべてダンプします。CON：は「コンソール」（キーボードと画面）です。いくつかの番号を付けて、それらを区別することができます。COM：ポートは、LPT：ポートと同様に、COM1：およびLPT1：などになります。

COM：ポートは「エンドポイント」です：Windows PCの観点からの通信リンクの遠端。コンピューティングの多くのものと同様に、そこにあるブリッジは無視され、USBではなく、あなたが考えている遠端コンポーネントです。これは、PCキーボード（CPU-PCIe-USB-kbdとしてリンク）またはネットワークドライブ（CPU-PCIe-LAN-LAN-PCIe-CPU-PCIe-SATAなどとしてリンク）にも当てはまります。

USBもエンドポイントの概念を使用します。USBコントローラは、ホストPCをあらゆる種類のハードウェアに接続し、それらをリソースとして提供できます。したがって、USBで接続されたハードウェアを見ると、これらのエンドポイントが見えます。仮想COM：USBデバイスのポートは、エンドポイントとしてそのUSBスレーブデバイスから出てくる単純なシリアルポートです。Windowsはそれに番号（COM1：、COM27：など）を与え、そのシリアルポートは、COMの標準Windows APIを使用するすべてのプログラムで認識および使用できます：ポート。

一部のUSB接続ハードウェアは、Windowsソフトウェアの開発を容易にするため、シリアルポートを偽装することを好む場合があります。デバイスドライバーを作成する必要がないため、多くの作業が節約されます。USBデバイスはWindowsにシリアルポートであることを通知します。PCの観点から見ると、シリアルポートのように動作する場合はこれで問題ありません（バイトは常に開いているエンドレスシリアルストリームで送受信されます）。そのため、開発者にはメリットがあります。

Joren Vaesの答えに追加するには、一部のソフトウェアアプリ（Arduino IDEなど）が「仮想COM」ポートを作成するWindowsドライバーをインストールすることに注意してください。それらのポートがアクティブになると、オペレーティングシステムはプログラムに、利用可能なCOMポートがあることを通知します。COMポートは、標準シリアルポート[*]のように見えます。任意のシリアルポートに。ただし、内部ではこれらのビットはUSBケーブルに送信されます。Arduinoボードの内部では、類似したことが発生します。

[*]そして、ここでの「標準シリアルポート」とは、RS-9プロトコルを意味します。これは、従来DB-9またはDB-25コネクタ経由で送信されていた種類です。このコンテキストでは、USBが「シリアル」であることはまったく問題ではありません。

COMポートとUSBポートの違いについてのあなたの理解は正しいです。

いくつかのUSBポートがOSによって「COM」ポートとしてマップされる理由を簡単に答えてください。USBCDC（通信デバイスクラス）を実装するUSB​​デバイスがあります。これらのデバイスは、非常に複雑なUSBインターフェイスから標準のUART / RS-232タイプのインターフェイスへのブリッジを提供します。ユーザーの透過性を確保するために、オペレーティングシステムはトランスポート層を仮想COMポートであるCOMポートとして模倣するUSB​​ドライバーをロードします。このアプローチの歴史的な詳細と正当化を以下に示します。

COMポートはDB-9 / DB-15（別名RS-232シリアル、またはUART）コネクターを使用し、これらのポートのコントローラーはI / O空間の特定のアドレスにPCハードウェアに物理的にマッピングされます。このCOMコントローラーは、現代のPCでは時代遅れになっており、消滅しています。

同時に、多くのMCUは、周辺機器と通信するための主要な手段としてRS-232シリアル通信を使用しています。その理由は、この種のリンクのハードウェア（およびソフトウェア）は非常にシンプルで実装が簡単だからです。さらに、最新のAndroid開発/デバッグ通信はすべてCOMポートスタイルで行われます。また、多くの「通信」デバイス（4G LTE以上を含むモデムとして）は、いくつかの「COM」ポートでASCIIタイプの制御プロトコルを備えたUARTスタイルのインターフェースを引き続き使用します。

ホスト開発PCにCOMポートがない場合、開発者はこのようなマイクロコントローラーと通信する方法にジレンマを抱えています。ソリューションは、USBポートと、USBプロトコルとCOMポートRS-232インターフェースをつなぐ特別なUSBデバイスを使用することでした。FTDIチップとして専用のUSBデバイスがあり、他の多く（サイプレス、マイクロチップなど）がこのブリッジ機能を実行するデバイスを作成しています。

現在、これらのMCUへのネイティブ通信はすべてRS-232プロトコルで表現されており、ほとんどのアプリケーション例では、リンクを使用するためにターミナルアプリケーション（TeraTerm、HyperTerminalなど）の使用を想定しています。ユーザーの利便性のため、USB-to-UARTブリッジには、ポートを仮想COMポートとして表すドライバーが提供されています。最新のソフトウェアはすべて、COMハードウェアの仮想化を使用しているため、「COMレス」PCへのスムーズな移行が可能です。MCU開発プラットフォームのUARTポートに専用のFTDIブリッジを追加する（およびホストPCのFTDIドライバーを使用してUSBポートをCOMポートのように見えるようにする）か、MCU自体に適切なブリッジコードを埋め込むのが一般的な方法になります（ネイティブUSB機能があります）。

直接的なアプローチは、外部USB-to-UARTボードを使用して、UARTを開発中のMCUに配線することです。または、ボードにDB-9コネクタが既にある場合は、それに直接接続できるUSBドングルがあります。

すべての場合において、MCUのネイティブUART制御は、ホスト側で仮想COMポートとして表示され、すべての中間信号/プロトコル変換をスキップします。そのため、最近の人々は、USB-to-UARTブリッジとCOMポートの区別をしばしばスキップしています。

とても混乱しますが、心配する必要はありません。まず、それ自体が一般的な用語であるUARTについて考えますが、スタートビット、1つまたは2つのストップビット、7または8の通常データビット、および偶数または奇数のパリティを持つプロトコルを生成するものについて考えます。それはそこから変化する可能性があり、それはそれをはるかに悪化させます。

その意味は何でも、UARTはTTLレベルです。以前は5 Vでしたが、現在は3.3 V、1.8 Vなど何でもありました。おそらくTTLは間違った用語です。次に、RS-232、RS-422などがありました/ありました。これらは、プロトコル標準ではなく、電圧およびPIN標準です。ある種のUARTを意味するときに用語を混ぜてRS-232と言うのは正しくありません。

昔はUARTがマザーボードに搭載されていて、その時点で意味のある電圧レベルと標準的なピン配列/ケーブルを備えた外界への何らかのコネクタが必要でした。そのため、一般的な25および9ピン標準がさまざまな周辺機器によく見られ、Wintel PCの世界ではこれはCOMポートまたはシリアルポートと呼ばれていました。

確かに、シリアルデータを伝送するポートは、シリアルポート、SPI、I²C、MDIO、UART、HDLC、SDLCなど、さらにはUSBやSCSIとも呼ばれます。これに夢中になるかもしれません。通常、シリアルポートとは、UARTで取得できるピンのことです。

Unix / Linuxの世界では/ /のtty代わりに言っていますが、それは同じことです。comserialuart

今、実装があります。インターフェースを搭載したUARTチップを購入できます（はい、両端でシリアルなSPI UART、またはI²CUARTまたは専用バスまたはUSBなどを持つことができます）。当時でも、UARTの片側にバスがあり、最終的にCPUが通信していました。今日、私たちには素晴らしいUSB UARTソリューションを作成するFTDIと他のベンダーがあり、ソフトウェアとUARTの間のインターフェースのいくつかのレイヤーを変更せず、UARTの反対側にはTTL /チップレベルまたはRS-232CまたはRS-422など

初期のArduinosでは、Arduinoに電力を供給するFTDI USB-to-UARTボードをよく使用していました。Arduinoボード自体にUSB電源とシリアル/ UARTがあり、ボード全体でAVRチップ上のUARTに接続されているものもあります（一部のプロセッサとバスのレイヤーを処理して、ソフトウェアがUARTと通信できるようにします）それの反対側のいくつかのインターフェース、この場合、AVRのエッジのピン、チップ電圧レベル、TTL）。

UARTの機能は何十年も変わっていないのに、ソフトウェア用語やソフトウェアアプリケーションさえもアプリケーションレベルで変更する必要があるのはなぜですか？マザーボードのUARTチップに対して10〜15年前にLinux / Unix TTYアプリケーションを作成すると、USBからTTLレベル、USBからRS-232Cレベル、RS-422、またはその他のピンで現在も動作する可能性が高い/レベル定義。同じことはWindowsにも当てはまりますが、古いコードはまだ両方で動作します。Windowsの世界では、COMという用語が使用されます。

私はしばらくの間Arduinoサンドボックスを使用していませんでしたが、Linuxでそうだったら、Javaであるプログラムが正しいことを覚えていれば汎用的であり、システム名ttyS2をLinuxとCOM2で使用していても驚かないでしょうWindows上で。

質問を読み直すと、これらのAPI呼び出しを使用する既存のソフトウェアの量を活用して、さらに先へ進むことができます。繰り返しますが、何十年もの間、この双方向のデータを思いつく限り多くのものを運ぶソフトウェアで仮想ポートを作成できない理由はありません。UARTからイーサネットは非常に一般的なものであり、サーバーがまだCOM / TTY / RS-232ポートを使用しているサーバールームでは、多数のサーバーに接続できる多数のインターフェイスを備えたターミナルサーバーを使用できます。次に、反対側のイーサネット、telnetで接続しないことを選択した場合、仮想COMポートドライバーをインストールできます。

次に、コンピューター上のアプリケーションはCOMポートと通信していると見なしますが、実際には、バイトストリームがイーサネット上でホッピングし、ターミナルサーバー（THEN）をUARTからRS-232Cレベル（ただし、必ずしもピンアウトではない）のケーブルに接続しています同じ方法でサーバーとバック。

何らかの理由でCOMポートを仮想化して、これらのAPI呼び出し用に作成されたソフトウェアが引き続き機能するように、実際に実際のUARTにする理由がない場合もあります。おそらく私たちがまだ使用している古代の銀行ソフトウェアについて考えることができます。それは、おそらく当時はハードワイヤードであったか、最終的にサーバーにモデムに接続されたUARTインターフェイスへのダム端末を持っています。今日ではおそらくシリアルストリーム（たとえばTCP / IP）としてサーバーにイーサネットで送られる仮想COMポートを含むさまざまな量のエミュレーションを通じて、ソフトウェアが引き続き動作するようにすることができます。