連載企画 CPU 実験教室 実践編 第 4 回 RS232C について

今回は RS232C、つまりシリアル ポートによる通信の解説です。とはいっても、今回解説するのは RS232C の仕様だけで、具体的な通信仕様とモジュールの書き方については次回に回したいと思います。ソフトウェア的なことは cserver を参照してください。

具体的なモジュールの書き方は次回号を読んでねっ！

RS232C のピンについて

RS232C ポートにはピンがいっぱい伸びているけど、通信に使うのはたった 2 本の線、送信線と受信線です。この 2 本は全く無関係に動くので、送受信が同時にできます。他のピンは制御線ですが、仕様が曖昧なところもあり、使用はお勧めできません。むしろたった 2 本の線で通信できるのが RS232C のすごいところなので、これだけで通信しましょう。

ストレート ケーブルとクロス ケーブル

もともと RS232C は PC とモデムの間をつなぐのに使われていた物でした。そのときは、普通に PC から送信する線をモデム側が受信して、モデムが、 PC が受信できるように受信線に送信すればよかったわけです (ストレート ケーブル)。 これを、PC 間、あるいは他の機器と接続するとき、そのまま接続すると、受信線と受信線・送信線と送信線がつながってしまうということが発生してしまいます。そこで、受信線と相手の送信線をつなぐようにしたものを、クロス ケーブルというわけです。

これだけ聞くと当たり前であるように見えるのですが、制御線の定義を各メーカーが解釈したときに、クロス ケーブルの仕様がメーカー間で多少違いが出てきてしまったということがあります。これが制御線を使うのをお勧めできない理由のひとつ。

ちなみに筆者は ModelSim 上でストレート ケーブルでモジュールをつなげてしまうというミスをして、数時間ぐらいはまっていたことがあるので、皆さんは注意しましょうｗ。

in と in , out と out をつなげても ModelSim は警告してくれないよっ！

そんなミスをするとかヒョットしてあんたバカァ？

通信速度

当初の規格では、かなりの低速通信用として開発されたため、baud rate　(多少語弊はありますが、通信速度と思ってくれて構いません)は、110 bps(bit/s) -- 9600 bpsで策定されました。これが、ある程度時間がたつと、遅すぎるということで 14400 bps , 28800 bps が使われるようになり、さらに時間がたって、115200 bps が策定され、最終的に、Windows などで、その倍倍である、230400 bps , 460800 bps , 921600 bps が策定されたようです。

DELL の学科 PC や筆者の PC の後ろについているシリアル ポートは、多分 115200bps が上限 (デバイス ドライバ見てください)、それ以上の速さでは本来プログラムで開けないはずなんですが、TeraTerm では何をしているのか知らないけど、それ以上の速度で通信できているように見えてしまいます (多分実際にはその速度でやり取りしていないと思うのですが...)。入江先生の貸してくれたシリアル to USB を使うと、送信は 921600bps までいけて、受信は 460800bps までいけるようです。最も性能の高いシリアル to USB を使うと 921600 bps ≒ 1 Mbps まで出せるという噂もあります。こういう風に言っているのは、PC 側のシリアルデバイスに比べて、FPGA 基板の方が圧倒的に性能が高いため、たとえ 921600bps でも余裕で受信できるということ (1 bit に数十 -- 数百クロックかかります)。あと、921600bps で contest.sld を実行しても、IO だけで 0.5s かかります。

ちなみに、USB 2.0 以降の通信速度は、旧基板のチップでもシリアルの速度が無視できるぐらい速いよっ！ 旧基板でも概算で 50Mbps かなっ！

信号の電圧について

RS232C の信号は以下のような感じで定められています。

0	+12V
1	-12V

拡張基板上に RS232C ポートを作成する場合は、自分で電圧変換チップを挟む必要がありますが、新基板上では FPGA のピンをいったん電圧調整の石をはさんでソケットにつながっている形になっているので、何も考えずに送信線と受信線に 0 , 1 を出力すれば OK です。

参考文献

