Azure RTOS ThreadX 実践ガイド：タスク管理と通信機能の実践解説

はじめに

本記事では、Azure RTOS ThreadXを使用したマルチタスクシステムの実装を詳しく解説します。ThreadXは、組み込みシステム向けの高性能リアルタイムOS（RTOS）で、Microsoft Azureの一部として提供されています。

本記事の対象読者

ThreadXを初めて使用する方
RTOSの基本概念を学びたい方
マルチタスクプログラミングに興味がある方
実践的なタスク間通信の実装例を探している方

学習目標

この記事を読むことで、以下の知識とスキルが身につきます：

ThreadXの基本的な使い方
タスク（スレッド）の作成と管理方法
メッセージキュー、セマフォ、イベントフラグ、ミューテックスの使い分け
プロデューサー・コンシューマーパターンの実装
優先度ベースのスケジューリング制御

プロジェクト概要

使用ハードウェア

ボード: NXT社製i.MX RT1170リファレンスボード
プロセッサ: ARM Cortex-M7 (最大1GHz動作)
開発環境: MCUXpresso IDE 11.9.0

プロジェクトの目的

本デモプロジェクトは、ThreadXの主要機能を実践的に学ぶために設計されています：

1. 5つのスレッドによる協調動作
2. 4種類の通信メカニズムの実装
3. 優先度制御とタイムスライスの活用
4. センサーデータ処理を模したプロデューサー・コンシューマーパターン

ThreadXの基本概念

RTOSとは

RTOS（Real-Time Operating System）は、リアルタイム性が要求される組み込みシステムで使用されるOSです。決定論的な動作と高速な応答時間が特徴です。

ThreadXの特徴

高速: 最小限のオーバーヘッドで動作
小フットプリント: メモリ使用量が少ない
決定論的: 予測可能な実行時間
優先度ベース: プリエンプティブスケジューリング
豊富な通信機能: キュー、セマフォ、イベントフラグ、ミューテックスなど

スレッド（タスク）とは

スレッドは、独立して実行される処理の単位です。各スレッドは以下を持ちます：

独自のスタック領域: ローカル変数や関数呼び出し情報を保存
優先度: スケジューラがどのスレッドを実行するか決定
状態: 実行中、準備完了、待機、中断など

システムアーキテクチャ

スレッド構成

本デモでは5つのスレッドを使用します：

スレッド名	優先度	タイムスライス	役割
Command Thread	1（最高）	5 ticks	システム全体の制御とコマンド発行
Scheduler Thread	2	なし	イベント監視と高優先度処理
Producer Thread	3	なし	センサーデータの生成
Consumer Thread	4	なし	データの処理と統計更新
Monitor Thread	5（最低）	なし	システム監視とレポート

通信オブジェクト

オブジェクト	用途
Message Queue	センサーデータの受け渡し
Event Flags	複数イベントの通知と同期
Semaphore	バッチ処理の制御
Mutex	共有データ（統計情報）の保護

初期化処理の詳細

main関数の実装

int main(void)
    {
        BOARD_ConfigMPU();
        BOARD_InitPins();
        BOARD_BootClockRUN();
        BOARD_InitDebugConsole();
    
        PRINTF("\r\n=== Azure RTOS ThreadX タスク＆通信デモ ===\r\n");
        PRINTF("- 優先度/タイムスライス制御\r\n");
        PRINTF("- メッセージキュー／イベントフラグ／セマフォ／ミューテックス\r\n");
        PRINTF("- プロデューサー＆コンシューマー＋監視パターン\r\n\r\n");
    
        tx_kernel_enter();
        return 0;
    }

処理の流れ：

1．ハードウェア初期化

BOARD_ConfigMPU(): メモリ保護ユニットの設定
BOARD_InitPins(): GPIOピンの初期化
BOARD_BootClockRUN(): クロック設定（CPU動作周波数など）
BOARD_InitDebugConsole(): デバッグ用シリアル通信の初期化

2．ThreadXカーネルの起動

tx_kernel_enter(): ThreadXカーネルを起動（この関数は戻りません）
カーネル起動後、tx_application_define()が自動的に呼ばれます

tx_application_define関数

この関数はThreadXカーネルによって自動的に呼び出され、アプリケーションの初期化を行います。

1. メモリプールの作成

assert_success("byte_pool_create",
                   tx_byte_pool_create(&demo_byte_pool, "demo byte pool",
                                       demo_memory_pool, DEMO_BYTE_POOL_SIZE));

バイトプールは動的メモリ割り当てに使用されます。本デモでは各スレッドのスタック領域を確保するために使用します。

サイズ: 8192バイト
用途: スレッドスタックの動的割り当て

2. メッセージキューの作成

assert_success("queue_create",
                   tx_queue_create(&sensor_queue, "sensor queue",
                                   SENSOR_QUEUE_MSG_SIZE, sensor_queue_buffer,
                                   sizeof(sensor_queue_buffer)));

メッセージキューの重要なパラメータ：

メッセージサイズ: SENSOR_QUEUE_MSG_SIZE = sizeof(sensor_message_t) / sizeof(ULONG)
キュー深度: 16メッセージ
バッファ: 静的に確保された配列

sensor_message_t構造体：

typedef struct SensorMessage
    {
        ULONG sensor_id;    // センサーID
        ULONG value;        // センサー値
        ULONG timestamp;    // タイムスタンプ
    } sensor_message_t;

3. イベントフラグの作成

assert_success("event_flags_create",
                   tx_event_flags_create(&system_events, "system events"));

イベントフラグは複数のイベントを1つのオブジェクトで管理します：


    #define EVENT_SENSOR_DATA_READY   (1U << 0)  // ビット0: センサーデータ準備完了
    #define EVENT_HIGH_PRIORITY_ALERT (1U << 1)  // ビット1: 高優先度アラート
    #define EVENT_BATCH_COMPLETE      (1U << 2)  // ビット2: バッチ処理完了
    #define EVENT_ALERT               (1U << 3)  // ビット3: 一般アラート

4. セマフォの作成

assert_success("semaphore_create",
                   tx_semaphore_create(&batch_semaphore, "batch semaphore", 0));

セマフォはバッチ処理の制御に使用：

初期カウント: 0（最初はロック状態）
用途: Producerスレッドのバッチ処理開始を制御

5. ミューテックスの作成

assert_success("mutex_create",
                   tx_mutex_create(&metrics_mutex, "metrics mutex", TX_INHERIT));

ミューテックスは共有データの排他制御に使用：

TX_INHERIT: 優先度継承を有効化（優先度逆転問題を防ぐ）
用途: g_metrics構造体へのアクセス保護

保護対象のデータ：

