FreeRTOS tips

*以下、ページ番号はfreertos-kernel-dg.pdfのもの

アプリケーション通常運転時に実行することで未使用ヒープスペースが分かる

アプリケーションからもpvPortMalloc()を呼べるのでLuaエンジン内でmalloc()を呼んでいる箇所を全てpvPortMalloc()に置き換えるべき

かつ、malloc 失敗フック関数を利用して失敗を検出するべき

最低優先度 = 0

再考優先度 = (configMAX_PRIORITEIS – 1)

configMAX_PRIORITIES は必要最小値にすべき。値が高いほどRAM使用量が増え、最悪の場合実行時間が長くなる。

アイドルタスクの処理時間を測定することで予備の処理能力がわかる

Configurationでuse_idle_hook = trueにする必要がある

コールバック関数はFreeRTOSスケジューラ起動時に自動生成されたタスク(RTOSデーモンタスク)上で実行される

したがって呼び出し元のタスクをブロック状態に移行させるようなAPI関数は使用禁止

xQueueRecieci()はxTicksToWaitを0にすればブロック状態に移行しないので呼び出し可

ISR内で「FromISR」が含まれていないFreeRTOS API関数呼び出しは禁止

マクロ taskENTER_CRITICAL() と taskEXIY_CRITICAL() 間はタスク切り替えが起きない

注:

・両マクロは確実に対応させ、かつ間の処理は極力短くする必要がある

    コンソールへの出力等は時間が長いのでやめた方が良い

・割込みは発生するが、configMAX_SYSCALL_INTERRUPT_PRIORITYで設定した優先度までの割込みは無効になる

    それ以上の割込みではFreeRTOS API呼び出しは禁止されているのでタスク切り替えは起きない

ミューテックスの使用でデッドロックのリスクがある

回避案として、ブロック状態を無制限ではなくタイムアウト有で行うこと

タイムアウトした場合エラーではあるがデッドロック発生は検知できる

同一タスクで再度ミューテックスを取得するケースがある場合(ライブラリ関数内でミューテックス取得等)再帰的ミューテックスを使えば同一タスクで繰り返し取得が可能

リソースにアクセスするタスクを一つに限定し、キューを使用してこのタスクにデータを送ることでデッドロックや優先度逆転のリスクを回避できる

イベントグループに使用できるビットは8個までと考えておく方が無難

複数のタスクでイベントグループを使い同期する場合、

最後にビットを立てたタスクがxEventGroupWaitBits()を呼ぶ前に他のタスクにビットクリアされてしまう

この場合xEventGroupSync()を使うことで回避できる(ビットのクリアは自動的に行われる)

configASSERT()を使用するとランタイムデバッグに役立つ

但しコードサイズが大きくなり実行が遅くなる

configASSET()の定義をしないと削除される

アサーションが失敗した時点で実行を止めるべき


Comments

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です