組込みプレス Vol.2

組込みプレス　Vol.2にETロボコンの記事と開発環境のCDROMが掲載された。
記事のいくつかとCDROMの開発環境は私の執筆・編集による。
今回、私のメインの記事はC言語を用いた論理回路開発の話で、
自作CPUと自作コンパイラで組込みシステムを作ろうというものだ。
CDROMは例によってLiveCygwin環境を元に、記事に関連するデータを収録した。

組込みプレスにはそのほかSESSAMEからも大勢の執筆者が出ており、
昨日のSESSAME例会ではサイン大会が開催されたそうな（私は遅れていったので
その場には居合わせなかったが・・）

経済産業省の後押しもあり、このところ組込み関係の情報が多く発信されつつある。
今まで、組込みって外からは分かりにくいものだっただけに、このように
情報が発信されることはよいことだと思う。

SESSAME例会の後の懇親会で、
組込み技術者にはMが多いような気がするという、話をした。
はたかれても、踏みつけられても
一寸の虫に五分の魂、しぶとく生き残っていこう♪

飛行船ロボコン

今日はロボコン本番の日
アーキテクチャ委員も朝８：００にお台場の科学未来館に集合
夕べも未来館で調整作業をしていたため、朝早く出てくるのは
さすがにしんどく、みんなが泊まっている日本橋の宿を取った。
さて、今日はちゃんとみんな飛ばせるかなぁ～

（インフラは今回はばっちりOKの・・はず）

Xilinx ISE WebPackのLinux版

雑誌原稿の校正をしながら、確認のため、Xilinx社のホームページを
チェックしていたら、無償FPGAツールであるISE WebPackにLinux版が
出ていることに気がついた。
（編集部に指摘されたのだが7.1になってプロジェクトファイルの拡張子が
変更になっている。こういったユーザ資産への考慮はXもAも今一なのである。）

Linux版のISEがあれば、Windowsでの開発はほとんど必要なくなるかも？
少なくとも職場のマシンには是非入れておきたい。

ALTERA社もLinux版を持っているのであるが、Web版には提供していない。
各社ともXを見習って欲しいものだ。

今朝までに校正を終わらせるはずが、明かりをつけたまま寝てしまって、
ちょっと焦り気味・・・　今日は、会議で東京にでなくてはならないから、
早めに終わらせなくては。

サンプルコンパイラの拡張

結局、関数の引数自由度の増加、関数引数の局所変数化など
結構大掛かりな改造を行うことになった。

今回、引数の局所変数化と引数の数の制限緩和にともない、
引数渡しを全てスタック経由にしてしまったので、
レジスタ渡しの前のコンパイラに比べ、若干関数呼び出しが
遅くなってしまった。

IP-ARCHのWEBよりダウンロード可

自作CPUとコンパイラのエンハンス

テキストのCPU用のコンパイラが大きなプログラムを容易にコンパイルできるように
ほんの少しだけ、命令セットの拡張を行った。
ただし、講習会で行う内容に影響が出ないように、テキストにある命令は
バイナリコンパチブルで、クロック数を含めて全く同一となるように実装した。

追加命令を扱えるようにアセンブラも改造したが、
ついでにラベルの自由度を上げることにした。

もともと教育用に作成しているため、シンボルテーブルを持たず
L000から始まる数値を含んだラベルだけを扱っていたが、
コンパイラの拡張に対応可能なようにラベルはシンボルテーブルを
用いて管理することにした。

これらの改造にともない、コンパイラも、前は関数は１つだけしか許さなかったのを
自由に関数を定義して使えるようにした。

もちろん、コンパイラの生成するコードは、コンテストの課題にしていたから
従来のソースコードを与えたときには完全に一致するコードを出さなくては
ならない。

新しい機能をサポートするコンパイラは別に作ったほうが楽かもね。

ルネサスM16C用 GNU Cコンパイラ

RedHat社がgccプロジェクトにルネサスM16C用のコードを寄贈したというので、
CVSツリーを取ってきてコンパイルをトライ。
まずは、binutilsからコンパイルするが、M16Cは実はM32Cの一モードとして
実現されているので、ターゲットはM32Cでなくてはいけない。
binutilsのビルドは問題なく出来たので、次にgccのビルド。

ところが、xgccが実行可能コードを吐かないというエラーで途中で止まる。

