JPH1083342A - 情報処理装置およびその方法、オペレーティングシステム、記憶媒体 - Google Patents

Abstract

(57)【要約】 【課題】 機能の一部を、追加ソフトウエアによって拡
張することが可能な情報処理装置、さらに、ファームウ
エアのバージョンに依存しない追加ソフトウエアの開発
を可能にするソフトウエアの構造を提供する。 【解決手段】 メモリの断片化問題を解決するメモリ管
理、ファイル管理等の改良により目的を実現する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、任意の機能を後か
ら追加可能な情報処理装置およびその方法に関するもの
である。

【０００２】

【従来の技術】従来のカメラシステムでは、メモリの利
用目的とアドレスの関係はコンパイル＆リンク時に決定
するのが一般的である。したがって、メモリマネージャそ
のものが搭載されていなかった。メモリマネージャを搭
載して、ダイナミックにアロケーションするカメラシス
テムと従来のシステムを比較すると以下の様な特徴があ
る。

【０００３】メモリマネージャを搭載しない場合、追加
プログラムが利用するメモリは、あらかじめ予約してお
く必要がある。カメラのＲＯＭのバージョンとメモリの
配置が強く依存しているので、互換性を確保する為には
追加プログラム用の予約領域は少なめに設定する必要が
ある。一方、メモリマネージャを利用する場合は、同時に
利用するメモリの最大量が物理的なメモリ容量を越えな
い様に注意するだけで良いので、メモリを最大限利用可
能である。仮想記憶のシステムが無い場合のメモリマネ
ージメント手法は、大別してビットマップを利用したも
の、メモリ管理ブロックによって可変長のメモリを分割
して利用するものがある。ビットマップを利用する方法
は、要求されたサイズの空きメモリを検索するのに時間
がかかる為、実際のコンピュータシステムでもあまり利
用されていない。可変長のメモリを分割して利用する場
合はさらに、Best Fit法,First Fit法,Next Fit法の３つ
が良く知られている。Best Fit法は大きな連続領域がい
つも確保されるという特徴があるが、メモリブロックの
数に比例してアロケーションスピードが遅くなる。First
Fit法も同様の性質がある。Next Fit法は、ブロックの数
に依存せず、常に高速にアロケーションを行う事が可能
であるが、ストレスをかけると空きメモリが断片化して
いくという欠点がある。デジタルカメラで画像処理を行
う場合１画面分の画像を千ブロック程度に分割して処理
を行う為、アロケーション速度が遅ければカメラの処理
スピードに致命的な結果を及ぼす。また、デジタルカメラ
は従来のフィルムを使ったカメラと違い、大容量ハード
ディスクとＡＣ電源を使えばシャッターの耐久回数であ
る数万ショットを連続撮影する事が可能なのでメモリの
断片化によるアロケーションの失敗は許されない。Next
Fit法のアロケーションのしくみとメモリの断片化(ｆｒ
ａｇｍｅｎｔａｔｉｏｎ)についてさらに説明を加える。
図２ははNext Fitメモリマネージャの初期状態であ
る。主記憶は１つの空きメモリブロックとして管理し、ア
ロケーションポインタがその先頭にセットされている。
ここでいうブロックとは図４の様な情報を含む。ブロッ
クの大きさと、そのブロックが空きメモリか使用中かを
示すフラグとユーザアプリケーションが利用する部分で
ある。すべてのメモリを４バイトアライメント上に配置
しようとした場合ブロックサイズは４の倍数で良いので
余った最下位ビットを使用中フラグとして利用出来る。
次のブロックの先頭位置を知る為にもブロックサイズは
利用される。ブロックサイズや使用中フラグなどの情報
を格納している部分はＭＣＢ（メモリーコントロールブ
ロック）と呼ばれる。

【０００４】はアプリケーションからメモリＡを要求
され、割り当てた状態である。１つの空きブロックと１つ
の使用中メモリの2ブロックに分割され、アロケーション
ポインタは分割された空きメモリの先頭にセットされ
る。図２のはさらにアプリケーションからメモリＢを
要求され、割り当てた状態である。空きメモリをさらにメ
モリＢの為に分割し、主記憶は３つのブロックに分割さ
れた。図２のでメモリＡが不要になり開放を行った。メ
モリＡは空きブロックに変わったが、アロケーションポ
インタの位置は更新されない。図２のでメモリＣを要
求されるが、メモリＡが以前存在していた位置は利用し
ない。要求されたメモリサイズがアロケーションポイン
タが示している空きメモリより大きい場合に限ってアロ
ケーションポインタの位置から空きメモリの検索が始ま
る。要求されたサイズより大きな空きメモリを発見した
ら、そのブロックを分割して割り当てる。その様にメモリ
のアロケーションと開放を繰り返し続けると、図２の
のような状態になる。図２のは空きメモリの総量は要
求されたメモリＢの大きさより大きいが最大連続領域サ
イズがメモリＢよりも小さくなってしまった為に割り当
てに失敗してしまう様子である。この事から、Nest Fit法
を利用する場合は無限にアロケーションと開放を繰り返
す様なアプリケーションでの利用は困難であった。

【０００５】

【発明が解決しようとする課題】本発明のメモリマネー
ジャは、この様な問題を著しく軽減するファンクション
を定義し、アプリケーションがそのファンクションを利
用する事でデジタルカメラの様な分野で利用する事を可
能にする。断片化が発生した後でメモリの再配置を行え
ば再び最大連続領域サイズは増える。しかし、稼動中のシ
ステムでメモリの再配置を行えばメモリ転送に多くのＣ
ＰＵ時間を費やす事になる。カメラシステムを構成する
うえで断片化を回避するとすれば、一定期間ごとに必ず
システムをリスタートするという手段をとる事も可能で
ある。しかし、前途の様に連続動作はデジタルカメラの重
要なスペックである。システムをリスタートする事をあ
きらめたとしても、システムとしては、メモリの消費量が
極端に少なくなるタイミングがあり、それを利用する事
が可能である。必ずあるタイミングでメモリの消費量が
極端に少なくなるのであればそのタイミングでアロケー
ションポインタを主記憶の先頭へ移動させる事でメモリ
マネージャのリスタートに限りなく近い状態をつくりだ
す事が可能である有があるが、パーソナルコンピュータ
の技術革新サイクルは早く、新しい画像フォーマットが
次々に登場している。デジタルカメラの内部構造もコン
ピュータ化が進み、ソフトウェアによる処理の範囲も広
がってきている。そこで、デジタルカメラもパーソナルコ
ンピュータの様にソフトウェアを追加し、拡張していく
事でハードウェア開発の投資を押さえて早い技術革新サ
イクルに追従していく事が可能である。しかし、デジタル
カメラのソフトウェアは通信やファイルシステムなど多
岐にわたっており、どの機能が将来必要になるのか、どの
技術が陳腐化するのかをあらかじめ予測する事は難し
い。また、さまざまなロットのデジタルカメラが市場に出
るが、追加拡張ソフトウェアはどのロットの内部ソフト
ウェアとも共存する様に設計する必要がある。本発明は
デジタルカメラの任意の機能を後から追加するソフトウ
ェアによって置き換え、拡張する技術に関するものであ
る。

【０００６】

【課題を解決するための手段】本発明は、上記課題を解
決するために、Next Fit法によりメモリを管理し、且
つ、メモリの断片化問題を軽減する為のファンクション
を備えることを特徴とする情報処理装置を提供する。

【０００７】また、本発明は、上記課題を解決するため
に、電気的書き込み可能なフラッシュROMと、前記フラ
ッシュROMの論理構造をマネージメントするマネージメ
ントソフトウエアモジュールを備え、前記マネージメン
トソフトウエアモジュールが実行可能なソフトウエアモ
ジュールを前記フラッシュROMの任意のアドレスへマッ
ピングし、書き込む機能と、前記フラッシュROM中にあ
る任意のモジュールを検索し実行する機能を有すること
を特徴とする情報処理装置提供する。

【０００８】また、本発明は、上記課題を解決するため
に、実行可能なプログラムファイルの中から実行可能な
レコードを選択し、ロードするプログラムローダを備え
ることを特徴とする情報処理装置を提供する。

【０００９】また、本発明は、上記課題を解決するため
に、プロセス間で共有データのバインディングを行う情
報処理装置であって、共有データの検索の結果、目的の
共有データが登録されていない場合に、検索タスクを休
眠状態へと移行させ、目的の共有データが登録された時
に検索タスクを実行可能状態へ移すことを特徴とする情
報処理装置を提供する。

【００１０】また、本発明は、上記課題を解決するため
に、IOポートの特定の入力端子の状態によってスタート
アップさせるタスクを切り替えるスタートアップルーチ
ンを備えることを特徴とする情報処理装置を提供する。

【００１１】また、本発明は、上記課題を解決するため
に、内蔵メモリの特定のファイル名の実行可能ファイル
をスタートアップ時にロードし実行することを特徴とす
る情報処理装置を提供する。

【００１２】また、本発明は、上記課題を解決するため
に、外部記憶媒体の挿入時に、特定のファイル名のファ
イルが外部記憶媒体に存在すれば該ファイルを内蔵メモ
リへコピーし、前記外部記憶媒体の脱着に対応してコピ
ーされたファイルを消去することを特徴とする情報処理
装置を提供する。

【００１３】また、本発明は、上記課題を解決するため
に、抽象化されたIOポートのサポートソフトウエアとそ
れをコントロールするドライバーソフトウエアに論理的
に分離設計されていることを特徴とする情報処理装置を
提供する。

【００１４】また、本発明は、上記課題を解決するため
に、特定のイベントに対応した処理ルーチンとパラメー
タとを動的に複数登録可能なフック管理ソフトウエアを
備え、イベント発生時に登録されたサブルーチンへパラ
メータを引き渡し実行することを特徴とする情報処理装
置を提供する。

【００１５】また、本発明は、上記課題を解決するため
に、主電源を使用しているプログラムの数をカウント
し、該カウントが０になってから任意の時間経過した後
に主電源をオフすることを特徴とする情報処理装置を提
供する。

【００１６】また、本発明は、上記課題を解決するため
に、シャットダウンの処理を少なくとも３つ以上の複数
のレイアに分離して管理し、順次実行していくことを特
徴とする情報処理装置を提供する。

【００１７】また、本発明は、上記課題を解決するため
に、複数のエラーを検出した場合に最初に検出したエラ
ーの番号を優先的に表示することを特徴とする情報処理
装置を提供する。

【００１８】また、本発明は、上記課題を解決するため
に、複数のエラーを検出した場合に最も致命的なエラー
に対するリカバリーを優先して実行することを特徴とす
る情報処理装置を提供する。

【００１９】また、本発明は、上記課題を解決するため
に、Next Fit法によりメモリを管理し、且つ、メモリの
断片化問題を軽減する為のファンクションを備えること
を特徴とする情報処理方法を提供する。

【００２０】また、本発明は、上記課題を解決するため
に、実行可能なプログラムファイルの中から実行可能な
レコードを選択し、ロードすることを特徴とする情報処
理方法を提供する。

【００２１】また、本発明は、上記課題を解決するため
に、プロセス間で共有データのバインディングを行う情
報処理装置の情報処理方法であって、共有データの検索
の結果、目的の共有データが登録されていない場合に、
検索タスクを休眠状態へと移行させ、目的の共有データ
が登録された時に検索タスクを実行可能状態へ移すこと
を特徴とする情報処理方法を提供する。

【００２２】また、本発明は、上記課題を解決するため
に、IOポートの特定の入力端子の状態によってスタート
アップさせるタスクを切り替えるスタートアップルーチ
ンを備えることを特徴とする情報処理方法を提供する。

【００２３】また、本発明は、上記課題を解決するため
に、内蔵メモリの特定のファイル名の実行可能ファイル
をスタートアップ時にロードし実行することを特徴とす
る情報処理方法を提供する。

【００２４】また、本発明は、上記課題を解決するため
に、外部記憶媒体の挿入時に、特定のファイル名のファ
イルが外部記憶媒体に存在すれば該ファイルを内蔵メモ
リへコピーし、前記外部記憶媒体の脱着に対応してコピ
ーされたファイルを消去することを特徴とする情報処理
方法を提供する。

【００２５】また、本発明は、上記課題を解決するため
に、抽象化されたIOポートのサポートソフトウエアとそ
れをコントロールするドライバーソフトウエアに論理的
に分離設計されていることを特徴とする情報処理方法を
提供する。

【００２６】また、本発明は、上記課題を解決するため
に、特定のイベントに対応した処理ルーチンとパラメー
タとを動的に複数登録可能なフック管理ソフトウエアを
備え、イベント発生時に登録されたサブルーチンへパラ
メータを引き渡し実行することを特徴とする情報処理方
法を提供する。

