(57)【特許請求の範囲】
【請求項１】
ある周期サイクルで処理を繰り返し実行する動作をとるアプリケーションで記憶媒体へのアクセス要求が発生した際、前記記憶媒体へのアクセスを行う時に必要な関数を持つデバイスドライバに前記アプリケーションが当該関数の呼び出しを行い、当該呼び出しを受け付けた前記デバイスドライバが前記記憶媒体にアクセスを行うことにより、前記記憶媒体へのアクセスが実行される記憶媒体アクセス装置において、
前記アプリケーションと前記デバイスドライバとの間にミドルウェアとして設けられ、前記アプリケーションから前記関数の呼び出しを受け付けた際、前記アプリケーションがその１周期内において自処理を実行中であれば当該関数の呼び出しを一時的に保持し、前記アプリケーションが前記自処理を終了して次周期の処理開始を待つアイドル時間に入ると、それまで保持していた前記関数の呼び出しを前記デバイスドライバに送ることにより、前記アプリケーションに前記記憶媒体へのアクセスを実行させるアクセスモジュールを設け、
前記アクセスモジュールは、アクセス処理が１周期の前記アイドル時間で完了しない際、当該アクセス処理の続きを次周期のアイドル時間に継続して実行し、前記アクセス処理が完了するまでこの処理を繰り返し実行することを特徴とする記憶媒体アクセス装置。
【請求項２】
前記アクセスモジュールは、前記アプリケーションが前記アイドル時間になることを待つ最中に複数の前記関数の呼び出しを受け付けた際、予め設定された優先順位に沿って、優先順位の高い前記関数の呼び出しに準じたアクセス処理から順に実行することを特徴とする請求項１に記載の記憶媒体アクセス装置。
【請求項３】
ある周期サイクルで処理を繰り返し実行する動作をとるアプリケーションで記憶媒体へのアクセス要求が発生した際、前記記憶媒体へのアクセスを行う時に必要な関数を持つデバイスドライバに前記アプリケーションが当該関数の呼び出しを行い、当該呼び出しを受け付けた前記デバイスドライバが前記記憶媒体にアクセスを行うことにより、前記記憶媒体へのアクセスが実行される記憶媒体アクセス方法において、
前記アプリケーションと前記デバイスドライバとの間にミドルウェアとしてアクセスモジュールを設け、前記アクセスモジュールは、前記アプリケーションから前記関数の呼び出しを受け付けた際、前記アプリケーションがその１周期内において自処理を実行中であれば当該関数の呼び出しを一時的に保持し、前記アプリケーションが前記自処理を終了して次周期の処理開始を待つアイドル時間に入ると、それまで保持していた前記関数の呼び出しを前記デバイスドライバに送ることにより、前記アプリケーションに前記記憶媒体へのアクセスを実行させ、アクセス処理が１周期の前記アイドル時間で完了しない際、当該アクセス処理の続きを次周期のアイドル時間に継続して実行し、前記アクセス処理が完了するまでこの処理を繰り返し実行することを特徴とする記憶媒体アクセス方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、例えばＣＰＵに一体内蔵されたフラッシュＲＯＭ等の記憶媒体にＣＰＵがアクセスする際に動作する記憶媒体アクセス装置及び記憶媒体アクセス方法に関する。
【背景技術】
【０００２】
一般に、図７に示すように、マイクロコンピュータ（単にコンピュータとも言う）８０は、ＣＰＵ（Central Processing Unit）８１、ＲＯＭ（Read-Only Memory）８２、ＲＡＭ（Random Access Memory）８３等のデバイスを備え、ＲＯＭ８２に書き込まれた制御プログラム８４に沿いＣＰＵ８１がＲＡＭ８３を作業領域として動作することにより各種データ処理を行う。この種のＲＯＭ８２には、一ソフトウェアとしてアプリケーションソフトウェア（以下、単にアプリケーションと記す）８５が書き込まれている。アプリケーション８５は、特定の作業をＣＰＵ８１に行わせる時に実行するソフトウェアであって、一般的に各々の作業ごとに複数設けられている。ＣＰＵ８１は、これらアプリケーション８５の中から指定されたものを実行することにより動作する。
【０００３】
また、この種のマイクロコンピュータ８０には、ＣＰＵ８１のＩＣチップ（チップ筐体）８６の中にメモリ８７（以降、これをフラッシュロム（Flash Rom）と言う）を組み込んだもの（以降、これをメモリ内蔵型制御ＩＣ８８と言う）がある。このようなメモリ内蔵型制御ＩＣ８８を用いたマイクロコンピュータ８０の場合、ＲＯＭ８２には、ＣＰＵ８１がこのフラッシュロム８７にアクセスする時に実行されるプログラムとしてデバイスドライバ８９が書き込まれている。このデバイスドライバ８９は、フラッシュロム８７へのアクセス時に必要となる関数（アクセス関数）を含み、制御ＩＣ８８の製造先の半導体メーカにより提供されるものである。
【０００４】
ここで、アプリケーション８５でフラッシュロム８７へのアクセス要求として、例えばフラッシュロム８７へのデータの読み書き要求が発生した際、図８に示すように、アプリケーション８５はデバイスドライバ８９に関数の呼び出し（コール）を行い、デバイスドライバ８９の関数を呼ぶ。この関数の呼び出しを受け付けたデバイスドライバ８９は、自身の関数に基づきフラッシュロム８７へのアクセスを行い、その結果を戻り値としてアプリケーション８５に返す。このように、アプリケーション８５は、フラッシュロム８７へのアクセス要求が発生した際、デバイスドライバ８９の関数を呼ぶことにより、フラッシュロム８７にアクセスする。即ち、アプリケーション８５からフラッシュロム８７へのアクセス要求が発生した際には、アプリケーション８５がデバイスドライバ８９の関数を直接呼ぶことによりフラッシュロム８７へのアクセスが行われる。なお、この種のアクセス装置は例えば特許文献１等に開示されている。
【特許文献１】特開２００１−６０１６７号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
ここで、この種のアプリケーション８５は、図９に示すように、例えば自処理として通常処理を行っている際にフラッシュロム８７へのアクセス要求が発生（アプリケーション８５がデバイスドライバ８９の関数を呼ぶ）したとすると、その時点でデバイスドライバ８９が関数に準じた起動を開始するので、それまで行っていた通常処理を一旦中断して、フラッシュロム８７へのアクセス処理を行う動作をとる。即ち、デバイスドライバ８９は、アプリケーション８５から関数の呼び出しを受け付けると、アプリケーション８５の処理を一旦中断させた状態で、フラッシュロム８７にアクセスを行う。
【０００６】
ところで、この種のアプリケーション８５は、定期的に通常処理を繰り返し行う必要があるため、予め定められた周期時間内に通常処理が終了するように処理時間に制限時間が設定されている。しかし、先に述べたようにアプリケーション８５がフラッシュロム８７にアクセスする時に通常処理が一旦中断されてしまうと、例えばフラッシュロム８７へのアクセス回数が多くなった場合には、それに伴ってアプリケーション８５の中断時間が長くなってしまう。このため、アプリケーション８５の通常処理が周期時間内に終了しない状況が発生し、例えばアプリケーション８５の通常処理が途中で強制終了されたり、或いはこのアプリケーション８５が何度もリセットされたりするなどの不具合が発生してしまう問題があった。
【０００７】
本発明の目的は、アプリケーションが処理実行中に記憶媒体へのアクセス要求を受け付けても、それまで行っていたアプリケーションを周期時間内に終了することができ、しかもそのアクセス要求に基づくアクセス処理も滞りなく実行することができる記憶媒体アクセス装置及び記憶媒体アクセス方法を提供することにある。
【課題を解決するための手段】
【０００８】
前記問題点を解決するために、本発明では、ある周期サイクルで処理を繰り返し実行する動作をとるアプリケーションで記憶媒体へのアクセス要求が発生した際、前記記憶媒体へのアクセスを行う時に必要な関数を持つデバイスドライバに前記アプリケーションが当該関数の呼び出しを行い、当該呼び出しを受け付けた前記デバイスドライバが前記記憶媒体にアクセスを行うことにより、前記記憶媒体へのアクセスが実行される記憶媒体アクセス装置において、前記アプリケーションと前記デバイスドライバとの間にミドルウェアとして設けられ、前記アプリケーションから前記関数の呼び出しを受け付けた際、前記アプリケーションがその１周期内において自処理を実行中であれば当該関数の呼び出しを一時的に保持し、前記アプリケーションが前記自処理を終了して次周期の処理開始を待つアイドル時間に入ると、それまで保持していた前記関数の呼び出しを前記デバイスドライバに送ることにより、前記アプリケーションに前記記憶媒体へのアクセスを実行させるアクセスモジュールを設け、前記アクセスモジュールは、アクセス処理が１周期の前記アイドル時間で完了しない際、当該アクセス処理の続きを次周期のアイドル時間に継続して実行し、前記アクセス処理が完了するまでこの処理を繰り返し実行することを要旨とする。
【０００９】
この構成によれば、外部からの各種通知等により記憶媒体へのアクセス要求がアプリケーションで発生した際、アプリケーションはこのアクセス要求に応じて関数の呼び出し（アクセス要求）をアクセスモジュールに対して行う。アクセスモジュールは、アプリケーションから関数の呼び出しを受け付けると、この時にアプリケーションが自処理を実行中であれば、この関数の呼び出しを一旦保持する。これにより、アプリケーションは、外部から受け付けた記憶媒体へのアクセス要求に影響を受けず、それまで行っていた自処理を継続して行うことが可能となる。また、アクセスモジュールは、関数の呼び出しを保持している際、アプリケーションが自処理を終了してアイドル時間に入ったことを確認すると、それまで保持していた関数の呼び出しをデバイスドライバに送って、アプリケーションに記憶媒体へのアクセスを実行させる。
【００１０】
従って、本構成においては、記憶媒体へのアクセス要求がアプリケーションに発生した際、アプリケーションのアイドル時間にこのアクセス処理が実行される。これにより、アプリケーションが自処理を実行している最中に記憶媒体へのアクセス要求を受け付けても、これによってアプリケーションが一時的に中断されることがなくなる。このため、アプリケーションを周期内に終了させることが可能となるので、アプリケーションの実行エラーを生じ難くすることが可能となる。また、このようにアプリケーションをより確実に周期内に終了させるようにしても、アクセス処理はこれまで通り実行可能であるので、特別な不具合も発生しない。
【００１２】
この構成によれば、アクセス処理が１周期のアイドル時間で完了しない場合には、そのアクセス処理の続きが次周期のアイドル時間で継続実行される。このため、もし仮にアクセス処理時にやり取りされるデータ量が大きくなったとしても、この時のアクセス処理をより確実に完了させることが可能となる。
【００１３】
本発明では、前記アクセスモジュールは、前記アプリケーションが前記アイドル時間になることを待つ最中に複数の前記関数の呼び出しを受け付けた際、予め設定された優先順位に沿って、優先順位の高い前記関数の呼び出しに準じたアクセス処理から順に実行することを要旨とする。
【００１４】
この構成によれば、アクセスモジュールがアプリケーションのアイドル状態を待つ最中に複数の関数の呼び出しを受け付けたとしても、この時は予め設定された優先順位に従って、優先順位の高い関数呼び出しに準じたアクセス処理から順に実行される。このため、アクセスモジュールがアプリケーションのアイドル状態を待つ最中に複数の関数呼び出しを受け付けた際に、先にアクセス処理を行った方がよいものから順に処理が実行されるので、より効果的にアクセス処理を実行することが可能となる。
【００１５】
本発明では、ある周期サイクルで処理を繰り返し実行する動作をとるアプリケーションで記憶媒体へのアクセス要求が発生した際、前記記憶媒体へのアクセスを行う時に必要な関数を持つデバイスドライバに前記アプリケーションが当該関数の呼び出しを行い、当該呼び出しを受け付けた前記デバイスドライバが前記記憶媒体にアクセスを行うことにより、前記記憶媒体へのアクセスが実行される記憶媒体アクセス方法において、前記アプリケーションと前記デバイスドライバとの間にミドルウェアとしてアクセスモジュールを設け、前記アクセスモジュールは、前記アプリケーションから前記関数の呼び出しを受け付けた際、前記アプリケーションがその１周期内において自処理を実行中であれば当該関数の呼び出しを一時的に保持し、前記アプリケーションが前記自処理を終了して次周期の処理開始を待つアイドル時間に入ると、それまで保持していた前記関数の呼び出しを前記デバイスドライバに送ることにより、前記アプリケーションに前記記憶媒体へのアクセスを実行させ、アクセス処理が１周期の前記アイドル時間で完了しない際、当該アクセス処理の続きを次周期のアイドル時間に継続して実行し、前記アクセス処理が完了するまでこの処理を繰り返し実行することを要旨とする。
【発明の効果】
【００１６】
本発明によれば、アプリケーションが処理実行中に記憶媒体へのアクセス要求を受け付けても、それまで行っていたアプリケーションを周期時間内に終了することができ、しかもそのアクセス要求に基づくアクセス処理も滞りなく実行することができる。
【発明を実施するための最良の形態】
【００１７】
以下、本発明を具体化した記憶媒体アクセス装置及び記憶媒体アクセス方法の一実施形態を図１〜図６に従って説明する。
図１に示すように、車両１が車体前部に持つ一対の前部ドア（図１では助手席ドア２のみ図示）には、車両１の側部後方視界を確認するミラーとしてドアミラー３が各々取り付けられている。このドアミラー３の内部には、ドアミラー３の鏡面４の傾き角度（以降、これを鏡面角度θｍと言う）を切り換える際の駆動源としてモータ５が内蔵されている。このモータ５は、例えば鏡面角度θｍを上下方向で切り換える用と、鏡面角度θｍを左右方向で切り換える用との２つからなる。車内には、例えば十字操作式のドアミラースイッチ６が設けられ、このドアミラースイッチ６を操作することにより、モータ５が回転して鏡面角度θｍが上下左右方向に切り換えられる。
【００１８】
図２に示すように、車両１には、ドアミラー３を制御するコントロールユニットとしてドアミラー制御ＥＣＵ７が設けられている。ドアミラー制御ＥＣＵ７には、入力側にドアミラースイッチ６が接続され、出力側にモータ５が接続されている。ドアミラー制御ＥＣＵ７には、１つのＩＣチップからなる制御ＩＣ８が設けられている。制御ＩＣ８は、ドアミラー制御ＥＣＵ７を統括制御するＩＣであって、記憶領域としてＲＯＭ９及びＲＡＭ１０を持ちつつ、各種命令処理や演算処理等を行うＣＰＵ１１を持つとともに、同じチップ筐体内に、ドアミラー制御に関係する各種情報を保持しておくデータ記憶領域としてメモリ１３を持ったメモリ内蔵型制御ＩＣとなっている。このメモリ１３としては、各種データの読み書きが可能なメモリとして例えばフラッシュロム（Flash Rom）が使用されている。なお、フラッシュロム１３が記憶媒体に相当する。
【００１９】
ＲＯＭ９には、ドアミラー制御に関係する制御プログラム１４が書き込まれている。制御ＩＣ８（ＣＰＵ１１）は、ＲＯＭ９に書き込まれた制御プログラム１４に沿いつつＲＡＭ１０を作業領域として動作することにより、ドアミラー３を制御する。即ち、制御ＩＣ８（ＣＰＵ１１）は、ドアミラースイッチ６が操作されたことを検出すると、そのスイッチ操作量を基にモータ５を駆動することにより、ドアミラー３の鏡面角度θｍをそのスイッチ操作量に応じた角度に切り換える。
【００２０】
ＲＯＭ９には、ドアミラー制御に関係する一ソフトウェアとしてアプリケーション１５が書き込まれている。このアプリケーション１５は、ドアミラー制御の各々の一処理単位ごとに複数設けられ、例えばドアミラースイッチ６から取得したスイッチ操作量を基に鏡面角度θｍを切り換える際に実行されるアプリケーションや、その時々の鏡面角度θｍを検出してその鏡面角度情報をフラッシュロム１３に保持させるアプリケーション（モジュール）や、ドアミラー３の故障有無を監視して故障情報や故障履歴等をフラッシュロム１３に保持させるアプリケーション（モジュール）等がある。また、アプリケーション１５は、自処理がフリーズしてしまうことを防ぐために、図３に示すように予め定められた周期時間内に処理が終了するように処理時間に制限時間が設定され、この周期時間を１周期として自処理を繰り返す動作をとる。
【００２１】
また、ＲＯＭ９には、ＣＰＵ１１（即ち、アプリケーション１５）がフラッシュロム１３にアクセスする時に実行されるプログラムとしてデバイスドライバ１６が書き込まれている。このデバイスドライバ１６は、アプリケーション１５がフラッシュロム１３にアクセスする時に必要となる関数（アクセス関数）を含むものであって、アプリケーション１５とは別のアドレスに書き込まれている。また、デバイスドライバ１６は、制御ＩＣ８の製造先の半導体メーカにより提供され、各々の半導体メーカごとに規格が異なるものである。
【００２２】
アプリケーション１５は、外部（例えば他アプリケーション）からフラッシュロム１３へのアクセス要求を受け付けると、デバイスドライバ１６の関数を呼び出す。このアクセス要求は、フラッシュロム１３へのデータ読み書き要求である。また、デバイスドライバ１６は、例えばこの種の関数の呼び出し（コール）を受け付ける動作をとる際、これに応答してフラッシュロム１３へのアクセスを行う。即ち、アプリケーション１５は、デバイスドライバ１６の関数を呼び出すことにより、フラッシュロム１３にアクセスを行う仕組みをとっている。なお、このアクセス要求の受け付けは、一アプリケーション１５が実行動作を行っている最中に、例えば鏡面角度θｍの角度情報や、ドアミラー３の故障情報（故障履歴）をフラッシュロム１３に書き込む要求を受け付ける例が挙げられる。
【００２３】
ＲＯＭ９には、アプリケーション１５とデバイスドライバ１６との中間にミドルウェアとしてアクセスモジュール１７が書き込まれている。本例のアプリケーション１５は、このアクセスモジュール１７を介してデバイスドライバ１６の関数を呼び出すことにより、フラッシュロム１３にアクセスを行う。アクセスモジュール１７は、アプリケーション１５が自処理を行っている最中に外部からフラッシュロム１３へのアクセス要求を受け付けた際、アプリケーション１５がそれまで行っていた自処理を途中で停止させることなくこれを継続可能とし、しかもこの時に要求を受けたフラッシュロム１３へのアクセスも滞りなく実行することを可能とする処理（以降、これを調停処理と言う）を実行するモジュールである。
【００２４】
この調停処理においては、図４に示すように、外部から受け付けたアクセス要求に応答してアプリケーション１５が出力した関数の呼び出しをアクセスモジュール１７が取得すると、アクセスモジュール１７はこの関数の呼び出し（アクセス要求）を一旦バッファリングする。そして、図３に示すようにアプリケーション１５が周期単位における自処理を終了した後、次周期の処理開始を待つアイドル時間Ｔａ（待機時間）に入ると、アクセスモジュール１７はそれまでバッファリングしていた関数の呼び出し（アクセス要求）をデバイスドライバ１６に出力してデバイスドライバ１６の関数を呼び、このアイドル時間Ｔａ内にフラッシュロム１３のアクセスを行う。アクセスモジュール１７は、このアクセス処理（関数に準ずる処理）が終了すると、この時の調停結果を戻り値としてアプリケーション１５に返す動作をとる。
【００２５】
次に、本例のＣＰＵ１１がフラッシュロム１３にアクセスする時の動作過程を図５の動作フローに従って説明する。
ＣＰＵ１１が一アプリケーション１５の動作を開始したとする（ステップ１００）。この種のアプリケーション１５は、図３に示すように、１周期時間を制限時間として１周期時間内に収まる処理として設定され、これがこの周期サイクルで繰り返し実行される。続いて、アプリケーション１５の実行最中に、外部からフラッシュロム１３へのアクセス要求を受け付けたとする（ステップ１０１）。ここでは、アプリケーション１５の実行最中に、ＣＰＵ１１が外部から例えば鏡面角度情報や故障情報（故障履歴）を受け付けて、これらをフラッシュロム１３に書き込むアクセス要求が発生したとする。
【００２６】
このアクセス要求が発生した際、アプリケーション１５はアクセスモジュール１７に対して関数の呼び出し（アクセス要求）を行う（ステップ１０２）。このとき、アプリケーション１５は、アクセスモジュール１７に対して関数を呼び出すが、この時はデバイスドライバ１６から戻り値を得て、それまで実行していた自処理は継続して実行する状態をとる。アクセスモジュール１７は、アプリケーション１５から関数の呼び出し（アクセス要求）を受け付けると、アプリケーション１５が処理実行中であれば、これを一旦バッファリングし、この時点ではフラッシュロム１３に対して関数の呼び出し（アクセス要求）を行わずに、この要求を一旦保持する（ステップ１０３）。これにより、この時点でデバイスドライバ１６がフラッシュロム１３にアクセスを行う動作はとらないので、アプリケーション１５はアクセス処理に移行せず、それまで行っていた自処理を継続して実行する。よって、アプリケーション１５はフラッシュロム１３へのアクセス処理によって自処理が妨げられなくなる。
【００２７】
アプリケーション１５（１周期単位）の処理が終了し、アプリケーション１５がアイドル状態、即ち待機状態に移行する（ステップ１０４）。このとき、アプリケーション１５は、自身がアイドル状態に入った旨の通知（アイドル状態開始通知）をアクセスモジュール１７に出力する。アクセスモジュール１７は、アプリケーション１５からアイドル状態開始通知を受け付けると、それまでバッファリングしていた関数の呼び出し（アクセス要求）をデバイスドライバ１６に出力してデバイスドライバ１６の関数を呼び、フラッシュロム１３にアクセスを行う（ステップ１０５）。即ち、アプリケーション１５は、アプリケーション１５がアイドル時間Ｔａに入った時点でアクセスモジュール１７を介してデバイスドライバ１６の関数を呼ぶことにより、フラッシュロム１３にアクセスを行う。
【００２８】
アプリケーション１５は、アクセス処理を実行している最中、ＣＰＵ１１の外部にあるタイマ１８（図２参照）によりアクセスモジュール１７の処理状況を逐次監視し、その周期のアイドル時間Ｔａ内にアクセス処理が終了するかを判定する（ステップ１０６）。この制限時間判定としては、図３に示すように、例えばアイドル時間Ｔａの残り時間をタイマ１８でカウントするとともに、アクセス処理を最大限まで実行できる残り時間（リミット時間Ｔmt）を決めておき、アイドル時間Ｔａの残り時間がリミット時間Ｔmtに到達した際にアクセス処理が終了していれば、そのアクセス処理については終了する。一方、アイドル時間Ｔａの残り時間がリミット時間Ｔmtに到達しても、未だアクセス処理が終了していなければ、同周期におけるアクセス処理は一旦中断し、このアクセス処理の続きを次周期のアイドル時間Ｔａで継続実行する。
【００２９】
また、アクセスモジュール１７には、アクセス処理の開始を待つ際に複数の関数呼び出し（アクセス要求）を受け付けた場合に優先順位の高いものから順に実行する優先機能が設けられている。これは、ＣＰＵ１１は種々のＥＣＵからフラッシュロム１３へのアクセス要求（鏡面角度情報、故障情報（故障履歴）など）を受け付けていることから、アクセスモジュール１７がアプリケーション１５のアイドル状態を待っている際に、複数のＥＣＵからアクセス要求を受け付ける場合もあるので、これに対応するためである。
【００３０】
アプリケーション１５からアクセスモジュール１７に出力される関数の呼び出しには、図６に示すように、ＣＰＵ１１が受け付けたアクセス要求（各種情報）の種類に応じて属性が設定されている。例えば、アクセス要求として鏡面角度情報を受け付けたときは関数呼び出しの属性がＺ１に設定され、アクセス要求として故障情報（故障履歴）を受け付けたときは関数呼び出しの属性がＺ２に設定されている。なお、この種の属性Ｚ１，Ｚ２…は、例えばＡ，Ｂ，Ｃ…等の記号的な情報に限らず、属性内容を書き表すデータ群でもよい。一方、アクセスモジュール１７においても、図６に示すように、これら属性Ｚ１，Ｚ２…がどの順に優先度が高いかの優先順位表１９が予め登録されている。
【００３１】
これにより、アクセスモジュール１７は、アプリケーション１５のアイドル状態を待つ際に複数の関数呼び出しを受け付けた場合、この時はこれら関数呼び出しが持つ属性を確認しつつ、優先順位表１９を参照することにより、アクセス処理を行う時の優先順位を判定する。そして、アクセスモジュール１７は、この時に受け付けた複数の関数呼び出しのうち、優先順位の高い呼び出しに準ずるアクセス処理から順に実行する。例えば、鏡面角度情報及び故障情報（故障履歴）を同時期に受け付けた際、鏡面角度情報よりも故障情報（故障履歴）の方が書き込み優先順位が高ければ、これを先にフラッシュロム１３に書き込む。これにより、フラッシュロム１３へのアクセス要求を複数受け付けた際には、優先順位が高いもの、即ち先にフラッシュロム１３へのアクセスを行うべきものから順にアクセス処理が実行される。
【００３２】
さて、本例においては、アプリケーション１５とデバイスドライバ１６との間に、アプリケーション１５が実行されていないアイドル時間Ｔａを利用してフラッシュロム１３にアクセスを行わせるアクセスモジュール１７を設けた。これにより、アプリケーション１５が動作実行中に外部からフラッシュロム１３へのアクセス要求を受け付けても、この時のアプリケーション１５はその時に行っていた自処理を優先して継続実行するので、アプリケーション１５を途中で中断させずに済む。これにより、アプリケーション１５が周期内に終了しない状況が発生しなくなるので、アプリケーション１５に実行エラーを発生させずに済む。また、このように、アプリケーション１５に実行エラーが発生し難いソフトウェア構造を採用しても、フラッシュロム１３へのアクセスは従来通り実行可能である。
【００３３】
さらに、１周期のアイドル時間Ｔａで全てのアクセス処理が完了しない場合には、次の周期のアイドル時間Ｔａでアクセス処理の続きが行われるので、より確実にアクセス処理を完了させることが可能となる。また、例えば仮にアクセス処理でやり取りされるデータ量が多くなっても、その増えた分は次周期のアイドル時間Ｔａに次々に繰り越される処理で以て対応されるので、データ量増加の傾向にあっても、滞りなくアクセス処理を完了させることが可能となる。特に、今日においては装置の高精度化に伴い、やり取りされるデータ量が大きくなってきている傾向があるので、この観点から見ても非常に効果が高いと言える。
【００３４】
また、アクセスモジュール１７がアプリケーション１５のアイドル状態を待つ際に複数の関数の呼び出し（アクセス要求）を受け付けた場合に、優先順位の高いものから順にアクセス処理を実行する優先順位機能を設けた。このため、アクセスモジュール１７がアプリケーション１５のアイドル状態を待っている際に複数の関数の呼び出し（アクセス要求）を受け付けたとしても、この時は優先順位の高い関数呼び出しに準ずるアクセス処理から優先的に実行される。これにより、先にフラッシュロム１３へのアクセスを行うべきものから先に処理を実行することが可能となるので、フラッシュロム１３へのアクセス処理をより効率的に行うことが可能となる。
【００３５】
本実施形態の構成によれば、以下に記載の効果を得ることができる。
（１）アプリケーション１５とデバイスドライバ１６との間に、アプリケーション１５が処理を実行していないアイドル時間Ｔａの時にアクセス処理を実行するアクセスモジュール１７を設けた。このため、アプリケーション１５が処理を実行している最中に外部からフラッシュロム１３へのアクセス要求を受け付けても、この時に受け付けたアクセス処理がアプリケーション１５のアイドル時間Ｔａまで先送りされる。これにより、アプリケーション１５が処理の実行最中にアクセス要求を受け付けても、この時にアプリケーション１５はＣＰＵ１１をアクセス処理に奪われることがないので、それまで実行していたアプリケーション１５が継続して実行される。よって、アプリケーション１５の処理を途中で一時中断させずに済み、この処理を最後まで完了させることができる。また、このように、アプリケーション１５に実行エラーが生じ難くしても、アイドル時間Ｔａにアクセス処理を行うことで、これまで通り滞りなくアクセス処理も実行することができる。
【００３６】
（２）アクセス処理が１周期のアイドル時間Ｔａ内に完了しない場合には、そのアクセス処理の続きが次周期のアイドル時間Ｔａに持ち越され、アクセス処理が全て完了するまでこの処理が繰り返し実行される。よって、１周期のアイドル時間Ｔａ内にアクセス処理が完了しないデータやり取りが行われる場合であっても、問題なくアクセス処理を最後まで完了することができる。また、もし仮にアクセス処理時にやり取りされるデータ量が大きくなったとしても、その増えた分のデータやり取りが次周期に順次持ち越される処理がとられることになるので、この場合であってもより確実にアクセス処理を最後まで完遂させることができる。
【００３７】
（３）アクセスモジュール１７がアプリケーション１５のアイドル状態を待つ際に複数の関数の呼び出しを受け付けた際には、これら関数の呼び出しのうち優先順位の高い関数呼び出しに準じたアクセス処理から順に実行される。このため、アクセスモジュール１７がアプリケーション１５のアイドル状態を待つ際に複数の関数呼び出しを受け付けた際に、先にアクセス処理を行った方がよいものから順に処理が実行されるので、より効果的にアクセス処理を実行することができる。
【００３８】
（４）ＣＰＵ１１及びフラッシュロム１３は、これらが同一チップ筐体内に組み込まれた一体型ＩＣにより構成されているので、これらに要する部品点数を少なく抑えることができる。
【００３９】
なお、実施形態はこれまでに述べた構成に限らず、以下の態様に変更してもよい。
・  ＣＰＵ１１とフラッシュロム１３とは、必ずしも同一チップ筐体内に組み込まれた一体型に限らず、これらが各々別部品からなる別体型でもよい。
【００４０】
・  優先順位表１９は、必ずしもデータ書き換え不能（固定）であることに限らず、これを書き換え可能として、優先順位を変更可能としてもよい。
・  アクセス処理が１周期内に終了しない際にこれを次周期に持ち越す処理（次周期持ち越し処理）や、或いはアクセスモジュール１７がアプリケーション１５のアイドル状態を待つ時に複数の関数呼び出しを受け付けた時にアクセス処理を優先順位の高いものから行う処理（優先アクセス処理）は、必ずしも必要ではなく、これら処理を省略してもよい。
【００４１】
・  記憶媒体は、必ずしもフラッシュメモリに限定されず、ＥＥＰＲＯＭ等の他の読み書き可能なメモリを採用してもよい。
・  アプリケーション１５は、必ずしも一つの大きなソフトウェアの括りを意味することに限らず、例えば小さな１つの仕事単位のソフトウェアも含むものとし、要は所定周期サイクルで繰り返し実行されるソフトウェアであれば、特に限定されない。
【００４２】
・  本例の記憶媒体アクセス装置の採用対象は、必ずしも車両１のドアミラー３に限定されず、ＣＰＵ１１、ＲＯＭ９、フラッシュロム１３等を備えた機器や装置であれば、特に限定されない。
【００４３】
次に、上記実施形態及び別例から把握できる技術的思想について、それらの効果とともに以下に追記する。
（１）請求項１又は２において、前記記憶媒体は、前記アプリケーション（前記デバイスドライバ、前記アクセスモジュール）を実行するＣＰＵのチップ内（筐体内）に一体に組み込まれることにより、前記ＣＰＵと一体型のチップ部品として構成されている。この構成によれば、ＣＰＵと記憶媒体とが一体型であるので、これらに要する部品点数を少なく抑えることが可能となる。
【００４４】
（２）請求項１、２、前記技術的思想（１）のいずれかにおいて、前記アプリケーションは、１つの前記関数の呼び出しに準ずる前記アクセス処理が１周期の前記アイドル時間で完了しないとき、当該１関数の呼び出しに準じたアクセス処理の続きを次周期のアイドル時間に継続して実行する。この構成によれば、１つの関数の呼び出しに準ずるアクセス処理が１周期のアクセス時間内に完了しないとき、これを次周期のアイドル時間に持ち越すことにより、このアクセス処理を最後まで完了させることが可能となる。
【００４５】
（３）ある周期サイクルで処理を繰り返し実行する動作をとるアプリケーションで記憶媒体へのアクセス要求が発生した際、前記記憶媒体へのアクセスを行う時に必要な関数を持つデバイスドライバに前記アプリケーションが当該関数の呼び出しを行い、当該呼び出しを受け付けた前記デバイスドライバが前記記憶媒体にアクセスを行うことにより、前記記憶媒体へのアクセスが実行される記憶媒体アクセス用プログラムにおいて、前記アプリケーションと前記デバイスドライバとの間にミドルウェアとして設けられ、前記アプリケーションから前記関数の呼び出しを受け付けた際、前記アプリケーションがその１周期内において自処理を実行中であれば当該関数の呼び出しを一時的に保持し、前記アプリケーションが前記自処理を終了して次周期の処理開始を待つアイドル時間に入ると、それまで保持していた前記関数の呼び出しを前記デバイスドライバに送ることにより、前記アプリケーションに前記記憶媒体へのアクセスを実行させるアクセスモジュールを備え、前記アクセスモジュールは、アクセス処理が１周期の前記アイドル時間で完了しない際、当該アクセス処理の続きを次周期のアイドル時間に継続して実行し、前記アクセス処理が完了するまでこの処理を繰り返し実行することを特徴とする記憶媒体アクセス用プログラム。
【００４６】
（４）前記技術的思想（３）に記載の記憶媒体アクセス用プログラムを記憶した記憶媒体。
【図面の簡単な説明】
【００４７】
【図１】一実施形態における車両のドアミラー付近の外観を示す斜視図。
【図２】記憶媒体アクセス装置の電気的構成を示すブロック図。
【図３】記憶媒体アクセス装置が作動した際の動作推移を示すタイムチャート。
【図４】記憶媒体アクセス装置のソフトウェア構造を示す構造図。
【図５】記憶媒体アクセス装置が作動した際の動作推移を示すフロー図。
【図６】記憶媒体アクセス装置が行う優先処理の処理内容を説明する説明図。
【図７】従来における記憶媒体アクセス装置の電気的構成を示すブロック図。
【図８】その記憶媒体アクセス装置のソフトウェア構造を示す構造図。
【図９】その記憶媒体アクセス装置が作動した際の動作推移を示すタイムチャート。
【符号の説明】
【００４８】
１３…記憶媒体としてのフラッシュロム（メモリ）、１５…アプリケーション、１６…デバイスドライバ、１７…アクセスモジュール、Ｔａ…アイドル時間。
【図１】
0005086117.tif 000002
【図２】
0005086117.tif 000003
【図３】
0005086117.tif 000004
【図４】
0005086117.tif 000005
【図５】
0005086117.tif 000006
【図６】
0005086117.tif 000007
【図７】
0005086117.tif 000008
【図８】
0005086117.tif 000009
【図９】
0005086117.tif 000010