CVSツリーはリリースバージョンとは全然違うので、これ以上追求しても
無駄であり、このあたりであきらめることにしよう。

このチップ、アドレス範囲が24ビットと16ビットのモードがあり、
gccのようなマルチターゲットのコンパイラには難物である。
無償版のルネサス製コンパイラを用いると最適化は出来ないが、
そもそも最適化が役に立つような状況ではこのチップは用いないから
gccなぞ必要ないといえばないのであった（笑）

セグメント保護例外

自分のソフトに喰わせる、ある記述で、SEGVというエラーメッセージが出るという話。
原因は文法ファイルでは記述しにくいシンタックスエラーなので、
コードジェネレーション時に検出するべきところ、検出ルーチンが
入ってなく、NULLポインターを参照しようとしたのである。

ランタイムにOSがSEGVを検出するのであるが、SEGVというのは何とも
ピントはずれなメッセージであるといつも思う。
NULLポインター参照とかいうメッセージにしてくれればいいのであるが・・

とまぁ、OSのメッセージに文句を言っても仕方がないのである。

文法ファイルでエラーを検出できるとずいぶん楽になり、
特にエラー箇所のテキストまで特定できるのであるが、
コードジェネレーションで検出すると、自前で全部やらなくては
いけない上に、エラーテキストがモジュールの最後の(})となって
情報量がなくなってしまう。

このあたりを何とかしようとしたら、やはりケースを細かく分類して
文法ファイルで全て書き下すしかないのだろう。
言語仕様がブロック構造の最下位の動作のいくつかが上位構造によって
選択的に実行できるような構造になっているため、ブロック構造の
記述という、最下位動作以外に何も違わない似て非なる文法記述を
たくさん書かなくてはいけないのは、どうも気持ちが悪い。
他の手段としては、レキシカルアナライザのトークン切り出しと
シンタックス処理系を連携し、再帰下降だけに任せず自前の処理で
判定するというもの。
これはうまく行きそうだけれど、二つの系の間の独立性を弱めるので
ソフトウェア設計的にはきれいではない。

とりあえず、全体の再構成は少し時間をかけて検討しよう。

たかがスペース（FPGA CPU動作顛末記）

グランドの弱いH社のFPGAボード（A社のFPGA搭載）をあきらめ、
X社のFPGAボードにプラットホームを変更して、サンプル回路を実装中であるが、
これがまた全く思ったように動作せず、ずっと対策を検討していた。
A社は無償ツールのCDROM掲載の返事が遅く、結局CDROMには収録をしないことにしたので、
私としてはAでもXでもどちらでもかまわなくなったのである（笑）

X社の無償ツールはA社のと異なり、細かな情報が見えないので
なぜ動かないのかが不明なまま、アドホックに論理を変更しては
試すという作業を昨日から散々していた。

FPGA合成ツールでコンパイルして、ボードにダウンロードして試す作業を
何回やったか分からないが、全く動く気配がない。

CPUを回路から削り、シンプルにしたバージョンを別のディレクトリに作成し、
そちらで試すと思ったように動いている。
う～ん、このCPU記述がX社のつぼにはまったか？などと考えながら、
問題点を推定しようと考えるのであるが、合成メッセージをいくら眺めても
おかしそうなところは見当たらない。
CPUのシミュレーションだけでは、問題点が見つからないのかと、
実装用の周辺回路まで含んだシミュレーション環境を新たに作成し、
検証するけれど、どう考えてもシミュレーション上は思ったように動いている。

行き詰って、ベッドで横になっているうちに、いつの間にか寝ていた。

夜中におきて、コーヒーを飲んで、再度トライしていたが変わらず、
ふと、合成ツールのファイル一覧を見ると、「あれ？ピン配置ファイルが読まれていない！」
ことに気が付く。
ピン配置を自動にしたら、プリント基板上の配線とは全く関係なく
信号ピンがアサインされるから、これは動くわけがない。

Makefileのワークディレクトリへの転送指示にもれがあったので、
それを修正し、再度合成。

う～ん、やっぱりピン配置ファイルが読み込まれない？

動いている別ディレクトリのバージョンとつき合わせて考えると、
プロジェクトファイルの中でピン配置を指定する行の上に
スペース行が一行入っている以外の違いはない。