• 『RS232C接続回路』 http://www.ccad.sist.chukyo-u.ac.jp/~mito/syllabi/kikou/Serial/

最後に

もし何か意見・質問ございましたら下のコメント欄にお寄せくださいお寄せくださいお寄せください。

さて、次回はいよいよ RS232C の通信方法とモジュールの書き方についての説明ね。あんまり私をがっかりさせないことね

天空への LiLFeS 入門 (QM 法編)

こんにちは。team C# の花元です。今回は学科の後輩向けにLiLFeS (参照1 / 参照2) による QM 法の実装について書きたいと思います。えっ、なんか大変そうなんだけど大丈夫？との声が聞こえてきそうですが、実は QM 法の実装に LiLFeS はとてもオススメです。以下その理由。

1. 論理型言語である
2. lexer / parser がいらない

つまるところ QM 法とは論理圧縮ですから、論理型言語であるというのは大きなアドバンテージです。Prolog？ そんな軟弱な言語有り得ません。lexer / parser がいらないというのも良いですね。LiLFeS ならクエリを実行するだけで大丈夫です。ocamllex / ocamlyacc に飽きてしまった人も是非。

五月祭 2 日目

こんばんは、竹井です。五月祭も無事におわりまして、地上の喧騒から地下の楽園に帰ってきました。

と、ここで大ニュースがありまして、実は今日の五月祭 2 日目、なんと何もしないはずだった情報科学科でも出し物をしていた有志がいたのでありました！ その名も「東大地下を這い出たギークたち'08」という、なんともアヤシゲな雰囲気をかもし出すバンド名。実はこれ、地下、つまりわれわれがいる学生控え室というのは、4 年生の秋になると自動的に各研究室に配属されて、地面よりも高いところ (建物の 3F だとか 4F だとか)、つまり天空に位置する研究室の学生部屋へと移っていくわけでして、去年そうやって地下から地上へと旅立ってゆかれた私どもの諸先輩方のバンドだったのです。まぁこんな感じ↓

バンドの演奏中は、さすがに IS らしく、同じ 2008 の plus7 さんという方が Web カメラで中継してて、14 人がブロードキャスト中継を見ていたらしいです。なおこのバンド、3 人しかおらず、よく見るとドラムと思しき人がいない。いや、よく見なくてもドラムがいない。代わりにあるのは、「ドラマー」と手書きの紙が張ってある Mac のラップトップが。

実は、このボーカルをやってる Mekajiki さんという方が、無類の Apple 好きらしいのですが、こいつからドラムの音を吐かせていたようです。なので曲の始まるときにこうやってポチッとなをする必要があったみたい(笑)

というわけで、来年はわれわれ 2009 年代が引き継ぐべく、バンドをやりたいと思っています。考えたらわれわれの代、ギター、キーボード、サックス、チェロ、トランペット、ファゴット、ピアノ、合唱、指揮者とかなんだかいろいろできる人間がいるみたいですよ(笑) とりあえずこれらを全部ごちゃまぜにしてバンドを組んだら面白いことになりそう。だが！ やはりドラムはいなかった・・・。もういっそ僕がドラムを始めてみようかしら・・・。

---

おまけ: 最近、東大でもわりと残念な集団が神出鬼没にいろんなところでお目にかかれるようですが、総合図書館前ではこんな人たちが踊ってました・・・。企画名は「【東大生に】さんすう教室【踊らせてみた】」 ざっと 30 人程度でしょうか。衣装代もバカにならんでしょうな、、、ご苦労様でした。

五月祭 1 日目

こんにちは、竹井 悠人です。五月祭一日目、結局のところ何だかんだ言って色々と楽しんできました。実は僕自身、去年までの 3 年間はずっと所属している音楽部合唱団の屋台に詰めていて、文化祭らしく友達と企画や展示を見て回ったことが一切なかったのです。そして何より、中高は文化祭というものにそもそも参加した記憶が一切ないという・・・、というわけで僕にとっては非常に新鮮な一日でありました。