typedef struct SystemMetrics
    {
        ULONG samples_processed;  // 処理済みサンプル数
        ULONG last_value;         // 最後に処理した値
    } system_metrics_t;

6. スレッドの作成

各スレッドはtx_thread_create()で作成されます。例としてCommand Threadを見てみましょう：

assert_success("thread command",
                   tx_thread_create(&command_thread, "command thread",
                                    command_thread_entry, 0,
                                    allocate_stack("command"), DEMO_THREAD_STACK_SIZE,
                                    COMMAND_THREAD_PRIO, COMMAND_THREAD_PRIO,
                                    COMMAND_TIME_SLICE, TX_AUTO_START));

パラメータの説明：

&command_thread: スレッド制御ブロックへのポインタ
"command thread": スレッド名（デバッグ用）
command_thread_entry: スレッドのエントリ関数
0: スレッドに渡す引数
allocate_stack("command"): スタック領域（1024バイト）
COMMAND_THREAD_PRIO: 優先度（1 = 最高優先度）
COMMAND_TIME_SLICE: タイムスライス（5 ticks）
TX_AUTO_START: 作成後すぐに実行可能状態にする

スタック割り当て関数：

static VOID *allocate_stack(const char *name)
    {
        VOID *stack_pointer = TX_NULL;
        UINT status = tx_byte_allocate(&demo_byte_pool, &stack_pointer,
                                       DEMO_THREAD_STACK_SIZE, TX_NO_WAIT);
        assert_success(name, status);
        memset(stack_pointer, 0, DEMO_THREAD_STACK_SIZE);
        return stack_pointer;
    }

この関数はバイトプールから動的にスタック領域を確保し、ゼロクリアして返します。

各スレッドの実装解説

1. Command Thread（優先度1：最高）

Command Threadはシステム全体を制御する最高優先度のスレッドです。

static void command_thread_entry(ULONG thread_input)
    {
        UINT iteration = 0;
    
        bool producer_paused = false;
    
        while (true)
        {
            switch (iteration % 6U)
            {
                case 0U:
                    demo_log("command", "新しいサンプリングバッチを許可\r\n");
                    tx_semaphore_put(&batch_semaphore);
                    break;
                case 1U:
                    demo_log("command", "高優先度アラートを発行\r\n");
                    tx_event_flags_set(&system_events, EVENT_HIGH_PRIORITY_ALERT, TX_OR);
                    break;
                case 2U:
                    if (!producer_paused)
                    {
                        demo_log("command", "プロデューサースレッドを一時停止\r\n");
                        tx_thread_suspend(&producer_thread);
                        producer_paused = true;
                    }
                    break;
                case 3U:
                    if (producer_paused)
                    {
                        demo_log("command", "プロデューサースレッドを再開\r\n");
                        tx_thread_resume(&producer_thread);
                        producer_paused = false;
                    }
                    break;
                case 4U:
                    demo_log("command", "監視系イベントを通知\r\n");
                    tx_event_flags_set(&system_events, EVENT_ALERT, TX_OR);
                    break;
                default:
                    demo_log("command", "CPUを明示的に譲渡\r\n");
                    tx_thread_relinquish();
                    break;
            }
    
            iteration++;
            tx_thread_sleep(COMMAND_PERIOD_TICKS);  // 150 ticks待機
        }
    }

主な機能：

1. セマフォの発行 (case 0)

tx_semaphore_put()でProducerスレッドにバッチ処理の許可を与える

2．イベントフラグの設定 (case 1, case 4)

tx_event_flags_set()で各種イベントを通知
TX_ORオプション：既存のフラグとOR演算で結合

3．スレッドの制御 (case 2, case 3)

tx_thread_suspend(): Producerスレッドを一時停止
tx_thread_resume(): Producerスレッドを再開
これにより動的なスレッド制御を実演

4．CPU譲渡 (default)

tx_thread_relinquish(): 同じ優先度の他のスレッドにCPUを譲る
タイムスライスが設定されているため、自動的にも切り替わる

タイムスライスの効果：

Command ThreadはCOMMAND_TIME_SLICE = 5 ticksが設定されています。これにより、同じ優先度のスレッドが存在する場合、5 ticks経過後に自動的にコンテキストスイッチが発生します。

2. Scheduler Thread（優先度2）

Scheduler Threadはイベントを監視し、優先度の高い処理を行います。

static void scheduler_thread_entry(ULONG thread_input)
    {
        while (true)
        {
            ULONG high_flags = 0;
            UINT status = tx_event_flags_get(&system_events,
                                             EVENT_HIGH_PRIORITY_ALERT | EVENT_ALERT,
                                             TX_OR_CLEAR, &high_flags, 50U);
    
            if ((status == TX_SUCCESS) && (high_flags != 0U))
            {
                if ((high_flags & EVENT_HIGH_PRIORITY_ALERT) != 0U)
                {
                    demo_log("scheduler", "高優先度アラートを検出 - 緊急処理\r\n");
                }
                if ((high_flags & EVENT_ALERT) != 0U)
                {
                    demo_log("scheduler", "モニタからの注意喚起イベント\r\n");
                }
            }
    
            ULONG combo_flags = 0;
            status = tx_event_flags_get(&system_events,
                                        EVENT_SENSOR_DATA_READY | EVENT_BATCH_COMPLETE,
                                        TX_AND_CLEAR, &combo_flags, TX_NO_WAIT);
            if (status == TX_SUCCESS)
            {
                demo_log("scheduler", "AND条件(センサ＋バッチ完了)を満たしました\r\n");
            }
    
            tx_thread_sleep(20U);
        }
    }

イベントフラグの取得方法：

1．OR条件での取得 (最初のtx_event_flags_get)

EVENT_HIGH_PRIORITY_ALERT | EVENT_ALERT: どちらかのフラグが立っていればOK
TX_OR_CLEAR: フラグを取得後、自動的にクリア
タイムアウト: 50 ticks（フラグが立つまで最大50 ticks待機）

2．AND条件での取得 (2番目のtx_event_flags_get)

EVENT_SENSOR_DATA_READY | EVENT_BATCH_COMPLETE: 両方のフラグが必要
TX_AND_CLEAR: 両方立っている場合のみ取得し、クリア
TX_NO_WAIT: 待機せず、すぐに結果を返す

重要なポイント：

イベントフラグは複数のスレッドから同時に設定・取得できる
TX_OR_CLEARとTX_AND_CLEARにより、フラグの自動クリアが可能
タイムアウト設定により、柔軟な待機制御が可能

3. Producer Thread（優先度3）

Producer Threadはセンサーデータを生成し、キューに送信します。