【００２７】また、本発明は、上記課題を解決するため
に、主電源を使用しているプログラムの数をカウント
し、該カウントが０になってから任意の時間経過した後
に主電源をオフすることを特徴とする情報処理方法を提
供する。

【００２８】また、本発明は、上記課題を解決するため
に、シャットダウンの処理を少なくとも３つ以上の複数
のレイアに分離して管理し、順次実行していくことを特
徴とする情報処理方法を提供する。

【００２９】また、本発明は、上記課題を解決するため
に、複数のエラーを検出した場合に最初に検出したエラ
ーの番号を優先的に表示することを特徴とする情報処理
方法を提供する。

【００３０】また、本発明は、上記課題を解決するため
に、複数のエラーを検出した場合に最も致命的なエラー
に対するリカバリーを優先して実行することを特徴とす
る情報処理方法を提供する。

【００３１】また、本発明は、上記課題を解決するため
に、Next Fit法によりメモリを管理し、且つ、メモリの
断片化問題を軽減する為のファンクションを備えること
を特徴とするオペレーティングシステムを提供する。

【００３２】また、本発明は、上記課題を解決するため
に、主電源を使用しているプログラムの数をカウント
し、該カウントが０になってから任意の時間経過した後
に主電源をオフすることを特徴とするオペレーティング
システムを提供する。

【００３３】また、本発明は、上記課題を解決するため
に、Next Fit法によりメモリを管理し、且つ、メモリの
断片化問題を軽減する為のファンクションを有すること
を特徴とする記憶媒体を提供する。

【００３４】また、本発明は、上記課題を解決するため
に、主電源を使用しているプログラムの数をカウント
し、該カウントが０になってから任意の時間経過した後
に主電源をオフする工程を有することを特徴とする記憶
媒体を提供する。

【００３５】

【発明の実施の形態】図１は本発明の第一の実施例のブ
ロック図である。１はレンズ、２はレンズを通った光を
電気信号として出力するＣＣＤユニットである。３はＣ
ＣＤからのアナログ信号をデジタル信号へ変換するＡ／
Ｄコンバータ、４はＣＣＤとＡ／Ｄ変換器に同期信号を
供給するＳＳＧユニット、５はカメラシステムの中央演
算器、６は信号処理を高速に実現するためのアクセラレ
ータ、７は電池、８はシステム全体へ電源を供給するた
めのＤＣ／ＤＣコンバータ、９はＤＣ／ＤＣコンバータ
をコントロールする電源コントローラユニット、１０は
パネル操作・表示装置・電源のコントロールを行うマイ
クロコンピュータ、１１はユーザーへ情報を表示する表
示装置、１２はユーザーが直接操作するレリーズＳＷを
含むコントロールパネル、１３はＯＳ等システムプログ
ラムが記憶され、具体的には、図面に記述し、また後述
する動作手順を中央演算器５により読み込まれ実行され
るプログラムが記憶されている記憶媒体のＲＯＭ、１４
はカメラシステムの主記憶で、データや後述する動作手
順が記憶され、中央演算器５により手順が読み込まれ実
行されるプログラムも記憶される記憶装置のＤＲＡＭ、
１５は内臓記憶媒体として使用し、データや動作手順が
記憶され中央演算器５により読み込まれ実行されるフラ
ッシュＲＯＭ、１６はＰＣＭＣＩＡカードのインターフ
ェース部、１７はＡＴＡハードディスクなどの外部記録
媒体、１８は拡張バスインターフェース、１９はＰＣ通
信インターフェース、２０はＤＭＡコントローラ、２１
はストロボ、２２はパーソナルコンピュータである。

【００３６】このカメラの撮影時の動作を簡単に説明す
る。図１のコントロールパネル１２のレリーズスイッチ
をユーザが押したら、図１のＣＰＵ５がその事を検出し
て撮影シーケンスを開始する。以下の動作はすべて図１
のＣＰＵ５によるコントロールで行われる事を前提と
し、その説明を省略する。図１のＳＳＧ４が図１のＣＣ
Ｄ２を駆動する。図１のＣＣＤ２から出力されるアナロ
グ信号は、図１のＡ／Ｄコンバータ３でデジタル信号へ
変換される。図１のＤＭＡコントローラ２０によって図
１のＡ／Ｄコンバータ３の出力は、図１のＤＲＡＭ４へ
ＤＭＡ転送される。１フレーム分のＤＭＡ転送が終了し
た時点でＣＰＵ５は、信号処理シーケンスを開始する。
図１のフラッシュＲＯＭ１５から信号処理プログラムを
主記憶上に記憶して、それを逐次読みだして実行する。
主記憶上のデータを信号処理アクセラレータ６へ転送し
信号処理をおこなう。信号処理アクセラレータ６は信号
処理のすべてをおこなうわけではなく図１のＣＰＵ５で
行う処理の特に時間のかかる処理などを助ける演算回路
であり、図１のＣＰＵ５の処理ソフトウェアと連携して
動作する。信号処理の一部または全部が終了すると画像
ファイルとして外部記憶媒体１７へ記録する。また、カー
ドインターフェースに外部記憶媒体１７が接続されてい
ない場合、フラッシュＲＯＭ１５へ記録する。この時記
録するファイルフォーマットが圧縮処理を必要とするの
であれば圧縮も行う。第一の実施例は、以上のように撮
影画像を外部記憶媒体、もしくはフラッシュＲＯＭへフ
ァイルする電子カメラである。

【００３７】本発明のメモリマネージャはアロケーショ
ンポインタを主記憶の先頭へ移動させるファンクション
ResetAllocationPointerを実装している。アプリケーシ
ョンがResetAllocationPointerファンクションを頻繁に
呼び出せば、呼び出すほどメモリマネージャはFirst Fit
法に近い動きをする事になる。毎回アロケーションの前
にResetAllocationPointerファンクションを呼び出すと
もはやNext Fit法ではなく完全なFirst Fit法となり、ア
ロケーションにかかる時間はメモリの消費量に比例して
増加してしまう。ResetAllocationPointerファンクショ
ンの目的はあまでもメモリマネージャをリスタート後に
近い状態にする事である。デジタルカメラのシステムは
このファンクションを一回の撮影動作直後、録音動作直
後、モード設定直後などのタイミングで呼び出す。上記の
様に構成する事で高速なアロケーションと連続動作耐久
性の両方の特徴を備えたシステムを構築する事が可能で
ある。

【００３８】図３はこのメモリーマネージャのアロケー
ション動作のフローチャートである。このフローチャー
トにしたがって、アロケーション動作を説明する。ステッ
プ３０１で要求サイズを切り上げる。アプリケーション
プログラムが要求するメモリサイズの単位は１バイト単
位だが、メモリマネージャが管理する単位はそれよりも
大きい。メモリマネージャがＭＣＢと呼ばれる管理情報
を先頭に作成する為、に４バイトアライメント単位に乗
せる必要があるからである。ステップ３０２でメモリマ
ネージャのセマフォを獲得する。あるタスクがアロケー
ションや開放動作をしている時に別のタスクがアロケー
ションなどをすると二重アロケーションやＭＣＢの破壊
を引き起こす結果となるからである。かといって割り込
みを禁止してしまえば、ストロボやシャッターを制御す
るデジタルカメラとしての制御のレスポンスに影響を与
えてしまう為、セマフォによって排他制御を行う。この様
な方法で排他制御をする事によってメモリマネージャの
動作が他のプライオリティの高いタスクの動作に影響を
与える心配がなくなる。ステップ３０３で現在のアロケ
ーションポインタの位置をアロケーションスタート位置
として記憶する。このポインタの働きは後で説明する。ス
テップ３０４で現在のアロケーションポインタ位置の空
きブロックのサイズと比較する。要求サイズの方が大き
い場合ステップ３０５へ、要求サイズと空きブロックサ
イズが一致すればステップ３０３へ、要求さサイズの方
が小さい場合ステップ３１２へと制御を移す。ステップ
３０５へ進んだ場合それが最終ブロックかどうかを判断
する。最終ブロックならステップ３０７へ、そうでなけれ
ばステップ３０６へ分岐する。ステップ３０６では次の
メモリブロックへアロケーションポインタを進める。ス
テップ３０７ではアロケーションポインタを主記憶の先
頭のブロックへセットする。ステップ３０６と３０７は
どちらも次のブロックへ進めるという効果がある。ステ
ップ３０８ではステップ３０３で記憶したアロケーショ
ンスタート位置とアロケーションポインタを比較してい
る。もし、一致すればすべてのメモリブロックをスキャン
した事の証明となるので、アロケーションに失敗したこ
とになる。その場合ステップ３１６でセマフォを開放し、
ステップ３１７でメモリ獲得に失敗した事を告げるエラ
ー値を返却してアプリケーションへ制御を戻す。ステッ
プ３０８でアロケーションスタート位置と一致しない場
合はステップ３０９でアロケーションポインタ位置のブ
ロックが空きブロックかどうか判断する。

【００３９】使用中ブロックの場合はステップ３０５へ
戻る。そうでないならステップ３１１へ進む。ステップ３
１１では次のブロックが空きブロックかどうかを判断す
る。もし、空きブロックならステップ３１０へ分岐。次の
ブロックが空きブロックでないならステップ３０４へ戻
り、再び要求サイズとの比較を試みる。ステップ３１０で
は次のブロックと現在のアロケーションポインタ位置の
ブロックの２つのブロックをマージして１つの大きなメ
モリにする。そして再びステップ３１１へ戻る。この動作
を繰り返す事で連続した空きブロックをすべてマージす
る。ステップ３０４で要求ブロックサイズと現在のアロ
ケーションポインタ位置のメモリサイズが一致したらス
テップ３１３で現在のアロケーションポインタ位置のブ
ロックを使用中メモリに変更し、それを今回の獲得メモ
リとし、アロケーションポインタを次のブロックへ進め
る。ステップ３０４で要求サイズより現在のアロケーシ
ョンポインタ位置の空きブロックサイズのほうが大きい
場合はステップ３１２で要求サイズの空きブロックと残
ったサイズの空きメモリの２つの空きメモリへ分割し、
ステップ３１３へ進む。ステップ３１４でセマフォを開
放し、ステップ３１５で獲得したメモリの先頭番地をア
プリケーションプログラムへ返却して制御を戻す。図５
はメモリマネージャのメモリ開放動作のフローチャート
である。ステップ５０１でメモリマネージャのセマフォ
を獲得し、ステップ５０２で指定されたブロックが使用
中かどうかを判断する。もし、使用中でなければステップ
５０４でセマフォを開放し、ステップ５０６で開放が失
敗したというエラーコードを返却してアプリケーション
へ制御を戻す。ステップ５０２で指定されたブロックが
使用中なら、ステップ５０３で、そのブロックを空きブロ
ックへ変更し、ステップ５０４でセマフォを開放して、ス
テップ５０５で開放に成功したというリターンコードを
返却してアプリケーションへ制御を戻す。図６はResetAl
locationPointer動作のフローチャートである。ステップ
６０１でセマフォを獲得し、ステップ６０２でアロケー
ションポインタを主記憶の先頭のブロックへ移動。ステ
ップ６０３でセマフォを開放する。

【００４０】プログラムＲＯＭマネージャ デジタルカメラは撮影した画像をコンピュータの理解出
来るファイル形式で格納する。一方、コンピュータの画像
ファイルの種類は非常に多くすべてをサポートする事は
不可能であり、新しい画像フォーマットが次々に登場し
ている。この様な状況で、カメラ内部のソフトウェアに後
から機能を追加したり、変更を加える技術が重要になっ
てきている。

【００４１】図１のフラッシュＲＯＭ１５の一部はこの
デジタルカメラのファームウェアを格納するために利用
する。プログラムの一部を修正したり、追加する事が可能
であれば、ファームウェア開発や、カメラファームウェア
のバージョンアップに便利である。これから説明するプ
ログラムＲＯＭマネージャはこの様なフラッシュＲＯＭ
に書き込まれたプログラムを管理する機能である。

【００４２】図７はフラッシュＲＯＭの中に格納された
プログラムの形式を図にしたものである。

【００４３】格納されているプログラムはモジュール単
位で管理され、モジュールの先頭にはＭＨ（モジュール
ヘッダ）と呼ばれる管理ブロックがある。モジュールヘ
ッダにはモジュール名やプログラムのエントリーポイン
トなどの情報が格納されている。フラッシュＲＯＭはバ
イト単位での消去が出来ないので、一部のモジュールの
変更を行う場合も追加書き込みをするしかない。

【００４４】モジュールの書き換え モジュールは以下の様にフラッシュＲＯＭの前から書き
込まれる。モジュールの消去は、そのモジュールを無効
にする事によって実現している。モジュールの置き換え
は、一旦モジュールを消去して新しくモジュールを書き
込む事で実現している。図８の左は、フラッシュＲＯＭ
に複数のモジュールが存在する様子である。図８の右
は、モジュールＡを新しく書き換えた後の状態である。
元のモジュールＡが使用済みモジュールとなり新しいモ
ジュールＡが未使用領域だった場所へ書き込まれてい
る。

