高速協調検証システム・モデリングガイド

はい。 アセンブラのコードを含んでいる場合、 バジェット追加プログラムは受付けないため、 対処が必要です。

その方法は

1. アセンブラ部分をC言語に書き換える
2. アセンブラ実行時間に対応したwait文を挿入する。

という処理が必要です。

また以下の書き換えが必要です

• コンテキストの退避・復元処理（アセンブラコード）
  • ⇒suspend/resume指示
• タスクのディスパッチ処理（アセンブラコード）
  • ⇒書換え
• タスク制御本体
  • ⇒上記変更に伴う部分変更

RTOSの構成要素のうち変更の必要な モジュールを以下の図に示します。

SystemCの場合(ポーリング方式)

1. RTOSモデルは、タスクAの動作を継続する場合にはタスクAのサスペンドフラグを偽に、休眠を指示する場合には真にします。バジェット挿入ツールにより命令実行時間調整のためにRTOSメソッドwaitfor()が挿入されています。そのwaitfor()の呼出しがあるたびに、サスペンドフラグの真偽を判定します。
2. タスクAのサスペンドフラグが真の場合には、RTOSメソッドwaitfor()中で、タスクAの再開イベント(E_resume)待ちを実現するwait(E_resume)が実行されます。RTOSモデルは、タスクBの再開イベント(E_resume)を通知します。このイベント通知により、タスクBの動作が開始されます。
3. RTOSモデルは、タスクBの動作を継続する場合にはタスクBのサスペンドフラグを偽に、休眠を指示する場合には真にします。タスクBにも同じように、バジェット挿入ツールによりRTOSメソッドwaitfor()が挿入されています。このwaitfor()の呼出しのたびに、サスペンドフラグの真偽を判定します。
4. タスクのサスペンドフラグが真の場合には、RTOSメソッドwaitfor()中で、タスクAの再開イベント(E_resume)待ちを実現するwait(E_resume)が実行されます。RTOSモデルは、タスクAの再開イベント(E_resume)を通知します。このイベント通知により、タスクAの動作が再開されます。

RTOSの処理は

• サービスコールの受け付け
• 割込処理

が変更になります。

デバイスドライバはハードウェアのモデル記述方法により影響を受けます。

ハードウェアをPVTモデルで記述する場合

ハードウェアとの通信は抽象化されるため、デバイスドライバはこのレベルでは不要です。制御ソフトウェアから直接ハードウェアの持つインタフェースのメソッドを記述するという方法で高速化します。

ハードウェアをBCAモデルで記述した場合

この場合、デバイスドライバのI/Oバスアクセス部分だけが変更を受けます。

バジェット追加プログラムで、実行時間対応の wait文を挿入したり、ターゲットと異なるホスト上で 実行のために、RTOSはソースコードが必要になります。

アセンブラを含んでいる場合、必要な書き換えを 行うことで使えます。