static void producer_thread_entry(ULONG thread_input)
    {
        ULONG sample_id = 0;
    
        while (true)
        {
            tx_semaphore_get(&batch_semaphore, TX_WAIT_FOREVER);
            demo_log("producer", "サンプリングバッチを開始\r\n");
    
            for (ULONG i = 0; i < SENSOR_BATCH_SIZE; i++)
            {
                sensor_message_t message;
                message.sensor_id = (sample_id % 4U) + 1U;
                message.value = 100U + sample_id;
                message.timestamp = tx_time_get();
    
                assert_success("queue_send",
                               tx_queue_send(&sensor_queue, &message, TX_WAIT_FOREVER));
    
                tx_event_flags_set(&system_events, EVENT_SENSOR_DATA_READY, TX_OR);
                sample_id++;
    
                tx_thread_sleep(PRODUCER_DELAY_TICKS);  // 20 ticks
            }
    
            tx_event_flags_set(&system_events, EVENT_BATCH_COMPLETE, TX_OR);
    
            if ((sample_id % 15U) == 0U)
            {
                demo_log("producer", "閾値超過→高優先度アラート\r\n");
                tx_event_flags_set(&system_events, EVENT_HIGH_PRIORITY_ALERT, TX_OR);
            }
        }
    }

処理フロー：

1．セマフォ待機

tx_semaphore_get(&batch_semaphore, TX_WAIT_FOREVER)
セマフォが利用可能になるまで無期限に待機
Command Threadがtx_semaphore_put()を呼ぶまでブロック

2．バッチ処理

5個のセンサーメッセージを生成（SENSOR_BATCH_SIZE = 5）
各メッセージをキューに送信
tx_time_get()で現在のシステムティック数を取得

3．イベント通知

各メッセージ送信後にEVENT_SENSOR_DATA_READYを設定
バッチ完了後にEVENT_BATCH_COMPLETEを設定
15サンプルごとにEVENT_HIGH_PRIORITY_ALERTを発行

メッセージキューへの送信：

tx_queue_send(&sensor_queue, &message, TX_WAIT_FOREVER);

キューが満杯の場合、空きができるまで待機
メッセージはコピーされてキューに格納される
FIFO（先入れ先出し）方式

4. Consumer Thread（優先度4）

Consumer Threadはキューからメッセージを受信し、処理します。

static void consumer_thread_entry(ULONG thread_input)
    {
        sensor_message_t message;
    
        while (true)
        {
            if (tx_queue_receive(&sensor_queue, &message, TX_WAIT_FOREVER) == TX_SUCCESS)
            {
                assert_success("metrics_mutex_get",
                               tx_mutex_get(&metrics_mutex, TX_WAIT_FOREVER));
    
                g_metrics.samples_processed++;
                g_metrics.last_value = message.value;
    
                tx_mutex_put(&metrics_mutex);
    
                demo_log("consumer",
                         "センサ%lu: value=%lu timestamp=%lu\r\n",
                         message.sensor_id, message.value, message.timestamp);
            }
        }
    }

処理フロー：

1．キューからメッセージ受信

tx_queue_receive(&sensor_queue, &message, TX_WAIT_FOREVER)
キューが空の場合、メッセージが到着するまで待機

2．ミューテックスによる排他制御

tx_mutex_get(&metrics_mutex, TX_WAIT_FOREVER): ミューテックスを取得
共有データg_metricsを安全に更新
tx_mutex_put(&metrics_mutex): ミューテックスを解放

3．統計情報の更新

処理済みサンプル数をインクリメント
最後に処理した値を記録

ミューテックスの重要性：

g_metricsはConsumer ThreadとMonitor Threadの両方からアクセスされます。ミューテックスを使用することで：

データの整合性を保証
競合状態（race condition）を防止
優先度継承により優先度逆転問題を回避

5. Monitor Thread（優先度5：最低）

Monitor Threadは定期的にシステムの状態を監視します。

static void monitor_thread_entry(ULONG thread_input)
    {
        while (true)
        {
            tx_thread_sleep(MONITOR_PERIOD_TICKS);  // 300 ticks
    
            system_metrics_t snapshot;
            assert_success("metrics_mutex_get",
                           tx_mutex_get(&metrics_mutex, TX_WAIT_FOREVER));
            snapshot = g_metrics;
            tx_mutex_put(&metrics_mutex);
    
            demo_log("monitor", "処理サンプル=%lu, 最終値=%lu\r\n",
                     snapshot.samples_processed, snapshot.last_value);
    
            if ((snapshot.samples_processed != 0U) &&
                (snapshot.samples_processed % 20U == 0U))
            {
                tx_event_flags_set(&system_events, EVENT_ALERT, TX_OR);
            }
        }
    }

処理フロー：

1．定期的な監視

300 ticks（約3秒）ごとに実行
最低優先度なので、他のスレッドが実行中は待機

2．スナップショット取得

ミューテックスで保護された共有データを安全にコピー
ミューテックスの保持時間を最小化

3．条件チェックとイベント発行

20サンプルごとにEVENT_ALERTを発行
Scheduler Threadに通知

タスク間通信メカニズム

本デモでは4種類の通信メカニズムを使用しています。それぞれの特徴と使い分けを理解しましょう。

1. メッセージキュー（Message Queue）

用途: データの受け渡し

特徴:

FIFO（先入れ先出し）方式
固定サイズのメッセージを格納
送信側と受信側を疎結合にできる
バッファリング機能により、処理速度の違いを吸収

本デモでの使用例:

// Producer側（送信）
    sensor_message_t message;
    message.sensor_id = 1;
    message.value = 100;
    message.timestamp = tx_time_get();
    tx_queue_send(&sensor_queue, &message, TX_WAIT_FOREVER);
    
    // Consumer側（受信）
    sensor_message_t message;
    tx_queue_receive(&sensor_queue, &message, TX_WAIT_FOREVER);

適用場面：

センサーデータの収集と処理
コマンドの送受信
ログメッセージの転送

2. セマフォ（Semaphore）

用途: リソースの制御、同期

特徴:

カウンティングセマフォ（0以上の整数値を持つ）
tx_semaphore_get()でカウントを減らす（0なら待機）
tx_semaphore_put()でカウントを増やす
リソースの数を管理できる

本デモでの使用例:

// Command Thread（許可を与える側）
    tx_semaphore_put(&batch_semaphore);
    
    // Producer Thread（許可を待つ側）
    tx_semaphore_get(&batch_semaphore, TX_WAIT_FOREVER);
    // セマフォ取得後、バッチ処理を実行

適用場面：

バッチ処理の制御
リソースプールの管理
イベントの通知（バイナリセマフォとして）

3. イベントフラグ（Event Flags）

用途: 複数イベントの通知と同期

特徴:

32ビットのフラグを管理（最大32個のイベント）
OR条件：いずれかのフラグが立てば取得
AND条件：すべてのフラグが立った時のみ取得
複数スレッドが同時に待機可能

本デモでの使用例:

// イベントの設定（複数のスレッドから）
    tx_event_flags_set(&system_events, EVENT_SENSOR_DATA_READY, TX_OR);
    tx_event_flags_set(&system_events, EVENT_BATCH_COMPLETE, TX_OR);
    
    // OR条件での取得（どちらか一方でOK）
    ULONG flags;
    tx_event_flags_get(&system_events,
                       EVENT_HIGH_PRIORITY_ALERT | EVENT_ALERT,
                       TX_OR_CLEAR, &flags, 50U);
    
    // AND条件での取得（両方必要）
    tx_event_flags_get(&system_events,
                       EVENT_SENSOR_DATA_READY | EVENT_BATCH_COMPLETE,
                       TX_AND_CLEAR, &flags, TX_NO_WAIT);

適用場面：

複数条件の同期
システム状態の通知
複雑なイベント駆動処理

4. ミューテックス（Mutex）

用途: 排他制御（相互排除）

特徴:

所有権の概念がある（取得したスレッドのみが解放可能）
優先度継承をサポート（優先度逆転問題を防ぐ）
ネストロック可能（同じスレッドが複数回取得可能）
セマフォより排他制御に適している

本デモでの使用例:

// Consumer Thread
    tx_mutex_get(&metrics_mutex, TX_WAIT_FOREVER);
    g_metrics.samples_processed++;  // クリティカルセクション
    g_metrics.last_value = message.value;
    tx_mutex_put(&metrics_mutex);
    
    // Monitor Thread
    tx_mutex_get(&metrics_mutex, TX_WAIT_FOREVER);
    system_metrics_t snapshot = g_metrics;  // 安全にコピー
    tx_mutex_put(&metrics_mutex);

優先度継承の仕組み：

1. 低優先度スレッド（Monitor）がミューテックスを取得
2. 高優先度スレッド（Consumer）が同じミューテックスを要求
3. ThreadXが自動的にMonitorの優先度をConsumerと同じに引き上げ
4. Monitorがミューテックスを解放すると、元の優先度に戻る

これにより、中優先度のスレッドが高優先度スレッドをブロックする「優先度逆転問題」を防ぎます。

適用場面：

共有データ構造の保護
ハードウェアリソースへの排他アクセス
クリティカルセクションの保護

通信メカニズムの選択ガイド

目的	推奨メカニズム	理由
データの受け渡し	メッセージキュー	データのコピーとバッファリング
リソース数の管理	セマフォ	カウンティング機能
単純な通知	セマフォ（バイナリ）	シンプルで高速
複数条件の同期	イベントフラグ	AND/OR条件のサポート
共有データの保護	ミューテックス	優先度継承による安全性

実行結果と動作確認

シリアル出力の例

プログラムを実行すると、以下のようなログが出力されます：

=== Azure RTOS ThreadX タスク＆通信デモ ===
    - 優先度/タイムスライス制御
    - メッセージキュー／イベントフラグ／セマフォ／ミューテックス
    - プロデューサー＆コンシューマー＋監視パターン
    
    [command] 新しいサンプリングバッチを許可
    [producer] サンプリングバッチを開始
    [consumer] センサ1: value=100 timestamp=15
    [consumer] センサ2: value=101 timestamp=35
    [consumer] センサ3: value=102 timestamp=55
    [consumer] センサ4: value=103 timestamp=75
    [consumer] センサ1: value=104 timestamp=95
    [scheduler] AND条件(センサ＋バッチ完了)を満たしました
    [command] 高優先度アラートを発行
    [scheduler] 高優先度アラートを検出 - 緊急処理
    [monitor] 処理サンプル=5, 最終値=104
    [command] プロデューサースレッドを一時停止
    [command] プロデューサースレッドを再開
    [command] 新しいサンプリングバッチを許可
    ...

動作の流れ

1. Command Threadが150 ticksごとに各種コマンドを発行
2. Producer Threadがセマフォを取得してバッチ処理を開始
3. 5個のメッセージをキューに送信（各20 ticks間隔）
4. Consumer Threadがキューからメッセージを受信し、統計を更新
5. Scheduler Threadがイベントフラグを監視し、条件に応じて処理
6. Monitor Threadが300 ticksごとにシステム状態をレポート

デバッグのヒント

エラーハンドリング

static void assert_success(const char *context, UINT status)
    {
        if (status != TX_SUCCESS)
        {
            PRINTF("ERROR: %s failed (status=%u)\r\n", context, status);
            while (1)
            {
                __NOP();
            }
        }
    }

この関数により、ThreadX APIの呼び出しエラーを即座に検出できます。

よくあるエラー:

TX_QUEUE_FULL: キューが満杯（キュー深度を増やすか、Consumer側の処理を高速化）
TX_NO_MEMORY: メモリプール不足（DEMO_BYTE_POOL_SIZEを増やす）
TX_DELETED: オブジェクトが削除済み（オブジェクトのライフサイクルを確認）

おわりに

本記事では、実際に動作するコード（threadx_demo.c）を詳しく解説しながら、ThreadXの基本から実践的な使い方まで学びました。

ThreadXは高性能で使いやすいRTOSですが、マルチタスクプログラミング特有の注意点（デッドロック、優先度逆転、競合状態など）を理解することが重要です。

本デモプロジェクトをベースに、実際のアプリケーション開発に挑戦してみてください。センサーデータ処理、モーター制御、通信プロトコル実装など、様々な用途に応用できます。

ネクスティエレクトロニクスの取り組み

株式会社ネクスティエレクトロニクスは、豊田通商グループのエレクトロニクス事業の中核企業として、カーエレクトロニクスの分野においてトップクラスの規模を誇ります。

技術と商材を核として、幅広い分野でお客さまや世の中のニーズに応え、社会課題のソリューションを提供し、より善き社会の実現に貢献していきます。

また、ネクスティエレクトロニクスの開発部隊では、取り扱い商材を活用した自社開発、受託開発(ハードウェア、ソフトウェア開発)なども実施しています。

お客様の困りごとなどの解決なども含め寄り添って対応いたしますので、お気軽にお問合せください。

お問い合わせ

お問い合わせをする

はじめに

本記事の対象読者

ThreadXを初めて使用する方
RTOSの基本概念を学びたい方
マルチタスクプログラミングに興味がある方
実践的なタスク間通信の実装例を探している方

学習目標

この記事を読むことで、以下の知識とスキルが身につきます：