【００４５】プログラムＲＯＭマネージャのサービスは
以下の様になる。 1） モジュール名を指定してその番地を得る。 2） ファイル名を指定して追加書き込みを行う。 3） モジュール名を指定してそのモジュールを無効にす
る。 4） フラッシュＲＯＭのすべてのプログラムを物理的に
イレースする。

【００４６】プログラムＲＯＭマネージャはそのサブシ
ステムとしてＯＳのプログラムローダの機能を利用す
る。追加書き込みの時にプログラムのコードとリロケー
ションテーブルをを主記憶へ一旦読み込み書き込むフラ
ッシュＲＯＭの番地へマッピングするのである。プログ
ラムの実行可能ファイルにコードとリロケーション情報
を格納しておき、実行時に主記憶でマッピングする技術
は、パーソナルコンピュータなどの分野では一般的だ、し
かし、フラッシュＲＯＭの場合マッピング先のアドレス
とプログラムがロードされた主記憶のアドレスが違うの
でＡＰＩでその情報を引き渡す必要がある点が異なる。
本実施例のプログラムローダはプログラムを読み込んだ
主記憶のアドレス以外のターゲット番地に対するマッピ
ングをサポートしている。フラッシュＲＯＭへの物理的
書き込みを行うプログラムに限ってはフラッシュＲＯＭ
に配置する事が出来ない。なぜなら、フラッシュＲＯＭの
書き込みシーケンスにデータポーリングという技術が使
われている為、書き込み途中ではフラッシュＲＯＭのど
のアドレスも同一のポーリング情報しか読めないので、
もし、実行中のプログラムがフラッシュＲＯＭに配置さ
れているものなら、書き込みが始まったとたんに次の命
令が狂ってしまう。又、デジタルカメラのソフトウェアの
ほとんどはこのフラッシュＲＯＭに納まっているので書
き込み中にタスクスイッチがかかったら上記の様な問題
が発生してしまう。この様な問題を解決するために本発
明のプログラムＲＯＭマネージャは書き込みのプログラ
ムをいつも主記憶で実行し、１書き込み単位（バイトま
たはワードまたはダブルワード）が始まってからデータ
ポーリングが終了するまでの間、タスクＳＷと割り込み
を禁止するように構成した。この様に構成する事で稼動
中のシステムを停止せずにプログラムの追加が可能とな
った。

【００４７】本実施例のフラッシュＲＯＭへ物理的な書
き込みを行うデバイスドライバー部は追加プログラムと
一緒に外部記録媒体へ格納しておき、プログラムの追加
書き込みの時に主記憶へロードして実行する。

【００４８】プログラムローダ プログラムローダの動作の説明の前に実行可能プログラ
ムファイルがどのような形式で格納されているかを説明
する。

【００４９】一般形 本実施例の実行可能プログラムファイルフォーマットの
一般形は、図１０のようになっている。

【００５０】ファイルは、複数のレコードから構成され
る。レコードは、サイズフィールド・タイプフィールド
・ボディーフィールドから構成される。

【００５１】レコードのサイズは、サイズフィールドに
よって定義される。１バイトのモジュールタイプによっ
てそのレコードの性質が定義される。ボディーフィール
ドに実際のデータが格納されている。ファイル中に存在
するレコードの数には、制約が無い。プログラムローダ
は、ファイル中のレコードの中から実行に必要な情報を
主記憶に読みだし実行をする。プログラムの実行に必要
ないレコードは、認識せずに読み飛ばす。レコードタイ
プには、図１１の様な種類がある。各タイプ別に解説を
行う。TYPE_OBJECT_INFO（省略不可）

【００５２】このレコードは次の「TYPE_OBJECT_INFO」
までのすべてのレコードの性質をテキストで表現したも
のである。

【００５３】名前=内容 の形式で改行で区切って図１３に示すように記述する。

【００５４】TYPE_PROGRAM バイナリのプログラムである。

【００５５】TYPE_RELOCATE_TABLE プログラム中の絶対アドレッシングを行っているアドレ
スのテーブルである。

【００５６】ＣＰＵの命令として相対アドレッシングを
サポートしていない場合のみ存在するレコードである。
図９の様に絶対アドレッシングのアドレスフィールドを
格納したテーブルである。前提条件としてＣＰＵが絶対
アドレッシングする場合のアドレス幅が３２ｂｉｔであ
る事を仮定している。テーブルの値は、プログラムの先
頭番地を原点とした相対番地である。ローダプログラム
は、バイナリプログラムの該当する番地の値を書き換え
る。書き換えるルールは、以下の通りである。

【００５７】新たに格納する値＝マッピング先番地＋そ
の番地に格納されていた値

【００５８】マルチプラットホームへの対応 本ブロックの連続によって複数のプラットホームへの対
応が可能である。右の図の様に複数のプラットホームの
データを一つのファイルへまとめる事で、単一ファイル
による実行ファイルのマルチプラットホーム化が可能で
ある。システムは、ファイル中から自システムで実行可
能なモジュールを検索して実行する事が出来る。特定の
ＣＰＵを想定した実行可能プログラムファイルを採用し
た場合、ＣＰＵ種類を変更する事ができなくなってしま
う。ＣＰＵ種別を自己記述してある実行可能プログラム
ファイルを採用している場合、生産コスト削減などの理
由でＣＰＵを変更する事が可能となる。

【００５９】図１２は複数種類ＣＰＵのプログラムを格
納したファイルの様子を現している。

【００６０】前記の様にプログラムがモジュール単位に
分割され、モジュールのアドレスが変更されるシステム
では他のモジュールのファンクションの存在するアドレ
スを知る手段が必要となる。サブルーチンのアドレスを
実行時に決定する技術はレートバインディングやダイナ
ミックリンクと呼ばれている。この様な技術を用いる事
でモジュール間のインターフェース設計を柔軟に行う事
が可能になる。パーソナルコンピュータにおけるダイナ
ミックリンクは、ライブラリ（サブルーチン群）の共有
化が主な目的である。目的のライブラリが主記憶中に存
在すれば、即座にリンクは完了するが、目的のライブラリ
が主記憶中に存在しなければ記憶媒体から主記憶にロー
ドし、リンクを行う。

【００６１】本発明のデジタルカメラのソフトウェアは
ＲＯＭに格納されており、共有データもダイナミックア
ロケーションによって作成している為、共有データをダ
イナミックにバインディングする必要がある。図１４は
主記憶にローディングされた共有ライブラリの様子であ
る。ファンクションＡは共有データに対してアクセスを
行っている。ファンクションＡをコールすればどのタス
クからでも共有データにアクセス出来る。共有データと
ライブラリが主記憶にある場合、共有データとファンク
ションＡは、マッピングされた絶対アドレッシングか、相
対アドレッシングで目的のデータをアクセス可能なので
ある。図１５はフラッシュＲＯＭへ書き込まれた共有ラ
イブラリと、主記憶にアロケーションされた共有データ
の様子である。この場合、共有データを作成した時点でア
ドレスが決定されるが、フラッシュＲＯＭのプログラム
はもうマッピングが済んでしまっているのでそのアドレ
スへ対応出来ない。

【００６２】プロセス間で共有データのバインディング
を行う場合、データを用意して公開す（登録）るタスク
と公開（登録）された共有データを検索するタスクの間
のタイミングが重要となる。パーソナルコンピュータの
ダイナミックリンクの場合、共有ライブラリが主記憶に
存在しなければ記録媒体から主記憶にロードすれば良い
が、共有データが存在しない場合はそうはいかない。一定
時間ＣＰＵを別のタスクに明け渡した後で再び検索を行
う様にシステムを構築すると、大変なＣＰＵ時間を無駄
な検索に費やす事になる事が予想出来る。この様なバイ
ンディングの問題を解決する為に、本発明では検索の結
果、目的の共有データが存在しない場合、そのタスクが休
眠状態になり、目的の共有データが別のタスクによって
公開（登録）される事で検索側タスクが再び実行可能状
態へ戻る様に構成した。特定のタスクが共有データを初
期化する場合のタイミングに関しては上記の様に構成す
る事で解決出来る事が分かった。しかし、共有データを初
期化するタスクが不特定の場合には共有データを初期化
する事そのものに対する排他制御が必要である。具体的
に詳しく述べると、例えば、タスクＡが共有データの初期
化を含むＡＰＩを呼び出したとする。タスクＡによって
呼び出されたＡＰＩは初期化済みの共有データが存在す
るかを調べる。存在しなかった場合には共有データを作
成、初期化し、公開（登録）するが、公開（登録）直前に
タスクスイッチがかかり、タスクＢに切り替わる。そし
て、タスクＢもタスクＡが呼び出したＡＰＩと同一のＡ
ＰＩを呼び出す。まだ共有データは公開（登録）されて
いないので、タスクＢも共有データを作成、初期化し、公
開（登録）する。そして、ＡＰＩは共有データを利用する
事が可能となり、サービスを開始する。再びタスクスイッ
チがかかると、タスクＡがさらに共有データを公開（登
録）するので、タスクＢが作成した共有データは失われ
てしまう。この様な不具合をさけるために共有データの
検索から登録までの期間を不可分な動作として行える様
に構成した。

【００６３】ダイナミックバインディングを実現するＡ
ＰＩは以下の様なシンボル管理サービスである。 1) AddSymbol シンボルの登録 2) FindSymbol シンボルの検索 3) LockAndFindSymbol シンボルシステムのロックと検索 4) UnlockAndAddSymbol シンボルシステムのアンロックと登録 5) UnlockSymbol シンボルシステムのアンロック

【００６４】共有データにユニークな名前を定義し、そ
の名前でアドレスを登録、検索するというシンプルなシ
ステムである。

【００６５】図１７はこのシンボル管理システムの内部
データ構造を示している。シンボルを指定してAddSymbol
やFindSymbolを実行するとシンボル管理システムはま
ず、シンボルのセマフォを獲得し、指定されたシンボルを
ハッシュ関数にかけてハッシュ値を計算する。ハッシュ
値は、たとえば文字列の文字コードの合計などで良い。そ
して得られたハッシュ値でインデックスしてテーブルを
引く。テーブルには最初のデータへのポインタが格納さ
れている。END_OF_LISTが格納されていた場合はまだその
ハッシュ値を持つシンボルが１つも登録されていない事
になる。シンボルのデータはそのポインタを先頭にして
リンクドリストとして登録されている。リスト上のＩＴ
ＥＭを１つ１つ指定されたシンボルと比較して検索す
る。図１７の場合、LCD_INSTANCEとAF_INSTANCEというシ
ンボルが登録されている。AddSymbolでシンボルがすでに
存在していれば、アドレスのフィールドを書き換える。存
在していなければ新しいITEMを作成し、リンクドリスト
に追加する。そして、シンボルシステムのセマフォを開放
し、アプリケーションへ復帰する。FindSymbolですでに
シンボルが存在している場合はシンボルのセマフォを開
放し、アドレスをアプリケーションへ返却して即時復帰
出来る。FindSymbolの検索結果、シンボルが存在しなかっ
た場合はまだ有効なデータが格納されていない事を示す
フラグを立てたＩＴＥＭと待ち状態タスクの情報を格納
したＷＡＩＴＩＴＥＭを作成し、ＩＴＥＭへ登録する。Ｗ
ＡＩＴＩＴＥＭのセマフォはあらかじめ０に初期化、タ
イムアウトフラグはTRUEに初期化しておく。その状態を
図１８のに示した。図１８の場合は、２つのタスクがLCD_
INSTANCEの登録を待っている。そして、シンボルのセマフ
ォを開放し、FindSymbolのパラメータで指定されたタイ
ムアウト時間を指定しＷＡＩＴＩＴＥＭのセマフォを獲
得する。ＷＡＩＴＩＴＥＭのセマフォはあらかじめ０に
初期化してあるので、獲得に失敗し、タスクは休眠状態に
なる。次にそのタスクが実行可能状態へ復帰する為には、
タイムアウトが発生するか、セマフォにシグナルが行わ
れるかのどちらかである。その様にしてシンボル待ちタ
スクが休眠してるシンボルを別のタスクがAddSymbolし
た場合、ＷＡＩＴＩＴＥＭのアドレスに値を代入し、タイ
ムアウトフラグをFLASEにしてから、セマフォにシグナル
操作を行う。セマフォ待ち関数の戻り値のタイムアウト
を利用しないのは、シグナルとほぼ同時にタイムアウト
を起こす場合があるからである。そして、ＷＡＩＴＩＴＥ
ＭのリストからＷＡＩＴＩＴＥＭを外す。AddSymbolはＷ
ＡＩＴＩＴＥＭが無くなるまでこれを繰り返す。実行可
能状態へなったFindSymbolタスクは最初にシンボルのセ
マフォを獲得するのでAddSymbolがセマフォを離すまで
の間、再び休眠状態となる。FindSymbolはセマフォを獲得
した後でタイムアウトフラグを確認し、タイムアウトで
ないならセマフォを開放し、ＷＡＩＴＩＴＥＭのアドレ
スフィールドを返却し、アプリケーションへ復帰する。タ
イムアウトなら、セマフォを開放し、エラーコードを返却
してアプリケーションへ復帰する。