えー、というわけで、今日の後半は僕の高校時代の友人と一緒に回りまして、彼の日記のほうがより秀逸にまとまっているので、リンクを張ってしまいます、悪しからず。
東京大学第83回五月祭 @ 雪明りの光合成。 (写真いっぱい)

ちなみに、この記事に出てくる折り紙サークル Orist は、わが班の金沢君が立ち上げたサークルらしいですよ。FPU の高速化に貢献した数学力もさることながら、彼の手先の器用さも侮れないようです。。。

五月祭

おはようございます、班長の竹井です。今日は CPU 実験とはまったく関係ない記事ですが、とりあえず宣伝しておきます。

今週末、つまり今日と明日は東京大学の本郷キャンパスで、五月祭という文化祭をやっております。毎年、いろんな大学の学生や受験生たちなどが訪れ、一般には「勉強ができる」という誤解で認知されている東大生が、実は如何にアホかという企画 初夏の青々とした銀杏に囲まれ建物のレンガには生命力豊かな蔦が絡んでいるアカデミックな雰囲気の中で、如何に社会を支える研究をしてきたかを発表する企画の数々を見ることができます。

ここまでネタを振っておいて残念なお知らせですが、
われわれ情報科学科は何もしません。
何も！

いえ、強いていうなれば、いつもどおり陰湿で澱んだ空気たちこめる地下室で怪しげなプログラムを書いていることでしょう。それを展示すればよい、という考えも無きにしも非ずでしたが、さすがに世間に情報科学の重要性を説くことなく、誤ってプログラマたちの暗い暗い暗黒かつ邪悪なイメージを植えつけることがなきよう自重したのでありました。

というわけで、五月祭は東京大学の本郷キャンパスで今日明日、みんな来てね！

cpu実験最後の3ヶ月 その3

こんにちは。team C#の花元です。班長の竹井くんと一緒に書いています。

時は3月12日、僕は某駅のホームに立っていました。この日から朝のラッシュ時における駅員補助のバイトをすることにしたのです。発表まで時間が少なく、またハードウェア班の4人のうち2人が失踪してしまうという事態に、僕はほぼCPUの完成を諦めていました。しかし、大好きな電車に関われる喜びで、すこしやる気が回復することに。バイトが終わり次第すぐ大学に直行しました。

幸いなことに、エミュレータ係の新井くんがハードウェアデバッグのお手伝いをしに大学に来てくれました。彼が持ってきたのは三角関数のテストコード。これが動けば（浮動小数点数の）四則演算が正しく動くことが証明されます。…が（当然のごとく）動きません。検証の結果、そもそも（浮動小数点数の）足し算がうまくいっていないことが判明。単体テストは通っているはずだし制御機構も間違っていないようだし…半日掛けて原因がわかりました。

ファイル名が違っていた

fp_adderをfp_addと書き間違えていました。…あまりのポンコツっぷりに皆脱力してこの日のデバッグは終了しました。

cpu実験最後の3ヶ月 その2

こんにちは。team C#の花元です。気ままに書いているので更新は不定期ですが気ままにお読みください。

試験後から3月初旬にかけてはずっとコンパイラのデバッグをやっていました。ハードウェア班の僕はCPUでフィボナッチ以上のことがやれるかどうか検証しようとしました。ところが、僕のマシンでアセンブラが正常に動作せず諦めました。今思うとこれは大変な失策でした。後に判明するのですが、この時点で我が班のCPUは整数の足し算と引き算ぐらいしかまともに動かなかったのです。

この時期最も頑張っていたのはコンパイラ係の竹井くん…ではなくてエミュレータ係の新井くんでした。新井くんのが必死でデバッグしている横で、僕と竹井くんが麻雀をやっていたなんてこともあった気が。よくそれで班が崩壊しなかったなーと思います。

そんな彼らの努力により3月10日にプログラムがエミュレータ上で動作。実験発表は3月16日。コンパイラのデバッグに1ヶ月かかったのに、ハードウェアのデバッグが6日で終わるのか？そんな疑問を抱えながら作業はハードウェアのデバッグに突入することになります。(cpu実験最後の3ヶ月 その3へ続く)