ThreadXの基本的な使い方
タスク（スレッド）の作成と管理方法
メッセージキュー、セマフォ、イベントフラグ、ミューテックスの使い分け
プロデューサー・コンシューマーパターンの実装
優先度ベースのスケジューリング制御

プロジェクト概要

使用ハードウェア

ボード: NXT社製i.MX RT1170リファレンスボード
プロセッサ: ARM Cortex-M7 (最大1GHz動作)
開発環境: MCUXpresso IDE 11.9.0

プロジェクトの目的

本デモプロジェクトは、ThreadXの主要機能を実践的に学ぶために設計されています：

1. 5つのスレッドによる協調動作
2. 4種類の通信メカニズムの実装
3. 優先度制御とタイムスライスの活用
4. センサーデータ処理を模したプロデューサー・コンシューマーパターン

ThreadXの基本概念

RTOSとは

RTOS（Real-Time Operating System）は、リアルタイム性が要求される組み込みシステムで使用されるOSです。決定論的な動作と高速な応答時間が特徴です。

ThreadXの特徴

高速: 最小限のオーバーヘッドで動作
小フットプリント: メモリ使用量が少ない
決定論的: 予測可能な実行時間
優先度ベース: プリエンプティブスケジューリング
豊富な通信機能: キュー、セマフォ、イベントフラグ、ミューテックスなど

スレッド（タスク）とは

スレッドは、独立して実行される処理の単位です。各スレッドは以下を持ちます：

独自のスタック領域: ローカル変数や関数呼び出し情報を保存
優先度: スケジューラがどのスレッドを実行するか決定
状態: 実行中、準備完了、待機、中断など

システムアーキテクチャ

スレッド構成

本デモでは5つのスレッドを使用します：

スレッド名	優先度	タイムスライス	役割
Command Thread	1（最高）	5 ticks	システム全体の制御とコマンド発行
Scheduler Thread	2	なし	イベント監視と高優先度処理
Producer Thread	3	なし	センサーデータの生成
Consumer Thread	4	なし	データの処理と統計更新
Monitor Thread	5（最低）	なし	システム監視とレポート

通信オブジェクト

オブジェクト	用途
Message Queue	センサーデータの受け渡し
Event Flags	複数イベントの通知と同期
Semaphore	バッチ処理の制御
Mutex	共有データ（統計情報）の保護

初期化処理の詳細

main関数の実装

int main(void)
    {
        BOARD_ConfigMPU();
        BOARD_InitPins();
        BOARD_BootClockRUN();
        BOARD_InitDebugConsole();
    
        PRINTF("\r\n=== Azure RTOS ThreadX タスク＆通信デモ ===\r\n");
        PRINTF("- 優先度/タイムスライス制御\r\n");
        PRINTF("- メッセージキュー／イベントフラグ／セマフォ／ミューテックス\r\n");
        PRINTF("- プロデューサー＆コンシューマー＋監視パターン\r\n\r\n");
    
        tx_kernel_enter();
        return 0;
    }

処理の流れ：

1．ハードウェア初期化

BOARD_ConfigMPU(): メモリ保護ユニットの設定
BOARD_InitPins(): GPIOピンの初期化
BOARD_BootClockRUN(): クロック設定（CPU動作周波数など）
BOARD_InitDebugConsole(): デバッグ用シリアル通信の初期化

2．ThreadXカーネルの起動

tx_kernel_enter(): ThreadXカーネルを起動（この関数は戻りません）
カーネル起動後、tx_application_define()が自動的に呼ばれます

tx_application_define関数

この関数はThreadXカーネルによって自動的に呼び出され、アプリケーションの初期化を行います。

1. メモリプールの作成

assert_success("byte_pool_create",
                   tx_byte_pool_create(&demo_byte_pool, "demo byte pool",
                                       demo_memory_pool, DEMO_BYTE_POOL_SIZE));

バイトプールは動的メモリ割り当てに使用されます。本デモでは各スレッドのスタック領域を確保するために使用します。

サイズ: 8192バイト
用途: スレッドスタックの動的割り当て

2. メッセージキューの作成

assert_success("queue_create",
                   tx_queue_create(&sensor_queue, "sensor queue",
                                   SENSOR_QUEUE_MSG_SIZE, sensor_queue_buffer,
                                   sizeof(sensor_queue_buffer)));

メッセージキューの重要なパラメータ：

メッセージサイズ: SENSOR_QUEUE_MSG_SIZE = sizeof(sensor_message_t) / sizeof(ULONG)
キュー深度: 16メッセージ
バッファ: 静的に確保された配列

sensor_message_t構造体：

typedef struct SensorMessage
    {
        ULONG sensor_id;    // センサーID
        ULONG value;        // センサー値
        ULONG timestamp;    // タイムスタンプ
    } sensor_message_t;

3. イベントフラグの作成

assert_success("event_flags_create",
                   tx_event_flags_create(&system_events, "system events"));

イベントフラグは複数のイベントを1つのオブジェクトで管理します：


    #define EVENT_SENSOR_DATA_READY   (1U << 0)  // ビット0: センサーデータ準備完了
    #define EVENT_HIGH_PRIORITY_ALERT (1U << 1)  // ビット1: 高優先度アラート
    #define EVENT_BATCH_COMPLETE      (1U << 2)  // ビット2: バッチ処理完了
    #define EVENT_ALERT               (1U << 3)  // ビット3: 一般アラート

4. セマフォの作成

assert_success("semaphore_create",
                   tx_semaphore_create(&batch_semaphore, "batch semaphore", 0));

セマフォはバッチ処理の制御に使用：

初期カウント: 0（最初はロック状態）
用途: Producerスレッドのバッチ処理開始を制御

5. ミューテックスの作成

assert_success("mutex_create",
                   tx_mutex_create(&metrics_mutex, "metrics mutex", TX_INHERIT));

ミューテックスは共有データの排他制御に使用：

TX_INHERIT: 優先度継承を有効化（優先度逆転問題を防ぐ）
用途: g_metrics構造体へのアクセス保護

保護対象のデータ：

typedef struct SystemMetrics
    {
        ULONG samples_processed;  // 処理済みサンプル数
        ULONG last_value;         // 最後に処理した値
    } system_metrics_t;

6. スレッドの作成

各スレッドはtx_thread_create()で作成されます。例としてCommand Threadを見てみましょう：

assert_success("thread command",
                   tx_thread_create(&command_thread, "command thread",
                                    command_thread_entry, 0,
                                    allocate_stack("command"), DEMO_THREAD_STACK_SIZE,
                                    COMMAND_THREAD_PRIO, COMMAND_THREAD_PRIO,
                                    COMMAND_TIME_SLICE, TX_AUTO_START));

パラメータの説明：