【００６６】共有データの初期化に対する排他制御 LockAndFindSymbolとUnlockAndAddSymbolまたはUnlockS
ymbolは、検索と登録までの期間の排他制御を実現するフ
ァンクションである。

【００６７】LockAndFindSymbolを実行してからUnlockA
ndAddSymbolまたはUnlockSymbolを実行するまでの期間
シンボルのシステムを独占し、他のタスクによるシンボ
ル操作（検索、登録）が行われない事を保証する。図１９
は、このファンクションを使って共有データの初期化を
行うプログラムの動作をフローチャートにしたものであ
る。ステップ１９０１でLockAndFindSymbolを実行し、シ
ンボルシステムのロックと検索を行う。検索の結果、シン
ボルが発見されれば、ステップ１９０２へ分岐し、シンボ
ルが無ければ１９９３へ分岐する。LockAndFindSymbolは
現時点でのシンボルの存在を確認し、シンボルが登録さ
れていない場合は即時復帰する。待ち状態にならないの
で、タイムアウト時間を指定するパラメータは無い。ステ
ップ１９０１でLockAndFindSymbolを実行し、検索の結
果、シンボルが発見されれば、ステップ１９０２へ分岐
し、１９０２でシンボルシステムのロックを解除する。ス
テップ１９０１でLockAndFindSymbolを実行し、検索の結
果、シンボルが発見されなかった場合、ステップ１９０３
で共有データ用のメモリをアロケーションする。そして
ステップ１９０４でセマフォを０に初期化する。そして、
ステップ１９０５でUnlockAndAddSymbolファンクション
を使い、シンボルのアンロックと共有データの公開を行
う。共有データの初期化はまだ不完全だが、セマフォを０
に初期化しているので、別のタスクがセマフォを獲得し
ようとしても待ち状態に遷移するので問題ない。共有デ
ータの初期化すべてを行うまでシンボルシステムをロッ
クしてしまうと、自タスクよりプライオリティの高い他
タスクのバインディングの遅延につながる。したがって、
シンボルのロック期間は短ければ短いほど良い。図１９
の点線で囲んである部分はシンボルのシステムを独占し
ている期間である。ステップ１９０６で共有データの初
期化を済ませ、ステップ１９０７で共有データのセマフ
ォを開放する。この時点で他のタスクからこの共有デー
タが利用可能になる。LockAndFindSymbolの動作はFindSy
mbolの動作に非常に良く似ている。FindSymbolとの違い
は、シンボルが存在しない場合に即時復帰する事とシン
ボルのセマフォを返却せずに復帰する点である。UnlockS
ymbolはシンボルシステムのセマフォを返却するだけの
ファンクションである。UnlockAndAddSymbolもAddSymbol
と良く似ている。シンボルシステムのセマフォを獲得し
ている事を前提にしているので、セマフォの獲得をしな
い点でAddSymbolと異なる。

【００６８】次にこのカメラのスタートアップ方法を説
明する。

【００６９】カーネルのスタートアップ図１の５のＣＰ
Ｕの電源が投入され、リセットが解除されると、図１の５
のＣＰＵは図１の１３のＲＯＭのリセット後のエントリ
ポイントから実行を始める。図１の１３のＲＯＭにはリ
アルタイムオペレーティングシステムなどの基本機能だ
けが搭載されている。オペレーティングシステムそのも
のをバージョンアップする事を可能にする為に図１の１
３のＲＯＭのプログラムはオペレーティングシステムを
スタートする前に図１の１５のフラッシュＲＯＭへジャ
ンプするようになっている。図１の１５のフラッシュＲ
ＯＭが手違いや事故によって書き換わってしまった場合
に暴走してしまう危険があるので、図１の１５のフラッ
シュＲＯＭの別の特定番地にはキーワードが格納されて
おり、キーワードが一致した場合のみフラッシュＲＯＭ
へジャンプする。キーワードが一致するが、フラッシュＲ
ＯＭのプログラムにバグがあったり、事故で一部の書き
込みに失敗した場合も、やはり暴走する。書き込みの失敗
に関しては、プログラムの書き込みとベリファイが終了
してからキーワードを書く様に構成する事で回避可能で
あるが、プログラムのバグによって暴走する場合は防ぎ
ようがない。この様な問題は主に開発段階で発生するの
で、特別なハードウェアを使って回避するのが、実装もデ
バッグもはるかに簡単である。特別なハードウェアとい
ってもＩＯポートの特定のビットを電源側へプルアップ
したり、グランドへプルダウンするだけで良い。本実施例
では図１の１９のＰＣインターフェースの製品ではプル
アップされているポートをグランドへショートする事で
メンテナンスモードである事をカメラへ伝える。もし、ス
タートアップ時にメンテナンスモードである事を検出す
ると、たとえキーワードが一致してもフラッシュＲＯＭ
のプログラムは一切実行せず、図１の１３のＲＯＭのプ
ログラムだけで動作し、フラッシュＲＯＭのオペレーシ
ョンなどを行うモードとなる。特定のハードウェアを用
意する必要があるので、この機能が市場でトラブルを起
こす心配はまったくない。図２０は本実施例のスタート
アップシーケンスのフローチャートである。ステップ２
００１でリセットが解除されると、ＣＰＵはＲＯＭの特
定番地を読み出して、そこから実行を始める。ステップ２
００２でＢＵＳのタイミングなど必要最低限のハードウ
ェアの設定を済ませる。ステップ２００４で、メンテナン
スモードかどうかを判断する。本実施例では図１の１９
のＰＣインターフェースの製品ではプルアップされてい
るポートがグランドへショートされているかどうかを判
断する。もし、メンテナンスモードならステップ２００６
へ分岐する。ステップ２００６ではリアルタイムＯＳの
カーネル、メモリマネージャ、シンボル管理、プログラム
ＲＯＭマネージャを初期化しスタートさせる。そして、ス
テップ２００７でフラッシュＲＯＭオペレーション用の
プログラムのスタートアップタスクを実行する。スター
トアップタスクは、必要なタスク類のテーブルをもって
おり、順次タスクを作成し、実行させる。

【００７０】ステップ２００３でメンテナンスモードで
なかった場合、ステップ２００４へ分岐する。ステップ２
００４でフラッシュＲＯＭの特定番地のキーワードをチ
ェックする。キーワードは、プログラムＲＯＭマネージャ
が管理していない領域を予約する方法もあるが、フラッ
シュＲＯＭの最後の番地にしておけば、この機能を使わ
ない時に通常のプログラムを格納する事も可能となる。
そして、キーワードチェックの結果キーワードが一致す
ればステップ２００５へ分岐する。ステップ２００５で
は、フラッシュＲＯＭへジャンプしてしまうので、オペレ
ーティングシステムそのものを置き換える様なプログラ
ムやハードウェア設定の追加などのプログラムを用意す
る事が可能である。ステップ２００４でキーワードが一
致しなかったらステップ２００８へ分岐する。ステップ
２００８の処理内容はステップ２００６とまったく同じ
である。そしてステップ２００９ではプログラムＲＯＭ
マネージャの機能を使って、デジタルカメラのスタート
アップタスクを検索し、実行する。

【００７１】デジタルカメラのスタートアップ デジタルカメラとしての重要な機能はステップ２００９
でスタートする。図２０のステップ２００９のスタート
アップタスクの動作を図１のフローチャートで示した。
スタートアップタスクはモジュール名のテーブルをもっ
ており、そのテーブルにしたがって、プログラムＲＯＭマ
ネージャ経由でモジュールを検索し、順次タスクを作成
していく。図２１はそのテーブルの順番をおおざっぱに
グループわけして表現している。

【００７２】ステップ２１０１でデバッグ用のプログラ
ムをスタートする。ウォッチドッグやイリーガルオペコ
ードトラップなどの製品としての異常検出を目的とした
ものからログ（経歴）サービスなどの開発時のみに利用
するものも含む。ステップ２１０２ではハードウェアの
初期化を行う。仮想化されたハードウェアのドライバを
用意するのもこの時点で行う。また、ローバッテリー例外
処理や、シャットダウンのフックもステップ２１０２で
初期化し、公開する。

【００７３】ステップ２１０３でファイルシステムの初
期化と内蔵フラッシュＲＯＭＤＩＳＫドライバーの初期
化とファイルシステムのマウントを行う。

【００７４】ステップ２１０４は工場調整値データのデ
ータベースサービスをスタートとカメラステータスデー
タベースをスタートする。この時、ステップ２１０３で初
期化したファイルシステムを用いて内蔵フラッシュＲＯ
ＭＤＩＳＫの工場調整値データのファイルをオープン
し、工場の調整値データを読み出す。カメラステータス情
報のデータファイルも同様にオープンし、データを読み
出す。カメラステータスデータとは、現在の圧縮率やスト
ロボ使用のＯＮ・ＯＦＦ、ＤＩＳＫの残り空き容量など
の情報が格納されている。

【００７５】ステップ２１０５でその他のデバイスドラ
イバーの公開（登録）をするだけのタスクを起動する。
デジタルカメラのデバイスドライバは、パーソナルコン
ピュータでよく知られているもの以外に、ＣＣＤデバイ
ス、ＪＰＥＧデバイス、信号処理アクセラレータデバイ
ス、測光デバイス、測色デバイス、フォーカスコントロー
ルデバイス、などデジタルカメラのハードウェアに依存
した特徴を隠蔽するためのものが多数含まれる。この時
点ではデバイスドライバのエントリーポイントをシンボ
ルとして公開するだけである。ステップ２１０６で内蔵
ＲＯＭＤＩＳＫの中に特定のファイル名を持った実行可
能ファイルが存在していれば主記憶にロードして実行す
る。内蔵ＲＯＭＤＩＳＫの中のプログラムを実行可能に
しておく事で、プログラムＲＯＭマネージャの管理する
フラッシュＲＯＭへの書き込みをする事なくカメラの機
能を拡張する事が出来る。内蔵ＲＯＭＤＩＳＫのプログ
ラムがステップ２１０５で公開されたデバイスドライバ
ーと同じ名前のドライバーを公開する事で、その機能を
完全に置き換える事が可能になる。ステップ２１０８で
バッテリーチェックシステムをスタートさせ、２１０８
でパワーロックのサービスをスタートさせる。ステップ
２１０９でコントロールパネルをスタートさせる。コン
トロールパネルによってボタンが押された情報はこの時
点で伝達され、撮影などの動作にはいる。デバイスドライ
バがバインディングされるのはステップ２１０９の後で
ある。シンボルの書き換えによるモジュールの置き換え
はステップ２１０９よりも前でなければならない。

【００７６】実行ファイル 内蔵のフラッシュＲＯＭにプログラムを追加する場合、
追加書き込みをする未使用領域が無くなってしまうと、
一旦すべてのプログラムを消去しなければならない。よ
り多くのアプリケーションに対応する為に、外部記憶媒
体に追加プログラムを書き込む様にしたい。

【００７７】外部記憶媒体の追加プログラムをデジタル
カメラがスタートアップ時に読み出す様に構成した場
合、デジタルカメラのスタートアップ時間が外部記憶媒
体のスタートアップ時間に大きく依存してしまう。デジ
タルカメラのスタートアップはユーザが操作部のキーへ
触れた時から始まる。ユーザが操作部のキーへ触れてか
ら約２００ミリ秒ほどの期間はコントロールパネル部で
チャタリングの除去の為のタイムラグがある。その時間
の間にスタートアップが終了しなければ、ユーザーから
の操作に対しての反応が遅くなり、操作感が悪くなる。そ
れに対しハードディスクのスタートアップは７秒〜十数
秒かかる。その事から外部記憶媒体から直接追加プログ
ラムをロードする事は不可能である。本発明では、外部記
憶媒体をデジタルカメラへ挿入したタイミングで自動実
行ファイルが外部記憶媒体に存在すれば、それを内蔵Ｒ
ＯＭＤＩＳＫへコピーし、外部記憶媒体がデジタルカメ
ラから脱着されたタイミングで内蔵ＲＯＭＤＩＳＫの中
の自動実行ファイルを消去する様に構成する事で、外部
記憶媒体の中の自動実行ファイルをスタートアップ時に
高速にロードし、実行する事を可能としている。スタート
アップ時に自動実行ファイルをロードするタイミングは
図２１のステップ２１０６で説明した。

