特許 5912804 周辺装置アクセスシステム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】5912804

(24)【登録日】2016年4月8日

(45)【発行日】2016年4月27日

(54)【発明の名称】周辺装置アクセスシステム

(51)【国際特許分類】

   G06F 13/10 20060101AFI20160414BHJP

   G06F 9/52 20060101ALI20160414BHJP

【ＦＩ】

   G06F13/10 330B

   G06F9/46 472Z

   G06F13/10 320A

【請求項の数】5

【全頁数】20

(21)【出願番号】特願2012-97096(P2012-97096)

(22)【出願日】2012年4月20日

(65)【公開番号】特開2013-225218(P2013-225218A)

(43)【公開日】2013年10月31日

【審査請求日】2015年3月16日

(73)【特許権者】

【識別番号】000005234

【氏名又は名称】富士電機株式会社

(73)【特許権者】

【識別番号】508296738

【氏名又は名称】富士電機機器制御株式会社

(74)【代理人】

【識別番号】100074099

【弁理士】

【氏名又は名称】大菅 義之

(72)【発明者】

【氏名】内田 修平

【審査官】 古河 雅輝

(56)【参考文献】

【文献】 特開２００２−２７８７７７（ＪＰ，Ａ）

【文献】 特開２０１２−１１３５３６（ＪＰ，Ａ）

【文献】 特開２００６−１７１８２１（ＪＰ，Ａ）

【文献】 特開２００３−３４５６１４（ＪＰ，Ａ）

【文献】 特開２００６−１６４１９１（ＪＰ，Ａ）

【文献】 特開２００７−０４７８６６（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ ３／０６− ３／０８

Ｇ０６Ｆ ９／０６

Ｇ０６Ｆ ９／４４− ９／５４

Ｇ０６Ｆ １１／００

Ｇ０６Ｆ １１／３６

Ｇ０６Ｆ １３／１０−１３／１４

(57)【特許請求の範囲】

【請求項1】

オペレーティングシステムと、周辺装置用の現ドライバと、前記オペレーティングシステム搭載前における周辺装置用の旧ドライバを介して周辺装置にアクセスするための各呼出処理を有する既存アプリケーションとを有する情報処理装置における周辺装置アクセスシステムであって、
前記既存アプリケーションの前記各呼出処理は、前記周辺装置にアクセスする為の前記旧ドライバの各処理をそれぞれ呼び出す処理であり、
前記各呼出処理に応じた各仲介処理を有すると共に、前記周辺装置へのアクセスに関する排他制御を行うアプリ実行手段を有し、
該アプリ実行手段は、任意の前記呼出処理がある毎に、該呼出処理に対応する前記仲介処理によって前記現ドライバの該当処理を呼出して実行させることで、前記周辺装置へのアクセスを行うことを特徴とする周辺装置アクセスシステム。

【請求項2】

前記各呼出処理は、前記旧ドライバの各処理をその処理名によって呼出すものであり、
前記各仲介処理には前記旧ドライバの各処理名と同一の処理名が与えられていると共に、前記現ドライバの各処理には前記旧ドライバの各処理名とは異なる処理名が与えられていることを特徴とする請求項１記載の周辺装置アクセスシステム。

【請求項3】

前記オペレーティングシステム搭載の環境下に応じて作成された新規アプリケーションを更に有し、
前記アプリ実行手段は、前記新規アプリケーションから所定のアクセス処理がある毎に、該アクセス処理に応じた前記現ドライバの複数の該当処理を順次呼出して実行させることで、該アクセス処理に応じた前記周辺装置へのアクセスを行うことを特徴とする請求項１または２に記載の周辺装置アクセスシステム。

【請求項4】

前記周辺装置へのアクセスが読出しである場合、前記旧ドライバの各処理と前記現ドライバの該当処理は、何れも、読出しの開始と完了確認とであり、
前記既存アプリケーションによって前記旧ドライバの読出しの開始と完了確認の各処理を呼び出すための呼出処理があると、前記アプリ実行手段の前記仲介処理が呼び出されて実行されることによって、前記現ドライバの読出しの開始と完了確認の各処理が呼び出されて実行されることを特徴とする請求項１〜３の何れかに記載の周辺装置アクセスシステム。

【請求項5】

前記オペレーティングシステムはリアルタイムオペレーティングシステムであり、前記既存アプリケーションは組込みソフトウェアであることを特徴とする請求項１〜４の何れかに記載の周辺装置アクセスシステム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、情報処理装置における周辺装置にアクセスするシステムに関する。

【背景技術】

【0002】

情報処理装置上で動作するアプリケーションソフトウェア（以下、アプリケーション）には、フラッシュメモリ等の周辺装置にアクセスするために、周辺装置用のドライバ（デバイスドライバ等；以下、単にドライバと記す場合もある）を介して周辺装置にアクセスすることが、一般に実施されている。

【0003】

上記周辺装置は、例えば記憶装置であり、一例がフラッシュメモリであるが、この例に限らない。
情報処理装置に関する技術の進歩に伴い、アプリケーションを実行するベースとなる環境は変化している。一例として、従来では、例えば時間制約が厳しい情報処理装置にはオペレーティングシステム（以下、ＯＳ）は搭載しないケースが多かった。これは、ＯＳの使用による時間的なオーバヘッド等の問題があるからである。ＯＳが搭載されていない情報処理装置においては、各アプリケーションが、直接、周辺装置用のドライバを制御して周辺装置へのアクセスを行うことになる。

【0004】

しかしながら近年では、情報処理装置に関する技術の進歩に伴い、ＯＳの使用による時間的なオーバヘッドは小さくなり、時間制約が厳しい情報処理装置に対しても、ＯＳを搭載して使用可能になりつつある。

【0005】

例えば上記アプリケーションとしての“組込みソフトウェア”が搭載された情報処理装置（組込み機器や組込みシステム等と呼ばれる）が知られている。この様な情報処理装置では、ＯＳが搭載されていないケースが多かったが、近年、ＯＳが搭載されるケースが増えている。このＯＳは、例えばＲＴＯＳ（リアルタイムＯＳ）等である。これに伴って、既存の（ＯＳが搭載されていない）情報処理装置に対して、後から、ＯＳを搭載するケースがある。

【0006】

ＯＳを搭載・使用する場合、タスクごとのスタック、およびメモリプール等のため、ＯＳを搭載していない既存の情報処理装置と比べ、多くのデータ領域が必要である。また、タスク切り替え等のＯＳ処理に伴い、プログラムサイズも増加する。このため、ＯＳを搭載していない既存の情報処理装置に対して後からＯＳを搭載・使用する場合は、フラッシュメモリ等のハードウェアを変更しなければならないことが多い。この場合、周辺装置用のドライバは再度作成する必要があり、通常はＯＳ上で動作するドライバとして作成する。

【0007】

