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 つのフォルダがあります。これらのフォルダは、実際に私たちがオペレーティングシステムカーネルを移植するために必要なすべてのソースコードです。
まず、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