【００７８】仮想ＩＯポート デジタルカメラのＢＵＳには、カスタムのデバイスが使
われている。カスタムのデバイスをより安く生産できれ
ば、デジタルカメラも安く生産出来る。周辺カスタムデバ
イスのコストを下げる為に、出来るだけゲート数の少な
い回路で沢山の機能を搭載したい。１つのアドレスデコ
ード回路でいくつかの機能のコントロールを行う事や、
コントロール用レジスタを書き込み機能だけ（ＣＰＵか
ら読めない）にする事で周辺カスタムデバイスのゲート
数をかなり下げる事が出来るが、コントロールするソフ
トウェアの設計が困難になってしまう。本実施例では、読
み書き可能なバッファーを備えた仮想のＩＯポートを構
成し、ソフトウェアモジュール間で共有する事で、周辺カ
スタムＩＣのコントロールポートへ読み出し機能がある
場合と同等のソフトウェアの構成を可能としている。

【００７９】図２２は仮想ＩＯポートのデータ構造を示
している。アプリケーションはデバイスハンドルとレジ
スタＩＤナンバーをつかってコントロールを行う。ＡＰ
Ｉはデバイスハンドルで指定されたバッファーの配列に
対してリードモディファイライトを行い、その内容をバ
ッファーと対で格納されているＩＯ番地情報を使って周
辺デバイスへ書き込みを行う。このデバイスハンドルは、
スタートアップ時の図２１のステップ２１０２で初期化
し、ハンドルをシンボル登録する。

【００８０】図２３はこの仮想デバイスを使ったビット
セットファンクションのフローチャートである。ステッ
プ２３０１でステータスレジスタの内容を待避する。ス
テップ２３０２で割り込みを禁止する。ステップ２３０
３でハンドルとレジスタＩＤからバッファーとＩＯ番地
のアドレスを計算する。レジスタＩＤは、あらかじめ図２
２のテーブルのインデックス値を定義しておく。ステッ
プ２３０４でバッファーのデータとセットするビットパ
ターンのＯＲをとり、バッファーへ格納し、ＩＯポートへ
も出力（書き込み）を行う。ステップ２３０５でステー
タスレジスタを復帰する。もし、ステップ２３０２を実行
するより以前が割り込み許可状態だったなら割り込み許
可状態へ戻る事になる。

【００８１】仮想デバイスのＡＰＩとしてビットセット
以外にビットクリア、ビット幅を指定した書き込みと読
み出しがあればコントロールプログラムは作成可能であ
る。

【００８２】仮想デバイスを利用する事のメリットとし
て、仮想デバイスＡＰＩを変更してＩＯの経歴をとるな
どのデバッグ用の用途に利用出来る点が上げられる。ま
た、ハードウェアの設計変更によって周辺デバイスのア
ドレスに変更があった場合に、変更が及ぶ範囲がテーブ
ルの値だけなので管理も変更もしやすい。別の言い方を
すれば開発期間とコストを軽減する効果がある。

【００８３】フック管理 イベントの発生に対してコールバック処理を行う場合が
ある。コールバックの依頼主が不特定多数である場合に
はそれらを管理するＡＰＩがあると便利である。デジタ
ルカメラの場合、そのような不特定多数が利用するコー
ルバックサービスがいくつか必要である。ローバッテリ
ー発生の例外処理、シャットダウンの処理などは、制御プ
ログラムのほとんどに例外処理が必要になるからであ
る。本発明ではそれらのフックを管理するＡＰＩをオペ
レーティングシステムのサービスとして用意している。
フックのＡＰＩは以下の様なサービスである。 1） フックハンドルの作成 2） フックハンドルの抹消 3） ファンクションとインスタンスの登録 4） ファンクションの登録解除（リストから削除） 5） フックの実行

【００８４】フックハンドルの作成は、フック管理用の
メモリをアロケーションし、セマフォを１で初期化、最初
のファンクションへＥＮＤ＿ＯＦ＿ＬＩＳＴを代入し、
そのメモリのポインタをフックハンドルとしてアプリケ
ーションへ引き渡す。ファンクションとインスタンスの
登録は、フックハンドル、ファンクションアドレス、イン
スタンスアドレスを指定して呼び出し、ファンクション
とインスタンスを登録し、ファンクションのハンドルを
返却する。ファンクションのハンドルは後で削除する時
に使用する。図２４はフック管理のデータ構造を示して
いる。フックハンドルに対し、２つのファンクションが登
録されている。

【００８５】ファンクションの実行はセマフォを獲得
し、リストをたどりながら順次ファンクションを実行し
ていく。フックを利用したアプリケーションの例を図２
５のフローチャートで説明する。図２５の例はフォーカ
スモータをコントロールプログラムである。ステップ２
５０１でフォーカスコントロールを開始する。ステップ
２５０２でローバッテリー例外処理のフックへコールバ
ック関数を登録する。この時登録する関数は図２６のフ
ローチャートで示した関数である。インスタンスとして
フォーカスシステムのコントロール時間待ち用のセマフ
ォを登録する。このセマフォはコールバックファンクシ
ョンの中で使用する。ステップ２５０３で１ステップだ
け駆動する。ステップ２５０４では、ステップ２５０２で
コールバックファンクションのインスタンスとして指定
したセマフォに対してタイムアウト指定で獲得を試み
る。このセマフォは０で初期化しているので通常は獲得
に失敗し、タイムアウトが発生する。ステップ２５０５で
タイムアウトが発生したかどうかを判定する。タイムア
ウトならステップ２５０６へ、タイムアウトが発生して
いない場合は２５０９へ分岐する。ステップ２５０６で
は駆動すべき全ステップの駆動が終了したか判断し、ま
だ終了していないなら、ステップ２５０３へ戻り、終了し
ていればステップ２５０７へ分岐する。ステップ２５０
７ではステップ２５０２で登録したファンクションをフ
ックから削除する。ステップ２５０８で正常に終了する。
もし、ステップ２５０５でタイムアウトが発生していな
ければステップ２５０９でローバッテリ例外処理フック
からステップ２５０２で登録したファンクションを削除
し、ステップ２５１０で異常終了のエラーコードを返却
して呼び出し元へ復帰する。図２６はステップ２５０２
で登録したコールバックファンクションのフローチャー
トである。ステップ２６０１でフォーカスモータの電源
を落とし、ステップ２６０２でセマフォへシグナルし、ス
テップ２６０３で復帰する。このコールバックファンク
ションがステップ２６０２でセマフォをシグナルしなけ
れば必ず図２５のステップ２５０５でタイムアウトにな
る。この様な構成でローバッテリ時の例外処理を行う事
で検出から対応までのレスポンスが早く、ＣＰＵタイム
を無駄遣いしない制御が可能となる。

【００８６】イベントプロシジャ スタートアップの後、呼び出されるプログラムは、コント
ロールパネルからの操作イベントに対応した処理であ
る。コントロールパネル部がメインＣＰＵへ送るイベン
トはどのキーが押された、又は離されたという情報であ
る。２つボタン押しや２つボタン押しなどの操作をいろ
んな機能に割り当てる事で少ないキーで多くの機能を持
たせる事が可能になる。そこで押されたキーのイベント
はキーの操作を理解するモジュールへと伝達される。そ
して、そのモジュールでキー操作の内容を理解した結果、
それに対応したデジタルカメラの機能を起動する。ここ
でいうデジタルカメラの機能は、EraseSingleとかSetMac
roModeといった単機能の動作である。これらの機能はイ
ベントが起こった時にそれに対応して呼び出されるサブ
ルーチンのテーブルとして管理しており、イベントプロ
シージャと呼んでいる。名前とファンクションを対にし
て記憶しているテーブルであり、パーソナルコンピュー
タではマクロ言語をサポートしたＥｍａｃｓなどのテキ
ストエディタなどでもこの様なテーブルを実装してい
る。本発明のデジタルカメラは、イベントプロシージャの
テーブルをスタートアップ時に作成する。したがって、自
動実行ファイルが特定のイベントプロシージャを置き換
える事でデジタルカメラの機能の一部を変更する事が可
能である。

【００８７】メインパワーマネージャ このようにシステムが立ち上がるとコントロールパネル
からのイベントに対応して、制御が行われる。撮影や録音
の処理が終了すれば、必ず電源を落とすシステムにした
場合、スタートアップとシャットダウンの時間のタイム
ラグや、ＤＩＳＫキャッシュのフラッシュなどの処理を
毎回行う事になり、連続的な操作に対するレスポンスが
悪くなってしまう。また、ＤＩＳＫキャッシュやＥＦのチ
ャージのシステムは録音などのアプリケーションとは分
離して設計する事が望ましい。しかし、電源を落とす為に
はその様なサブシステムの動作状態を管理しなければな
らない。さらに、自動実行ファイルなどでカメラの機能を
拡張したり、パソコンからのリモートコントロールで録
音や撮影の動作を行う事も考慮しなければならない。こ
の様なシステムの電源を落とすプログラムをメインシー
ケンスの流れの中で設計するのは非常に困難である。

【００８８】本発明では、デジタルカメラの主電源を落
とす為のしくみを用意する事で、上記の問題点を解決し
ている。

【００８９】メインパワーマネージャのＡＰＩ 1） パワーのロック 2） パワーのアンロック 3） オートシャットダウンタイムの設定

【００９０】各アプリケーションの中で最も最上位のプ
ログラムは、メインパワーマネージャに対して電源のロ
ックを行う。例えば、ＤＩＳＫキャッシュや、ＥＦチャー
ジも独立したアプリケーションとして設計する為、主電
源のロックは行う。主電源がロックされている期間は必
ず主電源が供給される事をメインパワーマネージャが保
証する。メインパワーマネージャは、ロックの数をカウン
トし、ロックの数が０になったタイミングからオートシ
ャットダウンタイムの時間を計測する。ロックの数が０
になっている時間が連続Ｎミリ秒に達するとシャットダ
ウンシーケンスに突入する。ロックの数が０になってか
らＮミリ秒以内にロックカウンタが０以外になれば再び
主電源の供給が保証される。ただし、ローバッテリー検出
システムがローバッテリを検出した場合は例外的に主電
源が切断される。

【００９１】図２７はパワーロックカウンタとオートシ
ャットダウンタイマーの様子を示したタイムチャートで
ある。一番上のラインは撮影のアプリケーションがパワ
ーをロックしている期間を現している。撮影の点線は露
光のタイミングである。それ以前はＡＦやＡＥを行いな
がら待機している期間である。露光時にストロボを使用
したので、ＥＦチャージが始まり、ＥＦチャージプログラ
ムが主電源をロックした。一番下の行にロックカウンタ
の数字を記載している。このとき、撮影プログラムとＥＦ
チャージが主電源をロックしているので、ロックカウン
タは２になっている。しばらくすると露光された画像が
処理され、画像ファイルとして記憶媒体に格納されるの
でＤＩＳＫキャッシュが稼動しはじめ、主電源をロック
する。この時のロックカウンタは３になる。次に撮影プロ
グラムが処理のすべてを終了するが、ＤＩＳＫキャッシ
ュとＥＦチャージはまだ稼動中なのでロックカウンタは
２である。ＤＩＳＫキャッシュが保留していたデータの
すべてをＤＩＳＫへ書きおわり、ＥＦチャージが次の撮
影に十分な電力を主電源からストロボ部へ充電し終える
とロックカウンタが０になり、オートシャットダウンタ
イマーが時間計測を開始する。しかし、十分な時間が経過
していないうちに再び撮影準備にはいってしまった為、
シャットダウンは起こらずに、ロックカウンタが１へ変
化する。ロックカウンタはその後１→２→３→２→１→
０と変化し、オートシャットダウンタイマーが動作し、Ｎ
ミリ秒が経過した後にシャットダウンが始まる。

【００９２】シャットダウン処理 シャットダウンの処理は、その時稼動しているアプリケ
ーションによって異なる。又、追加プログラムなどがある
場合の処理も異なる。したがって、処理そのものをフック
の実行によって行うのが良い。しかし、他のシャットダウ
ン処理との順序関係が重要になる場合がある。データベ
ースのシャットダウン処理はファイルをクローズする事
だが、すでにファイルシステムがシャットダウンを終え
てしまっていたらファイルのクローズすら出来ない事に
なるからである。本発明のデジタルカメラではシャット
ダウンをフックの実行で行い、シャットダウン処理を３
っつのレイアに分けて順番に実行を行う事で上記の問題
点を解決している。

【００９３】シャットダウンのレイアー １）アプリケーションレイア 1） システムレイア 2） デバイスレイア