上記のようにＯＳが搭載されていない情報処理装置においては、各アプリケーションが、直接、周辺装置用のドライバを制御して周辺装置へのアクセスを行うことになる。この様な周辺装置へのアクセス処理の一例を図１２に示す。

【0008】

図１２は、ＯＳ未搭載の情報処理装置における周辺装置へのアクセス処理例を示す図である。
図１２に示す情報処理装置１００がＯＳ未搭載の情報処理装置である。この情報処理装置１００には、上記周辺装置の一例であるフラッシュメモリ１２０が設けられており、このフラッシュメモリ１２０用のドライバ１１０が、情報処理装置１００内に搭載されている。

【0009】

このドライバ１１０には、フラッシュメモリ１２０にアクセスする為の所定の関数（処理コード）が、予め用意されている。図示の例では、ドライバ１１０は、「読出開始（関数名；startRead）」１１１、「読出完了確認（関数名；checkReadEnd）」１１２、「書込開始（関数名；startWrite）」１１３、「書込完了確認（関数名；checkWriteEnd）」１１４、「ドライバメイン関数（関数名；mainDriver）」１１５の各処理（関数）を有している。

【0010】

全体のメイン関数１０２は、各アプリケーション１０１やドライバメイン関数１１５の管理制御（定期的な起動や、優先度に応じた割込み等）を行う。尚、全体のメイン関数１０２は、例えばアプリケーション作成者等が作成する。これは、ＯＳ未搭載である為にＯＳの機能（タスクディスパッチャ等）を利用できないので作成するものである。

【0011】

各アプリケーション１０１は、様々な処理を行うものであってよいが、ここではフラッシュメモリ１２０へのアクセスに係わる処理だけを図示・説明する。
各アプリケーション１０１は、上記ドライバ１１０の各関数名を用いて任意の関数を呼び出して処理実行させることで、ドライバ１１０を介したフラッシュメモリ１２０へのアクセスを実現する。ここで、例えばフラッシュメモリ１２０からのデータリードを行う場合には、アプリケーション１０１は、まず「読出開始」１１１を呼出し、その後、「読出完了確認」１１２を呼出す。その際、プロセッサの実行権を逐一解放しながら動作する必要がある。これは、ドライバ１１０中の処理（ドライバメイン関数１１５）を実行させるためにはアプリケーション１０１が持つ実行権を解放する必要があるためである。

【0012】

同様に、データライトの場合には、まず「書込開始」１１３を呼出し、その後、「書込完了確認」１１４を呼出す必要がある。
尚、アプリケーション１０１は、「読出開始」１１１または「書込開始」１１３の呼出しの際には、アクセス先のアドレスやファイル名等を引数として渡す。

【0013】

上記呼び出された「読出開始」１１１や「書込開始」１１３は、例えばドライバ１１０内の状態変数（例えば不図示の各種フラグ）を変えること等で、ドライバメイン関数１１５にフラッシュメモリ１２０へのアクセス処理を実行させる。

【0014】

すなわち、例えば、上記呼び出された「読出開始」１１１は、ドライバ１１０内に格納されている読出開始フラグ（不図示）をオンすると共に、ドライバ１１０内の所定の記憶領域に上記アクセス先のアドレスやファイル名を格納する。ドライバメイン関数１１５は、これらフラグや所定の記憶領域を参照して、例えば読出開始フラグがオンであれば所定の記憶領域に格納されているアドレスやファイル名を用いてフラッシュメモリ１２０にアクセスする（データリードする）。

【0015】

同様に、上記呼び出された「書込開始」１１３は、ドライバ１１０内に格納されている書込開始フラグ（不図示）をオンすると共に、ドライバ１１０内の所定の記憶領域に上記アクセス先のアドレスやファイル名を格納する。ドライバメイン関数１１５は、これらフラグや所定の記憶領域を参照して、例えば書込開始フラグがオンであれば所定の記憶領域に格納されているアドレスやファイル名を用いてフラッシュメモリ１２０にアクセスする（データライトする）。

【0016】

一方、ＯＳが搭載された情報処理装置上で動作するアプリケーション（不図示）は、上記ドライバ１１０の機能に応じた複数の処理（「読出開始」と「読出完了確認」）を呼び出す必要もなければ、プロセッサの実行権を逐一解放する必要も無い（この様な処理は、ＯＳが行う）。これにより、アプリケーションの処理を簡素にすることが可能になるため（例えば周辺装置へのアクセス処理を、例えば単純に「読出」（read）や「書込」（write）等とすることができる）、アプリケーションの開発効率が（ＯＳ未搭載の場合と比べて）向上する。

【0017】

また、例えば特許文献１に記載の従来技術が知られている。
特許文献1には、ＯＳが異なる場合であっても、アプリケーションを変更することなく実行可能なシステムが開示されている。

【0018】

特許文献１には、例えばその従来技術に、あるＣＰＵ（Ａ）用のＯＳ（Ｂ）に対応して書かれたアプリケーションを、異種のＣＰＵ（Ｃ）用のＯＳ（Ｄ）上でも動作させる方法として、ＯＳ（Ｄ）上に、ＣＰＵ（Ａ）の命令をシミュレートするシミュレート部を設けると共に、このシミュレート部上でＯＳ（Ｂ）を実行し、このＯＳ（Ｂ）上でアプリケーションを実行する方法が記載されている。

【0019】

特許文献１の発明では、アプリケーションソフトウェアのソースプログラムは、プログラム本体中に記述された手続、関数、論理を、仮想実行環境が実現される既存ＯＳの種別毎に他の手続、関数、論理に置き換える情報を記述した置換情報記述部を有する。そして、プログラム本体と、置換情報記述部に記述された置換情報を、既存ＯＳ用コンパイラを利用して、仮想実行環境上で実行可能な実行可能プログラムに翻訳する翻訳部を有する。更に、上記既存ＯＳを利用して上記実行可能プログラムが実行する命令を実行する実行部を備える。

【先行技術文献】

【特許文献】

【0020】

【特許文献1】特開平８-６３３６３号公報

【発明の概要】

【発明が解決しようとする課題】

【0021】

ここで、上記図１２に示すようなＯＳ未搭載の情報処理装置１００に対して、後からＯＳを搭載させることが行われる場合がある。これは、例えば、上記組込みソフトウェアが搭載された情報処理装置に対して、上記ＲＴ（リアルタイム）ＯＳが搭載される場合等である。

【0022】

この場合、ＯＳ搭載後に新たに追加作成するアプリケーション（新規アプリケーションという）に関しては、搭載されたＯＳの機能（ＡＰＩ等）を利用するものとすればよい。よって、上記の通り、処理が簡素化されるし、プロセッサの実行権を逐一解放する処理を行う必要もないものとなる。

【0023】

