RTOSについての真実。 記事＃16。 信号

この記事では、Nucleus SEのタスク間の相互作用のための最も単純なメカニズムであるシグナルについて説明します。 これらは、タスク間で簡単なメッセージを転送するための低コストの方法を提供します。





シリーズの以前の記事：

記事＃15。 メモリパーティション：サービスとデータ構造

記事＃14。 メモリのセクション：紹介と基本サービス

記事＃13。 タスクデータ構造とサポートされていないAPI呼び出し

記事＃12。 タスクを操作するためのサービス

記事＃11。 タスク：APIの構成と紹介

記事＃10。 スケジューラ：高度な機能とコンテキストの保存

記事＃9。 スケジューラ：実装

記事＃8。 Nucleus SE：内部設計と展開

記事＃7。 Nucleus SE：はじめに

記事＃6。 その他のRTOSサービス

記事5。 タスクの相互作用と同期

記事4。 タスク、コンテキストの切り替え、および割り込み

記事＃3。 タスクと計画

記事＃2。 RTOS：構造とリアルタイム

記事＃1。 RTOS：はじめに。

信号を使用する

シグナルは、自律的ではないという点で他のすべてのタイプのカーネルオブジェクトと異なります。シグナルはタスクに関連付けられており、タスクなしでは存在できません。 アプリケーションがシグナルを使用するように構成されている場合、各タスクには8つのシグナルフラグのセットがあります。



どのタスクでも、別のタスクのシグナルを設定できます。 シグナルは、シグナルの所有者のみが読み取ることができます。 読み取り中、信号はリセットされます。 タスクは、他のタスクから信号を読み取ったりリセットしたりすることはできません。



Nucleus RTOSには、別のタスクが1つ以上の信号フラグを設定したときに実行される機能をタスクが割り当てることができるツールがあります。 これは、割り込み処理ルーチンに似ています。 この機能はNucleus SEではサポートされていません;ここでは、タスクはシグナルフラグを明示的に要求する必要があります。

信号設定

ほとんどのNucleus SEオブジェクトと同様に、信号のチューニングはnuse_config.hの #defineディレクティブによって決定されます 。 主なパラメーターはNUSE_SIGNAL_SUPPORTで 、機能サポートをアクティブにします（アプリケーションのすべてのタスクに対して）。 シグナルの数を示す問題は価値がありません。各タスクに8つのフラグが割り当てられます。



この有効化パラメータを設定すると、メイン信号アクティベータとして機能します。 これにより、適切なサイズの明確に定義されたデータ構造が提供されます。 さらに、このオプションはAPI設定をアクティブにします。

API呼び出しをアクティブにする

Nucleus SEの各API関数（ユーティリティ呼び出し）は、 nuse_config.hの #defineディレクティブによってアクティブにされます 。 信号の場合、次のものが含まれます。

NUSE_SIGNALS_SEND NUSE_SIGNALS_RECEIVE
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

デフォルトでは、これらはFALSEに設定されているため、各サービス呼び出しが無効になり、それらを実装するコードがオンになりません。 アプリケーションで信号を構成するには、必要なAPI呼び出しを選択し、対応するディレクティブをTRUEに設定する必要があります。



以下は、デフォルトのnuse_config.hファイルからの抜粋です。

 #define NUSE_SIGNAL_SUPPORT FALSE /* Enables support for signals */ #define NUSE_SIGNALS_SEND FALSE /* Service call enabler */ #define NUSE_SIGNALS_RECEIVE FALSE /* Service call enabler */
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

シグナリングサポートをオフにしてアクティブ化されたAPI関数は、コンパイルエラーになります。 アクティブ化されていないAPI呼び出しをコードで使用すると、アプリケーションに実装コードが含まれていなかったため、レイアウトエラーが発生します。 もちろん、2つのAPI関数を含める必要はありません。これらのAPIがない場合、信号サポートをアクティブ化しても意味がないからです。 他のNucleus SE機能との互換性のために、アクティベーターが追加されました。

呼び出し信号

Nucleus RTOSは、次の機能を提供する4つの信号関連のオーバーヘッドコールをサポートしています。

• 特定のタスクに信号を送信します。 Nucleus SEはNUSE_Signals_Send（）関数に実装されています。
• 信号の受信。 Nucleus SEはNUSE_Signals_Receive（）関数に実装されています。
• シグナルハンドラーの登録。 Nucleus SEには実装されていません。
• 信号をオン/オフ（制御）します。 Nucleus SEには実装されていません。

