Overview
G-TuneのFirmware（と言っていいのかどうかよくわからないのですが、本文中ではG-Tuneに載っているソフトウェアそう表現することにします）は、すべてC言語で書かれています。アセンブラ等は使用していません。また、マルチタスクモニタといった類のものも無く、一本のプログラムといくつかの割り込みプログラムによって作られています。プログラムサイズは、バイナリで110K Byteぐらいで、かなり大きくなってしまいました。

図の見方ですが、箱が１つのソースコードの単位だと思ってください。また、上のほうに行くほど、呼び出しの階層が浅い（呼び出し側）になっています。実際には、呼び出し関係がもう少し変なんですが、概要ブロックを理解するにはちょうどいい図だと思います。

■GFM: G-Tune Firmware Main
G-TuneのFirmwareが起動するときに一番最初に実行される部分です。CPUにリセットが入ると、各I/Oの向きやモードを設定して、プログラム内部で使用している変数などの初期化を行います。また、DIP-SWの読み込みを行い、動作モードを決定します。G-Tuneの動作モードは、以下の３つがあります。また、オートモードの場合、GFMより各動作パターンの実行を行います。
　　メンテナンスモード：　パソコンからの指示で動作させたり状態チェックをします。
　　アクティブモード：　プロポからの指示で動作させます。
　　オートモード：　動作パターンの自動再生を行います。

■SOI: SCI Operation Interface
起動モードがメンテナンスの場合にこのソースコードがGFMより呼び出されます。
このソースコードは、SCIを使用してパソコンと情報のやり取りを行い、G-Tuneの動作データの転送や状態の表示、操作などを行います。メニューや画面表示用のデータは、すべてSH7047Fのプログラムとして実装されており、パソコン側はただのシリアル通信端末で操作を行います。結局未完成の部分が多いのですが、以下の機能があります。
　　サーボ操作：　サーボをパソコンのキーボードから直接操作します。
　　動作パターンメンテナンス：　動作パターンの登録、保存、テスト実行を行います。
　　プロポ信号テスト：　プロポからの信号取り込み状態をチェックします。
　　ハードウェアテスト：　DIP-SWの信号取り込み状態チェックなどをします。

■ROI: Remote Operation Interface
起動モードがアクティブの場合にこのソースコードがGFMより呼び出されます。
このソースコードは、プロポからの信号を読み取って各動作パターンや歩行プログラムなどの呼び出しを行います。なるべく操作が直感的になるようにするのが苦労した部分です。プロポからの信号そのものは、RPAが数値化してくれますので、ここでは、それを動作パターン、及び「歩行」、「格闘」などの動作モード管理に変換して、各動作パターンの実行を行っています。

■ASM: Action Script Manager
G-Tuneでは、動作パターンのことを「Action Script」と呼んでいます。これの再生を管理しているのがこのソースコードです。実行を指示されると、該当するAction Script Dataを読み出し、指定された時間でにServo Position Controllerに指示をします。ここでは、「何十ミリ秒でどこまで動きなさい。そのときはそっとスタートしなさい。」等のデータが指示情報として送られます。
角度指示が基本なのですが、脚に関しては角度だけではなく、ニ次元分（横から見た状態）だけは、Y-Z座標で指示する事ができます。G-Tuneのメカが完成してから歩行するまで比較的スムーズにいけたのは、この機能のおかげだと思っています。何しろ、脚を後から前に出すという指示をするのに、(120,20)-(120,-20)といった指示を書くだけで、脚が水平に動きますので。完全なものはできないにしろ、こういった機能は多少でもつけておくと、結構役に立ちます。

■ASD: Action Script Data
Action Scriptのデータです。RAM上に存在しますので、メンテナンスモードにてパソコンから書き換え可能です。

■WSC: Walk Sequence Controller
歩行するためのソースコードです。歩行データ自体は、いくつかのAction Scriptによって構成されているのですが、これの順次呼び出しや停止処理などを行っています。G-Tuneは、歩行開始しだして片足を上げ始めた状態でも、プロポのスティックを中央に戻すだけで、最短時間で停止状態（そのまま脚を降ろします）に戻る事ができます。こういったところが結構ROBO-ONEとかでは効いてくると思うんです。一回指示したら「がーっ」と行ってしまうのは、何が起こるのか分からないリング上では危険かと考えています。今のところ前進歩行のみですが、なるべくこういったロジックが簡単に入れられるよう、Action Scriptも含めて、今後とも改良したいところです。

■SPC: Servo Position Controller
Servo動作させるときに、ASMからは開始点と終了点及び動作時間によって指示が来ますので、サーボを滑らかに動かすため、このプログラムで補間動作を行います。20msec毎のサーボ位置を計算し、Servo Pulse Generatorへ指示をします。今のところ、２点間の補間動作しかないんですが、それなりにはスムーズ動いています。サインカーブを使って補間しているのですが、理由は、「やっぱ格闘といえば基本の動きは円でしょう」（ほんとか？）だからです。でも、いずれはなんとか曲線とかを使って、もっと複数点間での連続したスムーズ動作をさせたいと思っています。