&command_thread: スレッド制御ブロックへのポインタ
"command thread": スレッド名（デバッグ用）
command_thread_entry: スレッドのエントリ関数
0: スレッドに渡す引数
allocate_stack("command"): スタック領域（1024バイト）
COMMAND_THREAD_PRIO: 優先度（1 = 最高優先度）
COMMAND_TIME_SLICE: タイムスライス（5 ticks）
TX_AUTO_START: 作成後すぐに実行可能状態にする

スタック割り当て関数：

static VOID *allocate_stack(const char *name)
    {
        VOID *stack_pointer = TX_NULL;
        UINT status = tx_byte_allocate(&demo_byte_pool, &stack_pointer,
                                       DEMO_THREAD_STACK_SIZE, TX_NO_WAIT);
        assert_success(name, status);
        memset(stack_pointer, 0, DEMO_THREAD_STACK_SIZE);
        return stack_pointer;
    }

この関数はバイトプールから動的にスタック領域を確保し、ゼロクリアして返します。

各スレッドの実装解説

1. Command Thread（優先度1：最高）

Command Threadはシステム全体を制御する最高優先度のスレッドです。

static void command_thread_entry(ULONG thread_input)
    {
        UINT iteration = 0;
    
        bool producer_paused = false;
    
        while (true)
        {
            switch (iteration % 6U)
            {
                case 0U:
                    demo_log("command", "新しいサンプリングバッチを許可\r\n");
                    tx_semaphore_put(&batch_semaphore);
                    break;
                case 1U:
                    demo_log("command", "高優先度アラートを発行\r\n");
                    tx_event_flags_set(&system_events, EVENT_HIGH_PRIORITY_ALERT, TX_OR);
                    break;
                case 2U:
                    if (!producer_paused)
                    {
                        demo_log("command", "プロデューサースレッドを一時停止\r\n");
                        tx_thread_suspend(&producer_thread);
                        producer_paused = true;
                    }
                    break;
                case 3U:
                    if (producer_paused)
                    {
                        demo_log("command", "プロデューサースレッドを再開\r\n");
                        tx_thread_resume(&producer_thread);
                        producer_paused = false;
                    }
                    break;
                case 4U:
                    demo_log("command", "監視系イベントを通知\r\n");
                    tx_event_flags_set(&system_events, EVENT_ALERT, TX_OR);
                    break;
                default:
                    demo_log("command", "CPUを明示的に譲渡\r\n");
                    tx_thread_relinquish();
                    break;
            }
    
            iteration++;
            tx_thread_sleep(COMMAND_PERIOD_TICKS);  // 150 ticks待機
        }
    }

主な機能：

1. セマフォの発行 (case 0)

tx_semaphore_put()でProducerスレッドにバッチ処理の許可を与える

2．イベントフラグの設定 (case 1, case 4)

tx_event_flags_set()で各種イベントを通知
TX_ORオプション：既存のフラグとOR演算で結合

3．スレッドの制御 (case 2, case 3)

tx_thread_suspend(): Producerスレッドを一時停止
tx_thread_resume(): Producerスレッドを再開
これにより動的なスレッド制御を実演

4．CPU譲渡 (default)

tx_thread_relinquish(): 同じ優先度の他のスレッドにCPUを譲る
タイムスライスが設定されているため、自動的にも切り替わる

タイムスライスの効果：

2. Scheduler Thread（優先度2）

Scheduler Threadはイベントを監視し、優先度の高い処理を行います。

static void scheduler_thread_entry(ULONG thread_input)
    {
        while (true)
        {
            ULONG high_flags = 0;
            UINT status = tx_event_flags_get(&system_events,
                                             EVENT_HIGH_PRIORITY_ALERT | EVENT_ALERT,
                                             TX_OR_CLEAR, &high_flags, 50U);
    
            if ((status == TX_SUCCESS) && (high_flags != 0U))
            {
                if ((high_flags & EVENT_HIGH_PRIORITY_ALERT) != 0U)
                {
                    demo_log("scheduler", "高優先度アラートを検出 - 緊急処理\r\n");
                }
                if ((high_flags & EVENT_ALERT) != 0U)
                {
                    demo_log("scheduler", "モニタからの注意喚起イベント\r\n");
                }
            }
    
            ULONG combo_flags = 0;
            status = tx_event_flags_get(&system_events,
                                        EVENT_SENSOR_DATA_READY | EVENT_BATCH_COMPLETE,
                                        TX_AND_CLEAR, &combo_flags, TX_NO_WAIT);
            if (status == TX_SUCCESS)
            {
                demo_log("scheduler", "AND条件(センサ＋バッチ完了)を満たしました\r\n");
            }
    
            tx_thread_sleep(20U);
        }
    }

イベントフラグの取得方法：

1．OR条件での取得 (最初のtx_event_flags_get)

EVENT_HIGH_PRIORITY_ALERT | EVENT_ALERT: どちらかのフラグが立っていればOK
TX_OR_CLEAR: フラグを取得後、自動的にクリア
タイムアウト: 50 ticks（フラグが立つまで最大50 ticks待機）

2．AND条件での取得 (2番目のtx_event_flags_get)

EVENT_SENSOR_DATA_READY | EVENT_BATCH_COMPLETE: 両方のフラグが必要
TX_AND_CLEAR: 両方立っている場合のみ取得し、クリア
TX_NO_WAIT: 待機せず、すぐに結果を返す

重要なポイント：

イベントフラグは複数のスレッドから同時に設定・取得できる
TX_OR_CLEARとTX_AND_CLEARにより、フラグの自動クリアが可能
タイムアウト設定により、柔軟な待機制御が可能

3. Producer Thread（優先度3）

Producer Threadはセンサーデータを生成し、キューに送信します。

static void producer_thread_entry(ULONG thread_input)
    {
        ULONG sample_id = 0;
    
        while (true)
        {
            tx_semaphore_get(&batch_semaphore, TX_WAIT_FOREVER);
            demo_log("producer", "サンプリングバッチを開始\r\n");
    
            for (ULONG i = 0; i < SENSOR_BATCH_SIZE; i++)
            {
                sensor_message_t message;
                message.sensor_id = (sample_id % 4U) + 1U;
                message.value = 100U + sample_id;
                message.timestamp = tx_time_get();
    
                assert_success("queue_send",
                               tx_queue_send(&sensor_queue, &message, TX_WAIT_FOREVER));
    
                tx_event_flags_set(&system_events, EVENT_SENSOR_DATA_READY, TX_OR);
                sample_id++;
    
                tx_thread_sleep(PRODUCER_DELAY_TICKS);  // 20 ticks
            }
    
            tx_event_flags_set(&system_events, EVENT_BATCH_COMPLETE, TX_OR);
    
            if ((sample_id % 15U) == 0U)
            {
                demo_log("producer", "閾値超過→高優先度アラート\r\n");
                tx_event_flags_set(&system_events, EVENT_HIGH_PRIORITY_ALERT, TX_OR);
            }
        }
    }