【００９４】スタートアップ時に上記のレイアごとにフ
ックハンドルを用意して公開している。１のアプリケー
ションレイアでは、データベースやリモートコントロー
ル用の通信プログラムなどがシャットダウンを行う。す
なわち、ファイルに対してデータを書いたり、パーソナル
コンピュータへ終了メッセージを送ったりといった処理
である。２のシステムレイアでは、ファイルシステムや通
信のデータリンクレイアの部分などのシャットダウン処
理が行われる。３のデバイスレイアで、ＰＣＭＣＩＡのカ
ードへの電源供給を落としたり、コントロールパネルと
の通信のシャットダウン処理などを行う。上記の順にす
べてのフックを実行した後で、主電源を落とす。シャット
ダウンの処理にファイルシステムも含まれる為、ＤＩＳ
Ｋキャッシュサイズにも依存するが数十ミリ秒から数百
ミリ秒の時間が必要である。ローバッテリーが発生した
場合速やかにシャットダウンを行うが、急激な電圧降下
により、システムの動作が数ミリ秒程度しか保証されな
い場合には、３のデバイスレイアの処理だけを行う。カメ
ラのローバッテリー検出は、数段階のランクがあり、通常
の動作禁止の電圧を検出する事が出来ない程の質の悪い
電池の場合に限って、３のデバイスレイアだけのシャッ
トダウンの処理になる。その場合ファイルシステムなど
に破壊が生じる可能性があるが、電流のリークなどのよ
り致命的な障害を避ける事が出来る。

【００９５】ＦＡＴＡＬＥＲＲＯＲ時の処理 ハードウェアの故障などの障害を検出した場合、デジタ
ルカメラはエラーを表示して、システムを停止させる必
要がある。システムはモジュールごとに分離設計をして
いる為、障害の検出の後の処理を設計時に定義するのが
難しい。又、仮に障害検出後の処理を定義したとしても、
自動実行ファイルなどのプログラムが追加されている場
合に問題を起こす可能性がある。本発明では、この様な問
題を解決する為にエラー処理を受け持つ専門のモジュー
ルを定義し、処理内容を抽象化した。エラーが発生した後
のリカバリー方法に関して大まかに分類し、エラーコー
ドでその種類を伝達する。エラーコードにダブルワード
を定義した場合、４ギガ種類のエラーに対応出来るが、そ
れほどの種類のエラーが必要になる事は無い。したがっ
てエラーの種類を特定するコードはせいぜい５１２種類
程度である。本実施例では、エラーコードの上位ワードを
エラーの分類とし、下位ワードを表示用に利用する。図２
８はＦＡＴＡＬＥＲＲＯＲの分類を表にまとめたもので
ある。

【００９６】ＦＡＴＡＬＥＲＲＯＲもキー入力と同等の
内部イベントとして、イベントプロシージャに定義され
る。ＡＢＯＲＴのエラーは、主にシャッターやフォーカス
モータなどのメカ部品に障害がある場合に使う。シャッ
ターやフォーカスモータの障害の場合、システムとして
は安全に継続稼動できるので、エラー表示を行い、再び次
のオペレーションを受け付けるモードへ戻る。例えばス
トロボに障害がある場合に日中撮影は可能なので、すぐ
サービスに持っていくかストロボを使わずに撮影を続け
るかはユーザが選択出来るべきである。可能な限り動作
を行う。ＩＮＩＴ＿ＤＢは撮影した画像をディスクへ書
き込んでいる途中で障害が起こった場合など、記憶媒体
の空き容量やディレクトリ情報に間違いが混入する可能
性があるタイミングでの障害を検出した場合や記憶媒体
の空き容量やディレクトリ情報に間違いを検出した場合
に用いる。ＦＡＴＡＬＥＲＲＯＲモジュールが、この種類
のエラーコードを受け取った場合、記憶媒体の空き容量
やディレクトリー情報などの収集をやり直す。ＩＮＩＴ
＿ＳＹＳのエラーコードは内蔵ＤＩＳＫの論理構造を破
壊する可能性のある障害が発生した場合や内蔵ＤＩＳＫ
の論理構造の破壊を検出した場合である。内蔵ＤＩＳＫ
へはデジタルカメラのステータス情報など重要な情報が
納まっており、この情報に誤りがあるとデジタルカメラ
を安全に稼動させる事が出来ない。しかも、さらに内蔵Ｄ
ＩＳＫへの書き込みを続けるとＤＩＳＫの論理構造の破
壊を悪化させる可能性があり、撮影済みの画像ファイル
まで失ってしまう可能性がある。したがって、デジタルカ
メラは内蔵ＤＩＳＫの画像・音声データ読み出しとＤＩ
ＳＫフォーマットしか出来ないモードになり、完全な初
期化をユーザの手で実行してもらうしかない。ＡＳＳＥ
ＲＴは主に開発中に内部エラーや発狂検出でひっかかっ
た場合の為にある。ＦＡＴＡＬＥＲＲＯＲモジュールが
このコードを受け取った場合、デバッグ情報のログを吐
き出し、解析モードへ入る。システムとしては、複数のモ
ジュールが連携して動作しているので、１つのモジュー
ルがエラーを検出した場合に別のエラーを誘発する事が
よくある。しかし、きっかけとなるエラーは最初にレポー
トされる事が多い。そこで、ＦＡＴＡＬエラーのモジュー
ルは必ず最初にレポートされたエラーだけを表示する。
しかし、リカバリー手段はそうはいかない。最も致命的な
エラーを優先してリカバリーを行う。図の分類は下にな
るほど致命的なエラーになる順番で記述してある。

【００９７】前途の様に内蔵ＲＯＭＤＩＳＫへは、シス
テムの稼動に必要な重要なファイルが存在する。デジタ
ルカメラの動作はそのファイルにしたがって決定され
る。しかし、内蔵ＲＯＭＤＩＳＫに障害がある場合には、
そうはいかない。内蔵ＲＯＭＤＩＳＫに障害が発生した
場合の処理を特別に設計するのは、基本設計を二重化し
なければならない事を意味する。本発明では内蔵ＲＯＭ
ＤＩＳＫに障害がある場合、プログラムＲＯＭの一部を
読み出し専用ファイルとして利用し、内蔵ＲＯＭＤＩＳ
Ｋに障害がある場合の動作を決定出来るように構成し
た。さらに、内蔵ＲＯＭＤＩＳＫのフォーマット直後にプ
ログラムＲＯＭからそのファイルをコピーして継続的な
動作が可能になるよう構成した。図２９はプログラムＲ
ＯＭの一部をファイルの代替えとして利用している様子
である。Ｃ言語でファイルを読む場合read関数を使うが
フラッシュＲＯＭからの読み出しは代りにmemcpyを使っ
て読み出す。

【００９８】シンボル管理の動作 １．ＡｄｄＳｙｍｂｏｌ・ＵｎｌｏｃｋＡｎｄＡｄｄＳ
ｙｍｂｏｌ＜シンボルの登録＞ ここではＡｄｄＳｙｍｂｏｌファンクションとＵｎｌｏ
ｃｋＡｎｄＡｄｄＳｙｍｂｏｌを同時に説明する。Ｕｎ
ｌｏｃｋＡｎｄＡｄｄＳｙｍｂｏｌは図１９のＳＴＥＰ
１９０５で仕様されているＯＳコールであり、その存在
意義はすでに説明済みのものであるが、ＵｎｌｏｃｋＡ
ｎｄＡｄｄＳｙｍｂｏｌはＡｄｄＳｙｍｂｏｌファンク
ションの一部として実装されている。したがってＡｄｄ
ＳｙｍｂｏｌとＵｎｌｏｃｋＡｎｄＡｄｄＳｙｍｂｏｌ
を同時に説明するのが効率が良い。まず、図３０がＡｄ
ｄＳｙｍｂｏｌのフローチャートである。ＳＴＥＰ３０
０１でＡｄｄＳｙｍｂｏｌが始まる。ＳＴＥＰ３００２
でバイナリセマフォを用いてシンボルのデータベースの
排他ロックを行う。ＳＴＥＰ３００３でＵｎｌｏｃｋＡ
ｎｄＡｄｄＳｙｍｂｏｌへジャンプする。ＡｄｄＳｙｍ
ｂｏｌはシンボルのデータベースをロックする事以外は
すべてＵｎｌｏｃｋＡｎｄＡｄｄＳｙｍｂｏｌと共通な
のである。図３１はＵｎｌｏｃｋＡｎｄＡｄｄＳｙｍｂ
ｏｌのフローチャートである。ＳＴＥＰ３１０１でＵｎ
ｌｏｃｋＡｎｄＡｄｄＳｙｍｂｏｌは始まる。次にＳＴ
ＥＰ３００２で該当シンボルの検索を行う。もし、該当
シンボル項目が見つからなかったらＳＴＥＰ３１０４で
新規シンボル項目を作成して、データベースへ追加す
る。ＳＴＥＰ３１０２で該当シンボル項目が見つかった
らＳＴＥＰ３１０３へ分岐する。ＳＴＥＰ３１０３でそ
の項目が、有効なデータを持っているのか、待ちタスク
のハンドルを持っているのかを判断する。もし待ちタス
クの行列を持っているのであればＳＴＥＰ３１０５で待
ち行列のタスクをすべてウェークアップさせる。ＳＴＥ
Ｐ３１０４、ＳＴＥＰ３１０３ＳＴＥＰ３１０５の次に
ＳＴＥＰ３１０６で新規項目へデータを格納し、ＳＴＥ
Ｐ３１０７でシンボルテーブルデータベースをアンロッ
ク（セマフォの開放）する。

【００９９】２．ＦｉｎｄＳｙｍｂｏｌ＜シンボルの検
索＞ 図３２はシンボル検索ファンクションＦｉｎｄＳｙｍｂ
ｏｌのフローチャートである。ＳＴＥＰ３２０１でＦｉ
ｎｄＳｙｍｂｏｌが始まる。ＳＴＥＰ３２０２でセマフ
ォなどの手法を用いてシンボルのデータベースをロック
する。ＳＴＥＰ３２０３で該当シンボル項目の検索を行
う。検索の結果シンボルが存在しなかった場合はＳＴＥ
Ｐ３２１１で新規シンボルを作成してデータベースへ加
える。ＳＴＥＰ３２０３で該当シンボル項目が見つかっ
た場合はＳＴＥＰ３２０４へ分岐する。ＳＴＥＰ３２０
４でその項目に有効なデータが含まれているのか、待ち
タスクのハンドルが含まれているかを判断する。もし、
待ちタスクのハンドルを持っているのであればＳＴＥＰ
３２０５へ分岐する。ＳＴＥＰ３２１１の後もまた３２
０５へ移行する。ＳＴＥＰ３２０５ではシンボルデータ
ベースをアンロックして休眠状態になる。そして、タイ
ムアウト時間か、ＡｄｄＳｙｍｂｏｌ／ＵｎｌｏｃｋＡ
ｎｄＡｄｄＳｙｍｂｏｌによってウェークアップするま
でＳＴＥＰ３２０５で休眠状態となる。ＳＴＥＰ３２０
４で有効なデータを持っていた場合はＳＴＥＰ３２０６
でシンボルデータベースのアンロックを行い、ＳＴＥＰ
３２１０で登録データを返却して復帰する。ＳＴＥＰ３
２０５からウェークアップしたらＳＴＥＰ３２０７へ移
行する。ＳＴＥＰ３２０７ではそれがタイムアウトによ
るウェークアップかどうか判断する。データが登録され
た事によるウェークアップならばＳＴＥＰ３２１０へ分
岐し、登録データを返却して復帰する。ＳＴＥＰ３２０
７でタイムアウトによるウェークアップだったならＳＴ
ＥＰ３２０８で他に待ちタスクがなければシンボル項目
を削除し、ＳＴＥＰ３２０９でタイムアウトエラーを返
却して復帰する。

【０１００】図３３は図３２ＳＴＥＰ３２０３と図３１
ＳＴＥＰ３１０２の該当シンボル項目の検索を少し詳し
くしたものである。ＳＴＥＰ３３０１で該当シンボル項
目の検索を開始する。ＳＴＥＰ３３０２でシンボル文字
列からハッシュ値の算出を行う。ＳＴＥＰ３３０３でハ
ッシュ値に該当するデータのリストを検索する。もし、
該当項目がなければＳＴＥＰ３３０５へ分岐しＳＴＥＰ
３３０５でデータ不在コードを返却して復帰する。ＳＴ
ＥＰ３３０３で該当する項目があればＳＴＥＰ３３０４
へ分岐し、ＳＴＥＰ３３０４では項目へのポインタを返
却し、復帰する。