一方、ＯＳ搭載前から存在したアプリケーション（既存アプリケーションという）は、上記新規アプリケーションと同様にＯＳの機能を利用する処理へと変更する必要があった。この変更の為に、工数が多く掛かる（手間が掛かる）という問題があった。特に、既存アプリケーションの数が多い場合には、非常に手間が掛かっていた。

【0024】

この様な問題に対して、例えば特許文献1に記載のシステムは、既存情報処理装置、新情報処理装置の双方ともＯＳ上で動作することが前提である。このため、上記のようなＯＳ未搭載の情報処理装置であってこの環境に応じた既存アプリケーションが既に存在する情報処理装置に対して、後からＯＳを搭載する場合における上記既存アプリケーションに係わる問題は、特許文献１では何等想定されておらず、特許文献１の発明ではこの様な問題は何等解決できない。

【0025】

本発明の課題は、ＯＳ未搭載の環境に応じた既存アプリケーションを有する情報処理装置に対して、ＯＳを搭載して且つ周辺装置用のドライバを再作成した場合に、既存アプリケーションを変更することなく新規ドライバを介した周辺装置へのアクセスを容易に実現する周辺装置アクセスシステム等を提供することである。

【課題を解決するための手段】

【0026】

本発明の周辺装置アクセスシステムは、オペレーティングシステムと、周辺装置用の現ドライバと、前記オペレーティングシステム搭載前における周辺装置用の旧ドライバを介して周辺装置にアクセスするための各呼出処理を有する既存アプリケーションとを有する情報処理装置における周辺装置アクセスシステムであって、前記既存アプリケーションの前記各呼出処理は、前記周辺装置にアクセスする為の前記旧ドライバの各処理をそれぞれ呼び出す処理であり、前記各呼出処理に応じた各仲介処理を有すると共に、前記周辺装置へのアクセスに関する排他制御を行うアプリ実行手段を有し、該アプリ実行手段は、任意の前記呼出処理がある毎に、該呼出処理に対応する前記仲介処理によって前記現ドライバの該当処理を呼出して実行させることで、前記周辺装置へのアクセスを行う。

【0027】

上記旧ドライバは上記情報処理装置がオペレーティングシステム未搭載のときの周辺装置用のドライバであり、上記既存アプリケーションは旧ドライバを介して周辺装置にアクセスしていた。周辺装置用のドライバは、オペレーティングシステム搭載に伴って上記現ドライバへと変更される。この場合でも、上記アプリ実行手段の各仲介処理によって、上記既存アプリケーションに手を加える必要なく、周辺装置へのアクセスを実現させる。

【発明の効果】

【0028】

本発明の周辺装置アクセスシステム等によれば、ＯＳ未搭載の環境に応じた既存アプリケーションを有する情報処理装置に対して、ＯＳを搭載して且つ周辺装置用のドライバを再作成した場合に、既存アプリケーションを変更することなく新規ドライバを介した周辺装置へのアクセスを容易に実現できる。

【図面の簡単な説明】

【0029】

【図1】本例の情報処理装置のハード構成例である。

【図2】図１の情報処理装置におけるフラッシュメモリへのアクセス動作例を示す図である。

【図3】（ａ）、（ｂ）は、アプリ実行部の「読出開始」、「書込開始」の処理フローチャート図である。

【図4】（ａ）、（ｂ）は、アプリ実行部の「読出完了確認」、「書込完了確認」の処理フローチャート図である。

【図5】（ａ）、（ｂ）は、アプリ実行部の「読出」、「書込」の処理フローチャート図である。

【図6】（ａ），（ｂ）は、ドライバの「読出開始」、「書込開始」の処理フローチャート図である。

【図7】（ａ），（ｂ）は、ドライバの「読出完了確認」、「書込完了確認」の処理フローチャート図である。

【図8】ドライバタスクの処理フローチャート図である。

【図9】既存アプリケーションの処理動作例である。

【図10】新規アプリケーションの処理動作例である。

【図11】（ａ）、（ｂ）は、タスク管理制御の一例を示す図である。

【図12】ＯＳ未搭載の情報処理装置における周辺装置へのアクセス処理例を示す図である。

【発明を実施するための形態】

【0030】

以下、図面を参照して本発明の実施の形態について説明する。
図１は、本例の情報処理装置１０のハード構成例である。
図示の例の情報処理装置１０は、プロセッサ１１、ＲＡＭ１２、フラッシュメモリ１３等を有する。ここでは、上記周辺装置の一例としてフラッシュメモリ１３を示している。尚、図示の構成以外の構成もあってもよい。例えば、ＲＯＭやハードディスク等の不図示の記憶装置があってよく、記憶装置に予め記憶されている所定のプログラムをプロセッサ１１が読出・実行することにより、後述する各種フローチャートの処理が実現されるものであってもよい。

【0031】

また、周辺装置はフラッシュメモリ１３に限らないが、ここではフラッシュメモリ１３を例にして図示・説明するものとする。
尚、プロセッサ１１は、例えばＣＰＵ、ＭＰＵ等である。

【0032】

図２は、上記情報処理装置１０におけるフラッシュメモリ１３へのアクセス動作例を示す図である。
図示の例の情報処理装置１０は、タスクディスパッチャ１、既存アプリケーション２、新規アプリケーション３、読出用セマフォ４、書込用セマフォ５、アプリ実行部２０、ドライバ３０（デバイスドライバ等）を有する。

【0033】

これら既存アプリケーション２、新規アプリケーション３等の各種アプリケーションプログラムや、タスクディスパッチャ１、アプリ実行部２０、ドライバ３０の後述する各種処理機能を実現するプログラムは、予め例えば上記不図示の記憶装置に記憶されている。上記ＣＰＵ／ＭＰＵ等であるプロセッサ１１が、この記憶装置からこれらの各種プログラムを読出し実行することにより、後述する各種処理機能が実現される（例えば、図３〜図１０の各フローチャート図に示す処理機能が実現される）。

【0034】

概略的には、後述するＯＳの機能の一部であるタスクディスパッチャ１が、各既存アプリケーション２、各新規アプリケーション３、ドライバ３０の後述するドライバタスク３５等の各タスクの実行制御を行う。任意の既存アプリケーション２または新規アプリケーション３を実行中にフラッシュメモリ１３へのアクセス処理が発生した場合には、例えばＡＰＩ等であるアプリ実行部２０によって、読出用セマフォ４または書込用セマフォ５による排他制御を行いつつ、ドライバ３０を介してフラッシュメモリ１３にアクセスすることになる。

【0035】

尚、アプリ実行部２０やドライバ３０は、ＯＳ（オペレーティングシステム）の機能を利用するものであるが、最初からＯＳに組み込まれているものではなく、例えばアプリケーション２，３等を作成するメーカ側で作成する。

【0036】