処理フロー：

1．セマフォ待機

tx_semaphore_get(&batch_semaphore, TX_WAIT_FOREVER)
セマフォが利用可能になるまで無期限に待機
Command Threadがtx_semaphore_put()を呼ぶまでブロック

2．バッチ処理

5個のセンサーメッセージを生成（SENSOR_BATCH_SIZE = 5）
各メッセージをキューに送信
tx_time_get()で現在のシステムティック数を取得

3．イベント通知

各メッセージ送信後にEVENT_SENSOR_DATA_READYを設定
バッチ完了後にEVENT_BATCH_COMPLETEを設定
15サンプルごとにEVENT_HIGH_PRIORITY_ALERTを発行

メッセージキューへの送信：

tx_queue_send(&sensor_queue, &message, TX_WAIT_FOREVER);

キューが満杯の場合、空きができるまで待機
メッセージはコピーされてキューに格納される
FIFO（先入れ先出し）方式

4. Consumer Thread（優先度4）

Consumer Threadはキューからメッセージを受信し、処理します。

static void consumer_thread_entry(ULONG thread_input)
    {
        sensor_message_t message;
    
        while (true)
        {
            if (tx_queue_receive(&sensor_queue, &message, TX_WAIT_FOREVER) == TX_SUCCESS)
            {
                assert_success("metrics_mutex_get",
                               tx_mutex_get(&metrics_mutex, TX_WAIT_FOREVER));
    
                g_metrics.samples_processed++;
                g_metrics.last_value = message.value;
    
                tx_mutex_put(&metrics_mutex);
    
                demo_log("consumer",
                         "センサ%lu: value=%lu timestamp=%lu\r\n",
                         message.sensor_id, message.value, message.timestamp);
            }
        }
    }

処理フロー：

1．キューからメッセージ受信

tx_queue_receive(&sensor_queue, &message, TX_WAIT_FOREVER)
キューが空の場合、メッセージが到着するまで待機

2．ミューテックスによる排他制御

tx_mutex_get(&metrics_mutex, TX_WAIT_FOREVER): ミューテックスを取得
共有データg_metricsを安全に更新
tx_mutex_put(&metrics_mutex): ミューテックスを解放

3．統計情報の更新

処理済みサンプル数をインクリメント
最後に処理した値を記録

ミューテックスの重要性：

g_metricsはConsumer ThreadとMonitor Threadの両方からアクセスされます。ミューテックスを使用することで：

データの整合性を保証
競合状態（race condition）を防止
優先度継承により優先度逆転問題を回避

5. Monitor Thread（優先度5：最低）

Monitor Threadは定期的にシステムの状態を監視します。

static void monitor_thread_entry(ULONG thread_input)
    {
        while (true)
        {
            tx_thread_sleep(MONITOR_PERIOD_TICKS);  // 300 ticks
    
            system_metrics_t snapshot;
            assert_success("metrics_mutex_get",
                           tx_mutex_get(&metrics_mutex, TX_WAIT_FOREVER));
            snapshot = g_metrics;
            tx_mutex_put(&metrics_mutex);
    
            demo_log("monitor", "処理サンプル=%lu, 最終値=%lu\r\n",
                     snapshot.samples_processed, snapshot.last_value);
    
            if ((snapshot.samples_processed != 0U) &&
                (snapshot.samples_processed % 20U == 0U))
            {
                tx_event_flags_set(&system_events, EVENT_ALERT, TX_OR);
            }
        }
    }

処理フロー：

1．定期的な監視

300 ticks（約3秒）ごとに実行
最低優先度なので、他のスレッドが実行中は待機

2．スナップショット取得

ミューテックスで保護された共有データを安全にコピー
ミューテックスの保持時間を最小化

3．条件チェックとイベント発行

20サンプルごとにEVENT_ALERTを発行
Scheduler Threadに通知

タスク間通信メカニズム

本デモでは4種類の通信メカニズムを使用しています。それぞれの特徴と使い分けを理解しましょう。

1. メッセージキュー（Message Queue）

用途: データの受け渡し

特徴:

FIFO（先入れ先出し）方式
固定サイズのメッセージを格納
送信側と受信側を疎結合にできる
バッファリング機能により、処理速度の違いを吸収

本デモでの使用例:

// Producer側（送信）
    sensor_message_t message;
    message.sensor_id = 1;
    message.value = 100;
    message.timestamp = tx_time_get();
    tx_queue_send(&sensor_queue, &message, TX_WAIT_FOREVER);
    
    // Consumer側（受信）
    sensor_message_t message;
    tx_queue_receive(&sensor_queue, &message, TX_WAIT_FOREVER);

適用場面：

センサーデータの収集と処理
コマンドの送受信
ログメッセージの転送

2. セマフォ（Semaphore）

用途: リソースの制御、同期

特徴:

カウンティングセマフォ（0以上の整数値を持つ）
tx_semaphore_get()でカウントを減らす（0なら待機）
tx_semaphore_put()でカウントを増やす
リソースの数を管理できる

本デモでの使用例:

// Command Thread（許可を与える側）
    tx_semaphore_put(&batch_semaphore);
    
    // Producer Thread（許可を待つ側）
    tx_semaphore_get(&batch_semaphore, TX_WAIT_FOREVER);
    // セマフォ取得後、バッチ処理を実行

適用場面：

バッチ処理の制御
リソースプールの管理
イベントの通知（バイナリセマフォとして）

3. イベントフラグ（Event Flags）

用途: 複数イベントの通知と同期

特徴:

32ビットのフラグを管理（最大32個のイベント）
OR条件：いずれかのフラグが立てば取得
AND条件：すべてのフラグが立った時のみ取得
複数スレッドが同時に待機可能

本デモでの使用例:

// イベントの設定（複数のスレッドから）
    tx_event_flags_set(&system_events, EVENT_SENSOR_DATA_READY, TX_OR);
    tx_event_flags_set(&system_events, EVENT_BATCH_COMPLETE, TX_OR);
    
    // OR条件での取得（どちらか一方でOK）
    ULONG flags;
    tx_event_flags_get(&system_events,
                       EVENT_HIGH_PRIORITY_ALERT | EVENT_ALERT,
                       TX_OR_CLEAR, &flags, 50U);
    
    // AND条件での取得（両方必要）
    tx_event_flags_get(&system_events,
                       EVENT_SENSOR_DATA_READY | EVENT_BATCH_COMPLETE,
                       TX_AND_CLEAR, &flags, TX_NO_WAIT);