【０１０１】３．ＬｏｃｋＡｎｄＦｉｎｄＳｙｍｂｏｌ
シンボルシステムのロックと検索図３４はＬｏｃｋＡ
ｎｄＦｉｎｄＳｙｍｂｏｌファンクションのフローチャ
ートである。ＳＴＥＰ３４０１でＬｏｃｋＡｎｄＦｉｎ
ｄＳｙｍｂｏｌが開始される。ＳＴＥＰ３４０２でシン
ボルデータベースの排他ロックを行う。ＳＴＥＰ３４０
３で該当シンボルの検索を行うこれは、図３３で説明し
た関数である。もし、該当項目がなければＳＴＥＰ３４
０６へ分岐し、ＳＴＥＰ３００６でデータ無しのエラー
コードを返却して復帰する。ＳＴＥＰ３４０３で該当シ
ンボルがあった場合はＳＴＥＰ３４０４で有効なデータ
が格納されているのか、待ちタスクのハンドルが格納さ
れているのかを判断する。もし、ＳＴＥＰ３４０４で有
効なデータが格納されてなければ、ＳＴＥＰ３４０６で
データ無しを示すエラーコードと共に即時復帰する。Ｓ
ＴＥＰ３４０４で有効なデータがある場合はＳＴＥＰ３
４０５でデータを返却して復帰する。

【０１０２】メインパワーマネージャのＡＰＩ 図２７の様な動作をするメインパワーマネージャの動作
をフローチャートを使って説明する。アプリケーション
は電源の保証が必要になる直前にＬｏｃｋＭａｉｎＰｏ
ｗｅｒファンクションを呼び電源が落ちても良くなった
らＵｎＬｏｃｋＭａｉｎＰｏｗｅｒファンクションを呼
び出す。

【０１０３】１．ＬｏｃｋＭａｉｎＰｏｗｅｒ（パワー
のロック） 図３５はＬｏｃｋＭａｉｎＰｏｗｅｒのフローチャート
である。ＳＴＥＰ４００１でＬｏｃｋＭａｉｎＰｏｗｅ
ｒを開始する。ＳＴＥＰ４００１でセマフォを用いて共
有データの排他ロックを行う。ここでいう共有データと
はロックカウンタやカウントストップフラッグなどのメ
インパワーマネージャが内部で利用するデータの事であ
る。ＳＴＥＰ４００３でロックカウンタが０かどうかを
確かめる。もし、０ならオートシャットダウンタイムの
カウントをストップさせる。具体的にはカウントストッ
プフラグをＴＲＵＥにする。ＳＴＥＰ４００５でロック
カウンタをインクリメントする。ＳＴＥＰ４００６で共
有データのアンロックを行い、ＳＴＥＰ４００７で復帰
する。

【０１０４】２．パワーのアンロック 図３６はＵｎＬｏｃｋＭａｉｎＰｏｗｅｒのフローチャ
ートである。ＳＴＥＰ４１０１でＵｎＬｏｃｋＭａｉｎ
Ｐｏｗｅｒを開始する。ＳＴＥＰ４１０２でセマフォを
用いて共有データの排他ロックを行う。ＳＴＥＰ４１０
３でロックカウンタが１ならＳＴＥＰ４１０４へ分岐す
る。ＳＴＥＰ４１０４でオートシャットダウンタイムの
カウントを０にクリアしてカウントをスタートさせる。
具体的にはカウントストップフラグをＦＡＬＳＥにす
る。ＳＴＥＰ４１０５でロックカウンタのディクリメン
トを行い、ＳＴＥＰ４１０６で共有データをアンロック
する。ＳＴＥＰ４１０７で復帰する。

【０１０５】３．オートシャットダウンタイムのカウン
ト 図３７はオートシャットダウンタイムをカウントするタ
スクのフローチャートである。ＳＴＥＰ４２０１でタス
クを開始する。ＳＴＥＰ４２０２で共有データの排他ロ
ックを行う。ＳＴＥＰ４２０３でカウントストップフラ
グのチェックを行い、もしＴＲＵＥならばカウント動作
をスキップしてＳＴＥＰ４２０６へジャンプする。もし
ＦＡＬＳＥならＳＴＥＰ４２０４でカウンタをインクリ
メントする。ＳＴＥＰ４２０５でタイムアウト時間の設
定値と比較し、もし、タイムアウト時間と一致したらＳ
ＴＥＰ４２０７へ分岐する。ＳＴＥＰ４２０７ではシャ
ットダウンシーケンスを起動する。もしＳＴＥＰ４２０
５でタイムアウト時間と比較した結果が不一致ならＳＴ
ＥＰ４２０６へ進む。ＳＴＥＰ４２０６では共有データ
をアンロックする。ＳＴＥＰ４２０８で一定時間タスク
を休眠状態にした後ＳＴＥＰ４２０２へ戻る。以後ＳＴ
ＥＰ４２０２からＳＴＥＰ４２０８の間を繰り返す。

【０１０６】プログラムＲＯＭマネージャの動作 プログラムＲＯＭマネージャの動作をサービス毎にフロ
ーチャートを用いて説明する事にする。

【０１０７】１．モジュール名を指定してその番地を得
る 図３８はモジュール名からモジュールの番地を得る為の
ファンクションＦｉｎｄＭｏｄｕｌｅのフローチャート
である。ＳＴＥＰ５００１でＦｉｎｄＭｏｄｕｌｅを開
始し、ＳＴＥＰ５００２でモジュール検索の排他ロック
を行う。排他ロックにはセマフォなどを用いる。このタ
スクがモジュールを検索中に他のタスクがモジュールを
無効にしたり、追加すると動作に不具合が発生する為に
排他ロックを行うのである。ＳＴＥＰ５００３でモジュ
ールを検索する。ＳＴＥＰ５００３は図５１でさらに詳
しく解説を加える。ＳＴＥＰ５００４でモジュール検索
の排他ロックを解除し、ＳＴＥＰ５００５でＳＴＥＰ５
００３のリターン値である番地又はエラー値を返却す
る。

【０１０８】次に図３８ＳＴＥＰ５００３のモジュール
検索の手順を図３９を使って説明する。ＳＴＥＰ５１０
１でモジュール検索を開始する。ＳＴＥＰ５１０２でフ
ラッシュＲＯＭの先頭番地へポインタをセットする。こ
のポインタを進めながらモジュールを検索していくので
ある。次にＳＴＥＰ５１０３で、ポインタがポイントし
ているモジュールの使用済みフラグをチェックする。も
し、使用済みフラグがＴＲＵＥならＳＴＥＰ５１０７へ
分岐し、ＦＡＬＳＥならＳＴＥＰ５１０４へ移行する。
ＳＴＥＰ５１０４ではモジュール名が検索している名前
と一致するかどうかと同時に未使用領域かどうかを確か
める。もし、名前が不一致ならＳＴＥＰ５１０７へ分岐
する。つまり、使用済みフラグがＴＲＵＥか名前が不一
致ならＳＴＥＰ５１０７が実行される。ＳＴＥＰ５１０
７では次のモジュールの先頭番地を算出し、再び５１０
３へ戻る。こうして名前が不一致するか使用済みフラグ
がＴＲＵＥの間検索を続ける。ＳＴＥＰ５１０４で名前
が一致したらＳＴＥＰ５１０５でその番地を返却し、呼
び出し元へ復帰する。ＳＴＥＰ５１０４で未使用領域を
検出したら、ＳＴＥＰ５１０６へ分岐し、エラーを呼び
出し元へ返却して復帰する。

【０１０９】２．ファイル名を指定して追加書き込みを
行う 図４０はファイル名を指定して追加書き込みを行うＷｒ
ｉｔｅＭｄｕｌｅのフローチャートである。ＳＴＥＰ５
２０１でＷｒｉｔｅＭｄｕｌｅを開始する。ＳＴＥＰ５
２０２でモジュール検索の排他ロックを行う。ＳＴＥＰ
５２０３でモジュールの検索を行う。ここでのモジュー
ル検索は図３９で説明したサブルーチンをそのまま用い
る。もし、モジュールを発見する事ができればＳＴＥＰ
５２０４へ分岐し、図７の使用済みフラグへＴＲＵＥを
書き込む。そして、ＳＴＥＰ５２０３でモジュールを発
見出来なかった場合とＳＴＥＰ５２０４の後もＳＴＥＰ
５２０６へ分岐する。ＳＴＥＰ５２０６で空き領域の番
地を検索する。空き領域検索は、モジュールの検索と大
変類似しているので説明を省略する。もし、ＳＴＥＰ５
２０６で空き領域が不足している事が検出されたら、Ｓ
ＴＥＰ６２１０へ分岐し、モジュール検索の排他ロック
を解除してＳＴＥＰ６２１１で空き領域不足のエラーを
返却し復帰する。ＳＴＥＰ６２０２で空き領域番地が分
かった後にＳＴＥＰ５２０６でモジュールのロードとマ
ッピングを行う。ＳＴＥＰ５２０６でモジュールが書き
込まれる番地が確定するので、ファイルからプログラム
を主記憶へ取り込み、絶対アドレッシングされている部
分を実際の番地へ書き換え、実行可能な状態にする。そ
して、ＳＴＥＰ５２０７でそのプログラムを実際にフラ
ッシュＲＯＭへ書き込む。そして、ＳＴＥＰ５２０８で
モジュール検索の排他ロックを解除してＳＴＥＰ５２０
９でエラー無しのコードを返却して復帰する。

【０１１０】３．モジュール名を指定してそのモジュー
ルを無効にする 図４１はモジュール名を指定してモジュールを無効にす
るＫｉｌｌＭｏｄｕｌｅファンクションのフローチャー
トである。ＳＴＥＰ５３０１でＫｉｌｌＭｏｄｕｌｅを
開始する。ＳＴＥＰ５３０２でモジュール検索の排他ロ
ックを行い、ＳＴＥＰ５３０３でモジュールの検索を行
う。これは図５１で説明したルーチンである。モジュー
ルが発見されたらＳＴＥＰ５３０４へ分岐し、そのモジ
ュールの使用済みフラグ（図７参照）をＴＲＵＥにす
る。ＳＴＥＰ５３０３でモジュールが存在しなかった場
合と５３０４の後はＳＴＥＰ５３０５を実行する。ＳＴ
ＥＰ５３０５はモジュール検索の排他ロックの解除を行
い、ＳＴＥＰ５３０６で復帰する。

【０１１１】また、本発明は、前述した実施形態の機能
を実現するソフトウエアのプログラムコードを記録した
記憶媒体を、システムあるいは装置に供給し、そのシス
テムあるいは装置のコンピュータ（またはCPUやMPU）が
記憶媒体に格納されたプログラムコードを読み出し実行
することによっても、達成されることは言うまでもな
い。

【０１１２】この場合、記憶媒体から読み出されたプロ
グラムコード自体が本発明の新規な機能を実現すること
になり、そのプログラムコードを記憶した記憶媒体は本
発明を構成することになる。

【０１１３】プログラムコードを供給するための記憶媒
体としては、例えば、フロッピーディスク、ハードディ
スク、光ディスク、光磁気ディスク、CD―ROM、CD―R、
磁気テープ、不揮発性のメモリカード、ROMなどに用い
ることができる。

【０１１４】さらに、記憶媒体から読み出されたプログ
ラムコードが、コンピュータに挿入された機能拡張ボー
ドやコンピュータに接続された機能拡張ユニットに備わ
るメモリに書き込まれた後、そのプログラムコードの指
示に基づき、その機能拡張ボードや機能拡張ユニットに
備わるCPUなどが実際の処理の一部または全部を行い、
その処理によっても前述した実施形態の機能が実現され
得る。

【０１１５】尚、本発明は、前述した実施形態の機能を
実現するソフトウエアのプログラムコードを記録した記
憶媒体からそのプログラムをパソコン通信等通信インフ
ラを介して要求者にそのプログラムを配信する場合にも
適用できることは言うまでもない。

【０１１６】

【発明の効果】本発明により、機能の一部を追加ソフト
ウエアによって拡張することが可能となり、さらに、フ
ァームウエアのバージョンに依存しない追加ソフトウエ
アの開発が可能になった。

【図面の簡単な説明】

【図１】本発明を説明するブロック図

【図２】メモリマネージャの説明図

【図３】アロケーション動作の手順を説明する図

【図４】メモリブロックの説明図

【図５】メモリ開放動作の手順を説明する図

【図６】リセットアロケーションポインタの動作の手順
を説明する図

【図７】ROMに記憶されたプログラムの形式を説明する
図

【図８】モジュールの書換えを説明する図

【図９】アドレステーブルを説明する図

【図１０】ファイルフォーマットを示す図

【図１１】レコードタイプを説明する図

【図１２】プログラムファイルを説明する図

【図１３】レコードの形式を説明する図

【図１４】主記憶部に記憶された共有ライブラリの説明
図

【図１５】主記憶部とフラッシュROMに記憶された共有
ライブラリの説明図

【図１６】シンボル管理を説明する図

【図１７】シンボル管理システムの内部構造を説明する
図

【図１８】シンボル管理システムの内部構造を説明する
図

【図１９】共有データの初期化を行う動作の処理手順を
説明する図

【図２０】スタートアップシーケンスの処理手順を説明
する図

