デバイスドライバの生産性・移植性の向上に向けてーデバイスドライバ設計ガイドラインからー

三菱電機マイコン機器ソフトウエア株式会社
技術企画センター／デバイスドライバ設計ガイドラインWG幹事
宿口 雅弘
ms89019@mms.co.jp
http://www.mms.co.jp
http://www.itron.gr.jp/GUIDE/device‑j.html

2000/11/15〜17

• デバイスドライバとは？
周辺デバイス（ハードウェア)をドライブ(制御)するプログラム(比較的小規模のプログラム)のハズだがその定義範囲が広すぎる

2000/11/15〜17

• 組込みシステムの周辺デバイスに着目– 共通にもつデバイスはＣＰＵだけ– システム毎に制御したデバイスが異なる– 周辺デバイスを複数のタスクで共有したい例
は少ない– 制御にタイムクリティカルなものが多い• アセンブリ言語を必要とする• 高度なコーディングを必要とする– 周辺デバイスを制御するのが主目的

2000/11/15〜17

• 組込みシステムのデバイスドライバって？
(汎用システムと比較して)– ＯＳが採用されはじめのたのは近年• ＯＳ組込み型デバイスドライバの概念が無い– ハードウェア（デバイス）の制御が主• 組込みプログラム≒デバイスドライバ であろう

– システム自体が少量多品種• あるデバイス制御専用システムの場合もある→ 移植性の要求は低かった。

2000/11/15〜17• 汎用システムと組込みシステムの構成– 汎用システムのハードウェア構成
ＣＰＵ＋コンソール＋ハードディスク＋ネットワーク– 構成は概ね固定されている» ＷｉｎｄｏｗｓＯＳはＰＣ専用ＯＳ»Ｌ
ｉｎｕｘもＰＣ専用ＵＮＩＸ（だった）– ＯＳはハードウェアの違いを隠蔽する役割をもつ– 不特定多数のプロセスがデバイスを共有する

ＯＳのデバイスドライバサポートは必須

2000/11/15〜17• 汎用システムと組込みシステムの構成– 組込みシステムのハードウェア構成
ＣＰＵ＋。。。ｅｔｃ．ｅｔｃ！決まった形が無い(製品分野毎にはある程度決まっているが)– タスク制御(ＣＰＵの効率的活用)がＯＳ主目的– ハードウェアの隠蔽は必須でない

ＯＳがデバイスドライバをサポートする必要無し
しかし近年の特徴として。。。

2000/11/15〜17• 近年の組込みシステムの状況– 組込みシステムの機能の複合化• 特に通信機能(ネットワーク)が不可欠– 汎用機の機能が取込まれている• ネットワーク機能はＰＣの世界で発達→ ＰＣベースの考え方– 組込みシステムの複雑化– 製品の短命化– 開発期間の短縮– 開発コストの圧縮– 品質の向上2000/11/15〜17• 近年の組込みシステムの現況– 開発期間の短縮– 開発コストの圧縮• 出来る限りモノを作らない方が良い– 品質の向上• 設計、評価時間を充分にとる→現実問題 難しい

2000/11/15〜17• 近年の組込みシステムの状況
結論：・使えるプログラムは流用する。
例：プロトコルスタック
・移植性の高いプログラムを作成する。
周辺デバイスが変るケースは少ない。
同じデバイスならば制御プログラムは流用できる。
→ 移植性重視の設計・製作が必須である。

2000/11/15〜17

• デバイスドライバの製作が難しい理由– デバイス制御処理– タイムクリティカル処理– 割込み処理– システムの主役でないアプリケーションに依存– ＯＳ組込み型の場合– ＯＳ組込み型でない場合

2000/11/15〜17

• デバイスドライバの製作が難しい理由– デバイス制御処理• デバイスの仕様の理解が必須• ハードウェアの知識が必須！デバイスはＣＰＵと非同期に動作している→タイミングの問題等一筋縄ではいかない→学習する以外に道は無い

2000/11/15〜17