適用場面：

複数条件の同期
システム状態の通知
複雑なイベント駆動処理

4. ミューテックス（Mutex）

用途: 排他制御（相互排除）

特徴:

所有権の概念がある（取得したスレッドのみが解放可能）
優先度継承をサポート（優先度逆転問題を防ぐ）
ネストロック可能（同じスレッドが複数回取得可能）
セマフォより排他制御に適している

本デモでの使用例:

// Consumer Thread
    tx_mutex_get(&metrics_mutex, TX_WAIT_FOREVER);
    g_metrics.samples_processed++;  // クリティカルセクション
    g_metrics.last_value = message.value;
    tx_mutex_put(&metrics_mutex);
    
    // Monitor Thread
    tx_mutex_get(&metrics_mutex, TX_WAIT_FOREVER);
    system_metrics_t snapshot = g_metrics;  // 安全にコピー
    tx_mutex_put(&metrics_mutex);

優先度継承の仕組み：

1. 低優先度スレッド（Monitor）がミューテックスを取得
2. 高優先度スレッド（Consumer）が同じミューテックスを要求
3. ThreadXが自動的にMonitorの優先度をConsumerと同じに引き上げ
4. Monitorがミューテックスを解放すると、元の優先度に戻る

これにより、中優先度のスレッドが高優先度スレッドをブロックする「優先度逆転問題」を防ぎます。

適用場面：

共有データ構造の保護
ハードウェアリソースへの排他アクセス
クリティカルセクションの保護

通信メカニズムの選択ガイド

目的	推奨メカニズム	理由
データの受け渡し	メッセージキュー	データのコピーとバッファリング
リソース数の管理	セマフォ	カウンティング機能
単純な通知	セマフォ（バイナリ）	シンプルで高速
複数条件の同期	イベントフラグ	AND/OR条件のサポート
共有データの保護	ミューテックス	優先度継承による安全性

実行結果と動作確認

シリアル出力の例

プログラムを実行すると、以下のようなログが出力されます：

=== Azure RTOS ThreadX タスク＆通信デモ ===
    - 優先度/タイムスライス制御
    - メッセージキュー／イベントフラグ／セマフォ／ミューテックス
    - プロデューサー＆コンシューマー＋監視パターン
    
    [command] 新しいサンプリングバッチを許可
    [producer] サンプリングバッチを開始
    [consumer] センサ1: value=100 timestamp=15
    [consumer] センサ2: value=101 timestamp=35
    [consumer] センサ3: value=102 timestamp=55
    [consumer] センサ4: value=103 timestamp=75
    [consumer] センサ1: value=104 timestamp=95
    [scheduler] AND条件(センサ＋バッチ完了)を満たしました
    [command] 高優先度アラートを発行
    [scheduler] 高優先度アラートを検出 - 緊急処理
    [monitor] 処理サンプル=5, 最終値=104
    [command] プロデューサースレッドを一時停止
    [command] プロデューサースレッドを再開
    [command] 新しいサンプリングバッチを許可
    ...

動作の流れ

1. Command Threadが150 ticksごとに各種コマンドを発行
2. Producer Threadがセマフォを取得してバッチ処理を開始
3. 5個のメッセージをキューに送信（各20 ticks間隔）
4. Consumer Threadがキューからメッセージを受信し、統計を更新
5. Scheduler Threadがイベントフラグを監視し、条件に応じて処理
6. Monitor Threadが300 ticksごとにシステム状態をレポート

デバッグのヒント

エラーハンドリング

static void assert_success(const char *context, UINT status)
    {
        if (status != TX_SUCCESS)
        {
            PRINTF("ERROR: %s failed (status=%u)\r\n", context, status);
            while (1)
            {
                __NOP();
            }
        }
    }

この関数により、ThreadX APIの呼び出しエラーを即座に検出できます。

よくあるエラー:

TX_QUEUE_FULL: キューが満杯（キュー深度を増やすか、Consumer側の処理を高速化）
TX_NO_MEMORY: メモリプール不足（DEMO_BYTE_POOL_SIZEを増やす）
TX_DELETED: オブジェクトが削除済み（オブジェクトのライフサイクルを確認）

おわりに

本記事では、実際に動作するコード（threadx_demo.c）を詳しく解説しながら、ThreadXの基本から実践的な使い方まで学びました。

ネクスティエレクトロニクスの取り組み

お客様の困りごとなどの解決なども含め寄り添って対応いたしますので、お気軽にお問合せください。

お問い合わせ

お問い合わせをする

はじめに

本記事の対象読者

学習目標

プロジェクト概要

使用ハードウェア

プロジェクトの目的

ThreadXの基本概念

RTOSとは

ThreadXの特徴

スレッド（タスク）とは

システムアーキテクチャ

スレッド構成

通信オブジェクト

初期化処理の詳細

main関数の実装

処理の流れ：

tx_application_define関数

1. メモリプールの作成

2. メッセージキューの作成

3. イベントフラグの作成

4. セマフォの作成

5. ミューテックスの作成

保護対象のデータ：

6. スレッドの作成

各スレッドの実装解説

1. Command Thread（優先度1：最高）

主な機能：

タイムスライスの効果：

2. Scheduler Thread（優先度2）

イベントフラグの取得方法：

重要なポイント：

3. Producer Thread（優先度3）

処理フロー：

メッセージキューへの送信：

4. Consumer Thread（優先度4）

処理フロー：

ミューテックスの重要性：

5. Monitor Thread（優先度5：最低）

処理フロー：

タスク間通信メカニズム

1. メッセージキュー（Message Queue）

2. セマフォ（Semaphore）

3. イベントフラグ（Event Flags）

4. ミューテックス（Mutex）

優先度継承の仕組み：

通信メカニズムの選択ガイド

実行結果と動作確認

シリアル出力の例

動作の流れ

デバッグのヒント

おわりに

ネクスティ エレクトロニクスの取り組み

お問い合わせ

関連技術コラム

関連製品情報

はじめに

本記事の対象読者

学習目標

プロジェクト概要

使用ハードウェア

プロジェクトの目的

ThreadXの基本概念

RTOSとは

ThreadXの特徴

スレッド（タスク）とは

システムアーキテクチャ

スレッド構成

通信オブジェクト

初期化処理の詳細

main関数の実装

処理の流れ：

tx_application_define関数

1. メモリプールの作成

2. メッセージキューの作成

3. イベントフラグの作成

4. セマフォの作成

5. ミューテックスの作成

保護対象のデータ：

6. スレッドの作成

ネクスティエレクトロニクスの取り組み

ネクスティエレクトロニクスの取り組み