2.3. シリアルポートの速度とパラメータを選択する

この 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ビット毎秒です。 でもこれではあまりにも選択の幅が狭すぎます。 低速の国際電話回線では電話をかけられず、かといって、 大きいファイルのアップロードに耐えられるほど高速でもないのです。 ですから場合によっては、必要な速度を選んだ結果、 ソフトウェアの設定がもっと特殊なものになってしまうかもしれません。

Figure 2-2. 拡張 BNF 記法で表したシリアルビットレート構文

<速度> ::=  <数字列>
<数字列> ::= <数字> | <数字><数字列>
<数字> ::= 0 | 1 | … | 9

<パリティ>

パリティビットの種類と、パリティビットが 1 の場合の解釈

使用できる値は、パリティ無しの場合は n 、 1 ビットの偶数パリティなら e 、 1 ビットの奇数パリティなら o となります。

この中でも、パリティ無し、 および 8 ビット幅のデータを使うことをお奨めします。

パリティを使う場合は、普通偶数パリティを用います。

パリティはエラーを検出する基本的な方法です。 最近のモデムに備わっているエラー検出機能とエラー訂正機能は、 ずっと性能が良いものになっています。 しかし結果的にパリティビットが保護するのは、 モデムとシリアルポートの間のケーブル上のデータだけですから、 そのケーブルのエラー発生率が低ければパリティビットは不要です。 実際、ケーブルのエラー発生率はたぶん低いと思います。

Figure 2-3. 拡張 BNF 記法によるシリアルパリティ構文

<パリティ> ::= n | e | o

<データ>

一文字あたりのデータビット数

Linux で使っているのが、最低でも 7 ビット必要な ASCII 文字セットなので、 使用できる値は 7 ビットか 8 ビットです。

データ幅は 8 ビット をお奨めします。 これならリンクを簡単にファイル転送で使えるし、 英語以外のテキストが現れても大丈夫です。

Figure 2-4. 拡張 BNF 記法によるシリアルデータビット構文

<データ> ::= 7 | 8

<ストップ>

ストップビットタイム数 [5]

使用できる値は、12 です。

ストップビットタイムには 1 をお奨めします。

RS-232 ケーブルが非常に長い場合は、 2 ストップビットタイム必要かも知れません。

1.5 ストップビットタイムというのを時折見かけることがあります。 これは、1 ストップビットタイムで済ますにはリンクが長すぎるし、 2 ストップビットタイムが必要なほどには長いわけでもない場合に、 データのスループットをあと 4 パーセント上げるためにそうしているのです。 でも 1.5 ストップビットタイムというのは危険すぎるので、 今ではめったに使いません。

Figure 2-5. 拡張 BNF 記法によるシリアルストップビット構文

<ストップ> ::= 1 | 2

<フロー制御>

使用するフロー制御のタイプ

Linux カーネルでは、無手順と CTS/RTS のフロー制御が できるようになっています。

デフォルトは無手順です。これを表す場合は <フロー制御>を省略します。

推奨するのは CTS/RTS のフロー制御です。 シリアルポートへのログインアクセスもできるようにもなっている場合には、 特にお奨めです。 これは r という <フロー制御> で表します。

CTS/RTS のフロー制御は、 文字の流れを調整するものです。コンピュータが文字を伝送するのは、 モデムが "Clear To Send" をアサートしてからです。 コンピュータ側に文字を受け取るだけの充分なバッファがあれば、 コンピュータは "Ready To Send" をアサートします。 だから、コンピュータのバッファもモデムのバッファも、 飽和してオーバーフローするというようなことはありません。

Caution

カーネルの CTS/RTS によるフロー制御は、現時点ではバグが多いです。 フロー制御が有効になっていても、 CTS がアサートされないと、 コンソールメッセージの表示に著しく時間がかかることがあります (モデムに着信していなかったり、 ヌルモデムケーブルやケーブルでターミナルサーバー接続しても、 セッションが無い場合にこうなります)。 カーネルのスタート時にカーネルメッセージが大量に出ると、 その結果、カーネルの CTS/RTS フロー制御を組み込んで構成したマシンでは、 リブートに何分も時間がかかることがあります。

ですから、現時点ではカーネルの CTS/RTS フロー制御はお奨めできません。 筆者はカーネルパッチを持っています。 これがカーネル本体に反映されることを強く希望しています。

しかし、ユーザー空間のアプリケーションで使用する CTS/RTS フロー制御はカーネルのバグとは無関係ですから、 getty にはやはりこのフロー制御をお奨めします。

Figure 2-6. 拡張 BNF 記法によるシリアルフロー制御の構文

<フロー制御> ::= <nil> | r

現時点では、カーネルは RS-232 のステータスラインを無視します。 ですから、 "Data Carrier Detect" と "Data Set Ready" がアサートされていなくても、カーネルメッセージは出力されます。 この結果、カーネルメッセージは、 アイドル状態でコマンドモードになっているモデムに送られることになります。

コンソールが CTSDSR、それに DCD をいいかげんに解釈すると、 RS-232 のマルチドロップ回線に、 シリアルコンソールを接続できなくなります。 マルチドロップ回線には、コンピュータが 3 台以上あり、 従来は 4 芯のケーブルか衛星通信サービス、 あるいは無線サービスを使用しています。

Linux のカーネルでは Figure 2-7 にある構文を使って、シリアルパラメータを記述します。 ブートローダーの多くが使っている構文は、 Linux カーネルが使っている構文のバリエーションです。

Figure 2-7. 拡張 BNF 記法によるカーネルのシリアルパラメータ構文

<モード> ::= <速度><パリティ><データ><フロー制御>

<モード><ストップビット> が入っていないことに注意して下さい。 カーネルは、ストップビットの数は当然 1 だと思っているのです。 ですから長い RS-232 ケーブルをつなげる場合には、 この欠点を考慮する必要があります。

ほとんどのブートローダーでは、 9600n8 がデフォルトになっていますが、 昔の端末になると、9600e7 が一般的なデフォルトになっています。

たいていの Linux ソフトウェアやモデム装置では 9600n8 がデフォルトになっているので、 できればこれを使って下さい。

この HOWTO では、 常にシリアルポートの速度とパラメータを設定しています。 厳密には必要無いところであってもそうしています。 こうしておけば、推奨値や一般的なデフォルトになっている 9600n8 以外のパラメータを設定している人たちに、 変更すべき箇所がわかるからです。

Notes

[1]

邦訳は Serial-HOWTO です。

[2]

邦訳は Modem-HOWTO です。

[3]

bps

[4]

この違いについては、筋の通った理由はありません。 この奇妙な点を修正するパッチを linux-kernel メーリングリストに遠慮なく投稿してください。

[5]

ビットタイム というのは、 1 ビットの転送に要する時間のことです。 信号の ビットタイム とデータの ビット の違いは、 1.5 ビットタイムの信号というのはあり得るけれども、 1.5 ビットのデータというのはあり得ない、 ということを考えれば明らかです。