USBポートがシリアルポートと呼ばれ、COMと呼ばれることがあるのはなぜですか？
私のコンピュータポートの理解に関する限り、
- シリアルポートは、 ここ に示されているような9ピンプラグであり、COMポートとも呼ばれます。
- USBポートは、シリアルポートとは異なる規格です。
では、なぜ「シリアルポート」と呼ばれるUSBポートが頻繁に表示されるのですか。たとえば、Arduino IDEでは、USBポートはCOMプレフィックスによって識別されますか？また、シリアルポートが含まれていないのに、仮想COMポートが必要になる場合があるのはなぜですか。 （例：Prologix GPIB-USBアダプター。）
この2つの異なることを説明するための同じ名前の使用は、少し混乱するかもしれません。
これらは、シリアルポートと呼ばれるUSBポートではありません。あなたの例では、ArduinoにUSB-to-serialデバイス（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で接続されたハードウェアを見ると、これらのエンドポイントがわかります。 USBデバイスの仮想COM：ポートは、そのUSBスレーブデバイスからエンドポイントとして出てくるシリアルポートです。 Windowsはそれに番号（COM1：、COM27：など）を付け、そのシリアルポートは、COM：ポート用の標準のWindows APIを使用するすべてのプログラムで認識および使用できます。
一部のUSB接続ハードウェアは、Windowsソフトウェアの開発を容易にするため、シリアルポートの偽装を好む場合があります。デバイスドライバーを作成する必要がないため、多くの作業を節約できます。USBデバイスはWindowsにシリアルポートであることを通知します。 PCの観点から見ると、シリアルポートのように動作する場合は問題ありません（バイトは常に開いているエンドレスシリアルストリームで送受信されます）。したがって、開発者にはメリットがあります。
追加するには Joren Vaesの答え ：一部のソフトウェアアプリ（Arduino IDEなど）は、「仮想COM」ポートを作成するWindowsドライバーをインストールすることに注意してください。これらのポートがアクティブ化されると、オペレーティングシステムはプログラムに、使用可能なCOMポートがあることを通知します。これは、標準のシリアルポート[*]のように見え、プログラム（Arduino IDEだけでなく他のプログラムも）は次のようなビットを送受信できます。任意のシリアルポートに。ただし、内部的には、これらのビットはUSBケーブルに送信されます。 Arduinoボードの内部でも同様のことが起こります。
[*]そして、ここでの「標準シリアルポート」とは、RS-232プロトコルを意味します。これは、従来DB-9またはDB-25コネクタを介して送信されていたものです。私たちのコンテキストでは、USBが「シリアル」であることもまったく問題ではありません。
COMポートとUSBポートの違いについての理解は正しいです。
OSによって一部のUSBポートが「COM」ポートとしてマップされる理由は次のとおりです。USBCDC（通信デバイスクラス）を実装するUSBデバイスがある。これらのデバイスは、非常に複雑なUSBインターフェースから標準のUART/RS-232タイプのインターフェースへのブリッジを提供します。ユーザーの透過性のために、オペレーティングシステムは、トランスポート層を仮想COMポートであるCOMポートとして模倣するUSBドライバーを読み込みます。このアプローチのいくつかの歴史的詳細と正当化は以下の通りです。
COMポートはDB-9/DB-15（別名RS-232シリアル、またはUART）コネクタを使用し、これらのポートのコントローラーはPCハードウェアに物理的にマッピングされ、I/Oスペースの特定のアドレスに割り当てられます。この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、ハイパーターミナルなど）の使用を想定しています。ユーザーの便宜のために、USB-UARTブリッジには、ポートを仮想COMポートとして表すドライバーが付属しています。最新のソフトウェアはすべて、COMハードウェアの仮想化を使用しており、「COMなし」のPCにスムーズに移行できます。 専用FTDIブリッジをMCU開発プラットフォームのUART ports に追加し、ホストPCでFTDIドライバーを使用してUSBポートの外観を作成する） COMポートなど）、または適切なブリッジコードをMCU自体に埋め込む（ネイティブUSB機能がある場合）。
ストレートなアプローチは、 外部USB-to-UARTボード を使用し、UARTを開発中のMCUに配線します。または、ボードにすでにDB- 9コネクタ、そこに直接接続できる SBドングル があります。
すべての場合において、ネイティブのUART MCUの制御は、ホスト側では仮想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などを持っている/持っています。これらはVOLTAGE AND PIN標準であり、プロトコル標準ではありません。ある種のUARTを意味する場合、用語を組み合わせてRS-232と言うのは正しくありません。
UARTがマザーボード上にあり、当時は理にかなっている電圧レベルとある種の標準的なピン配置/ケーブルを備えた、外界へのある種のコネクタが必要だった当時のことです。そのため、さまざまな周辺機器でよく使用される25ピンおよび9ピンの標準が見つかりました。WintelPCの世界では、これは通信ポートまたはシリアルポートと呼ばれることもありました。
もちろん、シリアルデータを伝送するポートは、シリアルポート、SPI、I²C、MDIO、UART、HDLC、SDLCなど、場合によってはUSBやSCSIとも呼ばれます。これで夢中になれるかもしれません。通常、シリアルポートは、UARTで取得できるいくつかのピンを意味します。
Unix/Linuxの世界ではtty/com/serialではなくuartと表示されていますが、同じことです。
今、実装があります。インターフェースを備えたUARTチップを購入できます（そうです、両端にシリアルのSPI UART、またはI²CUARTまたは一部の専用バスまたはUSBなど）。その時代でさえ、UARTの片側には、最終的にCPUが通信していたバスがありました。今日、FTDIとその他のベンダーがあり、Nice USB UARTソリューションを提供しています。ソフトウェアとUARTの間のインターフェイスのいくつかのレイヤーを変更せず、 UARTには、TTL /チップレベル、RS-232C、RS-422などのインターフェイスがあります。
初期のArduinoでは、Arduinoに電力を供給するFTDI USB-to-UARTボードを頻繁に使用していました。 Arduinoボード自体にUSB電源とシリアル/ UARTがあり、それがボード全体でAVRチップのUARTに接続されているものもあります（一部のプロセッサはバスのいくつかの層を備えており、ソフトウェアが反対側にインターフェイスがあるUARTと通信します。この場合、チップ電圧レベル（TTL）でAVRのエッジのピン）。
UART機能は何十年も変更されていないため、ソフトウェア用語やソフトウェアアプリケーションでさえアプリケーションレベルで変更する必要があるのはなぜですか？マザーボードのUARTチップに対して10〜15年前にLinux/Unix TTYアプリケーションを作成します。現在でも、USBがTTLレベルまたはUSBで動作する可能性は十分にあります。 RS-232CレベルまたはRS-422または任意のピン/レベル定義。同じことがWindowsにも当てはまります。私は古いコードでもまだ両方で機能します。 Windowsの世界では、COMという用語が使用されています。
私はしばらくArduinoサンドボックスを使用していなかったので、Linuxの場合はそうでしたが、Javaであるプログラムが一般的であり、LinuxでttyS2なのでシステム名を使用している場合でも、驚かないでしょうWindows上のCOM2。
質問をもう一度読むと、これらのAPI呼び出しを使用する既存のソフトウェアの量を利用して、さらに先に進むことができます。何十年にもわたって、この双方向データを考えられるほとんどすべてのソフトウェアに転送するソフトウェアで仮想ポートを作成できない理由はありません。 UARTからイーサネットへの接続は非常に一般的なものであり、サーバーがまだCOM/TTY/RS-232ポートを非常に多く使用するサーバールームでは、接続可能な多数のインターフェイスを持つターミナルサーバーを使用できます。いくつかのサーバーに接続し、反対側にイーサネットを接続し、Telnetを使用しない場合は、仮想COMポートドライバーをインストールできます。
次に、コンピューター上のアプリケーションは、COMポートと通信していると見なしますが、実際には、バイトストリームがイーサネットにホップし、その後、ターミナルサーバーTHENをUARTからRS-232Cレベル（ただし、サーバーへのケーブルのピン配置は必ずしも同じではありません）。
これらのAPI呼び出し用に作成されたソフトウェアが引き続き機能するように、COMポートを仮想化する理由が何であれ、実際のUARTに実際に到達する理由がない場合があります。 UARTインターフェースへのばかばかしい端末を備えた、私たちが今でも使用している古代の銀行ソフトウェアについて考えることができます。おそらく、当時は有線で接続されていたか、モデムに接続して最終的にサーバーになりました。シリアルストリーム（たとえば、TCP/IPなど）としてイーサネットに接続されている仮想COMポートを含むさまざまなエミュレーションを介して、ソフトウェアが引き続き機能するようにすることができます。