Configuration

[API]

Modules

* Customisation
* Memory Management
* Stack Overflow Detection


Customisation

[Configuration]

FreeRTOS カーネルは特定のアプリケーションに適応するため多くの構成可能なパラメータがあります。
これらの項目は FreeRTOSConfig.h ファイルに置かれています。
FreeRTOS ソースコードダウンロードしたデモアプリケーションは、それ自身の FreeRTOSConfig.hを持ちます。
ここに典型例、及び、それぞれのパラメータを説明する:

#ifndef FREERTOS_CONFIG_H
#define FREERTOS_CONFIG_H

/* Here is a good place to include header files that are required across 
your application. */
#include "something.h"

#define configUSE_PREEMPTION                1
#define configUSE_IDLE_HOOK                 0
#define configUSE_TICK_HOOK                 0
#define configCPU_CLOCK_HZ                  58982400
#define configTICK_RATE_HZ                  250
#define configMAX_PRIORITIES                5
#define configMINIMAL_STACK_SIZE            128
#define configTOTAL_HEAP_SIZE               10240
#define configMAX_TASK_NAME_LEN             16
#define configUSE_TRACE_FACILITY            0
#define configUSE_16_BIT_TICKS              0
#define configIDLE_SHOULD_YIELD             1
#define configUSE_MUTEXES                   0
#define configUSE_RECURSIVE_MUTEXES         0
#define configUSE_COUNTING_SEMAPHORES       0
#define configUSE_ALTERNATIVE_API           0
#define configCHECK_FOR_STACK_OVERFLOW      0
#define configQUEUE_REGISTRY_SIZE           10
#define configGENERATE_RUN_TIME_STATS       0

#define INCLUDE_vTaskPrioritySet            1
#define INCLUDE_uxTaskPriorityGet           1
#define INCLUDE_vTaskDelete                 1
#define INCLUDE_vTaskCleanUpResources       0
#define INCLUDE_vTaskSuspend                1
#define INCLUDE_vResumeFromISR              1
#define INCLUDE_vTaskDelayUntil             1
#define INCLUDE_vTaskDelay                  1
#define INCLUDE_xTaskGetSchedulerState      1
#define INCLUDE_xTaskGetCurrentTaskHandle   1
#define INCLUDE_uxTaskGetStackHighWaterMark 0

#define configUSE_CO_ROUTINES               0 
#define configMAX_CO_ROUTINE_PRIORITIES     1

#define configKERNEL_INTERRUPT_PRIORITY			[dependent of processor]
#define configMAX_SYSCALL_INTERRUPT_PRIORITY	[dependent on processor and application]

#endif /* FREERTOS_CONFIG_H */

「環境設定」パラメータ

configUSE_PREEMPTION

configUSE_IDLE_HOOK

configUSE_TICK_HOOK


configCPU_CLOCK_HZ

プロセッサコアが実行している周波数(Hz)を入力してください。
この値はタイマ周辺機器の構成を正確に設定するために必要とします。


configTICK_RATE_HZ

RTOS の割り込み周波数。
チック(システムクロック)割り込みは時間を測るために使われます。そのためにより高いチック周波数がより高い時間分解能で測ることができることを意味します。
しかしながら、高いチック周波数は同じくカーネルのオーバーヘッドが多くなりCPU時間を消費するあろうことを意味します、それで無闇に高くしてはいけません。
RTOS デモアプリケーションはすべて 1000Hz のチックレートを使います。
これはカーネルをテストするために使われて、そして通常必要とされるであろうより高い。
 1つ以上のタスクが同一優先度を共有することができる。 RTOS がタスクを切り替えることによって、カーネルは同じ優先度のタスクの間でプロセッサ時間を共有する。従って高いチックレート周波数は、それぞれのタスクに与えられた「タイムスライス」の時間を減らす効果を持つ。


configMAX_PRIORITIES

アプリケーションタスクにとって入手可能なプライオリティ数。 どの優先度のタスクでも同じ優先度を共有することができます。 コルーチンはこれとは別に優先順位を付けられます − configMAX_CO_ROUTINE_PRIORITIES を参照してください。