ここで、図１、図２に示す情報処理装置１０は、典型的な一例としては、上記図１２の情報処理装置１００に対して、ＯＳ（例えば上記リアルタイムＯＳ）を追加・搭載したものである。このＯＳ自体については、特に図示・説明等しないが、上述した通り、ＯＳの追加搭載に伴って、フラッシュメモリやそのドライバの変更が行われる場合がある。すなわち、図１２のフラッシュメモリ１２０とそのドライバ１１０が、図２に示すフラッシュメモリ１３とそのドライバ３０へと変更されている。フラッシュメモリ１３は、例えば単に記憶容量が増えたものである。但し、この例に限らず、フラッシュメモリについては変更無しであってもよい（但し、この場合でも、ドライバは、ＯＳ搭載環境に応じたものへと変更する）。

【0037】

ドライバ１１０は、ＯＳ搭載前の（未搭載の）環境下における周辺装置用（ここではフラッシュメモリ１３用）のドライバであり、旧ドライバと言える。一方、ドライバ３０は、ＯＳ搭載後に作成された、当該ＯＳ搭載の環境下における（現在の環境下における）周辺装置用のドライバであり、現ドライバと言える。また、既存アプリケーション２は、上記ＯＳ未搭載の環境下に応じて作成され、上記旧ドライバを介して周辺装置にアクセスするための各呼出処理を有するものと言える。当該既存アプリケーション２の各呼出処理は、例えば、周辺装置へのアクセスの為の上記旧ドライバの各処理（一連の処理など）をそれぞれ（順次）呼び出して実行させる処理である。

【0038】

そして、上記アプリ実行部２０は、情報処理装置がＯＳ未搭載からＯＳ搭載へと変わった場合でも、既存アプリケーション２を変更／修正することなく上記現ドライバを介した周辺装置へのアクセスを実現させる処理機能を有する。つまり、アプリ実行部２０は、上記各呼出処理に応じた各仲介処理を有すると共に、周辺装置へのアクセスに関する排他制御を行う。アプリ実行部２０は、既存アプリケーション２から任意の呼出処理がある毎に、該呼出処理に対応する仲介処理によって上記現ドライバの該当処理を呼出して実行させることで、周辺装置へのアクセスを実現させるものである。これについては、後に、詳しく説明する。

【0039】

ドライバ３０は、基本的には上記ドライバ１１０と略同様の処理を行うものであってよいが、関数名が変わっている点や、「ドライバメイン関数」１１５が、タスクディスパッチャ１でタスク管理されると共に「読出開始」処理３１等との間のやりとりをＯＳの機能を利用してメッセージ通信で行う点等で、ドライバ１１０と異なる。

【0040】

ここで、本手法によれは、上記ＯＳ未搭載の環境に応じた上記アプリケーション１０１は、ＯＳ搭載があっても変更する必要はなく、これが図２に示す既存アプリケーション２であってもよい。換言すれば、典型的な例としては、既存アプリケーション２は、上記情報処理装置１００のアプリケーション１０１そのものである。これより、ここでは、既存アプリケーション２は、従来のアプリケーション１０１と同様に、上記“startRead”、“checkReadEnd”、“startWrite”、“checkWriteEnd”の各関数名を用いた関数呼び出しを行うものとする。

【0041】

一方、ドライバ３０は、「読出開始」処理３１、「読出完了確認」処理３２、「書込開始」処理３３、「書込完了確認」処理３４、「ドライバタスク」処理３５の各処理（関数）を有しており、これらは基本的には上記「読出開始」１１１、「読出完了確認」１１２、「書込開始」１１３、「書込完了確認」１１４、「ドライバメイン関数」１１５に相当する処理を行うが、図示のように処理名（関数名）が異なっている。これは、例えばドライバ３０の作成時にその作成者が意図的に異なる関数名等を付与するものである。

【0042】

従って、上記、既存アプリケーション２が上記“startRead”、“checkReadEnd”、“startWrite”、“checkWriteEnd”の各関数名を用いた関数呼び出し（各呼出処理）を行っても、ドライバ３０の処理（関数）が呼び出されることはない。

【0043】

その一方で、これらの関数名はアプリ実行部２０で用いるようにしている。すなわち、アプリ実行部２０の図示の各関数のうち、「読出開始」２１、「読出完了確認」２３、「書込開始」２４、「書込完了確認」２６の各処理（上記仲介処理に相当）の名称を、上記“startRead”、“checkReadEnd”、“startWrite”、“checkWriteEnd”としている。これは、アプリ実行部２０の作成時にその作成者が意図的に、上記既存アプリケーション２の各呼出処理に用いるものと同じ名称（関数名）を付与するものである。

【0044】

これより、既存アプリケーション２（１０１）は、フラッシュメモリ１３のアクセスの際には、アプリ実行部２０の「読出開始」２１、「読出完了確認」２３、「書込開始」２４、「書込完了確認」２６の何れかの仲介処理を呼び出すことになる。これは、データリード時には「読出開始」２１を呼出し、その後、「読出完了確認」２３を呼び出す。データライド時には、「書込開始」２４を呼出し、その後、「書込完了確認」２６を呼び出す。

【0045】

そして、アプリ実行部２０の「読出開始」２１、「読出完了確認」２３、「書込開始」２４、「書込完了確認」２６の各処理は、ＯＳの機能を用いた排他制御（読出用セマフォ４や書込用セマフォ５を用いた、フラッシュメモリ１３へのアクセスに関する排他制御）を行うと共に、上記ドライバ３０の「読出開始」処理３１、「読出完了確認」処理３２、「書込開始」処理３３、「書込完了確認」処理３４を呼び出す処理を行う。例えば、「読出開始」２１は、ドライバ３０の「読出開始」処理３１を呼び出して実行させる。これより、既存アプリケーション２が例えば上記“startRead”の呼出し処理を行うと、結果的に、上記「読出開始」１１１に相当する処理である「読出開始」２１が呼び出されて処理実行されることになる。

【0046】

尚、「読出完了確認」２３は、呼び出されると、ドライバ３０の「読出完了確認」処理３２を呼び出して実行させる。上記「書込開始」２４は、呼び出されると、ドライバ３０の「書込開始」処理３３を呼出して実行させる。上記「書込完了確認」２６は、呼び出されると、ドライバ３０の「書込完了確認」処理３４を呼び出して実行させる。

【0047】

上記呼び出された「読出開始」処理３１、「読出完了確認」処理３２、「書込開始」処理３３、「書込完了確認」処理３４は、何れも、ＯＳ（例えばＲＴＯＳ）の機能を利用してドライバタスク３５との間でメッセージ通信を行う。これより、ドライバタスク３５がフラッシュメモリ１３へのアクセス処理を実行する（フラッシュメモリ１３へのアクセス処理自体は、従来のドライバメイン関数１１５と略同様であってよい）。

【0048】