普段のプログラム言語等の感覚だとスペース行は無視するのが普通なのだが、
これはもしかして、と考えてスペース行を削除。

再度、ワークディレクトリをすべて削除した後、コンパイル・ダウンロード

な～んだ、ちゃんと動くじゃないか～

ということで、めでたしなのであるが、本日中に記事を作成しなくては・・

実は、動いたばかりで、LEDにはデバッグ用にCPUの命令アドレスを
出しているだけなので、これから記事用に微調整が必要である。

飛行船通信ユニット試験

今日は、MDD飛行船ロボットチャレンジのアーキテクチャチーム試作機の調整を行った。
前回の調整で、通信ユニットはパケットにプリアンブルさえ付ければ、ほぼ完と
話をしていたので、すぐに終了する（つもりだった）。

毎度のことながら、こういった前例のない仕事には不安定さがつきもの。
今回は、前回のプログラムにプリアンブルをつけただけなので、ソフトウェアの
基本は同じはず・・が、電波が出ない！
M氏は必死でソフトの不具合を探すが、どうにも見つからない。

う～ん、と唸っているので、持ち込んでいた、対向試験試作機と
送受を交換してみようということにして、試験を実施すると、
ちゃんと送信しているように見える。
では、マイコンのモジュールを交換してみようという話になり、
交換すると、無事電波が出て、ちゃんと通信できた。
では、だめだったマイコンモジュールを対向試験機に設置すると・・
やっぱりだめだ～！
F氏のモジュールが壊れているのか・・・
と、話は一件落着のはずだが、話はここで終わらず、実はしばらくすると、
届いていたメッセージが途絶えた！

げげ、てことは、このプラットホームが怪しいのか？
ここに挿したマイコンはどんどん破壊されていくとしたら大問題だ。

などと、色々考えながら、動かなくなったモジュールを再度対向試験機にセット。
完動を確認。

ふと、プラットホームを見ると、プルアップ抵抗の半田が外れている。
オシロスコープを付けたりする作業最中に外れたらしい。

状況を整理すると、どうやら、壊れたのは1モジュールだけで、他は大丈夫との
確信がもてたので、動くもの同士で対向試験実施。

微弱電波の強度はそれほど強くはないのだけれど、試験では９ｍ程度まで
ほぼ抜けなくパケットが到着した。今日は、基地局アンテナは細いホイップに
しているが、本番ではダイポールにする予定なので、到達距離はさらに
伸びる可能性が高い。

ということで、少なくともRF通信に関しては、事前試験は完了。

M氏、お疲れ様でした。

モデルロケットHAMANA-2打ち上げ

台風一過の朝、予定の朝一番の時間にはまだまだ風が強く、モデルロケットの
発射規定である風速８ｍ以内を満足しないため、時間設定を変更。
他の会議スケジュールを邪魔しないように、公開イベントではなく
プライベートイベントとして参加チームだけを射場に集めた。
風は強く吹いたり凪いだりと忙しく変わるけれども、風向きはほぼ一定のため、
発射台に設置して風の具合を見て、可能なタイミングを計り打ち上げた。
6発の打ち上げを行ったが、Kさんのロケットだけは回収不可能な場所に
流されロストしてしまった。上空に行ったところで、風が吹いて流される
可能性を考えて、パラシュートには大きく穴を開けておいたのであるが、
それでも見えないところまで流されていった。

その一機はともかく、他のロケットはそれぞれ一応の成果をあげて
打ち上げが無事に終了した。

ところが、閉会式でK氏は「データは取れませんでした」と宣言。
むむ、Wチームはちゃんと搭載カメラでリアルタイム画像の取り込みを
してきたし、別のK氏もデータ回収は成功しているのに、「取れませんでした」は
ないだろう～

我々が来年への課題を検討していたのに対し、来年の会議は7月中旬に
変更になるとアナウンス。

７月中旬だとうちのチームは出られない可能性が高いなぁ・・

浜名湖周辺に８：３０集合！

ということらしい。
25日は早起きが必要だ。
距離にして２５０ｋｍくらいかな？
前の日に実家に泊まれば１００ｋｍ程度なので、6時に出れば十分か。
浜名湖周辺の朝の渋滞状況が分からないけれど、こんなものだろう。

試射ということなので、マイロケットも持ち込もうかなぁ・・

