目次前次
ファームウエア仕様検討

　システム設計のブロック図を参照しながら、ライントレーサ
　としての動作を考えてみます。

　動くためのシーケンスを考えてみると、わかりやすくなります。

　次のように、動作を分解してみましょう。

システム初期化
スタートトリガー処理
カメラから画像データ入力
画像データから、走行パターン作成
モータ駆動
３にもどる

　動作シーケンスから、スタートボタンが押されたなら
　ゴールするまで、画像取得→画像解析→モータ制御と
　繰返せばよいと理解できることと思います。

　画像取得→画像解析→モータ制御と繰返すのは、動いて
　いる間だけです。システムで考えると、初期化以外にも
　接続しているハードウエアやメカのテストができないと
　扱いにくくなりますね。

　そこで、リアルタイムOSを導入し、各動作をタスクに
　分割して扱いやすくします。

　リアルタイムOSに、自作のUSO(Unvoiced Shadow Operating system)を
　使います。（USOに関しては、他のページを参照してください。）


タスク分割
　リアルタイムOSを使う場合、タスク分割作業が最も難しいと言われています。

　USOは、基本的に「タスクの状態だけを変更する」としてある
　ので、関数を並べていく手軽さで、システム動作をタスクに
　分割できます。

　システム動作を、次のシーケンスにしてみます。

テストデバッグ処理
スタート、ストップトリガー処理
カメラから画像データ入力
画像データから、走行パターン作成
モータを動かす
２にもどる

　システム内の各動作を決めたなら、タスクに処理を入れます。

　USOでは、タスクは、すべて「tskx_proc」（ｘは、０から１５）と
　いう関数名にするので、上記の内容をタスク関数にまとめます。

tsk0_proc テストデバッグ処理
tsk1_proc スタート、ストップトリガー処理
tsk2_proc カメラから画像データ入力
tsk3_proc 画像データから、走行パターン作成
tsk4_proc モータ駆動

　これでは、タスク処理の内容を決めただけで、繰返しの
　メカニズムが入っていないので、動作できないのではと
　考えるでしょう。

　リアルタイムOSを導入すると、繰返しはリアルタイムOSに
　一任できます。そのカラクリは、非常に簡単です。
　各タスクは、状態をもっています。リアルタイムOSは、この
　状態を、時間やタスクの依頼で変更します。

　具体的に、どうやるのかというと、タスク１（tsk1_proc）で
　タスク２、タスク３、タスク４の状態を変更します。

　システム起動時は、各タスクの状態を次のようにしておきます。

tsk0_proc READY   テストデバッグ処理
tsk1_proc READY   スタート、ストップトリガー処理
tsk2_proc SUSPEND カメラから画像データ入力
tsk3_proc SUSPEND 画像データから、走行パターン作成
tsk4_proc SUSPEND モータ駆動

　タスクを上の状態にすると、USOはタスクの状態を順番にみて
　いき、READYであればRUNに変更し、タスクにCPUを使わせます。
　タスクがCPUを使い終わると、次のタスクの状態を見て、同じ
　ことをします。

　SUSPEND状態にあるタスクは無視して、次のタスクの状態を
　見にいきます。

　USOを使うと、上の状態にあるタスクは、次のように動きます。

tsk0_proc(テストデバッグ処理)実行
tsk1_proc(スタート、ストップトリガー処理)実行
１にもどる

　常に、このような動作を繰返していますが、tsk1_procで
　スタートトリガーが入ると、タスク２～タスク４の状態を
　SUSPENDからREADYに変更します。

　　タスク状態変更には、USOが用意しているシステムコール
　　rsm_tskを使います。

　タスク１で、タスク２～タスク４の状態を変更すると、次の
　ような状態に置き換わります。

tsk0_proc READY テストデバッグ処理
tsk1_proc READY スタート、ストップトリガー処理
tsk2_proc READY カメラから画像データ入力
tsk3_proc READY 画像データから、走行パターン作成
tsk4_proc READY モータ駆動

　このような状態になれば、システム全体としては、次の
　ように動きます。