【図２１】スタートアップタスクの処理手順を説明する
図

【図２２】仮想IOポートのデータ構造を説明する図

【図２３】ビットセットファンクションの処理手順を説
明する図

【図２４】フック管理のデータ構造を説明する図

【図２５】フォーカスコントロールを説明する図

【図２６】フォーカスコントロールを説明する図

【図２７】フォーカス動作説明図

【図２８】FATALERRORの分類を示す図

【図２９】プログラムROMの一部をファイルの代わりに
する図

【図３０】AddSymbolの処理手順を示す図

【図３１】UnlockAndAddSymbolの処理手順を示す図

【図３２】シンボル検索ファンクションの処理手順を示
す図

【図３３】シンボル項目の検索の処理手順を示す図

【図３４】LockAndFindSymbolの処理手順を示す図

【図３５】LockMainPowerの処理手順を示す図

【図３６】UnlockMainPowerの処理手順を示す図

【図３７】オートシャットダウンタイムをカウントする
タスクの処理手順を示す図

【図３８】FindModuleの処理手順を示す図

【図３９】モジュール検索の処理手順を示す図

【図４０】WriteModuleの処理手順を示す図

【図４１】KillModuleの処理手順を示す図

【符号の説明】

１ レンズ ２ ＣＣＤユニット ３ Ａ／Ｄコンバータ ４ ＣＣＤとＡ／Ｄ変換器に同期信号を供給するＳＳＧ
ユニット ５ カメラシステムの中央演算器 ６ 信号処理を高速に実現するためのアクセラレータ ７ 電池 ８ システム全体へ電源を供給するためのＤＣ／ＤＣコ
ンバータ ９ ＤＣ／ＤＣコンバータをコントロールする電源コン
トローラユニット １０ パネル操作・表示装置・電源のコントロールを行
うマイクロコンピュータ １１ ユーザーへ情報を表示する表示装置 １２ ユーザーが直接操作するレリーズＳＷを含むコン
トロールパネル １３ ＯＳ等システムプログラムが入ったＲＯＭ １４ カメラシステムの主記憶であるＤＲＡＭ １５ 内臓記憶媒体として使用するフラッシュＲＯＭ １６ ＰＣＭＣＩＡカードのインターフェース部 １７ ＡＴＡハードディスクなどの外部記録媒体 １８ 拡張バスインターフェース １９ ＰＣ通信インターフェース ２０ ＤＭＡコントローラ ２１ ストロボ ２２ パーソナルコンピュータ

Claims (48)

【特許請求の範囲】
1. 【請求項１】Next Fit法によりメモリを管理し、且つ、
   メモリの断片化問題を軽減する為のファンクションを備
   えることを特徴とする情報処理装置。
2. 【請求項２】 前記メモリの断片化問題を軽減する為の
   ファンクションを少なくとも撮影動作前後に実行するこ
   とを特徴とする特許請求の範囲第１項に記載の情報処理
   装置。
3. 【請求項３】 前記メモリの断片化問題を軽減する為の
   ファンクションを少なくとも録音動作前後に実行するこ
   とを特徴とする特許請求の範囲第１項に記載の情報処理
   装置。
4. 【請求項４】 前記メモリの断片化問題を軽減する為の
   ファンクションを少なくとも消去動作前後に実行するこ
   とを特徴とする特許請求の範囲第１項に記載の情報処理
   装置。
5. 【請求項５】 電気的書き込み可能なフラッシュROM
   と、前記フラッシュROMの論理構造をマネージメントす
   るマネージメントソフトウエアモジュールを備え、前記
   マネージメントソフトウエアモジュールが実行可能なソ
   フトウエアモジュールを前記フラッシュROMの任意のア
   ドレスへマッピングし、書き込む機能と、前記フラッシ
   ュROM中にある任意のモジュールを検索し実行する機能
   を有することを特徴とする情報処理装置。
6. 【請求項６】 書き込まれたアドレスとは異なるアドレ
   スへのマッピングが可能なプログラムローダを有するこ
   とを特徴とする特許請求の範囲第５項に記載の情報処理
   装置。
7. 【請求項７】 実行可能なプログラムファイルの中から
   実行可能なレコードを選択し、ロードするプログラムロ
   ーダを備えることを特徴とする情報処理装置。
8. 【請求項８】 複数の異なるCPU或いは複数のプラット
   ホームに対して有効なレコードを有することを特徴とす
   る特許請求の範囲第７項に記載の情報処理装置。
9. 【請求項９】 プロセス間で共有データのバインディン
   グを行う情報処理装置であって、共有データの検索の結
   果、目的の共有データが登録されていない場合に、検索
   タスクを休眠状態へと移行させ、目的の共有データが登
   録された時に検索タスクを実行可能状態へ移すことを特
   徴とする情報処理装置。
10. 【請求項１０】 前記検索タスクが休眠状態に移行して
    から所定時間経過しても目的の共有データが登録されな
    かった場合にタイムアウトし、実行可能状態へ戻ること
    を特徴とする特許請求の範囲第９項に記載の情報処理装
    置。
11. 【請求項１１】 共有データの検索と登録を不可分な動
    作として行うことが可能なようにロック機構を有するこ
    とを特徴とする特許請求の範囲第９項に記載の情報処理
    装置。
12. 【請求項１２】 IOポートの特定の入力端子の状態によ
    ってスタートアップさせるタスクを切り替えるスタート
    アップルーチンを備えることを特徴とする情報処理装
    置。
13. 【請求項１３】 内蔵メモリの特定のファイル名の実行
    可能ファイルをスタートアップ時にロードし実行するこ
    とを特徴とする情報処理装置。
14. 【請求項１４】 前記実行可能ファイルの実行が終了し
    てから外部イベントに対応した動作を開始することを特
    徴とする特許請求の範囲第１３項に記載の情報処理装
    置。
15. 【請求項１５】 外部記憶媒体の挿入時に、特定のファ
    イル名のファイルが外部記憶媒体に存在すれば該ファイ
    ルを内蔵メモリへコピーし、前記外部記憶媒体の脱着に
    対応してコピーされたファイルを消去することを特徴と
    する情報処理装置。
16. 【請求項１６】 抽象化されたIOポートのサポートソフ
    トウエアとそれをコントロールするドライバーソフトウ
    エアに論理的に分離設計されていることを特徴とする情
    報処理装置。
17. 【請求項１７】 特定のイベントに対応した処理ルーチ
    ンとパラメータとを動的に複数登録可能なフック管理ソ
    フトウエアを備え、イベント発生時に登録されたサブル
    ーチンへパラメータを引き渡し実行することを特徴とす
    る情報処理装置。
18. 【請求項１８】 前記フック管理ソフトウエアを利用し
    たローバッテリー例外処理とシャットダウン処理を行う
    ことを特徴とする特許請求の範囲第１７項に記載の情報
    処理装置。
19. 【請求項１９】主電源を使用しているプログラムの数を
    カウントし、該カウントが０になってから任意の時間経
    過した後に主電源をオフすることを特徴とする情報処理
    装置。
20. 【請求項２０】 前記時間を動的に設定可能であること
    を特徴とする特許請求の範囲第１９項に記載の情報処理
    装置。
21. 【請求項２１】 シャットダウンの処理を少なくとも３
    つ以上の複数のレイアに分離して管理し、順次実行して
    いくことを特徴とする情報処理装置。
22. 【請求項２２】 複数のエラーを検出した場合に最初に
    検出したエラーの番号を優先的に表示することを特徴と
    する情報処理装置。
23. 【請求項２３】 複数のエラーを検出した場合に最も致
    命的なエラーに対するリカバリーを優先して実行するこ
    とを特徴とする情報処理装置。
24. 【請求項２４】 Next Fit法によりメモリを管理し、且
    つ、メモリの断片化問題を軽減する為のファンクション
    を備えることを特徴とする情報処理方法。
25. 【請求項２５】 前記メモリの断片化問題を軽減する為
    のファンクションを少なくとも撮影動作前後に実行する
    ことを特徴とする特許請求の範囲第２４項に記載の情報
    処理方法。
26. 【請求項２６】 前記メモリの断片化問題を軽減する為
    のファンクションを少なくとも録音動作前後に実行する
    ことを特徴とする特許請求の範囲第２４項に記載の情報
    処理方法。
27. 【請求項２７】前記メモリの断片化問題を軽減する為の
    ファンクションを少なくとも消去動作前後に実行するこ
    とを特徴とする特許請求の範囲第２４項に記載の情報処
    理方法。
28. 【請求項２８】 実行可能なプログラムファイルの中か
    ら実行可能なレコードを選択し、ロードすることを特徴
    とする情報処理方法。
29. 【請求項２９】 複数の異なるCPU或いは複数のプラッ
    トホームに対して有効なレコードを有することを特徴と
    する特許請求の範囲第２８項に記載の情報処理方法。
30. 【請求項３０】 プロセス間で共有データのバインディ
    ングを行う情報処理装置の情報処理方法であって、共有
    データの検索の結果、目的の共有データが登録されてい
    ない場合に、検索タスクを休眠状態へと移行させ、目的
    の共有データが登録された時に検索タスクを実行可能状
    態へ移すことを特徴とする情報処理方法。
31. 【請求項３１】 前記検索タスクが休眠状態に移行して
    から所定時間経過しても目的の共有データが登録されな
    かった場合にタイムアウトし、実行可能状態へ戻ること
    を特徴とする特許請求の範囲第３０項に記載の情報処理
    方法。
32. 【請求項３２】 共有データの検索と登録を不可分な動
    作として行うことが可能なようにロック機構を有するこ
    とを特徴とする特許請求の範囲第３０項に記載の情報処
    理方法。
33. 【請求項３３】 IOポートの特定の入力端子の状態によ
    ってスタートアップさせるタスクを切り替えるスタート
    アップルーチンを備えることを特徴とする情報処理方
    法。
34. 【請求項３４】 内蔵メモリの特定のファイル名の実行
    可能ファイルをスタートアップ時にロードし実行するこ
    とを特徴とする情報処理方法。
35. 【請求項３５】 前記実行可能ファイルの実行が終了し
    てから外部イベントに対応した動作を開始することを特
    徴とする特許請求の範囲第３４項に記載の情報処理方
    法。
36. 【請求項３６】 外部記憶媒体の挿入時に、特定のファ
    イル名のファイルが外部記憶媒体に存在すれば該ファイ
    ルを内蔵メモリへコピーし、前記外部記憶媒体の脱着に
    対応してコピーされたファイルを消去することを特徴と
    する情報処理方法。
37. 【請求項３７】 抽象化されたIOポートのサポートソフ
    トウエアとそれをコントロールするドライバーソフトウ
    エアに論理的に分離設計されていることを特徴とする情
    報処理方法。
38. 【請求項３８】 特定のイベントに対応した処理ルーチ
    ンとパラメータとを動的に複数登録可能なフック管理ソ
    フトウエアを備え、イベント発生時に登録されたサブル
    ーチンへパラメータを引き渡し実行することを特徴とす
    る情報処理方法。
39. 【請求項３９】 前記フック管理ソフトウエアを利用し
    たローバッテリー例外処理とシャットダウン処理を行う
    ことを特徴とする特許請求の範囲第３８項に記載の情報
    処理方法。
40. 【請求項４０】 主電源を使用しているプログラムの数
    をカウントし、該カウントが０になってから任意の時間
    経過した後に主電源をオフすることを特徴とする情報処
    理方法。
41. 【請求項４１】 前記時間を動的に設定可能であること
    を特徴とする特許請求の範囲第４０項に記載の情報処理
    方法。
42. 【請求項４２】 シャットダウンの処理を少なくとも３
    つ以上の複数のレイアに分離して管理し、順次実行して
    いくことを特徴とする情報処理方法。
43. 【請求項４３】 複数のエラーを検出した場合に最初に
    検出したエラーの番号を優先的に表示することを特徴と
    する情報処理方法。
44. 【請求項４４】 複数のエラーを検出した場合に最も致
    命的なエラーに対するリカバリーを優先して実行するこ
    とを特徴とする情報処理方法。
45. 【請求項４５】 Next Fit法によりメモリを管理し、且
    つ、メモリの断片化問題を軽減する為のファンクション
    を備えることを特徴とするオペレーティングシステム。
46. 【請求項４６】 主電源を使用しているプログラムの数
    をカウントし、該カウントが０になってから任意の時間
    経過した後に主電源をオフすることを特徴とするオペレ
    ーティングシステム。
47. 【請求項４７】 Next Fit法によりメモリを管理し、且
    つ、メモリの断片化問題を軽減する為のファンクション
    を有することを特徴とする記憶媒体。
48. 【請求項４８】 主電源を使用しているプログラムの数
    をカウントし、該カウントが０になってから任意の時間
    経過した後に主電源をオフする工程を有することを特徴
    とする記憶媒体。