利用可能な各優先度はカーネルの中で RAM を消費します、したがって、この値は実際にあなたのアプリケーションによって必要とされるより多く割り当てられるべきではありません。


configMINIMAL_STACK_SIZE

アイドル・タスクによって使われるスタックの大きさ。 一般にこれは(そのMPUの)ポートのデモアプリケーションで提供されるFreeRTOSConfig.h セット値から減らすべきではありません。


configTOTAL_HEAP_SIZE

もしあなたのアプリケーションが FreeRTOS ソースコードダウンロードで提供されたサンプルメモリ割付スキームの1つを利用するなら、この値を使う。 それ以上の詳細についてはメモリ・コンフィグレーション・セクションを参照してください。


configMAX_TASK_NAME_LEN

タスクを生成するとき、タスクに与えられた記述名の最大許容長。 長さはNULLターミネータ・バイトを含めた文字数で指定する。


configUSE_TRACE_FACILITY

 もしトレースビジュアリゼーション機能を利用可能とするならば、1にセットし、
使わない場合は0をセットする。
 トレース機能を使う場合同時にトレースバッファも供給しなくてはならない。


configUSE_16_BIT_TICKS

 時間は「チック」(システムクロック)で測ります、それはカーネルが開始されてからチック割り込み回数です。 チックカウントはタイプ portTickType の変数に持ちます。

configUSE_16_BIT_TICKS を1とすることは portTickType を無符号16bit タイプとして(typedef 'ed)定義されます。 configUSE_16_BIT_TICKS を0とすることは portTickType を無符号の 32bit タイプとして(typedef 'ed)定義されます。

 16ビットタイプを使った場合8/16ビットアーキテクチャでは大いにパフォーマンスを改善するが、しかし最大時間周期が65535チックに制限されます。 従って、 250Hz のチック周波数を仮定すると、 16bit カウンターが使われる場合タスクを遅延、あるいはブロックすることができる最大時間は263秒です、対して32bit カウンターを使うと、17,179,869秒となります。


configIDLE_SHOULD_YIELD

このパラメータはアイドル状態の優先度におけるタスクの行動をコントロールします。 次の場合のみ効果を持つ:

1.プリエンティブなスケジューラーを使用。
2.ユーザアプリケーションはアイドル状態の優先度で走るタスクを作成します。

同じ優先度を共有するタスクはにタイム・スライスする。 タスクのいずれもプリエンティブされないと仮定する、優先度が同じタスクは同量の処理時間を割り当てられるであろうと想定されるかもしれません、

そしてもし共有された優先権がアイドル優先度の上にあるなら、このケースはあり得ます。

タスクがアイドル状態の優先権を共有するとき、挙動は少し異なり得ます。 もしアイドル状態の優先度においての他のタスクが実行する準備ができていたなら、 configIDLE_SHOULD_YIELD が1にセットされていると、アイドル・タスクはすぐに(実行権を)譲るでしょう。 これは、アプリケーションタスクがスケジューリングに対して実行可能であるとき、アイドル・タスクは最小量の時間しか消費しないことを保証します。 下に示されるように、この挙動は(アプリケーションの要求によっては)望ましくない効果を持つことがあります:

この線図はアイドル状態の優先権において4つのタスクの実行パターンを示します。 タスクA、BとCはアプリケーションタスクです。 タスクiはアイドル・タスクです。 コンテキストスイッチが T0 、 T1 、が・・・時に通常の周期で起こります、 T6 。 アイドル・タスクが実行権をタスクAに譲る− しかしアイドル・タスクはすでに現在のタイムスライスのいくらかを消費しました。これはタスクIとタスクAが効果的にタイムスライスを共有するという結果をもたらします。 従ってアプリケーションタスクBとCはアプリケーションタスクAより多くの処理時間を得ます。
この状態は避けることができます:


