同期を取るために必要な謎の呪文
RS-232-Cを使うには、下の画像にある謎の呪文が必要である。これは冒頭で触れた「非同期送受信」が関係する。シリアル通信の場合、同期式と非同期式がある。同期式というのはデータとは別に送受信用のクロック信号を用意し、このクロック信号に合わせて送受信を行なう方式であり、I2CやSPIなどがこの代表例である。
謎の呪文。これはUSBポートに接続したwatt up! Proのもの。物理的にはUSB接続ながら、プログラム的にはRS-232-Cでの接続である
またPCI ExpressやUSB 3.0以降などは、データ信号にクロック信号を埋め込むEmbedded Clockという方式を利用して同期を取っている。これに対し、RS-232-CやUSB 1.1/2.0では、このクロック信号に当たるものが存在しない。
ではどうやって同期を取るか？ という話であるが、RS-232-Cの場合はまず転送速度を最初に定め(上の画像の一番上段がこの設定)、次いでスタートビット/ストップビットを設定する必要がある(スタートビットは1bit固定なので設定はなし)。
このスタートビットというのはデータビット(データの塊：5～8bit)の頭に同期を取るためのダミーbit、ストップビットは同様にデータビットの後ろに付加されるダミーbitである。RS-232-Cの約束として、スタートビットは0、ストップビットは1になることが決められており、一定期間(これはストップビットの設定次第。1/1.5/2bitの設定が可能)1が続いた後で0になったら、その次から読み出しを開始する格好になる。
この1→0になったタイミングでタイマーをスタートし、あとはタイマーに応じてデータビットを読み取る格好だ。ちなみにパリティは、データおよびスタート/ストップビットの値を合わせて、パリティ値を設定することで、通信エラーが起きた場合にこれを検出しやすくするためのものである。ただし、必ず検出できるわけではないし、エラー訂正はできない。
通信速度は75～38.4kbps程度。これは機種にもよる。当初IBM-PCで使われていた8250 UARTでは技術的には最大11万5200bpsの設定が可能だったが、実際の上限は38.4kbpsだった。のちに登場したNS16450と、これに16bytes FIFOを追加して高速転送に対応したNS16550A(NS16550はバグがあってFIFOが動作せず、これの修正版がNS16550Aである)では115.2kbpsが安定して使えるようになり、一部の互換品ではさらに高速な230.4kbpsが可能になった。
Macintoshも確か最高230.4kbpsが可能だったと記憶している。普通に使うにはこれで十分すぎる速度であったが、のちにISDNモデムやADSLモデムが登場すると遅すぎるという不満が出るようになった。これに対応するために、最大920kbpsを発揮するRS-232-Cカードも市場に登場した。当初はISAだけだったが、VL-BusやPCIのものも登場している。
なおUSBの場合、通信速度は1.5Mbpsなり12Mbpsの固定(USB 2.0では480Mbpsが追加された)であり、データの塊(フレームと呼ぶ)を送る前に一定期間のSOF(Start Of Frame)という時間があり、このSOFを利用して速度の検出と送受信の同期を取るようになっている。
話をRS-232-Cに戻すと、通信を正しく行なうためには転送速度とデータビット/パリティ/ストップビットの値を双方の機器で一致させる必要があり、ところがたまに周辺機器をつなごうとしたらこのあたりの設定がわからずに苦労する、なんてことがあったりした。
ちなみにRS-232-Cの信号、先の表でもわかるように、最低限必要なのはRxD/TxD/GNDで、それにフロー制御を加味してもRTS/CTSの5本の信号線があれば通信は可能である。したがって3ピンあるいは5ピンのコネクターが出ているだけ、という機器も世の中には存在した。もちろんこれは機器側の話で、ケーブルの反対側には9ピンないし25ピンのコネクターが付いていた。
またAppleのMacintoshシリーズは8ピンのDINコネクターが採用されていた。ではDCDやRI、DTR/DSRは使われなかったか？ というと、モデム相手にはちゃんと利用された。最初期のモデムは、ユーザーがプロバイダーなりホストなりに電話をかけ、相手が出たらモデムに切り替えるという原始的な接続方法を取っていた。音響カプラを使って通信するのもこれと同じ手順になる。
例えば着信応答機能付きFAXモデム(けっこう普通にあった)を使って留守電機能やFAX受信機能を使ったり、あるいはモデム経由でプロバイダー(やその前だとパソコン通信ホスト)に通信ソフトから電話をかけて自動接続するためにはDCDやRI、DTR/DSRが必須になるために、PCあるいはモデムはこのあたりの信号のハンドリングをきちんと行なっていた。逆にシリアルマウスなどは、そもそもマウスが受信しても仕方ないので、マウスからの送信のみが実装されていたりした。
USBにその座を奪われ、物理的なポートは姿を消すが
プログラム的にはいまだに健在
そんなRS-232-Cであるが、USBの登場で急速にその座を追われることになった。最大の理由はインテルとマイクロソフトが制定したPCxxシリーズである。
もともとUSBが登場したのは、RS-232-Cを含むさまざまなI/F規格がPCの中に混在しており、その設定も大変なら使い分けも大変で、これをもう少しなんとかしたいという目的の元に開発されたが、別に「USBを搭載したPCにRS-232-Cを搭載することはまかりならぬ」という制約はなかったし、当初はUSBも互換性などの面で問題が多かったので両者は共存していた。
ところがマイクロソフトはインテルと共同で、まずWindows 95に合わせてHardware Design Guideを発表。次いでPC 97 Hardware Design Guide/PC 98 System Design Guide/PC 99 System Design Guide/PC 2001 System Design Guideといった仕様を2000年までに相次いで打ち出し、この中で段階的にRS-232-CやそのほかのI/FをUSBに置き換えるように指導していく。
この流れを受けて周辺機器メーカーも次第にRS-232-CからUSBにI/Fを置き換えていき、そうなるとRS-232-Cを搭載しても使われる頻度が減る。結果、まずバックパネルからRS-232-Cが消え(ただしマザーボード上にはポートが用意されており、拡張スロットのブラケットにコネクターを装着する形)、2010年頃にはポートそのものが消えるようになった。
もっとも組み込み用途や古い周辺機器を使いたいというニーズは消えないため、そうした用途向けにRS-232-Cポートを搭載した製品はまだ存在する。またUSBとRS-232-Cの変換アダプターは多数存在しており、例えばArduino UnoをUSBでPCと接続すると、プログラム的にはRS-232-Cで接続されているように見える仕組みだ。要するに物理的なポートが消えても、プログラムから見ればまだRS-232-Cは健在というわけだ。
週刊アスキーの最新情報を購読しよう
