2

Arm M/R シリーズ (C++ で開発) 用の RTOS を探しています。誰かが ARM Cortex-M または R シリーズに適した RTOS を推奨できますか? ありがとうございました。

4

1 に答える 1

8

何らかの価値のある回答を得るには、誰かがそれらすべてを客観的に評価する必要がありますが、それはありそうにありません。

人気と適性は必ずしも同じではありません。アプリケーションが必要とする機能を備え、開発ツールで動作し、ライセンス モデルとコストがニーズと予算に合った RTOS を選択する必要があります。

使用するツール チェーンは明確な考慮事項です。カーネルを認識したデバッグとスタートアップ プロジェクトはすべて、開発の成功に役立ちます。一部のデバッガーと RTOS の組み合わせでは、スレッドレベルのブレークポイントとデバッグが可能になる場合もあります。

Keil の MDK-ARM には、優先度ベースのプリエンプティブ スケジューリングとプロセス間通信を備えたシンプルな RTOS と、ファイル システムなどのミドルウェアの選択、TCP/IP、CAN、および USB スタックが追加料金なしで含まれています (ソースコードが欲しい)。

IAR は、EWB で使用するための多くの RTOS 製品との統合を提供します。同社のARM EWB ページには、ビルトインおよびベンダー プラグインをサポートする RTOS がリストされています。

個人的には Keil RTX を使用していましたが、当時 RTX は Cortex-M で成熟しておらず、いくつかの問題が発生したため、Segger embOS に切り替えました。ただし、RTX の測定されたコンテキスト切り替え時間は、embOS よりも高速でした。IAR の EWB は embOS と統合されているため、ツール チェーンにまだ投資していない場合は、おそらくより簡単な方法です。また、Cortex M で FreeRTOS (OpenRTOS と同じですが、ライセンスとサポート モデルが異なる) を評価しましたが、その API は embOS よりも洗練されておらず完全ではなく、コンテキストの切り替え時間が大幅に遅いことがわかりました。

embOS には RTX と同様のミドルウェア サポートがありますが、追加料金がかかります。ただし、代替のオープン ソース ファイル システムとプロセッサ ベンダーが提供する USB スタックを embOS と RTX の両方で問題なくフックすることができたので、ミドルウェアのサポートはすべての場合に重要であるとは限りません。

その他のオプションは Micro C/OS-II です。追加料金で再びミドルウェアをサポートします。そのスケジューラは、他のほとんどのスレッドよりも少し原始的であり、すべてのスレッドに個別の優先度レベルが必要です。これは、非リアルタイム バックグラウンド タスクに役立つことが多いラウンド ロビン/タイム スライス スケジューリングをサポートしていません。これは主に、カーネルの実装を詳細に説明する関連書籍を通じて人気があります。新しい Micro C/OS-III は、スケジューラの制限を克服しています。

極端な例として、eCos はハイエンド機能を備えた完全な RTOS ソリューションであり、Linux などを選択してもリアルタイム サポートと小さなフットプリントが必要な多くのアプリケーションに適しています。

要点は、RTOS がプリエンプティブ スケジューリングと IPC をサポートし、妥当なパフォーマンス レベルを備えていることを読んで理解できるということです (さまざまなコンテキスト スイッチ時間について言及しましたが、範囲は STM32F1xx の 72MHz で 5 ～ 15 us でした)。 ）。そのため、成熟度 (ターゲットで RTOS が利用可能になった期間 - リリース ノートを参照して、成熟度に到達するまでの時間と発生した可能性のある問題を確認することもできます)、ツールの統合、API が適切かどうかなどを調べます。意図したソフトウェア アーキテクチャ、ベンダーまたはサード パーティからのミドルウェア サポートの枯渇、およびライセンスが必要です (それを購入する余裕はありますか? また、意図した方法で合法的に展開できますか?)。

C++ の使用に関しては、ほとんどの RTOS で C API が提供されます (C++ で記述された eCo でも)。C コードはバイナリ レベルで C++ と相互運用可能であるため、これは実際には問題ではありませんが、C++ の能力を有効に活用して、RTOS の選択の重要性を軽減することができます。私が行ったことは、必要な機能を提供する汎用 API を提供する C++ RTOS クラス ライブラリを定義することです。たとえばcTask、cMutex、cInterrupt、 、cTimerなどのクラスがあります。cSemaphoreアプリケーション コードはこの API に記述され、クラス ライブラリは任意の数の RTOS 用に実装されます。この方法では、クラス ライブラリが抽象化レイヤーとして機能するため、多くのターゲットや RTOS をほとんどまたはまったく変更せずに、アプリケーション コードを移植できます。このクラス ライブラリを Windriver VxWorks、Segger embOS、Keil RTX、さらにはシミュレーションとプロトタイピング用の Linux と Windows に実装することに成功しました。

一部のベンダーは、Accelerated Technology のNeucleus C++ for Neucleus RTOS などの RTOS に C++ ラッパーを提供していますが、アプリケーション コードを変更せずに RTOS を変更するために必要な抽象化を必ずしも提供するとは限りません。

RTOS での C++ 開発で注意すべきことの 1 つは、 main() が呼び出される前にmain()C++ が静的グローバル オブジェクトのコンストラクターを呼び出す間に、ほとんどの RTOS ライブラリが初期化されることです。RTOS の初期化前に一部の RTOS 呼び出しが無効になることは一般的であり、特に RTOS 間で異なるため、これが問題を引き起こす可能性があります。1 つの解決策は、C ランタイムの起動コードを変更して、RTOS の初期化が静的コンストラクターおよび の前に呼び出されるようにすることですが、基本的な C ランタイム環境が確立された後です。もう 1 つの解決策は、単純に静的オブジェクトでの RTOS 呼び出しを避けることです。main()

于 2012-08-05T13:39:46.917 に答える