* もし適切であるなら、アイドル状態の優先権において別個のタスクの代わりにアイドルフックを使う。
* アイドル状態の優先度より大きい優先度で全てのアプリケーションタスクを作成する。
* configIDLE_SHOULD_YIELD を0にセットします。configIDLE_SHOULD_YIELD をセットすることはアイドル・タスクがそのタイムスライスの終わりまで処理時間を譲ることを阻止します。 これはアイドル状態の優先権においてのすべてのタスクが等しい量の処理時間を割り当てられることを保証します。しかしアイドル・タスクに割り当てられている時間が処理時間より大きい事を犠牲にして。

configUSE_MUTEXES

ビルドに mutex 機能を含めるには1にセットする。
あるいはビルドから mutex 機能を除外するには0をセット。
 読者はFreeRTOS.org 機能でmutexes とバイナリセマフォの間の相違に精通するべきです。


configUSE_RECURSIVE_MUTEXES

ビルドに回帰的な mutex 機能を含めるには1にセットする、
ビルドから回帰的な mutex 機能性を削除するには0をセットする。


configUSE_COUNTING_SEMAPHORES

ビルドに計数セマフォ機能を含めるために1にセットする、
ビルドから計数セマフォ機能を削除するための0をセットする。


configUSE_ALTERNATIVE_API

ビルドに'alternative'待ち行列機能を含めるために1にセットする、
ビルドから'alternative'待ち行列機能を削除するために0にセットする。
'alternative' API は queue.h ヘッダファイル内に記述されています。


configCHECK_FOR_STACK_OVERFLOW

スタックオーバフロー検出のページはこのパラメータの使用を記述してあります。


configQUEUE_REGISTRY_SIZE

待ち行列レジストリは2つの目的を持っています、両方ともカーネル対応デバッギングと結び付けられます:
1.それは原文の名前がデバッギング GUI の中で容易な待ち行列同定のために待ち行列と結び付けられることを可能にします。
2.それはそれぞれの登録された待ち行列とセマフォの位置を定めるためにデバッガによって必要とされるインフォメーションを含んでいます。

あなたがカーネル対応デバッガを使っていないなら、待ち行列レジストリは目的を持っていません。

configQUEUE_REGISTRY_SIZE は登録することができる待ち行列とセマフォの最大値を定義します。
カーネル対応デバッガを使って見るべき、待ち行列とセマフォのみ登録する必要があります。
より多くの情報がvQueueAddToRegistry()とvQueueUnregisterQueue() のAPI のリファレンスドキュメンテーションにありますので参照してください。


configGENERATE_RUN_TIME_STATS

The Run Time Statsのページにはこのパラメータの使用を記述してあります。


configUSE_CO_ROUTINES

ビルドにコルーチン機能を含めるために1にセットする、
ビルドからコルーチン機能を削除するために0にセットする。
 コルーチンを含むためには croutine.c をプロジェクトに含めなくてはなりません。


configMAX_CO_ROUTINE_PRIORITIES

アプリケーションコルーチンにとって設定可能なプライオリティ数。
どんな優先度のコルーチンでもが同じ優先度を共有することができます。


configKERNEL_INTERRUPT_PRIORITY and configMAX_SYSCALL_INTERRUPT_PRIORITY

configKERNEL_INTERRUPT_PRIORITY は現在 Cortex-M3 、 PIC24 、 dsPIC と PIC32 ポートにだけあります。
configMAX_SYSCALL_INTERRUPT_PRIORITY は PIC32 と Cortex M3ポートでのみ現在利用可能です。
他のポートもまもなくアップグレードされるでしょう。
Cortex M3のユーザの特別注意がこのセクションの終わりにあります!
configKERNEL_INTERRUPT_PRIORITY は最下位優先度にセットすべきです。

次のディスカッションで「FromISR」で終わる API 機能だけが割り込みサービスルーチンの中から呼び出すことができることに注意してください。configKERNEL_INTERRUPT_PRIORITY を実行するだけのポートのため、configKERNEL_INTERRUPT_PRIORITY がカーネル自身によって使われる割込み優先度を設定します。API 関数を呼び出す割り込みがこの優先度おいて同じく実行しなくてはなりません。API 機能を呼び出さない割り込みがより高い優先度で実行ても、(ハードウェア自身の限度内で)決してカーネルアクティビティによって実行を遅らされる事はない。
configKERNEL_INTERRUPT_PRIORITY と configMAX_SYSCALL_INTERRUPT_PRIORITY 両方のインプリメントするポートのために:

configKERNEL_INTERRUPT_PRIORITY がカーネル自身によって使われる割込み優先度を設定します。
configMAX_SYSCALL_INTERRUPT_PRIORITY がそれから割り込みにとって安全な FreeRTOS.org API 機能が呼び出されることができる最も高い割込み優先度を設定します。

configKERNEL_INTERRUPT_PRIORITY より(すなわち、より高い優先順位レベルにおいて)上記の configMAX_SYSCALL_INTERRUPT_PRIORITY をセットすることによって、フルの割り込みをネストしているモデルが達成されます。API 機能を呼び出さない割り込みが configMAX_SYSCALL_INTERRUPT_PRIORITY の上の優先度で実行し、決してカーネル実行によって遅らせられることがありません。
例えば、8つの割込み優先度レベル − 0が最も低くて、そして7が最も高いようにする仮定のマイクロコントローラーを想像してください(このセクションの終わりのCortex M3ユーザのために特別なノートを見てください)。
見られように、2つのコンフィギュレーション定数が4と0にセットされたなら、下の図はそれぞれの優先順位レベルにおいて可能、不可を記します:

割込み優先度コンフィグレーション例

これらのコンフィギュレーションパラメータは非常にフレキシブルな割込み操作を許します:
* 割込み操作「タスク」が書かれて、そしてシステムで他のいかなるタスクにでも優先順位を付けることができます。これらは割り込みによって起こされるタスクです。
割り込みサービスルーチン(ISR)自身は出来得る限り短く書くべきです、それはデータを拾い、次に高優先順位タスクを起動するだけにします。 ISR は起動されたタスクハンドラーの中に直接戻るように見えます、それ自身 ISR ですべて終わっているかのように、割込み処理は連続的に即時処理されます。
これの特長は、ハンドラータスクが実行中も、すべての割り込みが使用可能なままでいるということです。

* configMAX_SYSCALL_INTERRUPT_PRIORITY これを実装するポートはさらに- 完全にネストされたモデルをカーネル中の割り込みが優先割り込み許可,及びconfigMAX_SYSCALL_INTERRUPT_PRIORITY はネストして、適切な API コールをすることができます。 configMAX_SYSCALL_INTERRUPT_PRIORITY 以上の優先権を持っている割り込みはカーネルアクティビティによって遅らせることは決してありません。

* 最大の syscall 優先度以上で実行している ISR は決してカーネルの機能によって影響されませんからカーネル自身によりマスクアウトされることはない。
これは非常に高い時間的正確度を必要とする割り込み − 例えばモーター整流を実行する割り込み等 − に理想的です。 しかしながら、このような ISR は FreeRTOS.org API 機能を使うことができません。
このスキームを利用するために、あなたのアプリケーションデザインは次の規則に従わなくてはなりません:
(configKERNEL_INTERRUPT_PRIORITY マクロによって構成を設定されるように)、 FreeRTOS.org API を使うどんな割り込みでもカーネルと同じ優先権にセットされなくてはなりません、あるいは この機能性を含むポートのためにconfigMAX_SYSCALL_INTERRUPT_PRIORITY 以下にしなくてはならない。

Cortex M3ユーザのための特別なノート:
割愛


INCLUDE Parameters

'INCLUDE' から始まるマクロは、アプリケーションによって利用されたこのとないリアルタイムカーネルのコンポーネントをビルドから除外することを可能にします。 これは RTOS が、その組み込みアプリケーションで必要とする以上のいかなる ROM あるいは RAM も使わないことを保証します。

それぞれのマクロ形式は・・・。

INCLUDE_FunctionName

FunctionName はオプションとして除外可能なAPI 関数(あるいは関数のセット)を示す場所で・・・。 API 関数セットを含むために、マクロを1にセット、関数を除外するにはマクロを0にセットする。 例えば、 vTaskDelete() API 関数を使用するには:

#define INCLUDE_vTaskDelete 1

あなたのビルドから vTaskDelete() を除外するには:

#define INCLUDE_vTaskDelete 0