tsk0_proc(テストデバッグ処理)実行
tsk1_proc(スタート、ストップトリガー処理)実行
tsk2_proc(カメラから画像データ入力)実行
tsk3_proc(画像データから、走行パターン作成)実行
tsk4_proc(モータ駆動)実行
１にもどる

　ここまで仕様を単純にすれば、ライントレーサのファームウエア
　が難しいものではないことがわかります。

　各タスクの概要を決めます。


タスクtsk0_proc(テストデバッグ処理)
　ハードウエアのテストデバッグをしたいので、シリアルインタフェース
　を使うことにします。

　MCRで利用するとH8/3048Fには、２つのシリアルインタフェースがあります。
　SCI0、SCI1ですが、プログラムダウンロードでも使うSCI1を、利用します。

　シリアルインタフェースは、物理的な接続をするだけなので、プロトコルを
　決めなければなりません。次のようにします。
　　データ転送速度　５７６００ｂｐｓ
　　データ長　　　　８ビット
　　ストップビット　１ビット
　　パリティ　　　　なし
　　フロー制御　　　なし

　プロトコルには、コマンドを定義しなければなりませんが、何をテストデバッグ
　するかを考えなければなりません。

　H8に接続するのは、トリガー用ボタン、モータ、SRAMなので
　これらのテストデバッグができるようにします。




タスクtsk1_proc(スタート、ストップトリガー処理)
　スタート、ストップをプッシュボタンを利用して実現します。
　また、移動スピードを変更できるように、スライドスイッチを使います。



　動作モードをIDLE、RUNのどちらかにしておき、次のように
　他のタスクの状態を決めます。

　動作モードがIDLEで、トリガーが入力された場合
　システムコールrsm_tskを利用して、タスク２～４
　をREADYとします。
    rsm_tsk(TSK_ID2);
    rsm_tsk(TSK_ID3);
    rsm_tsk(TSK_ID4);

　動作モードがRUNで、トリガーが入力された場合
　システムコールsus_tskを利用して、タスク２～４
　をSUSPENDとします。
    sus_tsk(TSK_ID2);
    sus_tsk(TSK_ID3);
    sus_tsk(TSK_ID4);

　プッシュボタンには、チャタリングが発生します。そこで
　タスクを周期的に動かして、チャタリングを除去します。
　周期動作をさせるために、システムコールwai_tskを使います。


タスクtsk2_proc(カメラから画像データ入力)
　カメラとしてc328-7640を使います。



　このカメラは、シリアルインタフェースを持っているので、SCI0に接続します。

　シリアルインタフェースは、物理的な接続をするだけなので、プロトコルを
　カメラに合わせます。
　　データ転送速度　１４４００ｂｐｓ
　　データ長　　　　８ビット
　　ストップビット　１ビット
　　パリティ　　　　なし
　　フロー制御　　　なし

　プロトコルについては、別途説明します。

　シリアルインタフェースで入力したデータを、SRAMに保存します。


タスクtsk3_proc(画像データから、走行パターン作成)
　カメラで取得した画像データは、SRAMに保存されています。

　８０ｘ６０の８ビット階調のデータになっているので、全データを
　入力後、指定ラインを２値化します。




　２値化したデータから指定ラインだけを抽出し、８０ビットデータを
　８ビットデータに変換して、モータのDuty比と回転時間を決定します。



タスクtsk4_proc(モータ駆動)
　他のタスクで、モータのDuty比と回転時間が決められているので
　H8内部のモジュールを利用し、モータを回転させます。

　時間は、タイマー割込みを利用して、最小分解能１ｍｓを生成し
　その倍数をカウンタに設定して対応します。

　モータ制御には、パワートランジスタを利用します。



　フォトカプラを利用して、H8の電源とモータの電源を完全に
　分離します。ノイズや逆電圧による破損を回避するためです。

　回路図では、2SA1020を利用していますが、モータ電流を
　１Ａ以上流せるデバイスであれば、トランジスタでもＦＥＴ
　でも構いません。
目次前次