また、上記の通り、上記アプリ実行部２０の「読出開始」２１、「読出」２２、「読出完了確認」２３、「書込開始」２４、「書込」２５、「書込完了確認」２６の各処理機能を実行する際には、セマフォによる排他制御も行われる。すなわち、アプリ実行部２０は、フラッシュメモリ１３の読出に関する排他制御のための読出用セマフォ４、および、フラッシュメモリ１３の書込に関する排他制御のための書込用セマフォ５を使用する。

【0049】

尚、従来のＯＳ未搭載の環境下では、排他制御は出来ない為、例えば各既存アプリケーションのフラッシュメモリのアクセス領域が相互に異なるようにすること等が、既存アプリケーションのプログラマに要求されていた。この為、プログラマは、この様な制約の元で既存アプリケーションを作成する手間が掛かっていたが、新規アプリケーションを作成する際には、この様な制約を気にする必要はなくなる。

【0050】

本手法の特徴の１つは、既存アプリケーション２を変更しないで済むようにすることであり、各既存アプリケーション２は、それぞれＯＳが搭載される前と同様にして上記“startRead”、“checkReadEnd”、“startWrite”、“checkWriteEnd”の各関数名を用いて関数呼出しを行うが、上記アプリ実行部２０やドライバ３０の構成・動作によって、何等問題なくドライバ３０のアクセス処理が行われることになる。

【0051】

更に、ＯＳ未搭載の環境下では排他制御が困難であるため、アプリケーション作成者は、複数のアプリケーションが同じファイルや同一の記憶領域にアクセスすることが無い様に、アプリケーション１０１を作成する必要があった。

【0052】

これに対して、ＯＳ搭載することで容易に排他制御が実現できるので、新規アプリケーション３は、既存アプリケーション２や他の新規アプリケーション３と同じファイルや同一の記憶領域にアクセスするように作成される場合も有り得る。この場合、もし、既存アプリケーション２が直接的にドライバ３０の関数を呼び出す構成とした場合、排他制御が実現できず、既存アプリケーション２と新規アプリケーション３とで同時期に同じファイルや同一の記憶領域にアクセスする可能性があった。これに対して、本手法では、新規アプリケーション３だけでなく既存アプリケーション２の実行の際にも、アプリ実行部２０を介してアクセスするので、この様な問題を解消できる。

【0053】

ここで、上記新規アプリケーション３は、ＯＳが搭載された後に作成されたアプリケーションであり、ＯＳ（そのＡＰＩ等）の機能を利用してフラッシュメモリ１３にアクセスする。つまり、新規アプリケーション３は、フラッシュメモリ１３のアクセスの際には、データリード時には「読出」２２を呼び出し、データライト時には「書込」２５を呼び出すように作成されている。

【0054】

これら「読出」２２や「書込」２５の各処理機能自体は、既存の一般的なＡＰＩ等の機能と略同様と見做してもよい。「読出」２２は、呼び出されると、まず、ドライバ３０の「読出開始」処理３１を呼出して実行させ、その後、ドライバ３０の「読出完了確認」処理３２を呼び出して実行させる。同様に、「書込」２５は、呼び出されると、まず、ドライバ３０の「書込開始」処理３３を呼出して実行させ、その後、ドライバ３０の「書込完了確認」処理３４を呼び出して実行させる。

【0055】

これより、新規アプリケーション３の作成者は、ＯＳ搭載前のようなドライバ制御（読出開始と、その後の読出完了確認）を意識する必要はなく、単に「読出」（関数名；read）または「書込」（関数名；write）を指定すれば済むようになる。この様な利便性向上が、ＯＳ搭載のメリットの１つであるが、上述したように既存アプリケーション２に関して問題が生じるが、上記の通り本手法ではこの問題を解消できる。

【0056】

尚、本例では周辺装置は記憶装置であり、記憶装置の一例がフラッシュメモリ１３である。記憶装置であるので、アクセス処理は基本的にデータリードとデータライトである。ドライバ３０を介してアクセスする記憶装置は、情報処理装置１０内蔵のものであってもよいし、外付けハードディスク等のように情報処理装置１０に接続するものであってもよいし、他の情報処理装置内の記憶装置であってもよい。他の情報処理装置内の記憶装置である場合には、通信線を介してアクセスするものとなる。

【0057】

上述した各関数／処理の処理について、図３〜図１０の各フローチャート図に示す。
以下、図３〜図１０の各フローチャート図の処理について説明する。
まず、図３（ａ）、（ｂ）は、アプリ実行部２０の「読出開始」２１、「書込開始」２４の処理フローチャート図である。

【0058】

図３（ａ）に示すように、上記アプリ実行部２０の「読出開始」２１は、既存アプリケーション２から呼び出されると、読出用セマフォ４から資源を獲得したら（ステップＳ１１）、ドライバ３０の「読出開始」処理３１を呼び出す（ステップＳ１２）。

【0059】

尚、図には示していないが、当然、読出用セマフォ４から資源を獲得出来なかった場合には、ステップＳ１２の処理を実行することなく、例えばエラーを呼出し元の既存アプリケーション２に返す。

【0060】

尚、セマフォによる資源獲得は、既存の一般的な技術であり、特に詳細には説明しないが、例えばアクセス禁止の記憶領域（アドレス）や、他のアプリケーション等によってアクセス中の記憶領域（アドレス）やファイル等に対するアクセス要求があった場合には、資源（アクセス権といってもよい）は獲得出来ないことになる。

【0061】

尚、既存アプリケーション２は、「読出開始」２１や「書込開始」２４の呼出しの際には、アクセス要求する記憶領域（アドレス／アドレス範囲）やファイル名等を例えばパラメータとして渡している。これは、新規アプリケーション３による「読出」２２や「書込」２５の呼出しの際も同様である。

【0062】

また、図３（ｂ）に示すように、上記アプリ実行部２０の「書込開始」２４は、既存アプリケーション２から呼び出されると、書込用セマフォ５から資源を獲得したら（ステップＳ１５）、ドライバ３０の「書込開始」処理３３を呼び出す（ステップＳ１６）。

【0063】

尚、図示していないが、この場合も、書込用セマフォ５から資源を獲得出来なかった場合には、ステップＳ１６の処理を実行することなく、例えばエラーを呼出し元の既存アプリケーション２に返す。

【0064】

なお、フラッシュメモリ１３が読出と書込が同時にできない場合に対応するため、読出用セマフォ４と書込用セマフォ５とに分けるのではなく、１つのセマフォ（アクセス用セマフォと呼ぶものとする）にしてもよい。この場合には、ステップＳ１１とＳ１５の処理は、何れも、アクセス用セマフォから資源を獲得することになる。

【0065】