• デバイスドライバの製作が難しい理由– タイムクリティカル処理• システムとしてリアルタイム処理が要求される。
• デバイス制御に時間制約がある。
例 ＳＩＯのデータ受信一定時間内にデータを受信(プログラムでＣＰＵのメモリに取込む）しなければデータが失われる。

→ 高度なコード最適化技術が要求される。
→ ＣＰＵの動作の理解が必須。
→ コンパイラの特性の理解が必須。

2000/11/15〜17

• デバイスドライバの製作が難しい理由– 割込み処理• 割込みはＣＰＵ外のイベントを知る効率的な手段。
• デバイスからの応答を知るために有効。
• 割込みでない場合はポーリング処理。
→システム負荷が上昇する場合あり。
• しかし、様々な問題が。。。
– 割込み処理自体がタイムクリティカルな処理である。
→ 割込みオーバヘッドがどれくらいか？
– 多重割込みへの対応が必要な場合がある。
– 非割込み部との排他処理が必須である。

2000/11/15〜17

• デバイスドライバの製作が難しい理由– システムの主役でない！アプリケーション機能に依存→ 他のプログラムへの影響を考慮する。
→ 製品機能を意識すると汎用的に書けない。
※ 矛盾、ジレンマ

2000/11/15〜17

• デバイスドライバの製作が難しい理由– ＯＳ組込み型の場合→ デバイス制御のシステムコールを持つＯＳ。
→ 他のシステムコールと同様に動作する。
→ 多くの場合サブルーチンとして提供される。
• ＯＳの動きを詳細に知る必要あり。
• ＯＳの決めたルールを詳細に知る必要あり。
• ＯＳの一部であるがゆえの注意事項が多い。

2000/11/15〜17

• デバイスドライバの製作が難しい理由– ＯＳ組込み型でない場合→ デバイス制御のシステムコールを持たないＯＳ。
μＩＴＲＯＮなど （以前はあったが使われていなかった）→ ＯＳ制御下のタスクとして動作する。
• 全くデバイスドライバの決まり毎が無い。
→ 手も足も出ない！
→ そこで「デバイスドライバ設計ガイドライン」

2000/11/15〜17

• デバイスドライバ設計ガイドラインの動機– ソフトウェア開発者• デバイスドライバ→規模が小さいが開発困難• 再利用性・流通性を高めたい– デバイス提供者• デバイスの付加価値を高めたい• デバイスとともにドライバを提供したい– 技術者教育面• デバイスドライバ設計の教科書が無い• 用語を統一したい → 技術者間の意志の疎通–ＩＴＲＯＮプロジェクト• デバイスドライバを揃えたい
2000/11/15〜17

• 生産性向上の考え方– ガイドラインにより生産性が向上するか？
• ガイドライン→パターンを多く見せる→型（アーキテクチャ）を多く見せることができる→ドライバの勘所が解る→生産性が向上する– ガイドラインにより移植性が向上するか？
• 共通事項（標準的規格）の提示• パターンに従った設計→移植性の向上（→生産性の向上）• パターンの理解による移植対象の早期理解
2000/11/15〜17

• 移植性を損ねる要因は？
– ＣＰＵに依存するもの• 割込みアーキテクチャ• ポートアクセス方式• エンディアン問題– プラットホームに依存するもの• プログラムの動作– マルチタスクｏｒ非マルチタスク• 割込み禁止方式

どのように対応すべきか？

2000/11/15〜17• 階層化構造の導入– デバイスドライバの構造を見る↓ デバイスドライバの内部を構造的に分析
アプリケーションプログラム
デバイスドライバ
アプリケーションインタフェース処理部
タスク（非割込み）部

割込み処理部

論理的処理部
デバイス制御処理部
物理デバイス
2000/11/15〜17• 階層化構造の導入– デバイスドライバの構造を見る• アプリケーションインタフェース部– アプリケーションプログラムとインタフェースをとる。

• タスク（非割込み）処理部– タスク処理を実行する。

• 割込み処理部– 割込み処理を実行する。

• 論理的処理部– デバイス制御以外の論理的処理を実行する。

• デバイス処理部– デバイス制御処理を実行する。

• ＣＰＵ依存部• ＯＳ依存部
2000/11/15〜17

• デバイスドライバ設計ガイドラインのアプローチ– DIC(Device Interface Component)アーキテクチャ
アプリケーション依存部

ＯＳ依存部

アプリケーション
ソフトウェア部品

ＧＤＩＣ（ＧｅｎｅｒａｌＤＩＣ）
デバイス依存部

ＣＰＵ依存部

ＰＤＩＣ（ＰｒｉｍｉｔｉｖｅＤＩＣ）
アクセスインタフェース

ＯＳ

ＳＩＬ(SystemInterfaceLayer)
ターゲットハードウェア
デバイス
割込み機構プロセッサ

2000/11/15〜17• 階層化構造導入のメリット– 各依存性を分離できる• デバイス依存性• ＣＰＵ依存性• ＯＳ依存性• アプリケーション依存性

2000/11/15〜17• 階層化構造導入のメリット– デバイス依存性の分離• 何を制御するのか明確にする／できる。
• デバイスの制御に専念できる。
• 単純な制御文に集約できる。
→• デバイスの制御は基本的には制御レジスタ（ポート）へのアクセスのみ。
• ※周辺ソフトウェアとの相互関係が処理を難しくしている。

2000/11/15〜17• 階層化構造導入のメリット– ＣＰＵ依存性の分離• 割込み処理– 割込みアーキテクチャの吸収– デバイスドライバの割込みハンドラはデバイスの制御に専念すべき→ ＣＰＵの割込み処理、割込みコントローラの処理はそれぞれのルーチンにて実施すべき。

• 割込み禁止／解除処理– 処理関数の導入• エンディアン変換– エンディアン変換関数の導入→ｗｏｒｄアクセス時に制約を持たせる。

2000/11/15〜17• 階層化構造導入のメリット– ＲＴＯＳ依存性の分離• ＯＳ非使用レイヤ− ＰＤＩＣ− ＯＳ存性の排除− ＯＳの機能を使わない待ちに入れない（非同期処理）− ＯＳ存性の排除• ＯＳ使用レイヤ− ＧＤＩＣ− ＯＳの機能を使う
待ちに入れる(同期処理)
2000/11/15〜17• 階層化構造導入のメリット– アプリケーション依存性の分離• アプリケーション特化機能を明確にする。
• 再利用性が高いデバイス部を切り出す。
★デバイスドライバはＣＰＵからみた機能分割された後の概念
例：DARTS(Design Approach for RealTimeSystem)法
I/Oタスク構造化基準(I/Oデバイスに着目)
以下それぞれを１つのタスクとする
・非周期的なI/Oデバイスのドライバ
・周期的なI/Oデバイスのドライバ
・複数からイベントを受信するI/Oデバイスドライバ

2000/11/15〜17

• デバイスドライバ設計ガイドラインのアプローチ– DIC(Device Interface Component)アーキテクチャ
階層構造の導入• Ｐ（Ｐｒｉｍｉｔｖｅ）ＤＩＣ→デバイスに対する最低限のインタフェースのみ提供• Ｇ（Ｇｅｎｅｒａｌ）ＤＩＣ→ＰＤＩＣに機能を追加する
ＧＤＩＣ
ＧＤＩＣ
低機能なデバイスのＰＤＩＣ
デバイス
2000/11/15〜17

高機能なデバイスのＰＤＩＣ
デバイス• デバイスドライバ設計ガイドラインのアプローチ– DIC(Device Interface Component)アーキテクチャ
アプリケーション依存部

ＯＳ依存部

アプリケーション
ソフトウェア部品

ＧＤＩＣ（ＧｅｎｅｒａｌＤＩＣ）
デバイス依存部

ＣＰＵ依存部

ＰＤＩＣ（Ｐｒｉｍｉｔｉｖ
ｅＤＩＣ）
アクセスインタフェース

ＯＳ

ＳＩＬ(SystemInterfaceLayer)
ターゲットハードウェア
デバイス
割込み機構
プロセッサ

2000/11/15〜17

• デバイスドライバ設計ガイドラインのアプローチ– DIC(Device Interface Component)アーキテクチャ
GDIC ・アプリケーション
ソフトウェア部 品

DSR：(Device Service Routine)
PDICと上 位 層 との インタフェースを司 る
DS R
アクセスインタフェース：
メモリ空 間 か IO空 間 か などの デバ イスへ の アクセス方
法 を抽 象 化 する

CBR

GDIC

CBR
ISR:
Intrrupts S ervice Rutine：
デバ イスの 割 込 み 処 理 の本体

DSR
PDIC
ISR

アクセス インタフェース

システム インタフェース
レイヤ (S IL)：
プロセッサ (I/O命 令 、円 デ
ィアン、割 込 み 禁 止 ／ 許 可命 令 )と割 込 み コントローラを抽 象 化 する

System Interface Laya

プロセッサ

割込み機構
ターゲットハ ー ドウェア

2000/11/15〜17

CBR:(C all Back Routine)
割 込 み 機 構 か ら処 理 要 求
完 了 通 知 または 事 象 通 知
で呼 ば れ るル ーチン

デバ イス• デバイスドライバ設計ガイドラインのアプローチ– DIC(Device Interface Component)アーキテクチャ
各レイヤのターゲットハードウェアへの対応
ＤＩＣ
ＧＤＩＣ
ＰＤＩＣ
アクセスインタフェース

ＳＩＬ
プロセッサ
割込み機構

デバイス

ターゲットハードウェア
デバイスとプロセッサの接続デバイスからの割込み線
2000/11/15〜17

• デバイスドライバ設計ガイドラインのアプローチ– μＩＴＲＯＮ４．０の割込みシステムモデル※デバイスＷＧの議論の成果(1) CPUの割込みアーキテクチャに依存する処理(2) 割込みコントローラなどのCPU以外のハードウェアに依存する処理(3) デバイスに依存する処理
(1 )

(2 )

(3 )

外 部 割 込 み
IR C の 操 作

リタ ー ン

2000/11/15〜17

IS R• デバイスドライバ設計ガイドラインのアプローチ– μＩＴＲＯＮ４．０の割込みシステムモデル
参照した割込みハードウェア構成
デバ イス

デバ イス・・・ デバ イス

対応

ISR・・・

ISR
対応

IRC
対応
ベクトル
エンコード
一本の場合も割 込 み ハ ンドラ
割 込 み ハ ンドラ
割 込 み ハ ンドラ
プロセッサ

割 込 み システム

2000/11/15〜17

ISR•システムインターフェースレイヤー– ターゲットハードウェアを抽象化し、各ＰＤＩＣ間で共通に利用できるレイヤー• デバイスとのデータ入出力（アドレス空間、データサイズ、エンディアン等）• 微小時間の遅延• 割込みロック状態の制御• 割込みサービスルーチンの管理

2000/11/15〜17

•デバイスとのデータ入出力ＡＰ
Ｉ– Ｉ／Ｏ空間とメモリ空間の違いの吸収• ８ビットのデータを読む場合
Ｉ／Ｏ空間からメモリ空間から

VB data = sil_reb_iop(VP iop);
VB data = sil_reb_mem(VP mem);• ８ビットのデータを書く場合
Ｉ／Ｏ空間へメモリ空間へ

2000/11/15〜17

void sil_wrb_iop(VP iop, VB data);
void sil_wrb_mem(VP mem, VB data);•デバイスとのデータ入出力ＡＰ
Ｉ– データサイズの違いの吸収• メモリ空間上の指定したアドレスからデータを読み取る。
８ビットサイズ
VB data = sil_reb_mem(VP mem);
１６ビットサイズ
VH data = sil_reh_mem(VP mem);
３２ビットサイズ
VW data = sil_rew_mem(VP mem);• メモリ空間上の指定したアドレスへデータを書き込む。
８ビットサイズvoid sil_wrb_mem(VP mem,VB data);
１６ビットサイズ
void sil_wrh_mem(VP mem,VH data);
３２ビットサイズ
void sil_wrw_mem(VP mem,VW data);

2000/11/15〜17

•デバイスとのデータ入出力API– エンディアンの違いの吸収• エンディアンの違いによる問題
デュアルポートメモリ(8ビットサイズ)

0x１２３４→→0x３４１２→

x‑1番地
プロセッサ
ビッグエンディアン

8ビット
サイズバス

x番地

0x12x+1番地

0x34

デバイス
(16ビットレジスタ)
リトルエンディアン

8ビット
サイズバス

x+2番地

• 問題の解決
デュアルポートメモリ(8ビットサイズ)

0x１２３４→→0x１２３４→

x‑1番地
プロセッサ
ビッグエンディアン

8ビット
サイズバスx番地

0x12x+1番地

0x34

x+2番地

2000/11/15〜17

8ビット
サイズバス

デバイス(16ビットレジスタ)
リトルエンディアン•デバイスとのデータ入出力API– メモリ空間デバイスへのデータ入出力• メモリ空間上の指定したアドレスから１６ビットのデータを読み取る。
自然なエンディアン
リトルエンディアン
ビッグエンディアン

VH data = sil_reh_mem(VP mem);
VH data = sil_reh_lem(VP mem);
VH data = sil_reh_bem(VP mem);• メモリ空間上の指定したアドレスへ１６ビットのデータを出力する。
自然なエンディアン
リトルエンディアン
ビッグエンディアン

void sil_wrh_mem(VP mem, VH data);
void sil_wrh_lem(VP mem, VH data);
void sil_wrh_bem(VP mem, VH data);

自然なエンディアン→エンディアンの違いを考慮する必要の無い状況

2000/11/15〜17•エンディアンの判別– プロセッサーのエンディアン判別用定数• 定数 SIL_ENDIAN をプロセッサーのエンディアンに合わせて定義• デバイスのエンディアンが設定できる場合はＤＩＣ内でのデバイス初期化時にこの定数を用いてエンディアン変換なしで入出力できるように初期化することができる。
#define SIL_ENDIAN_LITTLE#define SIL_ENDIAN_BIG

ビッグエンディアンを定義する場合#define SIL_ENDIAN

2000/11/15〜17

SIL_ENDIAN_BIG

0 リトルエンディアン
1 ビッグエンディアン•微小時間の遅延ＡＰＩ– デバイスによっては一定の微小時間（ＯＳのタイマ割込み間隔よりもはるかに短い時間）デバイスを操作できない場合がある。
→ＣＰＵの動作クロックが様々なので、毎移植毎に調整が必要となる。

– 微少時間のウェイト機能を用意する。
微小時間のウェイト
void sil_dly_nse(UINT dlytim)
UINT dlytim ウェイトする時間[nsec]

・タイマーまたはビジーループで実装する
・ＲＴＯＳ上ではこのＡＰＩ内で自ら待ち状態に入らない

2000/11/15〜17

•割り込みロック状態の制御ＡＰ
Ｉ– ＣＰＵロック状態•Ｉ
ＴＲＯＮの管理下にある割込みのみ禁止– 割り込みロック状態• ＮＭＩを除く全割り込みの禁止する。
ＤＩＣ内で割込みロック制御を使用する場合、ＤＩＣの呼び出し前後で状態を変えないための前処理が必要。
void SIL_PRE_LOC()
void SIL_LOC_INT()
void SIL_UNL_INT()

2000/11/15〜17

割り込みロック前処理
割り込みロック
割り込みロック解除

• 実装例
以下のサンプルプログラムを作成– ＳＩＯ» μPD72001用– フラッシュメモリ» 26F016SA用
共にWGのWebにて公開予定。
（遅れています。済みません。）

協力：
豊橋技術科学大学
組込みリアルタイムシステム研究室

2000/11/15〜17

• 今後の予定– サンプルプログラムの追加– ＧＤＩＣアーキテクチャの深堀• ＤＩＣ（タスク）のデザインパターン？
• ＤＩＣの構成方法•ｅｔｃ．ｅｔｃ．

引続き、ご意見募集しています。

2000/11/15〜17

御静聴ありがとうございました・デバイスドライバ設計ガイドライン第１版
は以下のURLで間もなく公開です。
(公開が遅れています。済みません）
http://www.itron.gr.jp/GUIDE/device‑j.html
・WGへのご意見は以下までお願いします。
device‑wg@itron.gr.jp

2000/11/15〜17