TOPPERS Realtime System Sample (RSS) - LPCXpresso GPS Clock


Prev Next

ソフトウェアについて


はじめに

本アプリケーションでは、TOPPERSのサンプルとして機能するシンプルなリアルタイムシステムの事例としてGPS時計アプリケーションを実装しました。 固定長メモリプールとメールボックスを組み合わせたタスク間通信や、優先度設計のポイントなども学習できます。 このアプリケーションは主に以下の二つを達成するものです。

システム全景

Figure 1にシステム全景を示します。 ARM Cortex-M3が搭載されたCPUボードにGPSモジュールとLED表示器、シリアル通信用ボードを接続しました。

Figure 1 システム全景
Figure 1 システム全景

アプリケーション

アプリケーションのタスク間の関係をFigure 2に示します。

Figure 2 タスク間の関係
Figure 2 タスク間の関係

GPSタスク(task_gps)は、GPSモジュールから時刻情報を取り出し、ディスプレイタスク(task_display)にタスク間通信で表示内容を渡します。 この表示内容を渡す方法は、固定長メモリプールとメールボックスを使います。 固定長メモリプールの資源が取得できる状態である限り、GPSタスクとディスプレイタスクはブロックされません。 リアルタイム性を確保する上でこのような実装方法は必要条件と言えますので、サンプルで実装を提示することでユーザの学習を促す事としました。 これが本アプリケーションのサンプルプログラムとしての第1のポイントです。

次に、シェルタスク(task_shell)は、シリアルポート経由でユーザからコマンドを受け付け、システムに制御を加えます。 今回はシステム情報を取得するための「infoコマンド」と、ディスプレイに所望の表示を行なうための「displayコマンド」を用意しました。 ディスプレイタスクへのリクエストは、GPSタスクで使用していたものと同じメカニズムを使用します。 小規模リアルタイムシステムにおいて、使いやすいシェルの存在は貴重です。 これが本アプリケーションのサンプルプログラムとしての第2のポイントです。

Figure 3には、実行中のシェルタスクの様子を示しました。

Figure 3 コマンドを実行している様子
Figure 3 コマンドを実行している様子

実装上の工夫とその狙い

sample1は、一本のソースに全てが詰め込まれていました。 本アプリケーションでは、以下のように幾つかの工夫を凝らしてあります。

タスク毎にファイルを分割

Figure 4に、タスク毎に分割されたファイルの様子について示します。

Figure 4 タスク毎に分割されたファイル
Figure 4 タスク毎に分割されたファイル

TOPPERSカーネルを初めて使うユーザがリアルタイムシステムを構築する場合、色々な疑問にぶつかるでしょう。 例えば、「どのようにタスク分割をするのか?」、「どのようにタスク間通信を行なうのか?」など様々な試行を繰り返しながら学習する事になります。 この際、APIの使用方法と同時にリアルタイム・オペレーティング・システムについて学習する事になります。 更に、学習者がソフトウェア開発も学ぶ事となれば、学習の負荷は比較的大きなものになります。 この時に有用なのが、上記Figure 4に示したような分割実装されたプロジェクトの存在です。 TOPPERSカーネルの初めてのユーザでも、簡単にタスクを追加、削除する事ができるようになります。

操作対象毎に分割した下層ライブラリ

次に、タスクで使用する細かなロジックはFigure 5に示すように、ライブラリとして別のディレクトリ構成としました。 このようにすることで、タスクの実装が単純になり、再利用性も高まります。 実際にRTOSの初心者は、ソフトウェアの初心者である事も少なくありません。 このような細かな配慮で提供されているコードを見て、RTOSと一緒にソフトウェア開発について学習してもらうのが一番効率的です。

Figure 5 階層化されたライブラリ
Figure 5 階層化されたライブラリ

タスク間通信の実装詳細を隠蔽

最後に、タスク間通信の箇所ですが、Figure 6のようにしました。

Figure 6 ディスプレイタスク本体関数とリクエスト用関数
Figure 6 ディスプレイタスク本体関数とリクエスト用関数

このコードは、ディスプレイタスクのヘッダから持ってきた宣言文です。 task_display関数は、ディスプレイタスクの本体です。 tskapi_display_update関数は、ディスプレイタスク以外のタスクがディスプレイタスクに要求をするためのAPIです。 内部では、固定長メモリプールとメールボックスが組み合わせて使われていますが、その事を意識せずにシステムを構成できるようにAPI内部に隠ぺいしてあります。

Figure 7にディスプレイタスクへのリクエスト用関数の実装を示します。 固定長メモリプールとメールボックスを組み合わせたタスク間通信は、TOPPERSを使ったリアルタイムシステムのタスク間通信の定石とも言えます。 これらを知らないあまり、きちんとリアルタイムシステムとして実装されていないケースが見受けられます。 サンプルではこういった事例も示し、リアルタイムシステムの特徴を最大限にシステムに取り入れられる人材を育成したいと考えました。

Figure 7 送信処理の実装
Figure 7 送信処理の実装

ディスプレイタスクの本体側では、メールボックスから受信したメッセージを処理し、固定長メモリプールに資源を戻す処理を実装してあります。

Figure 8 受信処理の実装
Figure 8 受信処理の実装

リアルタイム・システムで重要な事柄も学べるリアルタイム・システム・サンプル

リアルタイム・オペレーティング・システムを使用すれば自動的にリアルタイム性が付加されるわけではないのは周知のとおりです。 しかし、実際にリアルタイム・システムの教育メニューを見ても、リアルタイム性の検証に触れている例を見つける例は稀です。

本アプリケーションのように非常にシンプルな構成のシステムを使っても、リアルタイム・システムの評価について学習する事ができます。 Figure 9に、システムにロジックアナライザを接続した様子を示しました。

Figure 9 システムのプローブ
Figure 9 システムにロジックアナライザを接続した様子

Figure 10に、システムにロジックアナライザを接続して得られたデータを時間軸で示しました。 リアルタイム・システムのリアルタイム性を検証する場合、判定に用いるデータの母数が重要な役目を果たします。 時間軸方向でデータを見た場合、全データ間の間隔が適切であるのか確認するのは困難です。

Figure 10 時間軸で見た時
Figure 10 時間軸で見た処理間隔

リアルタイム・システムにおけるリアルタイム性の評価において、なんとなく良さそうとか少し動かして良さそうといった危険な判断は禁物です。 そこで、上記の時間軸データからヒストグラムをチャネル毎に作ってみましょう。 ヒストグラムはデータのばらつきを見ることができます。 ばらつきの傾向や度合いからリアルタイム・システムで定められた許容される時間の範囲で動作しているのかを客観的に評価できます。

Figure 11 ヒストグラムで見た時
Figure 11 ヒストグラムで見た処理間隔

上記のようにばらつきの範囲が客観的に求められましたから、システムに要求される範囲に収束しているのかを判定できます。


Prev Next