図４（ａ）、（ｂ）は、アプリ実行部２０の「読出完了確認」２３、「書込完了確認」２６の処理フローチャート図である。
図４（ａ）に示すように、上記アプリ実行部２０の「読出完了確認」２３は、既存アプリケーション２から呼び出されると、ドライバ３０の「読出完了確認」処理３２を呼び出す（ステップＳ２１）。そして、「読出完了確認」処理３２からの返信（“処理完了”の通知）を待ち、“処理完了”の返信があった場合には（ステップＳ２２，ＹＥＳ）、読出用セマフォ４に資源を返却して（ステップＳ２３）、本処理を終了する。

【0066】

一方、例えば所定の待ち時間内に“処理完了”の返信が無かった場合には（ステップＳ２２，ＮＯ）、そのまま本処理を終了する。尚、その後、例えば所定時間後に再び本処理を実行するようにしてもよいが、この例に限らない。

【0067】

また、図４（ｂ）に示すように、上記アプリ実行部２０の「書込完了確認」２６は、既存アプリケーション２から呼び出されると、ドライバ３０の「書込完了確認」処理３４を呼び出す（ステップＳ２５）。そして、「書込完了確認」処理３４からの返信（“処理完了”の通知）を待ち、“処理完了”の返信があった場合には（ステップＳ２６，ＹＥＳ）、書込用セマフォ５に資源を返却して（ステップＳ２７）、本処理を終了する。

【0068】

一方、例えば所定の待ち時間内に“処理完了”の返信が無かった場合には（ステップＳ２６，ＮＯ）、そのまま本処理を終了する。尚、その後、例えば所定時間後に再び本処理を実行するようにしてもよいが、この例に限らない。

【0069】

また、図５（ａ）、（ｂ）は、アプリ実行部２０の「読出」２２、「書込」２５の処理フローチャート図である。尚、「読出」２２、「書込」２５とも、パラメータにはタイムアウト時間が含まれる。

【0070】

図５（ａ）に示すように、上記アプリ実行部２０の「読出」２２は、新規アプリケーション３から呼び出されると、まず、読出用セマフォ４から資源を獲得したら（ステップＳ３１）、ドライバ３０の「読出開始」処理３１を呼び出す（ステップＳ３２）。

【0071】

尚、図には示していないが、読出用セマフォ４から資源を獲得出来なかった場合には、例えば、ステップＳ３２以降の処理を実行することなく、例えばエラーを呼出し元の新規アプリケーション３に返して、本処理を終了する。

【0072】

その後、「読出」２２は、パラメータとして指定されたタイムアウト時間が経過するまで（若しくはステップＳ３５の判定がＹＥＳとなるまで）、下記のステップＳ３４〜Ｓ３６のループ処理を繰り返し実行する（ステップＳ２３）。

【0073】

・ドライバ３０の「読出完了確認」処理３２を呼び出す（ステップＳ３４）。
・「読出完了確認」処理３２からの返信を待ち、“処理完了”が返信された場合には（ステップＳ３５，ＹＥＳ）、ループ処理を抜けてステップＳ３７へ移行する。

【0074】

・“処理完了”が返信されない場合には（ステップＳ３５，ＮＯ）、一定時間休止する（ステップＳ３６）。そして、一定時間経過後、再びステップＳ３４から処理実行する。
ステップＳ３５の判定がＹＥＳとなることなくタイムアウト時間経過した場合も、ループ処理を抜けてステップＳ３７へ移行する。

【0075】

ステップＳ３７では、読出用セマフォ４に資源を返却する。そして、本処理を終了する。
尚、ステップＳ３６における休止時間は、フラッシュメモリ１３の特性、および情報処理装置１０の性能要件を考慮して予め任意に決定されて設定されている。

【0076】

また、図５（ｂ）に示すように、上記アプリ実行部２０の「書込」２５は、新規アプリケーション３から呼び出されると、まず、書込用セマフォ５から資源を獲得したら（ステップＳ４１）、ドライバ３０の「書込開始」処理３３を呼び出す（ステップＳ４２）。

【0077】

尚、図には示していないが、書込用セマフォ５から資源を獲得出来なかった場合には、例えば、ステップＳ４２以降の処理を実行することなく、例えばエラーを呼出し元の新規アプリケーション３に返して、本処理を終了する。

【0078】

その後、「書込」２５は、パラメータとして指定されたタイムアウト時間が経過するまで（若しくはステップＳ４５の判定がＹＥＳとなるまで）、下記のステップＳ４４〜Ｓ４６のループ処理を繰り返し実行する（ステップＳ４３）。

【0079】

・ドライバ３０の「書込完了確認」処理３４を呼び出す（ステップＳ４４）。
・「書込完了確認」処理３４からの返信を待ち、“処理完了”が返信された場合には（ステップＳ４５，ＹＥＳ）、ループ処理を抜けてステップＳ４７へ移行する。

【0080】

・“処理完了”が返信されない場合には（ステップＳ４５，ＮＯ）、一定時間休止する（ステップＳ４６）。そして、一定時間経過後、再びステップＳ４４から処理実行する。
ステップＳ４５の判定がＹＥＳとなることなくタイムアウト時間経過した場合も、ループ処理を抜けてステップＳ４７へ移行する。

【0081】

ステップＳ４７では、書込用セマフォ５に資源を返却する。そして、本処理を終了する。
図６〜図８は、ドライバ３０の各関数の処理例を示すフローチャート図である。

【0082】

図６（ａ），（ｂ）は、ドライバ３０の「読出開始」処理３１、「書込開始」処理３３の処理フローチャート図である。
まず、図６（ａ）に示す「読出開始」処理３１は、上記メッセージ通信によってドライバタスク３５に対してフラッシュメモリ１３からのデータ読出しを依頼する（ステップＳ５１）。尚、その際、アクセス先アドレスやファイル名等（「読出開始」２１または「読出」２２から、当該「読出開始」処理３１の呼び出しの際に渡されている）を、ドライバタスク３５に渡す。

【0083】

また、図６（ｂ）に示す「書込開始」処理３３では、上記メッセージ通信によってドライバタスク３５に対してフラッシュメモリ１３へのデータ書込みを依頼する（ステップＳ５５）。尚、その際、データとアクセス先アドレスやファイル名等（「書込開始」２４または「書込」２５から、当該「書込開始」処理３３の呼び出しの際に渡されている）をドライバタスク３５に渡す。

【0084】

図７（ａ），（ｂ）は、ドライバ３０の「読出完了確認」処理３２、「書込完了確認」処理３４の処理フローチャート図である。
ドライバ３０の「読出完了確認」処理３２は、上記ステップＳ５１の処理後に、上記ステップＳ２１やＳ３４の処理によって上記「読出完了確認」２３や「読出」２２から呼び出されることで、図７（ａ）の処理を実行することになる。

【0085】