これらの各課題の実装について、以下で詳しく説明します。

シグナリングおよび受信サービス

一連のタスク信号で実行できる基本的な操作は、データの送信（任意のタスクで実行可能）およびデータの読み取り（したがって、データのクリアは所有者タスクのみで実行可能）です。 Nucleus RTOSおよびNucleus SEは、これらの操作のための2つの基本的なAPI呼び出しを提供します。これについては以下で説明します。



信号はビットであるため、2進数として視覚化するのが最適です。 歴史的に標準Cはバイナリ定数（8進および16 進のみ ）の表現をサポートしていないため、Nucleus SEには便利なヘッダーファイルnuse_binary.hがあり 、256個の8ビット値すべてにb01010101のような#define文字が含まれています。 以下は、 nuse_binary.hファイルからの抜粋です。

 #define b00000000 ((U8) 0x00) #define b00000001 ((U8) 0x01) #define b00000010 ((U8) 0x02) #define b00000011 ((U8) 0x03) #define b00000100 ((U8) 0x04) #define b00000101 ((U8) 0x05)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

信号を送る

どのタスクでも、アプリケーション内の他のタスクに信号を送信できます。 信号の送信には、1つ以上の信号フラグの設定が含まれます。 これは、以前に設定されたフラグに影響を与えないOR操作です。



Nucleus RTOSにシグナルを送信するための呼び出し

サービスコールのプロトタイプ：

STATUS NU_Send_Signals（NU_TASK *タスク、UNSIGNEDシグナル）;



パラメータ：



task-設定された信号フラグが属するタスク制御ユニットへのポインター。

シグナル -設定されたシグナルフラグの値。



戻り値：



NU_SUCCESS-呼び出しは正常に完了しました。

NU_INVALID_TASK-タスクへの無効なポインター。



Nucleus SEに信号を送信するための呼び出し

このAPIコールは、Nucleus RTOS APIのコア機能をサポートしています。



サービスコールのプロトタイプ：



STATUS_NUSE_Signals_Send（NUSE_TASKタスク、U8シグナル）;



パラメータ：



task-設定されたシグナルフラグが属するタスクのインデックス（ID）。

シグナル -設定されたシグナルフラグの値。



戻り値：



NUSE_SUCCESS-サービス呼び出しは正常に完了しました。

NUSE_INVALID_TASK-無効なタスクインデックス。



Nucleus SEでのシグナリングの実装

