ソリューション # ３機能タスクと優先性

前に例題でアプリケーションのタイミング必要条件がどのように３つのカテゴリに分かれ得るか見ました：

1. 厳密なタイミング − プラントコントロール
   前と同じように、高優先順位タスクがクリティカルなコントロール機能性に応じるために作成されます。
2. デッドラインタイミングのみ− 人的インタフェース
   ソリューション # ３が一つの中間の優先度タスク・グループに RS232 、 キースキャンと LED 関数をまとめます。
   前述のように組み込みWeb サーバタスクは低優先度で稼働するが望ましい。 Web サーバのために特にタスクを作成するよりむしろ、アイドル・タスクフックがアイドル・タスクに Web サーバ機能を導入する。 Web サーバは決してブロックしないように書かなければならない！
3. フレキシブルなタイミング − LED
   もし RAM が貴重であるなら、 LED 機能あまりにも単純であり、タスクである必要性は疑問です。 この例ではデモンストレーション上の理由で一つの中間の優先度タスクに LED 機能を含めます。 これは多くの方法で実装されます。（例えば周辺機器のタイマから）。
   イベントが処理を要求するまで、アイドル・タスク以外のタスクはブロック状態にある。 イベントは外部（キーが押される等）あるいは内部（タイマが期限等）です。

1. 待ち行列は中間の優先度タスクはデータ準備完了イベントがあるまでブロック状態で待つことを可能にします - そして直ちにイベントを処理する適切な関数にジャンプする。 これはプロセッサ・サイクルの浪費を妨げます - ループサイクルでイベントで適切なハンドラで処理されるような無限ループ実装と比較して。
2. リアルタイムカーネルの使用は、（アプリケーションソースコードの中で）時間クリティカルなタスクのスケジューリングの明示の必要は無い。
3. ループからの埋め込みの Web サーバ機能の撤去は実行時間をいっそう予測可能にしました。

#define DELAY_PERIOD 4
#define FLASH_RATE 1000

void MediumPriorityTask( void *pvParameters )
{
xQueueItem Data;
portTickType FlashTime;

    InitialiseQueue();
    FlashTime = xTaskGetTickCount();
    
    for( ;; )
    {
        do
        {
            // A
            if( xQueueReceive( xCommsQueue, &Data, DELAY_PERIOD ) )
            {
                ProcessRS232Characters( Data.Value );
            }
            
          // B
        } while ( uxQueueMessagesWaiting( xCommsQueue ) );
        
        // C
        if( ScanKeypad() )
        {
            UpdateLCD();
        }
        
        // D
        if( ( xTaskGetTickCount() - FlashTime ) >= FLASH_RATE )
        {
            FlashTime = xTaskGetTickCount();
            UpdateLED();
        }
    }

    // Should never get here.
    return 0;
}

1. タスクは最初に通信イベントを待つためにブロック状態に入ります。ブロックタイムは比較的短い。
2. データが空になるまで do-while loop を実行します。
   もしデータが空になるよりも速く待ち行列に到着するなら、この実装は修正しなければならない。
3. 待ち行列のデータを空にしたか、あるいはデータが指定ブロック期間に到着しなかった。
   データを待つブロック状態の最大時間は、キーパッドのタイミング条件を満し走査するのに、充分短い事を保証する。
4. LED のフラッシュ時間に到達したかをチェックする。
   この行が実行する周波数でいくらかのジッタがあるが、LED タイミング条件はこの実装によって十分フレキシブルであり満足する。