コンテキストスイッチの時間を決定する際に、RTOSが主要な役割を果たしますか、それともプロセッサが主要な役割を果たしますか?コンテキストスイッチ時間を決定する際の、これら2つの主要なプレーヤー間のシェアのパーセンテージはどれくらいですか。
誰かがuC/OS-II RTOSに関して言うことができますか?
コンテキストスイッチの時間を決定する際に、RTOSが主要な役割を果たしますか、それともプロセッサが主要な役割を果たしますか?コンテキストスイッチ時間を決定する際の、これら2つの主要なプレーヤー間のシェアのパーセンテージはどれくらいですか。
誰かがuC/OS-II RTOSに関して言うことができますか?
どちらも重要だと思いますが、それほど単純ではありません。
実際のコンテキスト切り替え時間は、切り替えを実行するために必要な命令サイクル数の問題です。ソフトウェアの他の場合と同様に、効率的にコーディングされる場合とされない場合があります。一方、他のすべての条件が同じであれば、レジスタセットが大きいプロセッサでは、コンテキストを保存するためにより多くの命令サイクルが必要になります。ただし、レジスタセットが大きいと、他のコードがはるかに効率的になる可能性があります。
プロセッサは、高速コンテキストスイッチングを直接サポートするアーキテクチャを備えている場合もあります。たとえば、低8ビット8051には4つの重複レジスタバンクがあります。したがって、コンテキストスイッチはレジスタバンクスイッチにすぎません(4つ以下のスレッドがある限り)。SiliconLabsが100MIPSで8051ベースのデバイスを生成することを考えると、これは非常に高速です。
より洗練されたプロセッサとオペレーティングシステムは、スレッドメモリ保護を提供するためにMMUを使用する場合があります。これは、追加のコンテキストスイッチのオーバーヘッドですが、それを上書きする可能性のある利点があります。またもちろん、そのようなプロセッサは一般的に高いクロックレートを持っているので役立ちます。
したがって、全体として、プロセッサ速度、プロセッサアーキテクチャ、RTOS実装の品質、およびRTOSによって提供される機能はすべて、コンテキストスイッチ時間に影響を与える可能性があります。しかし、結局のところ、切り替え時間を改善する最も簡単な方法は、ほぼ確実にクロックレートを上げることです。
より多くのヘッドルームがあることは素晴らしいことですが、コンテキストスイッチ時間が評判の良いRTOSでのプロジェクトの成功または失敗の問題である場合は、ハードウェアまたは設計のいずれかの適合性を検討する必要があります。コンテキストスイッチを最小限に抑える設計を目指す必要があります。たとえば、ADC変換に6usかかり、コンテキストスイッチに20usかかる場合、変換完了割り込みを使用するよりも、ビジーウェイトを使用する方が適切です。可能な場合は、DMA転送を使用して、単一のデータ項目のコンテキストスイッチを回避することをお勧めします。
uC / OS-II RTOSはCで記述されており、プロセッサ固有の処理のための非常に特殊なセクション(おそらくアセンブリ内)がいくつかあります。コンテキストスイッチングは、プロセッサに非常に固有のセクションの一部になります。
したがって、コンテキストスイッチの時間は、選択したプロセッサと、uC/OS-IIをそのプロセッサに適合させるために使用される特定のセクションに大きく依存します。すべてのソースコードが利用可能であると思うので、コンテキストスイッチに必要なソースの量を確認できるはずです。また、uC / OS-IIには、パフォーマンス測定コードを追加できるコールバックがあると思います。
クリフォードが言ったことを完全に説明するために、コンテキスト切り替え時間はコンテキスト切り替えをトリガーする条件にも依存するため、主にベンチマークに依存します。
RTOSの実装によっては、スケジューラを完全にバイパスして、最初の待機プロセスに直接切り替えることができる場合があります。
もちろん、これはいくつかのベンチマークで大きな後押しを与えます。
たとえば、信号を配信し、特定のカーネル構成とターゲットアーキテクチャを変更する優先度の高いプロセスに切り替えるために必要なオーバーヘッド(µs単位)を測定するベンチマークを作成します。http: //www.bertos.org/discover/context -スイッチオーバーヘッド