すなわち、「読出完了確認」処理３２は、ドライバタスク３５が後述するステップＳ７４の処理によって“読出完了”を通知してくるのを待つ（ステップＳ６１）。そして、特に図示しないが、“読出完了”通知があったら、上記「読出完了確認」２３や「読出」２２に“処理完了”を返信する（これによって上記ステップＳ２２やＳ３５がＹＥＳとなる）。尚、上記ステップＳ６１の待ち時間は、「読出完了確認」処理３２の呼出時に呼出し元等が指定する。

【0086】

ドライバ３０の「書込完了確認」処理３４は、上記ステップＳ５５の処理後に、上記ステップＳ２５やＳ４４の処理によって上記「書込完了確認」２６や「書込」２５から呼び出されることで、図７（ｂ）の処理を実行することになる。

【0087】

すなわち、「書込完了確認」処理３４は、ドライバタスク３５が後述するステップＳ７６の処理によって“書込完了”を通知してくるのを待つ（ステップＳ６５）。そして、特に図示しないが、“書込完了”通知があったら、上記「書込完了確認」２６や「書込」２５に“処理完了”を返信する（これによって上記ステップＳ２６やＳ４５がＹＥＳとなる）。

【0088】

図８は、ドライバタスク３５の処理フローチャート図である。
ドライバタスク３５は、例えば通常時は、「読出開始」処理３１からの読出依頼、または「書込開始」処理３３からの書込依頼の待ち状態となっている（ステップＳ７１）。そして、任意の依頼があると、読出依頼、書込依頼の何れであるかを判定し（ステップＳ７２）、読出依頼であればステップＳ７３へ移行し、書込依頼であればステップＳ７５へ移行する。

【0089】

すなわち、「読出開始」処理３１からの読出依頼を受けた場合には、フラッシュメモリ１３にアクセスしてデータを読み出す処理を実行する（ステップＳ７３）。勿論、これは、上記渡されたアドレスやファイル名等を用いてアクセスする。そして、データ読出し完了したら、「読出完了確認」処理３２に上記“読出完了”をメッセージ通信で通知する（ステップＳ７４）。

【0090】

一方、「書込開始」処理３３からの読出依頼を受けた場合には、フラッシュメモリ１３にアクセスしてデータを書き込む処理を実行する（ステップＳ７５）。勿論、これは、上記渡されたアドレスやファイル名等を用いてアクセスする。そして、データ書込み完了したら、「書込完了確認」処理３４に上記“書込完了”をメッセージ通信で通知する（ステップＳ７６）。

【0091】

図９は、既存アプリケーション２の処理動作例である。
尚、図９には読出し処理を示すが、特に図示・説明しないが、書込み処理も読出し処理と略同様と考えてよい。

【0092】

ここで、図９に示す「現在の状態」とは、アプリケーションがプロセッサの実行権を解放しながら動作する際、次に実行するべき処理を記録するための変数である。図示のステップＳ８１では、この変数（現在の状態）を参照することで、ステップＳ８２，Ｓ８５，Ｓ８７，Ｓ９０の何れかの処理に分岐する。

【0093】

すなわち、ステップＳ８１において、「現在の状態」が“前処理”であった場合には、ステップＳ８２へ移行する。この場合には、前処理を実行し（ステップＳ８２）、前処理が終了したならば（ステップＳ８３，ＹＥＳ）、上記「現在の状態」を“読出開始”へと変更する（ステップＳ８４）。

【0094】

そして、本処理を終了することで、プロセッサの実行権を解放する。これによって、プロセッサの実行権は、例えばドライバタスク３５等が有することになり、その後、再び当該アプリケーションが実行開始されると、今度はステップＳ８１において「現在の状態」が“読出開始”であることになり、ステップＳ８５へと移行することになる。この場合には、上述した「読出開始」２１を呼び出す処理を実行し（ステップＳ８５）、上記「現在の状態」を“読出完了確認”へと変更する（ステップＳ８６）。そして、本処理を終了する。

【0095】

これによって、次に図９の処理を実行するときには、ステップＳ８１において「現在の状態」が“読出完了確認”であることになり、ステップＳ８７へと移行することになる。この場合には、上述した「読出完了確認」２３を呼び出す処理を実行し（ステップＳ８７）、上述した“処理完了”が返信されてくるのを待つ。そして、上述した“処理完了”が返信されると（ステップＳ８８，ＹＥＳ）、上記「現在の状態」を“後処理”へと変更する（ステップＳ８９）。そして、本処理を終了する。

【0096】

これによって、次に図９の処理を実行するときには、ステップＳ８１において「現在の状態」が“後処理”であることになり、ステップＳ９０へと移行する。この場合には、後処理を実行し（ステップＳ９０）、後処理が終了したならば（ステップＳ９１，ＹＥＳ）、上記「現在の状態」を“完了”へと変更する（ステップＳ９２）。尚、ステップＳ９２の処理を、上記「現在の状態」を“前処理”へと変更する処理としてもよい。

【0097】

尚、上記前処理は、読出し処理の場合には必ずしも実行するものではないが、書込み処理の場合であれば書込みデータの生成処理等である。また、上記後処理は、例えば書込み処理の場合であれば書込み完了を他のアプリケーションに通知する処理等であるが、この例に限らない。

【0098】

尚、図９の処理には、上記従来の説明における逐一“プロセッサの実行権を解放する”ことも含まれている。すなわち、図９の処理は、図１０のように前処理から後処理までの一連の処理を連続して実行するのではなく、例えば前処理を実行完了したら（完了しなくてもステップＳ８３がＮＯであれば）上記の通り一旦処理終了となる。これは、上記の通り、読出開始、読出完了確認、後処理についても同様である。この様に一連の処理を一旦終了させることが上記“プロセッサの実行権を逐一解放する”ことに相当する。

【0099】

この様に、図９のアプリケーション処理を逐一中断することで、他のアプリケーション等の処理を実行可能となる。そして、中断後に再開したときに、どこまで処理実行したのか分かるようにする為に、上記のように「現在の状態」に記録している。

【0100】

一方、ＯＳが搭載された環境下では、後述する図１０の新規アプリケーション３の処理のように、逐一“プロセッサの実行権を解放する”ことは必要なくなる。しかし、本手法では既存アプリケーション２（１０１）を修正等することなくそのまま実行可能とするものであるので、既存アプリケーション２はＯＳ未搭載のときのまま上記図９の処理を実行することになる。

【0101】

図１０は、新規アプリケーション３の処理動作例である。
図示の例では、新規アプリケーション３は、上記前処理を実行した後（ステップＳ１０１）、アプリ実行部２０の上述した「読出」２２を呼び出して処理実行させる（ステップＳ１０２）。「読出」２２の処理によってフラッシュメモリ１３からの読出データを得たら、例えばこの読出データを使用して書込データを作成する等の処理を行う（ステップＳ１０３）。この例に限らないが、任意の書込データが発生したら、アプリ実行部２０の上述した「書込」２５を呼び出して処理実行させる（ステップＳ１０４）。そして、上述した“処理完了”の返信などによって書込み完了したことを確認したら、上記後処理を実行する（ステップＳ１０５）。

