この HOWTO では RS-232 標準の説明はしません。 この標準は正式には、 ANSI/TIA/EIA-232-F-1997 Interface Between Data Terminal Equipment and Data Circuit-Terminating Equipment Employing Serial Data Interchange といいます。 ‘ 1 秒あたりのビット数（訳注：bps）’ とか ‘スタートビット’、 ‘データビット’ 、 ‘パリティ’、 ‘ストップビット’、 それに ‘フロー制御’ についての説明は、 Serial-HOWTO [1] および Modem-HOWTO [2] を参照してください。
カーネルやブートローダー、それにログインアプリケーションで、 シリアルポートのパラメータを設定するコマンドの構文を説明する場合は、 RS-232 の特性を表す以下の変数を使用します。
一秒あたりのビット数で計測したシリアルリンクの速度
最近の PC で動作している Linux カーネルでは、シリアルコンソールの速度として、 1200, 2400, 4800, 9600, 19200, 38400, 57600, 115200（ビット毎秒 [3]） をサポートしています。
シリアルインタフェースをシリアルコンソールで使わなければ、 カーネルがサポートするシリアルビットレートの範囲はもっと広がります。 [4]
ごく最近の Linux カーネルでは、 USB のシリアルドングルを用いたシリアルコンソールを、 1200, 2400, 4800, 9600, 19200, 38400, 57600, 115200ビット毎秒で使えるようにもなっています。
一方、ほとんどのブートローダーがサポートする速度範囲は、 カーネルがサポートする範囲とは違っています。 LILO のバージョン 21.7.5 では、 110, 150, 300, 600, 1200, 2400, 4800, 9600, 19200, 38400, 56000, 57600, 115200 ビット毎秒の速度をサポートしています。 また、SYSLINUX のバージョン 1.67 では、 75ビット毎秒から 56000 ビット毎秒までをサポートしています。 GRUB のバージョン 0.90 がサポートしている速度は、 2400, 4800, 9600, 19200, 38400, 57600, 115200 ビット毎秒です。
シリアルポートで使用する速度は、 ブートローダーと Linux カーネルの両方で同じ速度にしなければなりません。 一つのオペレーティングシステムで、 複数のブートローダーを使っていることがあります。 例えば、 Red Hat Linux では、 オペレーティングシステムのインストールやアップグレードに SYSLINUX を使っています。 Red Hat Linux のバージョン 7.1 以前ではブートローダーに LILO を使い、 7.2 以降は GRUB を使用します。
シリアル端末やダムモデムを使うつもりなら、 その端末やダムモデムのビットレートも、 ブートローダーとカーネルで用いるビットレートと合わせる必要があります。
シリアルコンソールを 9600bps 未満のヘイズ互換モデムと接続する場合は、 そのシリアルコンソールをモデムと同じ速度に設定して下さい。 9600bps より高速のモデムの場合は、 たいてい自動的にシリアルポートの速度と同期します。
ここで選んだビットレートは、シリアルポートの UART 半導体チップでもサポートしていなければなりません。 チップ上に受信バッファが無い初期の UART では、 信頼して受信できるのは 14400bps までにすぎませんでした。 この中には 8250A や 82510、 16450 それに 16550（A 無し） も入ります。受信バッファが付いた最近の UART は、 シリアルビットレート全域で動作します。これに該当するモデルは、 16550A, 16552, 16650, 16654, 16750, 16850, 16950 です。
然るべき理由が無い限り、一般的なビットレートの 9600ビット毎秒 を使って下さい。これが大多数のデバイスの、デフォルトビットレート になっています。
カーネルでも、3種類の一般的なブートローダーでも、それに Linux が 動作する すべての IBM PCs でもサポートしている速度といえば、 2400, 4800, 9600 それに 19200ビット毎秒です。 でもこれではあまりにも選択の幅が狭すぎます。 低速の国際電話回線では電話をかけられず、かといって、 大きいファイルのアップロードに耐えられるほど高速でもないのです。 ですから場合によっては、必要な速度を選んだ結果、 ソフトウェアの設定がもっと特殊なものになってしまうかもしれません。
使用できる値は、パリティ無しの場合は n 、 1 ビットの偶数パリティなら e 、 1 ビットの奇数パリティなら o となります。
Linux で使っているのが、最低でも 7 ビット必要な ASCII 文字セットなので、 使用できる値は 7 ビットか 8 ビットです。
データ幅は 8 ビット をお奨めします。 これならリンクを簡単にファイル転送で使えるし、 英語以外のテキストが現れても大丈夫です。
使用できる値は、1 か 2 です。
ストップビットタイムには 1 をお奨めします。
RS-232 ケーブルが非常に長い場合は、 2 ストップビットタイム必要かも知れません。
1.5 ストップビットタイムというのを時折見かけることがあります。 これは、1 ストップビットタイムで済ますにはリンクが長すぎるし、 2 ストップビットタイムが必要なほどには長いわけでもない場合に、 データのスループットをあと 4 パーセント上げるためにそうしているのです。 でも 1.5 ストップビットタイムというのは危険すぎるので、 今ではめったに使いません。
Linux カーネルでは、無手順と CTS/RTS のフロー制御が できるようになっています。
デフォルトは無手順です。これを表す場合は <フロー制御>を省略します。
推奨するのは CTS/RTS のフロー制御です。 シリアルポートへのログインアクセスもできるようにもなっている場合には、 特にお奨めです。 これは r という <フロー制御> で表します。
| Caution |
カーネルの CTS/RTS によるフロー制御は、現時点ではバグが多いです。 フロー制御が有効になっていても、 CTS がアサートされないと、 コンソールメッセージの表示に著しく時間がかかることがあります （モデムに着信していなかったり、 ヌルモデムケーブルやケーブルでターミナルサーバー接続しても、 セッションが無い場合にこうなります）。 カーネルのスタート時にカーネルメッセージが大量に出ると、 その結果、カーネルの CTS/RTS フロー制御を組み込んで構成したマシンでは、 リブートに何分も時間がかかることがあります。 ですから、現時点ではカーネルの CTS/RTS フロー制御はお奨めできません。 筆者はカーネルパッチを持っています。 これがカーネル本体に反映されることを強く希望しています。 しかし、ユーザー空間のアプリケーションで使用する CTS/RTS フロー制御はカーネルのバグとは無関係ですから、 getty にはやはりこのフロー制御をお奨めします。 |
Linux のカーネルでは Figure 2-7 にある構文を使って、シリアルパラメータを記述します。 ブートローダーの多くが使っている構文は、 Linux カーネルが使っている構文のバリエーションです。
ほとんどのブートローダーでは、 9600n8 がデフォルトになっていますが、 昔の端末になると、9600e7 が一般的なデフォルトになっています。
たいていの Linux ソフトウェアやモデム装置では 9600n8 がデフォルトになっているので、 できればこれを使って下さい。
| [1] | 邦訳は Serial-HOWTO です。 |
| [2] | 邦訳は Modem-HOWTO です。 |
| [3] | bps |
| [4] | この違いについては、筋の通った理由はありません。 この奇妙な点を修正するパッチを linux-kernel メーリングリストに遠慮なく投稿してください。 |
| [5] | ビットタイム というのは、 1 ビットの転送に要する時間のことです。 信号の ビットタイム とデータの ビット の違いは、 1.5 ビットタイムの信号というのはあり得るけれども、 1.5 ビットのデータというのはあり得ない、 ということを考えれば明らかです。 |