Top -> FreeRtos -> memory-man.html
メモリ管理
[More Advanced]
タスク、待ち行列あるいはセマフォが作成されるたびに、 RTOS カーネルは RAM を割当てなければなりません。
malloc () とfree() 関数がこの目的のために使われます、しかし・・・。
  1. これらは、組み込みシステムで、常に利用可能であるというわけではありません
  2. 貴重なコードスペースを取ります、
  3. スレッドセーフ、ではありません、そして
  4. 決定論ではありません(関数の実行にとられる時間量は呼び出毎に異なるでしょう)
・・・それで多くの場合代わりのスキームが必要とされます。

組み込み / リアルタイムシステムは非常に異るRAM割当ての条件とタイミングを選ぶことになります。

一つの RAM 割付けアルゴリズムは、あるアプリケーションのサブセットに適切だと言うだけです。この問題を切り抜けるために、メモリ割付 API は RTOS ポータブルレイヤ − に含められます。
開発しているリアルタイムシステムにアプリケーションに特定された適切な実装を提供することができる。 リアルタイムカーネルが RAM を必要とするとき、 malloc () を呼び出す代わりに、pvPortMalloc () のコールをします。 RAM を解放するとき、free() を呼び出す代わりに、リアルタイムカーネルは vPortFree () のコールをします。
このスキームがソースコードダウンロードに含められます
3つのサンプル RAM 割付けスキームが FreeRTOS ソースコードダウンロード(V2.5.0以降)に含まれる。 これらは種々のデモアプリケーションによって適切に使われます。
次のサブセクションは利用可能なスキームを記述して、そしてそれらの用途をデモするデモアプリケーションを提示します。
それぞれのスキームがsource/portable/MemMang ディレクトリに位置し、別個のソースファイル(それぞれ heap_1.c 、 heap_2.c と heap_3.c)に含まれます。 もし必要とされるなら、他のスキームも加えることができます。
スキーム1 − heap_1.c
これはすべての中で最も単純なスキームです。 それはRAM割り当てをしますが解放は許可しません、にもかかわらず驚くほど多くのアプリケーションに適しています。
RAM のリクエストがされるときのアルゴリズムはただ一つの配列をより小さいブロックに細分します。 アレイの全体の大きさはFreeRTOSConfig.h の中でdifine configTOTAL_HEAP_SIZE によって設定されます。
このスキーム:
  • もしアプリケーションが決してタスクあるいは待ち行列をデリートしないなら、使うことができます(vTaskDelete () あるいは vQueueDelete () へのコールが決してされない場合)。
  • 常に決定論である(常に1ブロックを返すのに同じ量の時間を要します)。
  • PIC 、 AVR と8051のデモアプリケーション − によって使われます
    vTaskStartScheduler () が呼び出された後、これらは動的にタスクを作成あるいはデリートをしません。
カーネルがスタートされる前に、すべてのタスクと待ち行列が作成されるなら、 heap_1.c は多くの小さいリアルタイムシステムの使用に適しています。
スキーム2 − heap_2.c
このスキームはスキーム1と異なり適合度アルゴリズムを使って、前に割当てたブロックを解放することを許します。しかし大きいブロックの中の隣接した空きブロックを結合しません。
また(スキーム1と同様に)全体の利用可能RAM容量はFreeRTOSConfig.hの中のdefine configTOTAL_HEAP_SIZE によってセットされます。
このスキーム:
  • アプリケーションが繰り返して vTaskCreate () / vTaskDelete () あるいは vQueueCreate () / vQueueDelete () を呼び出すときも使用できます(pvPortMalloc () と vPortFree () への多数のコールを起こす)。
  • もし任意の大きさのブロックが割り当てられ、解放されものであるなら、使うべきではない − デリートされるタスクが異なったスタック深度を持っているか、あるいはデリートされる待ち行列が異なった長さのものであった場合がこれに当たる。
    メモリフラグメンテーション問題がアプリケーションで予想できない順序で待ち行列とタスクのブロックを作成することがある。 これはほとんどすべてのアプリケーションでありそうもないが念頭におくべきです。
  • 決定論的ではありませんが、特に非能率的でもない。
  • ARM7 と Flashlite デモアプリケーションによって使われます − これらは動的にタスクを作成して、そしてデリートする。
heap_2.c は動的にタスクを作成しなければならないたいていの小さいリアルタイムシステムに適しています。
スキーム3 − heap_3.c
これは標準的な malloc () とfree () 関数のためのラッパーです。 これはスレッドセーフ化するる。
このスキーム:
  • ヒープのセットアップにリンカーを必要とします、同様に malloc() と free() のインプリメンテーションを提供するコンパイラライブラリも。
  • 決定論ではありません。
  • おそらくかなりカーネルコードの大きさを増やすでしょう。
  • PC(x86 シングルボードコンピュータ)デモアプリケーションによって使われます。