以下は、NUSE_Signals_Send（）関数の完全なコードです。

 STATUS NUSE_Signals_Send(NUSE_TASK task, U8 signals) { #if NUSE_API_PARAMETER_CHECKING if (task >= NUSE_TASK_NUMBER) { return NUSE_INVALID_TASK; } #endif NUSE_CS_Enter(); NUSE_Task_Signal_Flags[task] |= signals; NUSE_CS_Exit(); return NUSE_SUCCESS; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

コードは非常に簡単です。 パラメータの検証後、信号値は指定されたタスクの信号フラグのOR演算を通過します。 タスクをロックしても信号には影響しません。

信号を受信する

タスクは、独自のシグナルフラグセットのみを読み取ることができます。 読み取り中、フラグ値はリセットされます。



Nucleus RTOSでシグナルを受信するための呼び出し

サービスコールのプロトタイプ：

UNSIGNED NU_Receive_Signals（VOID）;



パラメータ：なし。



戻り値：

信号フラグ値。



Nucleus SEでシグナルを受信するための呼び出し

このAPIコールは、Nucleus RTOS APIのコア機能をサポートしています。



サービスコールのプロトタイプ：

U8 NUSE_Signals_Receive（void）;



パラメータ：なし。



戻り値：

信号フラグ値。



Nucleus SE信号受信の実装

以下は、 NUSE_Signals_Receive（）関数の完全なコードです。

 U8 NUSE_Signals_Receive(void) { U8 signals; NUSE_CS_Enter(); Signals = NUSE_Task_Signal_Flags[NUSE_Task_Active]; NUSE_Task_Signal_Flags[NUSE_Task_Active] = 0; NUSE_CS_Exit(); return signals; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

コードは非常に簡単です。 フラグの値がコピーされ、初期値がリセットされ、API関数によってコピーが返されます。 タスクをロックしても信号には影響しません。

データ構造

信号は独立したオブジェクトではないため、メモリの使用はそれらが属するタスクに依存します。 以下は完全な理解のための情報です。 シグナルは、1つのデータ構造（RAM内）を使用します。これは、他のNucleus SEオブジェクトと同様に、アプリケーション内のタスクの数に対応する次元を持つテーブルです。 このデータ構造は、信号サポートが有効な場合にのみ使用されます。



アプリケーションコードはこのデータ構造に直接アクセスせず、利用可能なAPI関数を使用することを強くお勧めします。 これにより、Nucleus SEの将来のバージョンとの非互換性、望ましくない副作用が回避され、Nucleus RTOSへのアプリケーションの移植が簡素化されます。 サービス構造の理解とデバッグの原則を簡単にするために、データ構造について以下で詳しく説明します。

RAMに配置されたデータの構造

データ構造：

NUSE_Task_Signal_Flags [] -構成されたタスクごとに1つのエントリを持つタイプU8の配列。信号フラグはこの配列に格納されます。



このデータ構造は、Nucleus SEのロード時にNUSE_Init_Task（）関数によってゼロに初期化されます。

ROMに配置されたデータの構造

信号には、ROMのデータ構造がありません。

信号データを保存するためのメモリ量

すべてのNucleus SEコアオブジェクトと同様に、信号に必要なメモリ量は予測可能です。



アプリケーションのすべての信号のROMのデータ量は0です。



アプリケーションのすべての信号のデータをRAMに保存するためのメモリの量（バイト単位）は、構成されたタスクの数（ NUSE_TASK_NUMBER ）と同じです。 しかし実際には、このデータはタスクに属し、タスクに関する前の記事で説明されています。

未実現のAPI呼び出し

Nucleus SEには2つのNucleus RTOS APIシグナリングコールが実装されていません。

シグナルハンドラー登録

このAPI呼び出しは、現在のタスクの信号処理手順（関数）を設定します。 Nucleus SEでは、シグナルハンドラがサポートされていないため、これは必要ありません。



サービスコールのプロトタイプ：

STATUS NU_Register_Signal_Handler（VOID（* signal_handler）（UNSIGNED））;



パラメータ：

signal_handler-シグナルを受信するときに呼び出す必要がある関数



戻り値：

NU_SUCCESS-呼び出しは正常に完了しました。

NU_INVALID_POINTER-シグナルハンドラーへのNULLポインター（ NULL ）

信号の制御（有効化/無効化）

このサービスは、現在のタスクのシグナルをアクティブ化および/または非アクティブ化します。 タスクごとに32の信号を使用できます。 各信号は、 signal_enable_maskのビットで表されます。 signal_enable_maskにビットを追加すると、対応する信号が有効になり、ビットを削除すると無効になります。



サービスコールのプロトタイプ：

UNSIGNED NU_Control_Signals（UNSIGNED enable_signal_mask）;



パラメータ：

enable_signal_mask-正しい信号を表すビットパターン。



戻り値：

前の信号を有効/無効にするマスク。

Nucleus RTOS互換

Nucleus SEを開発するとき、私の目標はコードレベルをNucleus RTOSとの互換性を保つことでした。 シグナルも例外ではなく、開発者の観点からは、Nucleus RTOSとほぼ同じ方法で実装されます。 最終的なコードの方がはるかに理解しやすく、メモリをより効率的に使用できることを考えると、妥当と思われる非互換性がいくつかあります。 それ以外の場合、Nucleus RTOS APIコールはほぼ直接Nucleus SEコールに転送できます。

シグナルハンドラー

Nucleus SEでは、構造全体を簡素化するためのシグナルハンドラは実装されていません。

信号の可用性と量

Nucleus RTOSでは、タスクに32個のシグナルフラグを設定できます。 Nucleus SEでは、数を8に減らすことにしました。これは、より単純なアプリケーションには十分であり、RAMリソースを節約できるからです。 必要に応じて、信号を完全にオフにすることができます。

未実現のAPI呼び出し

Nucleus RTOSは、4つのシグナリングサービスコールをサポートしています。 これらのうち、2つはNucleus SEには実装されていません。 それらの説明は、上記の「Unrealized API Calls」セクションにあります。



著者について： Colin Wallsは電子業界で30年以上働いており、ほとんどの時間をファームウェアに費やしています。 現在、Mentor Embedded（Mentor Graphicsの一部門）のファームウェアエンジニアです。 Colin Wallsは、カンファレンスやセミナー、多くの技術記事の著者、ファームウェアに関する2冊の本でよく話します。 英国に住んでいます。 Colinのプロフェッショナルブログ 、電子メール：colin_walls@mentor.com。