【0102】

上記図９、図１０は、単に、ＯＳ未搭載の環境に応じたアプリケーションと、ＯＳ搭載の環境に応じたアプリケーションとの比較の為に示したものであり、図９、図１０の処理自体は一般的なものである。

【0103】

図９と図１０とを比較すれば明らかなように、例えばデータリード処理に関しては、新規アプリケーション３の場合は「読出」２２を呼び出せば済み、既存アプリケーション２の場合（「読出開始」２１と「読出完了確認」２３の呼出しが必要、且つ変数「現在の状態」による状態管理や“プロセッサの実行権を逐一解放する”こと等も必要）に比べて、アプリケーション中の処理呼出回数を少なくすることができる、状態管理が不要等、処理負荷が大幅に軽減できる。この点自体は、ＯＳ搭載による一般的なメリットであるが、既存アプリケーション２の処理を新規アプリケーション３のように変更することは、手間が掛かることは明らかである。この為、本手法では、既存アプリケーション２を変更しなくて済むようにしている。

【0104】

その為に、例えば、既存アプリケーション２が、ドライバ３０ではなくアプリ実行部２０中の処理機能を呼び出すようにするため、アプリ実行部２０中の上記「読出開始」２１、「読出完了確認」２３、「書込開始」２４、「書込完了確認」２６の各処理機能の名称（処理名というものとする；Ｃ言語であれば関数名であるので、上記説明では関数名としたが、この例に限らない）は、ＯＳ搭載前の情報処理装置１０のドライバ（ドライバ２０に相当）における各処理の処理名と同一にする（換言すれば、既存アプリケーション２中に記述された呼出し先名称（関数名など）と同一とする）。

【0105】

そのうえで、アプリ実行部２０中の上記各処理の処理内容は、ドライバ３０中の対応する処理（関数／処理コード等）を呼び出す処理としている。
図１１に、本例の情報処理装置１０におけるタスク管理制御の一例を示す。

【0106】

図２に示すように、本例の情報処理装置１０では、新旧アプリケーション（既存アプリケーション２と新規アプリケーション３）が混在する状態となる。この様な状況で新旧アプリケーションの動作を管理する為に、例えば図１１（ａ）に示すようにする。

【0107】

ここで、図１１では、既存アプリケーション２としてアプリケーションＡ、アプリケーションＢがあり、新規アプリケーション３としてアプリケーションＣがあるものとする。図示のＡ，Ｂ，Ｃ，が、それぞれ、アプリケーションＡ，Ｂ，Ｃを意味する。

【0108】

そして、複数の既存アプリケーションＡ，Ｂに関しては、図１１（ａ）に示すように、タスクαによって管理制御する。図示の通り、タスクαは、アプリケーションＡとアプリケーションＢとを順次繰り返し実行させるものである。これより、例えば、まずアプリケーションＡについて上記前処理に係る一連の処理（例えばステップＳ８２，Ｓ８３，Ｓ８４）を実行して“終了”したら、続いて、アプリケーションＢについても上記前処理に係る一連の処理（例えばステップＳ８２，Ｓ８３，Ｓ８４）を実行して“終了”したら、続いて、アプリケーションＡについて上記読出開始に係る一連の処理（ステップＳ８５等）を実行させることになる。

【0109】

一方、新規アプリケーションＣについては、図示のように、タスクβによって管理制御する。
そして、タスクディスパッチャ１が、これら複数のタスクα、βを管理制御する。この管理制御方法は任意でよいが、例えば図１１（ｂ）に示すように、優先度に応じて制御してもよい。尚、優先度は、予め各アプリケーション毎に任意に設定される。優先度に応じたタスク管理自体は、既存のタスク管理手法であるので、ここではこれ以上詳細には説明しない。

【0110】

尚、特に図示しないが、タスクディスパッチャ１は、更に、上記ドライバタスク３５等も管理制御する。
上記情報処理装置１０は、具体例としては、例えば、電源装置、ＵＰＳ（無停電電源装置）、インバータ、各種家電製品（エアコン等）である。換言すれば、情報処理装置１０は、一例としては、“組込みソフトウェア”の搭載機器（組込み機器、組込みシステムなど）と考えても良い。つまり、この例の場合、上記既存アプリケーション２（１０１）は“組込みソフトウェア”であることになる。また、この例の場合、上記新規アプリケーション３も“組込みソフトウェア”であってもよい。

【0111】

“組込みソフトウェア”の搭載機器としては、例えば、洗濯機、炊飯器、エアコン、テレビ、ビデオ、ＤＶＤプレイヤー、デジタルカメラ、プリンタ、コピー機、携帯電話、自動車、カーナビゲーションシステム、信号機、エレベーター、自動販売機、券売機、リモコン等が知られているが、これらの例に限らない。

【0112】

“組込みソフトウェア”搭載機器は、従来では基本的にはＯＳが無いものであったが、近年ではＯＳ搭載するものが増えてきている。例えば、従来のＯＳ未搭載の“組込みソフトウェア”搭載機器における“組込みソフトウェア”が既存アプリケーション２（１０１）に相当し、近年のＯＳ搭載型の“組込みソフトウェア”搭載機器における“組込みソフトウェア”が新規アプリケーション３に相当すると見做すこともできる。

【0113】

この様に、例えば“組込みソフトウェア”搭載機器等について、ＯＳ未搭載の状態からＯＳ搭載の状態へと変更した場合に、上述した既存アプリケーション２（１０１）に関する問題が生じるが、本手法ではこの問題を解決できる。

【0114】

すなわち、本手法では、上述したように、オペレーティングシステムが実装されていない環境で動作する各アプリケーション（各既存アプリケーション２）全てを、何ら手を加えることなく（修正等を行う必要なく）、オペレーティングシステムが実装されていない環境で動作させることができ、既存アプリケーション２の修正等に係わる作業負担を軽減できる。これは特に、既存アプリケーション２が多数ある場合には、作業負担を大幅に軽減することができる。

【符号の説明】

【0115】

１ タスクディスパッチャ
２ 既存のアプリケーション
３ 新規アプリケーション
４ 読出用セマフォ
５ 書込用セマフォ
１０ 情報処理装置
１１ プロセッサ
１２ ＲＡＭ
１３ フラッシュメモリ
２０ アプリ実行部
２１ 「読出開始」
２２ 「読出」
２３ 「読出完了確認」
２４ 「書込開始」
２５ 「書込」
２６ 「書込完了確認」
３０ ドライバ
３１ 「読出開始」処理
３２ 「読出完了確認」処理
３３ 「書込開始」処理
３４ 「書込完了確認」処理
３５ 「ドライバタスク」処理

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】