組み込みソフトウェアの場合、OSSといえどもターゲット基板は必要です。
作業効率を考えれば、基板は作業机に置いてあって電源さえ入れればいつでもデバッグ出来るという環境が理想です。しかしながら、自宅で趣味でソフトウェアを開発するとなると、そのような環境は、なかなか難しいものです。
そこで、今回は私の開発環境をご紹介します。
収納方法
基板はAmazonの配送箱に収納しています。
配送箱にはいくつか種類がありますが、私が使っているのはピザボックス風の平たいものです。
箱の蓋の部分は、そもそも開け閉めを考えていないため、事務用の玉紐を貼り付けています。
これはある程度の年齢の方なら昔はよく見たもので、紙製のワッシャの間に紐をからげて封をするものです。強い力は必要ありませんので、蓋は玉紐で十分です。私はキングジムの『とめるマルタック』を買いました。これはシールになっており、簡単に取り付けることが出来ます。
で、蓋を開けるとこうなっています。
基板はサンハヤトの接着式基板スタンド『SPT-600』で箱に留めてあるため、多少揺すっても動きません。目的は収納であって持ち運びではありませんので、これで十分です。
ケーブル類も同じ箱に入れていますが、巻き取り式のUSBケーブルを使って絡まないようにしています。また、巻き取ることが出来ないものについては、ベルクロを使ってまとめています。
実験をするときには、箱から取り出さずにこのままPCの横に持ってきて通電しています。荒っぽい方法ですが、箱から取り出さない分、逆に安全と言えます。また、箱の深さがそれなりにあるため、テストピンにケーブルを接続したまま収納できることも利点です。写真では多少見にくいですが、基板上でテストピンとして出ているUARTのポートには、USB-シリアル変換ケーブルが刺しっぱなしになっています。このケーブルは、Rapsbery Pi用にたくさん販売されているTTL信号レベルのもので、ドライバ無しでWindowsやLinuxで使えます。
このように、取り回しが良くなるように工夫しているため、収納場所（クローゼット）から取り出して以下の接続を行うまで2分とかかりません。
- 電源
- TRX-305のコンソール（USB）
- BlackfinのICE（USB）
- BlackfinのUARTポート（USB）
開発環境
開発環境は例によって、VMWare Workstation上のUbuntuです。
開発環境にVMを使う利点は、開発作業を中断して別の作業に移る際に、作業状態を丸のままサスペンドして保存できることです。私の場合、開発時はEclipse IDE、端末ウインドウ（複数）、PDFによる資料、Sourceforgeその他のWEBページを開いていますが、これらを開いたまま、ごっそりサスペンドできます。ですので、次回VMを起動したときには、前回中断したところから即座に作業を開始できます。
もちろん、USB接続のような外部との接続は再度やり直しです。とくに、USB-シリアル変換ケーブルを使う場合、ttyポート名は毎回変ると言ってかまいません。そうすると、ターミナル・シミュレータ（Kermit）から見たデバイス名が毎回変わってしまいます。これは新しい名前の指定が毎回必要であるため、なかなか面倒です。
そこで、以下のようなファイルを作って、/etc/udev/rules.d/の下に置くことで、デバイスに対して毎回固有のシンボル名をリンクとして割り当てています（例に挙げたファイルの名前は75-usb-serial-trx305.rules）。
# set USB Seiral port name to avoid the interface of
# other usb serial converter
# for TRX-305 Console USBSeiral conversion module.
ATTRS{manufacturer}=="FTDI", ATTRS{serial}=="AH016Q7S", \SYMLINK+="ttyTRX305-console"
# for TRX-305 DSP USBSerial conversion module
ATTRS{manufacturer}=="Prolific Technology Inc.", \ATTRS{product}=="USB-Serial Controller", SYMLINK+="ttyTRX305-dsp"
この例では、TRX-305のコンソールに使われているUSB-シリアル変換チップをシリアル番号で同定して、”ttyTRX305-console”というシンボル名からリンクを張っています。また、DSPのUART用のUSB-シリアル変換ケーブルは、シリアルナンバーがブランクであったため、代わりに会社名を使ってチップを同定し、”ttyTRX305-dsp”というシンボル名からリンクを張っています。
これらのシンボリック・リンクはデバイス名が変更になっても同じデバイスを指し示すため、端末アプリケーション側から真のデバイス名を心配する必要はありません。
udevのrulesファイルは毎回自分用に一度は書かないといけないのが欠点です。また、経験的に毎回不可解なトラブルに巻き込まれ、回避のためにrulesファイルを何度も書き直すことになります。これが大変面倒なのですが、その面倒を補って余りある利点があるので、私は環境を作るたびにこのファイルを作っています。当然、一度書けば変換ケーブルを交換するまで忘れてしまって結構です。
端末ソフトにはkermitを使っています。あまり機能がありませんが、英数文字列しか使わないデバッグ用途であれば、これで十分です。
kermit用には以下のような設定ファイルを作っています。
set line /dev/ttyTRX305-console
set speed 57600
set parity none
set flow-control none
set carrier-watch off
この設定ファイルはコンソール用ですが、DSPのUARTポートにもラインを /dev/ttyTRX305-dspとした同様な設定ファイルを作っています。
kermitは起動時に設定ファイルをコマンドライン引数として与えることで、設定ファイルを自動実行します。
まとめ
以上のような工夫の結果、「ちょっと実験してみよう」と思い立った時に準備が整うまで、大体4,5分に短縮することができました。
コマ切れの時間の中で組み込み系のOSS開発をしている方は、試してみてはいかがでしょう。