LiveCygwinは、IP ARCH, Inc.のホームページに
最新版を置いた。これは問題だったバッチファイルの多くをプログラム中に
押し込んだので、CDROMのロックや、排他制御ファイルの消え残りが
多少は改善されるはずと期待している。
（もちろん、ユーザが実行中に再起動したりすれば全然だめなのだが）

最終的にはWindowsアプリケーションにして終了イベントをモニタできるように
しないとだめなんだろうなぁ。それは少し長期的な目標としておこう。

LiveCygwin再び

しつこくLiveCygwinの安定稼動について考えている。
結局、Windowsのレジストリが競合するのがいけないのであるから、
Cygwinのソースコードを変更して競合を避けたバージョンを
収録すればよいはずだ。
Cygwinのツールセットをすべてコンパイルするのか・・・
これをしてしまえば、今まで苦労してきたことは、ほぼ問題はなくなる。
（０ではないが、少なくとも、おかしなことがあったら再起動してというだけですむ）

自分のPCのディスク空き容量との兼ね合いもあり、いまいち踏ん切りがつかないが
手順だけは確立しておこう。

Quick Hackで、レジストリの競合がない形にcygwin1.dllを修正してみた。
二つのCygwinが同時に動くかと思ったけれど、そうはいかず、
DLLのエントリはやっぱり競合するので、同時動作は不可能であった。
DLLのエントリまで切り替えるのは難しいので、まずはよしとするか。
今回の対策で、他のCygwin実行中にLiveCygwinを動作させたり、LiveCygwinの
実行中に他のCygwinの立ち上げを図ったときのマウントポイントの不整合は
なくなるので、ロックファイル以外の対策はほとんど必要なくなるはず。

今日のバイオリンのレッスンで、音程が不安定になっていると指摘された。
今まではそんなことがなかったのだが、さすがに練習不足もここまで続くと
前に出来たことも出来なくなってくる（笑）

これからはもう少し音階の練習だけでも増やさないといけないね。

クライスラーの曲は弓の使い方が難しい。
レッスンの時にはちゃんと聞いていて、楽譜にも記入してくれているのだが、
時間が経つとすっかり忘れてしまうので、やっぱりもう少し練習時間は
必要なんだよねぇ・・

パルテノン講習会終了

ここ3～4年、講習会の課題はほぼ同じ内容にしているのだけれど、
今年は初めて1チームも課題を完成できなかった。
懇親会が二日目に入ったのが痛いのであるが、これは去年も同じだから、
アンケートを分析して要因を調べないと。
テキストをCDROMにしたことが要因の一つになっている可能性もあるか。
朝、８：３０から部屋を開けて参加者へのサービスをしたのに、
その時間に来ていたのは2チームなので、意欲の問題もあったかな？

でも、I氏が「毎年思うのだけれど、この課題は鬼や」なんて言っていたから
そもそも敷居の高い課題なのか？
CPUの高速化を図る課題なのであるが、サンプルコンパイラへの
入力となる課題ソースコードは変更してはならず、
CPU自体、命令セット、コンパイラ、アセンブラの変更で高速化を試みるという
もので、課題としては楽しいものであるが、ハードウェア記述言語の
講習会の仕上げ課題としては、ソフトもあるので０から始める人には
多少時間の余裕が足りないか？
ただ、ソフトの変更を避けるために命令セットを同じにすると
パイプライン化や演算系の高速化をしなくてはならず、
それはそれで難しさが増すのである。
コンパイラの解説をもう少し丁寧にやるべきか。

（コンピュータ設計の基礎知識を副読本として配布できると、
課題の取り組みにあたって効率がずいぶん良いのであるが、
研究会でこの本を配布なんてしたら、問題ありだよなぁ。）

時間配分的に初日に基礎演習を3時間取れれば、後がかなり楽になるので、
来年の講習会は少しそのあたりをいじろうか。
備忘録：基礎演習、FPGA実装演習には各3時間は必要である。

LiveCygwinの環境はほぼうまく動いた。ただ、LiveCygwinが起動中に
シャットダウンする人が何人かいて、朝、立ち上がらないケースがあった。
シャットダウンイベントはコマンドプロンプトは受け取れないので、
今のところ手はないのであるが、コマンドプロンプトを使わず、全部
プログラム制御にしてしまって、シャットダウン時のシグナルイベントで
後処理をするような構成を考えないといけないか？

