ティック周波数をユーザレベル（APIのみ）でいつでも変更できるオプションがあれば、有効なティック周波数に到達するパラメータは何か（考慮する）？ダニが速すぎると、私はカーネルレベルで多くの実行を終わらせるでしょう。ダニが遅い場合、私はリアルタイム基準を欠場するでしょう。優先度の高い準備スレッドのうち最も早い時期のプロファイリングを行うべきですか？これは特定のOSではなく、より一般的な質問です。RTOSのティック周波数をどうやって決めるのですか？
ティックレートは、望ましい応答性を処理するのに十分速くなければなりません。
アプリケーションでタイムアウト/再スケジュール/遅延が必要な場合は、マイクロ秒単位で、1000ティック/秒（1ティック/ミリ秒）のティックレートが遅すぎます。ただし、アプリケーションの遅延が50ミリ秒であれば、50000ティック/秒の速度が明らかに過剰です。
ほとんどの場合、あなたのプロセッサは、要求されるティックレートを処理するのに十分速いと期待できます。そうでない場合は、おそらくコードアーキテクチャーやハードウェアの選択を再考する必要があります。
これが役に立ちます。
通常、RTOSでは、1つのティックは1msから10msまで異なりますが、要件とハードウェアプラットフォームによって異なります。私はあなたがこの値を動的に変更する必要はないと考えています。なぜなら、これは実装することができますが、必要ではなく、私が知っているようにこの機能をサポートしていません。
そこにあなたのソフトに多くのタイマーを必要とし、acuratestタイムベースYが10ミリ秒に1の間である場合は、NMS（1 < N < 10、N < Y）としてTICKを設定できるの。
タイマーが1マイクロ秒または1ナノ秒の明るさを必要とする場合、私はハードタイマーが正しい選択だと思っています.ISRを使用すると、ISR + TASKが可能です;
TICKの値を大きくすると、時間の基準は低くなりますが、同時にシステムのオーバーヘッドが小さくなります。
逆に小さいティックでは、より高い時間ベースを得ることができますが、システムオーバーヘッドが大きくなります。
TICKがあるポイントまで下がると、アプリケーションがCPU時間を取得できないため、システムは実行されず、CPUはRTOS自体をほとんど実行します。