連載企画 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へ続く)

4 年生になりました

こんにちは、そしてお久しぶりです。無事に理学部 情報科学科で 4 年生になった竹井です。気づけば CPU 実験も終わり、新しい 3 年生たちも加わり、われわれの学生控え室もにぎやかになっていました。

今年の 3 年生たちは、僕たちの代とは違って非常にマジメなので、もういろいろと CPU 実験のことを打ち合わせしだしているようで、この拙い拙い日記をたどって僕たちの過去の修羅場を見ているみたいなのですが(笑)、記事の更新がストップしてるので、なんだか寂しいと言われてしまいました。そういうわけで、ちょっとずつ、もうすこし役に立つ記事を提供しようということで、折を見てまた更新を再開しようかと思ってます。

ちなみに近況報告をしますと、4 年になった僕らは、この夏学期、各研究室の巡回 (情報科学演習 3 という科目) がありまして、3 つの研究室をまわって各研究室の中で課題を遂行する、ということをしています。C# 班のメンバも行き先がバラバラなのですが、コンパイラ係と班長を担当していたわたし竹井は最初、細谷研究室というところに行ってきました。脳科学の仕組みを情報科学に落とすようなことをしているところです。ハードウェアを担当していた花元は平木研究室で GPU 向けの CUDA を研究していたそうです。他には高機能なシミュレータを作ってくれた新井はソフトウェア全般を扱う米澤研究室へ、数学を駆使して浮動小数点処理装置を最適化していた金沢は並列数値解析などを扱う須田研究室へ、グラフィックに強い岡原は CG 全般で日本をリードしてる西田研究室へ、Apple を愛して止まない梶原は UI を扱う五十嵐研究室などなど、見事なまでに全員がバラバラです(笑) まぁでも、結構みんななんだかんだ言って、ちゃんと自分にあったテーマを選んでるんじゃないでしょうか。

ではでは、ぼちぼちまだ更新を不定期ながらはじめると思うので、どうぞよろしく。竹井 悠人がお送りしましたー。

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

こんにちは。team C#の花元です。お久しぶりです。皆様いかがお過ごしでしょうか。

とりあえず、更新が滞った1月からの話をすると、新年、team C#はキューバ危機的な何かに陥っていました。これまでの方針では、教科書通りのcpu(1stアーキテクチャ)を完成させた後、班独自のcpu(2ndアーキテクチャ)を作るという計画だったのですが、コンパイラ係兼班長の竹井くんが突然未完成の1stアーキテクチャの破棄及び2ndアーキテクチャによるcpu作成をエミュレータ係とハードウェア係に指示してきたのです。これにエミュレータ係とハードウェア係は猛反発。team C#は新年早々瓦解の危機(?)を迎えることになります。

ハードウェア係の僕は結局どうしたかというと、班長の指示に従う事にしました。これで動かなかったら班長を全力でdisってやろうと胸に抱きつつ。理由は幾つかあって、1stアーキテクチャはその時1ヶ月程度原因不明のバグ(後に実に下らない原因であることが分かるのですが)に悩まされ続けていて埒があきそうにないこと、ハードウェアのバグ取りにはコンパイラ係によるテストコードの作成が必要不可欠で対立するととても動きそうにないこと、コンパイラ係は1stアーキテクチャでの仕事を完成させていて動かなくても単位は来そうなことが挙げられました。うーん、立場が弱い。

エミュレータ係も仕方なく2ndアーキテクチャへの移行に了承します。こうしてteam C#は瓦解の危機から脱することができました。と言っても当然のことながら毎週の進捗報告で指導教官の不安を買うことになり、1週間で簡単なプログラム(フィボナッチ数を求めるプログラム)を動かせなかったらteamに強制介入されることになりました。

こうなると班長の意欲は最高潮に達し、徹夜でコードを書いて眠い僕を叩き起してデバッグさせるという素晴らしいプロジェクトマネージメント能力を遺憾なく発揮させつつ、自身も1日中ハードウェアのテストコードを機械語で書き続ける(その時点ではアセンブラがなかったので)という偉業(?)を成し遂げました。結果、2日でフィボナッチ数を求めるプログラムがハードウェア上で動くように。2ndアーキテクチャの開発が認められるようになります。

ここで試験期間につき一時活動を停止(試験の記事も誰かが書いてくれるかもしれません)。開発は試験後に持ち越され、注目はハードウェアから2ndアーキテクチャ用のコンパイラにしばらく移ることになりました。(cpu実験最後の3ヶ月 その2へ続く)

最後の追い込み

竹井です。短い記事で失礼。

えーと明日の実験発表会まであと 13 時間なわけで、地下には夜にもかかわらず 20 人もの人がいるという異常事態です。。。現状で動作している班は、超 ksk 班、喰いタン班、C# 班です。なんか例年の傾向では 3 班動けば豊作だそうで・・・、実際打ちの班の記録も去年の最速班の記録を抜いてますから (・・・むしろ去年の記録がひどかったみたいですが)

とりあえず、明日のプレゼンテーションに備えて、みんな最終調整をしている中、われわれ C# 班はベスト コンディションでプレゼンに望むという作戦に出るので、全員帰宅です(笑) では僕も帰ります、おやすみなさい

うごいたー

えーっと生存報告です。あけましておめでとうございます(笑)

C# 班、実機で動きました！
これで単位がくる！

失礼しました・・・、また別のポストで報告します。明後日が発表会ですしね。