さて、そろそろ、たまった仕事を片付けないといけない。
特に、ピエールから依頼された件は、いくら読んでも全然頭に入ってこないので
静かに集中して取り組まないといけないだろうなぁ（23日締め切りなので
崖っぷちに近いのであるが）

来週は22,23が東京、25,26日が浜松出張予定だから、今日はある程度めどを立てないと・・

原因と結果

何事にも原因があって結果があるのである。
PCの世界では某M社の影響からか、相性などという言葉が
まかり通って、動かないととりあえず再起動してみるなどという
乱暴が行われるのであるが、動かないのには動かないなりの理由が
あることを理解していなければ進歩はない。

月末の浜松のイベントに向けて、調整中の彼らは、一応それは分かっている
はずなのであるが、原因の追求手順がまったりしている。
ある結果が出た場合に、どうして、その結果になったのかを
系統的に追いかける思考過程が重要だと思うのであるが、実際に
起きている事象だけを悩んでいて上位の情報をすべて捨ててしまっている。

上位に行くほど情報量は多いのであるから、問題が発生したときに
切り分けのため手を入れるのは、まずは上位の階層からと考えるのが
普通だと思うのであるが・・

かと思うと、自分では何も考えも調べることもせず、ディスプレイの
モード設定まで一々人の仕事を中断させて聞いてくるやつがいる。
今の状況で何が優先で、どこから手をつけなくてはいけないかは
ざっと周りを見回しただけで分かるだろうに、何で5分も調べれば
解決するようなものまで、頻繁に聞きにくるのかなぁ

こういった傾向は必ずしも未経験だからというのではなく、
それなりに社会経験を積んでいるはずの連中にもあったりするのが
大問題なのである。

日本では、技術にかかわればみんなエンジニアだと思っているが、
世の中は認定コースを出た技術者以外はテクニシャンに分類される
というのが流れである。
JABEEを見ていると認定コースなんていうのも大いに怪しいので
所詮は人の問題ではあるのだが、同じ仕事をするなら楽しくできる
人としたいものだ。

Linuxクロス開発環境完成

一度構築できてしまえば、バリエーションは簡単に作れる。
（というか、今回は、以前インストールしたツールがファイルパスの
上限が低く設定されていたのが問題なので、そのツールを消しただけだが）

ということで、i686用Linuxだけでなく、x86_64用Linuxのクロスツールも
コンパイル中。
Zaurus用はもうさすがにいらないか・・

その後、思い直して、Zaurus用も作った。が、思いのほか苦労してしまった。
まず、crosstoolであるが、gcc-2.95.3-glibc-2.2.2で試すが、glibcが
うまく作成できない。Cygwinのgccが3.4.4であり、古いgccのソースの
コンパイルには失敗するのか？
仕方がないので、glibc-2.2.2とLinuxのヘッダファイルはシャープが
提供しているものを使う。
ところが、それでも、gccの構築ができない。
そこで、色々試しながら、gcc-3.3.6を構築してみる。
今度は、Linuxのヘッダがシンタックスエラーだって・・・
Linuxのヘッダを修正し、何とかgcc-3.3.6で環境構築
Zaurusに出来たバイナリを持っていくと、ipk形式は認識してくれない。
むむ・・
tar+gzに直し、再度やり直し
今度は、libgcc_s.so.1がない
gcc3.3.6はシェアードライブラリを余分に要求するのかと、
シェアードライブラリをパッケージに含めるととりあえず動作。

しかし、シェアードライブラリを配布するのはうれしくないので、
再度、gcc-2.95.3の構築を試みる。
まず、configureがこけるのはtrapの書式が古いからで、
Cygwinでこのバージョンのgccを作るときにはみんな困るはずだと
検索していると、crosstoolのアーカイブの中にいくつかパッチが
転がっている。
この中から関係しそうな４～５個のパッチを当ててコンパイル
今度は無事に完成！

でも、ipkが認識されないのはまだ不明

再度トライしてみるか

PS:　どうやら、ファイル名のつけ方が悪かったようで、ファイル名を変更し、
Zaurusのアプリケーション追加から追加できることが確認できた。

ずいぶん長い道のりだったなぁ～