■HIP: High-speed Integer Processor
かっちょいい名前がついていますが、SIN、COS、ATAN、SQRTの計算を行うソースコードです。Y-Z座標系で脚を制御したかったので実装しました。標準でリンクされる計算ライブラリを使用すると、１計算1msec以上かかります（これでもきっとマイコンの中ではすごく速いほうなんでしょう）。しょうがないので超高速バージョンを自作しました。高速化のため、精度はG-Tuneで問題ない程度まで落としています（例えば、ニュートン法を手抜きして、120までしか精度が無い平方根など）。

後で、doubleではなくfloatの計算ライブラリを使うともう少し速くなるのかもしれないということを知りました。みなさん、知ってました？（いいんだい、作ってしまったんだから）

■RPA: Receiver Pulse Analyzer
ラジコン受信機からの信号を解析して数値化します。ラジコン受信機からの信号はすべてIRQ端子に入力しています。SH7047Fには、ON/OFF両方をトリガにして割り込みをかける事ができます。タイマをずっと走らせておいて、割り込み処理の中で現在のタイマ値を読み取る事で、パルス幅を計測しています。

ところが、SH7047F、ONで割り込みが掛かったのか、OFFでかかったのかはプログラムではわかりません。そこで、次のような方法で、ON/OFFを判定しています。ラジコン受信機の信号はサーボ信号と同じで、20msec中に一度、2msec程度のパルスが入ります。簡単に言えば、18msecで割り込みが掛かった後、2msecで割り込みが掛かりますので、この時間によってどちらがONパルスかを判定しています。時間検出にはタイマを使用しており、割り込みが掛かったときの時間を読み取る事でパルス幅を決めています。異なるCPUで同じ方法を使う場合、ON/OFF両方をトリガにできるかどうかが、IRQで処理できるかどうかのポイントだと思います。

■SPG: Servo Pulse Generator
12ch分のサーボ制御パルスを発生するソースコードです。MTU（多機能タイマ）を使用して実現しています。どんな使い方をしているかというと、きわめて普通のモードで「時間が来ると信号を落とす」という機能があるのですが、これを使用して、パルス幅を決めています。やり方は次のようにしています。
　　コンペアマッチレジスタにパルス幅を設定しておきます。
　　パルスを出すタイマ出力端子を全部ONにしておいてタイマーをスタートさせます。
　　時間が来ると勝手にOFFのになります。
　　タイムアップします。次のサーボ制御パルス発生処理に移ります。

また、パルス出力タイミングについては、ハードウェアで解説しているように6ch分のパルスを一度に作る事が可能なのですが、実際には、サーボモータへの突入電流を考慮して、3chづつパルスを出しています。本当に効果があるかどうかはわかりませんけど。

G-Tune Firmwareのフローダイアグラム風の図

不定期TOPIC 2003/09/23より

じゃ～ん。初公開（いつでも何でも初公開ですが…）のG-Tune Firmwareソフトウェアのフローダイアグラム風です。小さくて見えません。しかも手書きです。大丈夫です。クリックすれば拡大した図が出てきます。でも、拡大しても字は汚いのですいません。個人的には、こういう図だけは、ごちゃごちゃ書き入れていくことができるので、大きめの紙に、手書きで書くのが好きでして…。こういうのは、見通しという点では、あまりそれぞれの処理レベルを考えずに書いた方がよいと思います。

図の見方ですが、特にルールはありません。フィーリングです。基本的には、四角枠がソフトモジュールみたいな感じで、角円の枠がデータです。細かいデータとかは書いてありません。それぞれの枠の中には、代表的な名前と処理がメモってあります。

なるほど。こうなっていたのかぁ。マジな話で、お仕事はソフト屋ですが、ここ数年、まともにソースコードは書いていません。やっているシステムが大きいため、人に指示するための資料を作ったり、お客さんと打ち合わせしたり、謝ったり、言い訳考えたり…そんな仕事ばかりです。

そのわりにはいい感じですね～。それぞれの処理の解説は上のOverviewを見てください。やっぱ、SH7047Fで、メモリサイズや処理効率をあまり考えずに作っただけあります。でも大した事やってませんね（笑）。

経験的には、リソースが少ない（メモリ、パワー等）コンピュータ用にプログラムを書こうとすると、どんどん職人芸的になっていく傾向があり、後で見直しても、わけがわからなくなるプログラムになりやすいです。それでも、そこそこの見通し性を維持しようと思うと、こういった大枠のブロック図などでコンセプトを維持することは、大事なことだと思います。