ThreadX カーネル内容紹介#
[!NOTE]
本文画像が多く、自サーバーから移転しておらず、依然として公共の画像ホスティングを使用しているため、画像の読み込みが遅くなる可能性があります。
threadx は eclipse 財団に寄付されており、現在のオープンソースコードはここにあります。
私が通常使用しているのは st 社のフォークで、実際のサポートはあまり良くなく、問題も依然として存在します。
ThreadX カーネルは、ThreadX オペレーティングシステムカーネル、Modules モジュール、trace デバッグモニタリングの 3 つの内容を含んでいます。ThreadX ソースコード内では、これらの内容は多くが混在しています。そこで、簡単にドキュメントを作成して記録します。これは移植チュートリアルでもあり、ライブラリ構造を記録しています。
このドキュメントのすべての画像は、画像に関連する説明文の上にあります。これは threadX ソースコードのすべての内容です。
ここにはシステムカーネルの 3 つのバージョンが表示されています。
common通常のカーネルcommon_moduleモジュールロード機能を持つカーネル、ハードウェアドライバとソフトウェアロジックを完全に分離可能common_smpマルチコア MCU サポートを持つカーネル
カーネル移植の目標は、これらのコンポーネントを使用することです。
- ThreadX オペレーティングシステムカーネル
- Modules モジュール
- Trace デバッグモニタリング
純カーネル移植#
純カーネルは私が言うところの ——modules版カーネルとsmp版カーネルに対して、実際には freertos、bios のような一般的な RTOS 機能と変わりません。ただ、threadX の他のコンポーネントを移植する方が便利で、命名も一貫しています。例えば、NetX、usbX、FileX は非常に簡単にシステムに追加できます。
どれが純カーネルソースコードですか？#
ThreadX オペレーティングシステムソースコード内には、図で囲まれた 2 つのフォルダがあります。この 2 つのフォルダが、実際に私たちがオペレーティングシステムカーネルを移植するために必要なすべてのソースコードです。
まず、common フォルダに注目します。これらは実際に必要なソースコードであり、私たちのプロジェクトに必要なファイルですが、いくつか注意すべき点があります。
stc フォルダ内には、tx_trace_xx という名前のソースコードファイルがいくつかあります。これらは trace デバッグモニタリングに使用されるソースコードです。
このモニタリングを開始する関数の例を挙げると、TX_ENABLE_EVENT_TRACE マクロ定義を使用してモニタリング機能を有効にしない限り、この関数は何も行いません。
inc フォルダ内にも、tx_trace.h というファイルがあります。
TX_ENABLE_EVENT_TRACE マクロ定義を有効にしない場合、ほとんど何も行いません。
ソースコードフォルダに戻り、ports フォルダに注目します。
自分に対応するカーネルを見つけます。
自分に対応するコンパイラを見つけます。ソースコードとヘッダーファイルはプロジェクトに必要です。また、tx_misra.S というファイルが存在する可能性があるため、tx_misra.c がすでに定義されているかもしれないことに注意してください。
ports/カーネル名/コンパイラ名/inc内のtx_port.hファイルについて簡単に説明します。ここは threadX の唯一のインターフェースであり、TX_ENABLE_EVENT_TRACEのようにオペレーティングシステムの機能を有効にするかどうかを制御するマクロ定義を、コンパイラ全体の define 部分に記述できます。
しかし、79 行目に注目すると、別の .h インターフェースが提供されていることがわかります。TX_INCLUDE_USER_DEFINE_FILEマクロ定義をコンパイラ全体の define に記述し、カスタムのtx_user.hファイルを作成してオペレーティングシステムのマクロ定義を制御できます。
このtx_user.hファイルには、オペレーティングシステムソースコードのcommon\inc内にtx_user_sample.hという名前のサンプルファイルがありますが、tx_user.hというファイル名は自分で作成するか、サンプルファイルの名前を変更する必要があります。
common\src には、tx_thread_initialize.c というファイルがあり、実行時に設定状況を確認できる変数があります。この変数は同時に tx_thread.h で extern 宣言されているため、threadX オペレーティングシステムを使用する際には、いつでもこの変数を確認でき、再宣言することはできません。
どのように有効にするか？#
私たちは ac6 コンパイラを使用していますが、gnu フォルダにも注目してみましょう。なぜなら、そこにはタスクを作成するための簡単なサンプルがあります。
ここにあります！
サンプルを簡単に分析します。
- この部分はヘッダーファイルで、tx_api.h だけを含んでいます。
- この部分は main エントリです。
- この部分は固定で自分で定義する必要がある関数で、この関数名は _tx_initialize_kernel_enter () で thread 内核を開始する際に呼び出されます。実際には、内核が開始された後にユーザープログラムに提供されるインターフェースです。
このユーザーインターフェース関数を簡単に分析すると、実際には threadX のいくつかの主要な API を示しており、メモリ空間を要求し、そのメモリ空間を使用してタスクを作成し、メッセージキューを作成し、メッセージ量を作成するなど、一般的に使用される API を示しています。具体的な使用方法はソースコードを参照してください。
全体のサンプルを考慮すると、threadX カーネルを使用するための最も基本的な操作は次のとおりです。
tx_api.hを含める。void tx_application_define(void *first_unused_memory)という関数を定義し、この関数の呼び出し後にタスクを作成します（この時点で threadX カーネルはすでに開始されています）。- メインプログラムで
tx_kernel_enter();関数を呼び出して threadX カーネルを開始します。
サンプルと同じフォルダ内のこのファイルに注目します。
ここにはいくつかの割り込み関数が定義されており、チップの割り込み処理を引き継ぎ、threadX オペレーティングシステムを実行させます。SYSTEM_CLOCKとSYSTICK_CYCLESを修正することに注意してください。図の例では、600000はチップの主クロック周波数が 6M であることを示し、100はオペレーティングシステムのクロック基準が 10ms であることを示します。つまり、tx_thread_sleep(1);は実際には内核を 10ms 解放します。
実際、この .S ファイルには修正が必要な場所があり、いくつかの割り込みが定義されていないようです。最良の方法は、stm32cubeMX を使用して自動生成し、それを自分のプロジェクトに貼り付けることです。オペレーティングシステムが正常に動作しない場合、最も可能性が高いのはこの tx_initialize_low_level.s に問題があることです。
コンパイラ全体の Define に次のように追加します。TX_INCLUDE_USER_DEFINE_FILE
モジュールマネージャー付きカーネル移植#
まず、モジュールマネージャーとモジュールの概念を確認します。
モジュールマネージャーは threadX カーネルを持ち、ハードウェアをドライブする能力があります。特定のストレージメディアからモジュールの実行可能バイナリコンテンツをロードすることができます（例えば、チップ内フラッシュの 0x8100000 というアドレスからモジュールをロードします）。モジュールはハードウェアをドライブする能力を持たず、threadX カーネルがないため、単独では動作できませんが、独立したプロジェクトとして存在し、独立してコンパイルおよび公開できます。
つまり、モジュールマネージャーとモジュールは 2 つのプロジェクトであり、同時に移植するソースコードは異なります。
このようなことを行う必要がある理由については、ここでは議論しません。
モジュールマネージャー付きのソースコードはどれですか？#
あまり気にせず、この 2 つのフォルダを自分のプロジェクトに貼り付けておきましょう。ThreadX オペレーティングシステムソースコード内には、図で囲まれた 3 つのフォルダがあり、これらのフォルダ内にはモジュールマネージャー付きのカーネルを移植するためのすべてのソースコードがあります。
デフォルトで純カーネル移植の内容を確認しているため、基礎カーネルおよび trace デバッグ追跡については一定の理解があると考えています。したがって、これらの内容については繰り返し説明しません。純カーネルと異なる点についてのみ議論します。
common_modulesフォルダに注目します。
モジュールマネージャーのカーネルとして必要なのは、囲まれた 2 つのソースコードフォルダであり、module_lib はモジュール移植用のソースコードです。
あまり気にせず、これら 2 つのフォルダのすべての内容を自分のプロジェクトに含めておき、後で調整します。
ports_modulesフォルダに注目します。
自分に対応するアーキテクチャを見つけます。
自分に対応するコンパイラを見つけます。
必要なのは囲まれた 2 つのソースコードフォルダであり、module_lib はモジュール移植用のソースコードです。
あまり気にせず、これら 2 つのフォルダのすべての内容を自分のプロジェクトに含めておき、後で調整します。
次に、例から見つけるか、stm32cubeMX を使用して自動生成されたtx_initialize_low_level.Sを使用します。stm32cubeMX はモジュールプロジェクトの生成をサポートしていないため、実際には適していません。モジュールを正常に使用するには、多くの適応と操作が必要です。
この図のプロジェクトでは、例から探すことをお勧めします。
純カーネル移植で既にtx_initialize_low_level.Sについて説明したため、繰り返し説明しません。
このフォルダに戻り、txm_module_user_sample.hという名前のファイルを見つけ、コピーしてtxm_module_user.hに名前を変更します。コンパイラ全体の define 設定にTXM_MODULE_INCLUDE_USER_DEFINE_FILEがある場合、モジュールマネージャープロジェクトとモジュールプロジェクトの両方でtxm_module_user.hというヘッダーファイルが呼び出されます（必ず同じでなければなりません）。これにより、オペレーティングシステムの機能を制御します。
txm_module_user.hの内容は大体このようになります。
tx_user.hも作成する必要があることを忘れないでください。純カーネルで説明があります。
どのように有効にするか#
実際には、純カーネルの有効化方法と同じです。ただし、このカーネルを使用する際の標準的な方法は、ビジネスロジックをすべてモジュールとして作成し、ロードすることです。しかし、モジュールプロジェクトの構築や両者の適応はかなり面倒で、まだ完全に理解していないため、文書化は行っていません。
ただし、普通のカーネルとして使用することも問題ありません。
この文は Mix Space によって xLog に同期更新されました。原始リンクは https://www.yono233.cn/posts/shoot/24_7_15_%E6%9C%80%E5%85%A8%E8%AE%A4%E8%AF%81RTOS%E2%80%94%E2%80%94azure_threadX%E7%A7%BB%E6%A4%8D%E6%95%99%E7%A8%8B