itronで安定した動作するソフトウェアを作るには

前の記事のアンチパターンの悪い悪い所から見るitronの悪い思い込み。

まず、前の記事のソースコードで悪い所がまだありますので、そこを指摘しましょう。

/**************************************************************************/
/**
 * @breaf 機構初期化処理 */
 */
/**************************************************************************/
int feed_init_proc()
{
     ERR err;
     UINT psw;
     FLGPTN ptn;

     PORTC.BIT.B0 = 0;    /* モーターへの電源イネーブル */
     PORTA.BIT.B0 = 1;    /* モーター１を正転 */
     PORTA.BIT.B1 = 0;    /* モーター１を正転 */
     PORTA.BIT.B2 = 0;    /* モーター２を逆転 */
     PORTA.BIT.B3 = 1;    /* モーター２を逆転 */
     feed_seq = 10;       /* 機構シーケンスを10へ */

    do
    {
        dly_tsk(100):     /* 100msディレイ */
    } (sens0_state == 0)  /* センサ０が紙ありになるまで待つ */

    PORTA.BIt.B2 = 0;    /* モーター２ブレーキ */
    PORTA.BIt.B3 = 0;
    dly_tsk(100);        /* 100ms ディレイ */.
    PORTA.BIt.B2 = 1;    /* モーター２正転 */
    PORTA.BIt.B3 = 0;

    ・
    ・
    ・
    ・
    return result:
  }

dly_tsk(100);の精度も相当荒いですけど、基本的な事ですけどitron仕様を忠実に実装しているとすればタスクの優先順位によって、この100msというタイマーは相当なズレが生じます。
それは、itronは時分割でタスクが実行される訳では無いという事です。
社内でもこの事を知らない組み込みプログラマーが多いという事に私も驚かされました。
itronはシステムコールを呼び出す事によってディスパッチ処理が行われ、タスクを切り替えるなり
itronのアイドル処理が実行されます。タスクが切り替わるのは、ディスパッチ処理でタスクがWAIT状態からREADY状態に遷移しているタスクです。また、そこにはタスクの優先順位も関わってきます。
不具合が、dly_tsk()の部分にあると分かってもitronを理解していないとタスクの優先順位を変えて不具合が解消されたので、その部分のみデバッグして評価部門に提出すると、その他の基本動作で不具合が出て、他のタスクの優先順位を変えたり他のタスクに修正を入れたりする場当たり的な修正を行わなければならないという痛い目に遭います。
評価部門で不具合が発生すれば良いですが、微妙なタイミングで不具合が発生する為に市場では大発生で社内では発生せず等というプログラマーとしては最悪な現象が出る事になります。
発生する現象が分かったとしても、そういうベースで作られたソフトウェアの為、対策が思いつかない、もしくはモグラ叩きみたいにあっちを叩いても、こっちが出てくるという憂き目にあって最終的にはその現象が起きない様にオペレーションで注意するという、製品としては欠陥品と言われても仕方無い事になります。

だからitronは時分割じゃないって言ってるでしょ！

どうもマルチタスクといえば時分割で動作するプログラムだと思っている人が多いように思えます。
そして、何故かシステムに制御を戻すという事が理解できない人が多いようにも思えます。
システムへ制御を戻すというのはシステムコールをコールするという事なのですが、どういう訳か処理の途中で無理矢理rot_rdq()とかをコールする人もいるんですよねぇ・・・。

私も処理が長すぎてWatchdog Timerでリセットしてしまうという恥ずかしいコードを書いてしまい、無理矢理rot_rdq()をコールするコードは書いた事はありますが（汗

まぁそういう人への対策は、次からはそういうソフトウェアは作らない様に指導するか、設計規定などで約束事と例を記載して無理矢理にでも更正させるしか無いでしょう・・・。
ソースコードのレビューをするのも一つ手だと思っていますが、時間が無いからすっ飛ばすとか、指摘しても今更変えるとスケジュールが・・・とか言い訳を作って結局、更正できない事も多々あります・・・。

安定した動作するソフトウェア

なんの為のエントリーかというとオレ流のRTOSプログラミングではタスクの優先順位など大ざっぱに高い優先順位と一つ低い優先順位さえあれば安定した動作をするソフトウェアを目指しているという事です。
機構制御を割り込み処理内でプログラミングするというのもその一つです。

※rot_rdq(tskpri) iTronのシステムコールの一つでtskpriで指定された優先順位の先頭タスクをレディー・キューの最後につなぎ替えます。 rot_rdq()の使い方の間違いに関しては別のエントリーにて解説します。