JP3832933B2 - Information processing apparatus and method, operating system, and storage medium - Google Patents
Information processing apparatus and method, operating system, and storage medium Download PDFInfo
- Publication number
- JP3832933B2 JP3832933B2 JP18973497A JP18973497A JP3832933B2 JP 3832933 B2 JP3832933 B2 JP 3832933B2 JP 18973497 A JP18973497 A JP 18973497A JP 18973497 A JP18973497 A JP 18973497A JP 3832933 B2 JP3832933 B2 JP 3832933B2
- Authority
- JP
- Japan
- Prior art keywords
- memory
- program
- symbol
- module
- function
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Description
【０００１】
【発明の属する技術分野】
本発明は、任意の機能を後から追加可能な情報処理装置およびその方法に関するものである。
【０００２】
【従来の技術】
従来のカメラシステムでは、メモリの利用目的とアドレスの関係はコンパイル＆リンク時に決定するのが一般的である。したがって、メモリマネージャそのものが搭載されていなかった。メモリマネージャを搭載して、ダイナミックにアロケーションするカメラシステムと従来のシステムを比較すると以下の様な特徴がある。
【０００３】
メモリマネージャを搭載しない場合、追加プログラムが利用するメモリは、あらかじめ予約しておく必要がある。カメラのＲＯＭのバージョンとメモリの配置が強く依存しているので、互換性を確保する為には追加プログラム用の予約領域は少なめに設定する必要がある。一方、メモリマネージャを利用する場合は、同時に利用するメモリの最大量が物理的なメモリ容量を越えない様に注意するだけで良いので、メモリを最大限利用可能である。仮想記憶のシステムが無い場合のメモリマネージメント手法は、大別してビットマップを利用したもの、メモリ管理ブロックによって可変長のメモリを分割して利用するものがある。ビットマップを利用する方法は、要求されたサイズの空きメモリを検索するのに時間がかかる為、実際のコンピュータシステムでもあまり利用されていない。可変長のメモリを分割して利用する場合はさらに、Best Fit法,First Fit法,Next Fit法の３つが良く知られている。Best Fit法は大きな連続領域がいつも確保されるという特徴があるが、メモリブロックの数に比例してアロケーションスピードが遅くなる。First Fit法も同様の性質がある。Next Fit法は、ブロックの数に依存せず、常に高速にアロケーションを行う事が可能であるが、ストレスをかけると空きメモリが断片化していくという欠点がある。デジタルカメラで画像処理を行う場合１画面分の画像を千ブロック程度に分割して処理を行う為、アロケーション速度が遅ければカメラの処理スピードに致命的な結果を及ぼす。また、デジタルカメラは従来のフィルムを使ったカメラと違い、大容量ハードディスクとＡＣ電源を使えばシャッターの耐久回数である数万ショットを連続撮影する事が可能なのでメモリの断片化によるアロケーションの失敗は許されない。Next Fit法のアロケーションのしくみとメモリの断片化(ｆｒａｇｍｅｎｔａｔｉｏｎ)についてさらに説明を加える。図２は▲１▼はNext Fitメモリマネージャの初期状態である。主記憶は１つの空きメモリブロックとして管理し、アロケーションポインタがその先頭にセットされている。ここでいうブロックとは図４の様な情報を含む。ブロックの大きさと、そのブロックが空きメモリか使用中かを示すフラグとユーザアプリケーションが利用する部分である。すべてのメモリを４バイトアライメント上に配置しようとした場合ブロックサイズは４の倍数で良いので余った最下位ビットを使用中フラグとして利用出来る。次のブロックの先頭位置を知る為にもブロックサイズは利用される。ブロックサイズや使用中フラグなどの情報を格納している部分はＭＣＢ（メモリーコントロールブロック）と呼ばれる。
【０００４】
▲２▼はアプリケーションからメモリＡを要求され、割り当てた状態である。１つの空きブロックと１つの使用中メモリの2ブロックに分割され、アロケーションポインタは分割された空きメモリの先頭にセットされる。図２の▲３▼はさらにアプリケーションからメモリＢを要求され、割り当てた状態である。空きメモリをさらにメモリＢの為に分割し、主記憶は３つのブロックに分割された。図２の▲４▼でメモリＡが不要になり開放を行った。メモリＡは空きブロックに変わったが、アロケーションポインタの位置は更新されない。図２の▲５▼でメモリＣを要求されるが、メモリＡが以前存在していた位置は利用しない。要求されたメモリサイズがアロケーションポインタが示している空きメモリより大きい場合に限ってアロケーションポインタの位置から空きメモリの検索が始まる。要求されたサイズより大きな空きメモリを発見したら、そのブロックを分割して割り当てる。その様にメモリのアロケーションと開放を繰り返し続けると、図２の▲６▼のような状態になる。図２の▲６▼は空きメモリの総量は要求されたメモリＢの大きさより大きいが最大連続領域サイズがメモリＢよりも小さくなってしまった為に割り当てに失敗してしまう様子である。この事から、Nest Fit法を利用する場合は無限にアロケーションと開放を繰り返す様なアプリケーションでの利用は困難であった。
【０００５】
【発明が解決しようとする課題】
本発明のメモリマネージャは、この様な問題を著しく軽減するファンクションを定義し、アプリケーションがそのファンクションを利用する事でデジタルカメラの様な分野で利用する事を可能にする。断片化が発生した後でメモリの再配置を行えば再び最大連続領域サイズは増える。しかし、稼動中のシステムでメモリの再配置を行えばメモリ転送に多くのＣＰＵ時間を費やす事になる。カメラシステムを構成するうえで断片化を回避するとすれば、一定期間ごとに必ずシステムをリスタートするという手段をとる事も可能である。しかし、前途の様に連続動作はデジタルカメラの重要なスペックである。システムをリスタートする事をあきらめたとしても、システムとしては、メモリの消費量が極端に少なくなるタイミングがあり、それを利用する事が可能である。必ずあるタイミングでメモリの消費量が極端に少なくなるのであればそのタイミングでアロケーションポインタを主記憶の先頭へ移動させる事でメモリマネージャのリスタートに限りなく近い状態をつくりだす事が可能である有があるが、パーソナルコンピュータの技術革新サイクルは早く、新しい画像フォーマットが次々に登場している。デジタルカメラの内部構造もコンピュータ化が進み、ソフトウェアによる処理の範囲も広がってきている。そこで、デジタルカメラもパーソナルコンピュータの様にソフトウェアを追加し、拡張していく事でハードウェア開発の投資を押さえて早い技術革新サイクルに追従していく事が可能である。しかし、デジタルカメラのソフトウェアは通信やファイルシステムなど多岐にわたっており、どの機能が将来必要になるのか、どの技術が陳腐化するのかをあらかじめ予測する事は難しい。また、さまざまなロットのデジタルカメラが市場に出るが、追加拡張ソフトウェアはどのロットの内部ソフトウェアとも共存する様に設計する必要がある。本発明はデジタルカメラの任意の機能を後から追加するソフトウェアによって置き換え、拡張する技術に関するものである。
【０００６】
【課題を解決するための手段】
上記課題を解決するために、本発明によれば、情報処理装置に、メモリのポインタから探索を開始して、要求されたサイズの空ブロックが最初に見つかった領域から当該空ブロックを割り当てる割当手段と、該割当手段による割当後に前記ポインタを当該割り当てられたブロックの直後の位置に更新する更新手段と、所定動作の実行後に発せられるアプリケーションからの要求に応じて、前記ポインタを前記メモリの先頭位置へ初期化する初期化手段とを備える。
【０００７】
また、他の態様によれば、情報処理方法に、メモリのポインタから探索を開始して、要求されたサイズの空ブロックが最初に見つかった領域から当該空ブロックを割り当てる割当工程と、該割当工程による割当後に前記ポインタを当該割り当てられたブロックの直後の位置に更新する更新工程と、所定動作の実行後に発せられるアプリケーションからの要求に応じて、前記ポインタを前記メモリの先頭位置へ初期化する初期化工程とを備える。
【００３５】
【発明の実施の形態】
図１は本発明の第一の実施例のブロック図である。１はレンズ、２はレンズを通った光を電気信号として出力するＣＣＤユニットである。３はＣＣＤからのアナログ信号をデジタル信号へ変換するＡ／Ｄコンバータ、４はＣＣＤとＡ／Ｄ変換器に同期信号を供給するＳＳＧユニット、５はカメラシステムの中央演算器、６は信号処理を高速に実現するためのアクセラレータ、７は電池、８はシステム全体へ電源を供給するためのＤＣ／ＤＣコンバータ、９はＤＣ／ＤＣコンバータをコントロールする電源コントローラユニット、１０はパネル操作・表示装置・電源のコントロールを行うマイクロコンピュータ、１１はユーザーへ情報を表示する表示装置、１２はユーザーが直接操作するレリーズＳＷを含むコントロールパネル、１３はＯＳ等システムプログラムが記憶され、具体的には、図面に記述し、また後述する動作手順を中央演算器５により読み込まれ実行されるプログラムが記憶されている記憶媒体のＲＯＭ、１４はカメラシステムの主記憶で、データや後述する動作手順が記憶され、中央演算器５により手順が読み込まれ実行されるプログラムも記憶される記憶装置のＤＲＡＭ、１５は内臓記憶媒体として使用し、データや動作手順が記憶され中央演算器５により読み込まれ実行されるフラッシュＲＯＭ、１６はＰＣＭＣＩＡカードのインターフェース部、１７はＡＴＡハードディスクなどの外部記録媒体、１８は拡張バスインターフェース、１９はＰＣ通信インターフェース、２０はＤＭＡコントローラ、２１はストロボ、２２はパーソナルコンピュータである。
【００３６】
このカメラの撮影時の動作を簡単に説明する。図１のコントロールパネル１２のレリーズスイッチをユーザが押したら、図１のＣＰＵ５がその事を検出して撮影シーケンスを開始する。以下の動作はすべて図１のＣＰＵ５によるコントロールで行われる事を前提とし、その説明を省略する。図１のＳＳＧ４が図１のＣＣＤ２を駆動する。図１のＣＣＤ２から出力されるアナログ信号は、図１のＡ／Ｄコンバータ３でデジタル信号へ変換される。図１のＤＭＡコントローラ２０によって図１のＡ／Ｄコンバータ３の出力は、図１のＤＲＡＭ４へＤＭＡ転送される。１フレーム分のＤＭＡ転送が終了した時点でＣＰＵ５は、信号処理シーケンスを開始する。図１のフラッシュＲＯＭ１５から信号処理プログラムを主記憶上に記憶して、それを逐次読みだして実行する。主記憶上のデータを信号処理アクセラレータ６へ転送し信号処理をおこなう。信号処理アクセラレータ６は信号処理のすべてをおこなうわけではなく図１のＣＰＵ５で行う処理の特に時間のかかる処理などを助ける演算回路であり、図１のＣＰＵ５の処理ソフトウェアと連携して動作する。信号処理の一部または全部が終了すると画像ファイルとして外部記憶媒体１７へ記録する。また、カードインターフェースに外部記憶媒体１７が接続されていない場合、フラッシュＲＯＭ１５へ記録する。この時記録するファイルフォーマットが圧縮処理を必要とするのであれば圧縮も行う。第一の実施例は、以上のように撮影画像を外部記憶媒体、もしくはフラッシュＲＯＭへファイルする電子カメラである。
【００３７】
本発明のメモリマネージャはアロケーションポインタを主記憶の先頭へ移動させるファンクションResetAllocationPointerを実装している。アプリケーションがResetAllocationPointerファンクションを頻繁に呼び出せば、呼び出すほどメモリマネージャはFirst Fit法に近い動きをする事になる。毎回アロケーションの前にResetAllocationPointerファンクションを呼び出すともはやNext Fit法ではなく完全なFirst Fit法となり、アロケーションにかかる時間はメモリの消費量に比例して増加してしまう。ResetAllocationPointerファンクションの目的はあまでもメモリマネージャをリスタート後に近い状態にする事である。デジタルカメラのシステムはこのファンクションを一回の撮影動作直後、録音動作直後、モード設定直後などのタイミングで呼び出す。上記の様に構成する事で高速なアロケーションと連続動作耐久性の両方の特徴を備えたシステムを構築する事が可能である。
【００３８】
図３はこのメモリーマネージャのアロケーション動作のフローチャートである。このフローチャートにしたがって、アロケーション動作を説明する。ステップ３０１で要求サイズを切り上げる。アプリケーションプログラムが要求するメモリサイズの単位は１バイト単位だが、メモリマネージャが管理する単位はそれよりも大きい。メモリマネージャがＭＣＢと呼ばれる管理情報を先頭に作成する為、に４バイトアライメント単位に乗せる必要があるからである。ステップ３０２でメモリマネージャのセマフォを獲得する。あるタスクがアロケーションや開放動作をしている時に別のタスクがアロケーションなどをすると二重アロケーションやＭＣＢの破壊を引き起こす結果となるからである。かといって割り込みを禁止してしまえば、ストロボやシャッターを制御するデジタルカメラとしての制御のレスポンスに影響を与えてしまう為、セマフォによって排他制御を行う。この様な方法で排他制御をする事によってメモリマネージャの動作が他のプライオリティの高いタスクの動作に影響を与える心配がなくなる。ステップ３０３で現在のアロケーションポインタの位置をアロケーションスタート位置として記憶する。このポインタの働きは後で説明する。ステップ３０４で現在のアロケーションポインタ位置の空きブロックのサイズと比較する。要求サイズの方が大きい場合ステップ３０５へ、要求サイズと空きブロックサイズが一致すればステップ３０３へ、要求さサイズの方が小さい場合ステップ３１２へと制御を移す。ステップ３０５へ進んだ場合それが最終ブロックかどうかを判断する。最終ブロックならステップ３０７へ、そうでなければステップ３０６へ分岐する。ステップ３０６では次のメモリブロックへアロケーションポインタを進める。ステップ３０７ではアロケーションポインタを主記憶の先頭のブロックへセットする。ステップ３０６と３０７はどちらも次のブロックへ進めるという効果がある。ステップ３０８ではステップ３０３で記憶したアロケーションスタート位置とアロケーションポインタを比較している。もし、一致すればすべてのメモリブロックをスキャンした事の証明となるので、アロケーションに失敗したことになる。その場合ステップ３１６でセマフォを開放し、ステップ３１７でメモリ獲得に失敗した事を告げるエラー値を返却してアプリケーションへ制御を戻す。ステップ３０８でアロケーションスタート位置と一致しない場合はステップ３０９でアロケーションポインタ位置のブロックが空きブロックかどうか判断する。
【００３９】
使用中ブロックの場合はステップ３０５へ戻る。そうでないならステップ３１１へ進む。ステップ３１１では次のブロックが空きブロックかどうかを判断する。もし、空きブロックならステップ３１０へ分岐。次のブロックが空きブロックでないならステップ３０４へ戻り、再び要求サイズとの比較を試みる。ステップ３１０では次のブロックと現在のアロケーションポインタ位置のブロックの２つのブロックをマージして１つの大きなメモリにする。そして再びステップ３１１へ戻る。この動作を繰り返す事で連続した空きブロックをすべてマージする。ステップ３０４で要求ブロックサイズと現在のアロケーションポインタ位置のメモリサイズが一致したらステップ３１３で現在のアロケーションポインタ位置のブロックを使用中メモリに変更し、それを今回の獲得メモリとし、アロケーションポインタを次のブロックへ進める。ステップ３０４で要求サイズより現在のアロケーションポインタ位置の空きブロックサイズのほうが大きい場合はステップ３１２で要求サイズの空きブロックと残ったサイズの空きメモリの２つの空きメモリへ分割し、ステップ３１３へ進む。ステップ３１４でセマフォを開放し、ステップ３１５で獲得したメモリの先頭番地をアプリケーションプログラムへ返却して制御を戻す。図５はメモリマネージャのメモリ開放動作のフローチャートである。ステップ５０１でメモリマネージャのセマフォを獲得し、ステップ５０２で指定されたブロックが使用中かどうかを判断する。もし、使用中でなければステップ５０４でセマフォを開放し、ステップ５０６で開放が失敗したというエラーコードを返却してアプリケーションへ制御を戻す。ステップ５０２で指定されたブロックが使用中なら、ステップ５０３で、そのブロックを空きブロックへ変更し、ステップ５０４でセマフォを開放して、ステップ５０５で開放に成功したというリターンコードを返却してアプリケーションへ制御を戻す。図６はResetAllocationPointer動作のフローチャートである。ステップ６０１でセマフォを獲得し、ステップ６０２でアロケーションポインタを主記憶の先頭のブロックへ移動。ステップ６０３でセマフォを開放する。
【００４０】
プログラムＲＯＭマネージャ
デジタルカメラは撮影した画像をコンピュータの理解出来るファイル形式で格納する。一方、コンピュータの画像ファイルの種類は非常に多くすべてをサポートする事は不可能であり、新しい画像フォーマットが次々に登場している。この様な状況で、カメラ内部のソフトウェアに後から機能を追加したり、変更を加える技術が重要になってきている。
【００４１】
図１のフラッシュＲＯＭ１５の一部はこのデジタルカメラのファームウェアを格納するために利用する。プログラムの一部を修正したり、追加する事が可能であれば、ファームウェア開発や、カメラファームウェアのバージョンアップに便利である。これから説明するプログラムＲＯＭマネージャはこの様なフラッシュＲＯＭに書き込まれたプログラムを管理する機能である。
【００４２】
図７はフラッシュＲＯＭの中に格納されたプログラムの形式を図にしたものである。
【００４３】
格納されているプログラムはモジュール単位で管理され、モジュールの先頭にはＭＨ（モジュールヘッダ）と呼ばれる管理ブロックがある。モジュールヘッダにはモジュール名やプログラムのエントリーポイントなどの情報が格納されている。フラッシュＲＯＭはバイト単位での消去が出来ないので、一部のモジュールの変更を行う場合も追加書き込みをするしかない。
【００４４】
モジュールの書き換え
モジュールは以下の様にフラッシュＲＯＭの前から書き込まれる。モジュールの消去は、そのモジュールを無効にする事によって実現している。モジュールの置き換えは、一旦モジュールを消去して新しくモジュールを書き込む事で実現している。図８の左は、フラッシュＲＯＭに複数のモジュールが存在する様子である。図８の右は、モジュールＡを新しく書き換えた後の状態である。元のモジュールＡが使用済みモジュールとなり新しいモジュールＡが未使用領域だった場所へ書き込まれている。
【００４５】
プログラムＲＯＭマネージャのサービスは以下の様になる。
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またはUnlockSymbolは、検索と登録までの期間の排他制御を実現するファンクションである。
【００６７】
LockAndFindSymbolを実行してからUnlockAndAddSymbolまたはUnlockSymbolを実行するまでの期間シンボルのシステムを独占し、他のタスクによるシンボル操作（検索、登録）が行われない事を保証する。図１９は、このファンクションを使って共有データの初期化を行うプログラムの動作をフローチャートにしたものである。ステップ１９０１でLockAndFindSymbolを実行し、シンボルシステムのロックと検索を行う。検索の結果、シンボルが発見されれば、ステップ１９０２へ分岐し、シンボルが無ければ１９９３へ分岐する。LockAndFindSymbolは現時点でのシンボルの存在を確認し、シンボルが登録されていない場合は即時復帰する。待ち状態にならないので、タイムアウト時間を指定するパラメータは無い。ステップ１９０１でLockAndFindSymbolを実行し、検索の結果、シンボルが発見されれば、ステップ１９０２へ分岐し、１９０２でシンボルシステムのロックを解除する。ステップ１９０１でLockAndFindSymbolを実行し、検索の結果、シンボルが発見されなかった場合、ステップ１９０３で共有データ用のメモリをアロケーションする。そしてステップ１９０４でセマフォを０に初期化する。そして、ステップ１９０５でUnlockAndAddSymbolファンクションを使い、シンボルのアンロックと共有データの公開を行う。共有データの初期化はまだ不完全だが、セマフォを０に初期化しているので、別のタスクがセマフォを獲得しようとしても待ち状態に遷移するので問題ない。共有データの初期化すべてを行うまでシンボルシステムをロックしてしまうと、自タスクよりプライオリティの高い他タスクのバインディングの遅延につながる。したがって、シンボルのロック期間は短ければ短いほど良い。図１９の点線で囲んである部分はシンボルのシステムを独占している期間である。ステップ１９０６で共有データの初期化を済ませ、ステップ１９０７で共有データのセマフォを開放する。この時点で他のタスクからこの共有データが利用可能になる。LockAndFindSymbolの動作はFindSymbolの動作に非常に良く似ている。FindSymbolとの違いは、シンボルが存在しない場合に即時復帰する事とシンボルのセマフォを返却せずに復帰する点である。UnlockSymbolはシンボルシステムのセマフォを返却するだけのファンクションである。UnlockAndAddSymbolもAddSymbolと良く似ている。シンボルシステムのセマフォを獲得している事を前提にしているので、セマフォの獲得をしない点でAddSymbolと異なる。
【００６８】
次にこのカメラのスタートアップ方法を説明する。
【００６９】
カーネルのスタートアップ
図１の５のＣＰＵの電源が投入され、リセットが解除されると、図１の５のＣＰＵは図１の１３のＲＯＭのリセット後のエントリポイントから実行を始める。図１の１３のＲＯＭにはリアルタイムオペレーティングシステムなどの基本機能だけが搭載されている。オペレーティングシステムそのものをバージョンアップする事を可能にする為に図１の１３のＲＯＭのプログラムはオペレーティングシステムをスタートする前に図１の１５のフラッシュＲＯＭへジャンプするようになっている。図１の１５のフラッシュＲＯＭが手違いや事故によって書き換わってしまった場合に暴走してしまう危険があるので、図１の１５のフラッシュＲＯＭの別の特定番地にはキーワードが格納されており、キーワードが一致した場合のみフラッシュＲＯＭへジャンプする。キーワードが一致するが、フラッシュＲＯＭのプログラムにバグがあったり、事故で一部の書き込みに失敗した場合も、やはり暴走する。書き込みの失敗に関しては、プログラムの書き込みとベリファイが終了してからキーワードを書く様に構成する事で回避可能であるが、プログラムのバグによって暴走する場合は防ぎようがない。この様な問題は主に開発段階で発生するので、特別なハードウェアを使って回避するのが、実装もデバッグもはるかに簡単である。特別なハードウェアといってもＩＯポートの特定のビットを電源側へプルアップしたり、グランドへプルダウンするだけで良い。本実施例では図１の１９のＰＣインターフェースの製品ではプルアップされているポートをグランドへショートする事でメンテナンスモードである事をカメラへ伝える。もし、スタートアップ時にメンテナンスモードである事を検出すると、たとえキーワードが一致してもフラッシュＲＯＭのプログラムは一切実行せず、図１の１３のＲＯＭのプログラムだけで動作し、フラッシュＲＯＭのオペレーションなどを行うモードとなる。特定のハードウェアを用意する必要があるので、この機能が市場でトラブルを起こす心配はまったくない。図２０は本実施例のスタートアップシーケンスのフローチャートである。ステップ２００１でリセットが解除されると、ＣＰＵはＲＯＭの特定番地を読み出して、そこから実行を始める。ステップ２００２でＢＵＳのタイミングなど必要最低限のハードウェアの設定を済ませる。ステップ２００４で、メンテナンスモードかどうかを判断する。本実施例では図１の１９のＰＣインターフェースの製品ではプルアップされているポートがグランドへショートされているかどうかを判断する。もし、メンテナンスモードならステップ２００６へ分岐する。ステップ２００６ではリアルタイムＯＳのカーネル、メモリマネージャ、シンボル管理、プログラムＲＯＭマネージャを初期化しスタートさせる。そして、ステップ２００７でフラッシュＲＯＭオペレーション用のプログラムのスタートアップタスクを実行する。スタートアップタスクは、必要なタスク類のテーブルをもっており、順次タスクを作成し、実行させる。
【００７０】
ステップ２００３でメンテナンスモードでなかった場合、ステップ２００４へ分岐する。ステップ２００４でフラッシュＲＯＭの特定番地のキーワードをチェックする。キーワードは、プログラムＲＯＭマネージャが管理していない領域を予約する方法もあるが、フラッシュＲＯＭの最後の番地にしておけば、この機能を使わない時に通常のプログラムを格納する事も可能となる。そして、キーワードチェックの結果キーワードが一致すればステップ２００５へ分岐する。ステップ２００５では、フラッシュＲＯＭへジャンプしてしまうので、オペレーティングシステムそのものを置き換える様なプログラムやハードウェア設定の追加などのプログラムを用意する事が可能である。ステップ２００４でキーワードが一致しなかったらステップ２００８へ分岐する。ステップ２００８の処理内容はステップ２００６とまったく同じである。そしてステップ２００９ではプログラムＲＯＭマネージャの機能を使って、デジタルカメラのスタートアップタスクを検索し、実行する。
【００７１】
デジタルカメラのスタートアップ
デジタルカメラとしての重要な機能はステップ２００９でスタートする。図２０のステップ２００９のスタートアップタスクの動作を図１のフローチャートで示した。スタートアップタスクはモジュール名のテーブルをもっており、そのテーブルにしたがって、プログラムＲＯＭマネージャ経由でモジュールを検索し、順次タスクを作成していく。図２１はそのテーブルの順番をおおざっぱにグループわけして表現している。
【００７２】
ステップ２１０１でデバッグ用のプログラムをスタートする。ウォッチドッグやイリーガルオペコードトラップなどの製品としての異常検出を目的としたものからログ（経歴）サービスなどの開発時のみに利用するものも含む。ステップ２１０２ではハードウェアの初期化を行う。仮想化されたハードウェアのドライバを用意するのもこの時点で行う。また、ローバッテリー例外処理や、シャットダウンのフックもステップ２１０２で初期化し、公開する。
【００７３】
ステップ２１０３でファイルシステムの初期化と内蔵フラッシュＲＯＭＤＩＳＫドライバーの初期化とファイルシステムのマウントを行う。
【００７４】
ステップ２１０４は工場調整値データのデータベースサービスをスタートとカメラステータスデータベースをスタートする。この時、ステップ２１０３で初期化したファイルシステムを用いて内蔵フラッシュＲＯＭＤＩＳＫの工場調整値データのファイルをオープンし、工場の調整値データを読み出す。カメラステータス情報のデータファイルも同様にオープンし、データを読み出す。カメラステータスデータとは、現在の圧縮率やストロボ使用のＯＮ・ＯＦＦ、ＤＩＳＫの残り空き容量などの情報が格納されている。
【００７５】
ステップ２１０５でその他のデバイスドライバーの公開（登録）をするだけのタスクを起動する。デジタルカメラのデバイスドライバは、パーソナルコンピュータでよく知られているもの以外に、ＣＣＤデバイス、ＪＰＥＧデバイス、信号処理アクセラレータデバイス、測光デバイス、測色デバイス、フォーカスコントロールデバイス、などデジタルカメラのハードウェアに依存した特徴を隠蔽するためのものが多数含まれる。この時点ではデバイスドライバのエントリーポイントをシンボルとして公開するだけである。ステップ２１０６で内蔵ＲＯＭＤＩＳＫの中に特定のファイル名を持った実行可能ファイルが存在していれば主記憶にロードして実行する。内蔵ＲＯＭＤＩＳＫの中のプログラムを実行可能にしておく事で、プログラムＲＯＭマネージャの管理するフラッシュＲＯＭへの書き込みをする事なくカメラの機能を拡張する事が出来る。内蔵ＲＯＭＤＩＳＫのプログラムがステップ２１０５で公開されたデバイスドライバーと同じ名前のドライバーを公開する事で、その機能を完全に置き換える事が可能になる。ステップ２１０８でバッテリーチェックシステムをスタートさせ、２１０８でパワーロックのサービスをスタートさせる。ステップ２１０９でコントロールパネルをスタートさせる。コントロールパネルによってボタンが押された情報はこの時点で伝達され、撮影などの動作にはいる。デバイスドライバがバインディングされるのはステップ２１０９の後である。シンボルの書き換えによるモジュールの置き換えはステップ２１０９よりも前でなければならない。
【００７６】
実行ファイル
内蔵のフラッシュＲＯＭにプログラムを追加する場合、追加書き込みをする未使用領域が無くなってしまうと、一旦すべてのプログラムを消去しなければならない。より多くのアプリケーションに対応する為に、外部記憶媒体に追加プログラムを書き込む様にしたい。
【００７７】
外部記憶媒体の追加プログラムをデジタルカメラがスタートアップ時に読み出す様に構成した場合、デジタルカメラのスタートアップ時間が外部記憶媒体のスタートアップ時間に大きく依存してしまう。デジタルカメラのスタートアップはユーザが操作部のキーへ触れた時から始まる。ユーザが操作部のキーへ触れてから約２００ミリ秒ほどの期間はコントロールパネル部でチャタリングの除去の為のタイムラグがある。その時間の間にスタートアップが終了しなければ、ユーザーからの操作に対しての反応が遅くなり、操作感が悪くなる。それに対しハードディスクのスタートアップは７秒〜十数秒かかる。その事から外部記憶媒体から直接追加プログラムをロードする事は不可能である。本発明では、外部記憶媒体をデジタルカメラへ挿入したタイミングで自動実行ファイルが外部記憶媒体に存在すれば、それを内蔵ＲＯＭＤＩＳＫへコピーし、外部記憶媒体がデジタルカメラから脱着されたタイミングで内蔵ＲＯＭＤＩＳＫの中の自動実行ファイルを消去する様に構成する事で、外部記憶媒体の中の自動実行ファイルをスタートアップ時に高速にロードし、実行する事を可能としている。スタートアップ時に自動実行ファイルをロードするタイミングは図２１のステップ２１０６で説明した。
【００７８】
仮想ＩＯポート
デジタルカメラのＢＵＳには、カスタムのデバイスが使われている。カスタムのデバイスをより安く生産できれば、デジタルカメラも安く生産出来る。周辺カスタムデバイスのコストを下げる為に、出来るだけゲート数の少ない回路で沢山の機能を搭載したい。１つのアドレスデコード回路でいくつかの機能のコントロールを行う事や、コントロール用レジスタを書き込み機能だけ（ＣＰＵから読めない）にする事で周辺カスタムデバイスのゲート数をかなり下げる事が出来るが、コントロールするソフトウェアの設計が困難になってしまう。本実施例では、読み書き可能なバッファーを備えた仮想のＩＯポートを構成し、ソフトウェアモジュール間で共有する事で、周辺カスタムＩＣのコントロールポートへ読み出し機能がある場合と同等のソフトウェアの構成を可能としている。
【００７９】
図２２は仮想ＩＯポートのデータ構造を示している。アプリケーションはデバイスハンドルとレジスタＩＤナンバーをつかってコントロールを行う。ＡＰＩはデバイスハンドルで指定されたバッファーの配列に対してリードモディファイライトを行い、その内容をバッファーと対で格納されているＩＯ番地情報を使って周辺デバイスへ書き込みを行う。このデバイスハンドルは、スタートアップ時の図２１のステップ２１０２で初期化し、ハンドルをシンボル登録する。
【００８０】
図２３はこの仮想デバイスを使ったビットセットファンクションのフローチャートである。ステップ２３０１でステータスレジスタの内容を待避する。ステップ２３０２で割り込みを禁止する。ステップ２３０３でハンドルとレジスタＩＤからバッファーとＩＯ番地のアドレスを計算する。レジスタＩＤは、あらかじめ図２２のテーブルのインデックス値を定義しておく。ステップ２３０４でバッファーのデータとセットするビットパターンのＯＲをとり、バッファーへ格納し、ＩＯポートへも出力（書き込み）を行う。ステップ２３０５でステータスレジスタを復帰する。もし、ステップ２３０２を実行するより以前が割り込み許可状態だったなら割り込み許可状態へ戻る事になる。
【００８１】
仮想デバイスのＡＰＩとしてビットセット以外にビットクリア、ビット幅を指定した書き込みと読み出しがあればコントロールプログラムは作成可能である。
【００８２】
仮想デバイスを利用する事のメリットとして、仮想デバイスＡＰＩを変更してＩＯの経歴をとるなどのデバッグ用の用途に利用出来る点が上げられる。また、ハードウェアの設計変更によって周辺デバイスのアドレスに変更があった場合に、変更が及ぶ範囲がテーブルの値だけなので管理も変更もしやすい。別の言い方をすれば開発期間とコストを軽減する効果がある。
【００８３】
フック管理
イベントの発生に対してコールバック処理を行う場合がある。コールバックの依頼主が不特定多数である場合にはそれらを管理するＡＰＩがあると便利である。デジタルカメラの場合、そのような不特定多数が利用するコールバックサービスがいくつか必要である。ローバッテリー発生の例外処理、シャットダウンの処理などは、制御プログラムのほとんどに例外処理が必要になるからである。本発明ではそれらのフックを管理するＡＰＩをオペレーティングシステムのサービスとして用意している。フックのＡＰＩは以下の様なサービスである。
1） フックハンドルの作成
2） フックハンドルの抹消
3） ファンクションとインスタンスの登録
4） ファンクションの登録解除（リストから削除）
5） フックの実行
【００８４】
フックハンドルの作成は、フック管理用のメモリをアロケーションし、セマフォを１で初期化、最初のファンクションへＥＮＤ＿ＯＦ＿ＬＩＳＴを代入し、そのメモリのポインタをフックハンドルとしてアプリケーションへ引き渡す。ファンクションとインスタンスの登録は、フックハンドル、ファンクションアドレス、インスタンスアドレスを指定して呼び出し、ファンクションとインスタンスを登録し、ファンクションのハンドルを返却する。ファンクションのハンドルは後で削除する時に使用する。図２４はフック管理のデータ構造を示している。フックハンドルに対し、２つのファンクションが登録されている。
【００８５】
ファンクションの実行はセマフォを獲得し、リストをたどりながら順次ファンクションを実行していく。フックを利用したアプリケーションの例を図２５のフローチャートで説明する。図２５の例はフォーカスモータをコントロールプログラムである。ステップ２５０１でフォーカスコントロールを開始する。ステップ２５０２でローバッテリー例外処理のフックへコールバック関数を登録する。この時登録する関数は図２６のフローチャートで示した関数である。インスタンスとしてフォーカスシステムのコントロール時間待ち用のセマフォを登録する。このセマフォはコールバックファンクションの中で使用する。ステップ２５０３で１ステップだけ駆動する。ステップ２５０４では、ステップ２５０２でコールバックファンクションのインスタンスとして指定したセマフォに対してタイムアウト指定で獲得を試みる。このセマフォは０で初期化しているので通常は獲得に失敗し、タイムアウトが発生する。ステップ２５０５でタイムアウトが発生したかどうかを判定する。タイムアウトならステップ２５０６へ、タイムアウトが発生していない場合は２５０９へ分岐する。ステップ２５０６では駆動すべき全ステップの駆動が終了したか判断し、まだ終了していないなら、ステップ２５０３へ戻り、終了していればステップ２５０７へ分岐する。ステップ２５０７ではステップ２５０２で登録したファンクションをフックから削除する。ステップ２５０８で正常に終了する。もし、ステップ２５０５でタイムアウトが発生していなければステップ２５０９でローバッテリ例外処理フックからステップ２５０２で登録したファンクションを削除し、ステップ２５１０で異常終了のエラーコードを返却して呼び出し元へ復帰する。図２６はステップ２５０２で登録したコールバックファンクションのフローチャートである。ステップ２６０１でフォーカスモータの電源を落とし、ステップ２６０２でセマフォへシグナルし、ステップ２６０３で復帰する。このコールバックファンクションがステップ２６０２でセマフォをシグナルしなければ必ず図２５のステップ２５０５でタイムアウトになる。この様な構成でローバッテリ時の例外処理を行う事で検出から対応までのレスポンスが早く、ＣＰＵタイムを無駄遣いしない制御が可能となる。
【００８６】
イベントプロシジャ
スタートアップの後、呼び出されるプログラムは、コントロールパネルからの操作イベントに対応した処理である。コントロールパネル部がメインＣＰＵへ送るイベントはどのキーが押された、又は離されたという情報である。２つボタン押しや２つボタン押しなどの操作をいろんな機能に割り当てる事で少ないキーで多くの機能を持たせる事が可能になる。そこで押されたキーのイベントはキーの操作を理解するモジュールへと伝達される。そして、そのモジュールでキー操作の内容を理解した結果、それに対応したデジタルカメラの機能を起動する。ここでいうデジタルカメラの機能は、EraseSingleとかSetMacroModeといった単機能の動作である。これらの機能はイベントが起こった時にそれに対応して呼び出されるサブルーチンのテーブルとして管理しており、イベントプロシージャと呼んでいる。名前とファンクションを対にして記憶しているテーブルであり、パーソナルコンピュータではマクロ言語をサポートしたＥｍａｃｓなどのテキストエディタなどでもこの様なテーブルを実装している。本発明のデジタルカメラは、イベントプロシージャのテーブルをスタートアップ時に作成する。したがって、自動実行ファイルが特定のイベントプロシージャを置き換える事でデジタルカメラの機能の一部を変更する事が可能である。
【００８７】
メインパワーマネージャ
このようにシステムが立ち上がるとコントロールパネルからのイベントに対応して、制御が行われる。撮影や録音の処理が終了すれば、必ず電源を落とすシステムにした場合、スタートアップとシャットダウンの時間のタイムラグや、ＤＩＳＫキャッシュのフラッシュなどの処理を毎回行う事になり、連続的な操作に対するレスポンスが悪くなってしまう。また、ＤＩＳＫキャッシュやＥＦのチャージのシステムは録音などのアプリケーションとは分離して設計する事が望ましい。しかし、電源を落とす為にはその様なサブシステムの動作状態を管理しなければならない。さらに、自動実行ファイルなどでカメラの機能を拡張したり、パソコンからのリモートコントロールで録音や撮影の動作を行う事も考慮しなければならない。この様なシステムの電源を落とすプログラムをメインシーケンスの流れの中で設計するのは非常に困難である。
【００８８】
本発明では、デジタルカメラの主電源を落とす為のしくみを用意する事で、上記の問題点を解決している。
【００８９】
メインパワーマネージャのＡＰＩ
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の処理手順を示す図
【符号の説明】
１ レンズ
２ ＣＣＤユニット
３ Ａ／Ｄコンバータ
４ ＣＣＤとＡ／Ｄ変換器に同期信号を供給するＳＳＧユニット
５ カメラシステムの中央演算器
６ 信号処理を高速に実現するためのアクセラレータ
７ 電池
８ システム全体へ電源を供給するためのＤＣ／ＤＣコンバータ
９ ＤＣ／ＤＣコンバータをコントロールする電源コントローラユニット
１０ パネル操作・表示装置・電源のコントロールを行うマイクロコンピュータ
１１ ユーザーへ情報を表示する表示装置
１２ ユーザーが直接操作するレリーズＳＷを含むコントロールパネル
１３ ＯＳ等システムプログラムが入ったＲＯＭ
１４ カメラシステムの主記憶であるＤＲＡＭ
１５ 内臓記憶媒体として使用するフラッシュＲＯＭ
１６ ＰＣＭＣＩＡカードのインターフェース部
１７ ＡＴＡハードディスクなどの外部記録媒体
１８ 拡張バスインターフェース
１９ ＰＣ通信インターフェース
２０ ＤＭＡコントローラ
２１ ストロボ
２２ パーソナルコンピュータ[0001]
BACKGROUND OF THE INVENTION
The present invention relates to an information processing apparatus and method for adding an arbitrary function later.
[0002]
[Prior art]
In a conventional camera system, the relationship between the purpose of use of the memory and the address is generally determined at the time of compiling and linking. Therefore, the memory manager itself was not installed. A camera system with a memory manager and dynamically allocated has the following characteristics when compared with a conventional system.
[0003]
If a memory manager is not installed, the memory used by the additional program must be reserved in advance. Since the ROM version of the camera and the memory layout are strongly dependent, it is necessary to set a small reserved area for the additional program in order to ensure compatibility. On the other hand, when the memory manager is used, it is only necessary to take care that the maximum amount of memory used simultaneously does not exceed the physical memory capacity, so that the memory can be used to the maximum. When there is no virtual storage system, the memory management method is roughly divided into a method using a bitmap and a method using a variable length memory divided by a memory management block. The method using a bitmap is not used much in an actual computer system because it takes time to search for free memory of a requested size. In the case of dividing and using a variable-length memory, three of the best fit method, first fit method, and next fit method are well known. The Best Fit method has a feature that a large continuous area is always secured, but the allocation speed becomes slow in proportion to the number of memory blocks. The First Fit method has similar properties. The Next Fit method does not depend on the number of blocks and can always perform allocation at high speed, but has the disadvantage that free memory becomes fragmented when stress is applied. When image processing is performed with a digital camera, an image for one screen is divided into about one thousand blocks for processing, and if the allocation speed is slow, a fatal result is exerted on the processing speed of the camera. Also, unlike conventional cameras using film, digital cameras can continuously shoot tens of thousands of shots, which is the number of times the shutter can be used, using a large-capacity hard disk and an AC power supply. Unacceptable. Further explanation will be given on the allocation mechanism and memory fragmentation in the Next Fit method. In FIG. 2, (1) is the initial state of the Next Fit memory manager. The main memory is managed as one free memory block, and an allocation pointer is set at the head thereof. The block here includes information as shown in FIG. This is a part used by the user application and a flag indicating whether the block is free memory or in use. When all the memories are arranged on the 4-byte alignment, the block size may be a multiple of 4, so that the least significant bit remaining can be used as a busy flag. The block size is also used to know the start position of the next block. A part storing information such as a block size and a busy flag is called an MCB (memory control block).
[0004]
(2) is a state in which the memory A is requested and assigned by the application. It is divided into two blocks, one empty block and one in-use memory, and the allocation pointer is set at the head of the divided empty memory. (3) in FIG. 2 is a state in which the memory B is further requested and assigned by the application. The free memory was further divided for memory B, and the main memory was divided into three blocks. In (4) of FIG. 2, the memory A is no longer needed and is released. The memory A is changed to an empty block, but the position of the allocation pointer is not updated. Although the memory C is requested in (5) in FIG. 2, the position where the memory A previously existed is not used. Only when the requested memory size is larger than the free memory indicated by the allocation pointer, the search for the free memory starts from the position of the allocation pointer. If free memory larger than the requested size is found, the block is divided and allocated. If the memory allocation and release are repeated in this manner, the state shown in FIG. (6) in FIG. 2 shows that allocation fails because the total amount of free memory is larger than the requested size of the memory B but the maximum continuous area size is smaller than the memory B. For this reason, when using the Nest Fit method, it was difficult to use it in an application that repeated allocation and release indefinitely.
[0005]
[Problems to be solved by the invention]
The memory manager of the present invention defines a function that remarkably reduces such a problem, and allows the application to use it in a field such as a digital camera by using the function. If memory is rearranged after fragmentation occurs, the maximum continuous area size increases again. However, if the memory is rearranged in an operating system, a large amount of CPU time is spent on memory transfer. If fragmentation is avoided in configuring the camera system, it is also possible to take a means to always restart the system at regular intervals. However, continuous operation is an important specification for digital cameras. Even if you give up restarting the system, there is a timing when the memory consumption of the system becomes extremely small, and it is possible to use it. If the memory consumption is always extremely small at a certain timing, it is possible to create a state as close as possible to the restart of the memory manager by moving the allocation pointer to the top of the main memory at that timing. Although the innovation cycle of personal computers is fast, new image formats are appearing one after another. The internal structure of digital cameras is also becoming computerized, and the scope of processing by software is also expanding. Therefore, it is possible to keep up with the rapid technological innovation cycle by reducing the investment in hardware development by adding and expanding the software of a digital camera like a personal computer. However, digital camera software has a wide variety of communication and file systems, and it is difficult to predict in advance which functions will be required in the future and which technologies will become obsolete. Various lots of digital cameras are on the market, but the additional expansion software needs to be designed to coexist with any lot of internal software. The present invention relates to a technique for replacing and expanding an arbitrary function of a digital camera by software added later.
[0006]
[Means for Solving the Problems]
In order to solve the above-described problem, according to the present invention, an allocation unit that starts a search from a memory pointer and allocates an empty block from an area where an empty block of a requested size is first found to the information processing apparatus. Updating means for updating the pointer to the position immediately after the assigned block after the assignment by the assigning means, and in response to a request from an application issued after execution of a predetermined operation, the pointer is moved to the start position of the memory. And initialization means for initializing.
[0007]
According to another aspect, in the information processing method, an allocation process of starting a search from a memory pointer and allocating the empty block from an area where an empty block of a requested size is first found, and the allocation process An update process for updating the pointer to a position immediately after the allocated block after the allocation by the initial stage, and initializing the pointer to the start position of the memory in response to a request from an application issued after execution of a predetermined operation And a crystallization process.
[0035]
DETAILED DESCRIPTION OF THE INVENTION
FIG. 1 is a block diagram of a first embodiment of the present invention.
[0036]
The operation of this camera during shooting will be briefly described. When the user presses the release switch of the
[0037]
The memory manager of the present invention implements a function ResetAllocationPointer that moves the allocation pointer to the top of the main memory. The more frequently the application calls the ResetAllocationPointer function, the more the memory manager will behave like the First Fit method. Calling the ResetAllocationPointer function before each allocation will no longer be a Next Fit method, but a complete First Fit method, and the time taken for allocation will increase in proportion to the amount of memory consumed. The purpose of the ResetAllocationPointer function is to make the memory manager as close as possible after restarting. The digital camera system calls this function immediately after a single shooting operation, immediately after a recording operation, or immediately after setting a mode. By constructing as described above, it is possible to construct a system having features of both high-speed allocation and continuous operation durability.
[0038]
FIG. 3 is a flowchart of the allocation operation of this memory manager. The allocation operation will be described according to this flowchart. In
[0039]
If the block is in use, the process returns to step 305. Otherwise, go to step 311. In
[0040]
Program ROM manager
Digital cameras store captured images in a file format that can be understood by a computer. On the other hand, there are so many kinds of computer image files that it is impossible to support all, and new image formats are appearing one after another. Under such circumstances, technology for adding or changing functions to the software inside the camera later has become important.
[0041]
A part of the flash ROM 15 in FIG. 1 is used for storing firmware of the digital camera. If it is possible to modify or add a part of the program, it is convenient for firmware development and camera firmware version upgrade. The program ROM manager described below is a function for managing programs written in such a flash ROM.
[0042]
FIG. 7 shows the format of the program stored in the flash ROM.
[0043]
The stored program is managed in module units, and a management block called MH (module header) is provided at the top of the module. The module header stores information such as the module name and program entry point. Since the flash ROM cannot be erased in byte units, there is no choice but to perform additional writing when changing some modules.
[0044]
Module rewriting
Modules are written from the front of the flash ROM as follows. A module is erased by invalidating the module. Module replacement is realized by erasing the module and writing a new module. The left side of FIG. 8 shows a plurality of modules in the flash ROM. The right side of FIG. 8 shows a state after the module A is newly rewritten. The original module A has been used, and the new module A has been written to the unused area.
[0045]
The service of the program ROM manager is as follows.
1) Specify the module name and get its address.
2) Specify the file name and perform additional writing.
3) Specify the module name and disable the module.
4) Physically erase all programs in the flash ROM.
[0046]
The program ROM manager uses the function of the OS program loader as its subsystem. At the time of additional writing, the program code and the relocation table are once read into the main memory and mapped to the address of the flash ROM to be written. The technology of storing code and relocation information in the executable file of the program and mapping it in the main memory at the time of execution is common in the field of personal computers, etc. However, in the case of a flash ROM, the mapping destination address and the program are loaded. Since the address of the main memory is different, the information must be transferred by API. The program loader of this embodiment supports mapping to a target address other than the main memory address from which the program is read. Only programs that physically write to the flash ROM cannot be placed in the flash ROM. Because the technology called data polling is used in the writing sequence of the flash ROM, only the same polling information can be read at any address in the flash ROM during the writing, so if the program being executed is placed in the flash ROM If so, as soon as writing begins, the next command goes crazy. In addition, since most of the software of the digital camera is stored in this flash ROM, the above-mentioned problems will occur if a task switch is activated during writing. In order to solve such a problem, the program ROM manager of the present invention always executes a writing program in the main memory, and starts from one writing unit (byte, word or double word) until data polling ends. The task SW and interrupts are prohibited. This configuration makes it possible to add programs without stopping the running system.
[0047]
The device driver unit that physically writes to the flash ROM of this embodiment is stored in an external recording medium together with the additional program, and is loaded into the main memory and executed when the program is additionally written.
[0048]
Program loader
Before describing the operation of the program loader, the format in which the executable program file is stored will be described.
[0049]
General type
The general form of the executable program file format of this embodiment is as shown in FIG.
[0050]
The file is composed of a plurality of records. A record is composed of a size field, a type field, and a body field.
[0051]
The size of the record is defined by the size field. The nature of the record is defined by a 1-byte module type. Actual data is stored in the body field. There is no restriction on the number of records present in the file. The program loader reads information necessary for execution from the records in the file into the main memory and executes it. Records that are not required for program execution are skipped without recognition. There are types of record types as shown in FIG. Explanations will be given for each type. TYPE_OBJECT_INFO (cannot be omitted)
[0052]
This record is a text representation of the properties of all records up to the next "TYPE_OBJECT_INFO".
[0053]
Name = Content
Are described as shown in FIG.
[0054]
TYPE_PROGRAM
It is a binary program.
[0055]
TYPE_RELOCATE_TABLE
This is a table of addresses for which absolute addressing is performed in the program.
[0056]
This record exists only when relative addressing is not supported as a CPU command. FIG. 10 is a table storing an address field for absolute addressing as shown in FIG. As a precondition, it is assumed that the address width when the CPU performs absolute addressing is 32 bits. The values in the table are relative addresses with the start address of the program as the origin. The loader program rewrites the value of the corresponding address in the binary program. The rules to be rewritten are as follows.
[0057]
New value to be stored = mapping destination address + value stored at that address
[0058]
Multi-platform support
This series of blocks can be used for multiple platforms. By combining the data of multiple platforms into one file as shown in the figure on the right, it is possible to make a multi-platform execution file with a single file. The system can search and execute modules that can be executed in the system from the file. When an executable program file that assumes a specific CPU is adopted, the CPU type cannot be changed. When an executable program file in which the CPU type is self-described is employed, the CPU can be changed for reasons such as production cost reduction.
[0059]
FIG. 12 shows a state of a file storing a plurality of types of CPU programs.
[0060]
As described above, in a system in which a program is divided into modules and the address of the module is changed, means for knowing the address where the function of another module exists is necessary. Techniques for determining subroutine addresses at the time of execution are called rate binding and dynamic linking. By using such a technology, it becomes possible to design the interface between modules flexibly. The main purpose of dynamic linking in a personal computer is to share a library (subroutine group). If the target library exists in the main memory, the link is completed immediately. If the target library does not exist in the main memory, the target library is loaded from the storage medium to the main memory and linked.
[0061]
Since the software of the digital camera of the present invention is stored in the ROM and the shared data is created by dynamic allocation, it is necessary to bind the shared data dynamically. FIG. 14 shows a state of the shared library loaded in the main memory. Function A accesses shared data. If function A is called, shared data can be accessed from any task. When the shared data and the library are in the main memory, the shared data and the function A can access the target data by mapped absolute addressing or relative addressing. FIG. 15 shows the shared library written in the flash ROM and the shared data allocated to the main memory. In this case, the address is determined when the shared data is created, but since the flash ROM program has already been mapped, the address cannot be handled.
[0062]
When binding shared data between processes, the timing between the task of preparing and publishing data (registering) and the task of searching for shared data that has been published (registered) is important. In the case of a dynamic link of a personal computer, if the shared library does not exist in the main memory, it may be loaded from the recording medium to the main memory. However, if the shared data does not exist, this is not the case. If the system is constructed such that the search is performed again after the CPU is given to another task for a certain period of time, it can be expected that a great amount of CPU time will be spent on a useless search. In order to solve such a binding problem, in the present invention, when the target shared data does not exist as a result of the search, the task becomes dormant, and the target shared data is disclosed (registered) by another task. By doing so, the search side task returns to the executable state again. It was found that the timing when a specific task initializes shared data can be solved by configuring as described above. However, if the task for initializing the shared data is unspecified, exclusive control over the initialization of the shared data is necessary. Specifically, for example, it is assumed that task A calls an API including initialization of shared data. The API called by task A checks whether there is any shared data that has been initialized. If it does not exist, the shared data is created, initialized, and published (registered). However, a task switch is applied immediately before publication (registration), and the task B is switched. Task B also calls the same API as that called by task A. Since the shared data has not been disclosed (registered) yet, Task B also creates, initializes, and discloses (registers) the shared data. Then, the API can use the shared data and starts the service. When the task is switched again, the shared data created by the task B is lost because the shared data is further released (registered) by the task A. In order to avoid such problems, the period from the search of shared data to registration can be performed as an inseparable operation.
[0063]
An API that realizes dynamic binding is a symbol management service as follows.
1) AddSymbol symbol registration
2) FindSymbol symbol search
3) LockAndFindSymbol Symbol system lock and search
4) UnlockAndAddSymbol Unlock and register symbol system
5) UnlockSymbol Symbol system unlock
[0064]
It is a simple system in which a unique name is defined for shared data, and addresses are registered and searched using that name.
[0065]
FIG. 17 shows the internal data structure of this symbol management system. When a symbol is specified and AddSymbol or FindSymbol is executed, the symbol management system first acquires the semaphore of the symbol and calculates the hash value by applying the specified symbol to the hash function. The hash value may be, for example, the sum of character codes of character strings. Then, the table is drawn by indexing with the obtained hash value. The table stores a pointer to the first data. If END_OF_LIST is stored, no symbol having that hash value has been registered yet. The symbol data is registered as a linked list with the pointer at the head. The ITEM on the list is searched by comparing with each specified symbol. In the case of FIG. 17, the symbols LCD_INSTANCE and AF_INSTANCE are registered. If the symbol already exists with AddSymbol, the address field is rewritten. If it doesn't exist, create a new ITEM and add it to the linked list. Then, the semaphore of the symbol system is released and the application returns to the application. If a symbol already exists with FindSymbol, the symbol semaphore can be released, the address can be returned to the application, and it can be immediately restored. As a result of the FindSymbol search, if there is no symbol, an ITEM with a flag indicating that no valid data has been stored yet and a WAITITE storing information on the waiting task are created and registered in the ITEM. The WAITITEM semaphore is initialized to 0 in advance, and the timeout flag is initialized to TRUE. The state is shown in FIG. In the case of FIG. 18, two tasks are waiting for registration of LCD_INSTANCE. Then, the symbol semaphore is released, the timeout time specified by the FindSymbol parameter is specified, and the WAITITE semaphore is acquired. Since the WAITITEM semaphore is initialized to 0 in advance, the acquisition fails and the task enters a sleep state. Next, for the task to return to an executable state, either a timeout occurs or a signal is sent to the semaphore. If another task AddSymbols a symbol that the symbol waiting task is sleeping in this way, a value is substituted for the WAITITEM address, the timeout flag is set to FLASE, and then a signal operation is performed on the semaphore. The reason for not using the timeout of the return value of the semaphore wait function is that the timeout may occur almost simultaneously with the signal. Then, remove WAITITE from the list of WAITITEM. AddSymbol repeats this until WAITITE is exhausted. The FindSymbol task that is ready to run gets the symbol semaphore first, so it goes to sleep again until AddSymbol releases the semaphore. FindSymbol checks the timeout flag after acquiring the semaphore, and if it does not time out, releases the semaphore, returns the address field of WAITITE, and returns to the application. If timed out, release the semaphore, return an error code, and return to the application.
[0066]
Exclusive control for initialization of shared data
LockAndFindSymbol and UnlockAndAddSymbol or UnlockSymbol are functions that realize exclusive control during the period from search to registration.
[0067]
Monopolizes the symbol system for the period from when LockAndFindSymbol is executed to when UnlockAndAddSymbol or UnlockSymbol is executed, and guarantees that symbol operations (search, registration) by other tasks will not be performed. FIG. 19 is a flowchart showing the operation of a program for initializing shared data using this function. In
[0068]
Next, the startup method of this camera will be described.
[0069]
Kernel startup
When the power of the
[0070]
If the maintenance mode is not set in
[0071]
Digital camera startup
An important function as a digital camera starts in
[0072]
In
[0073]
In
[0074]
[0075]
In
[0076]
Executable file
When a program is added to the built-in flash ROM, all programs must be erased once there is no unused area for additional writing. I want to write an additional program to an external storage medium to support more applications.
[0077]
When the digital camera is configured to read the additional program of the external storage medium at startup, the startup time of the digital camera greatly depends on the startup time of the external storage medium. The digital camera start-up begins when the user touches the keys on the control panel. There is a time lag for removing chattering in the control panel unit for a period of about 200 milliseconds after the user touches the keys on the operation unit. If the start-up does not end during that time, the response to the user's operation will be delayed and the operation feeling will be worsened. On the other hand, hard disk startup takes 7 to 10 seconds. Therefore, it is impossible to load the additional program directly from the external storage medium. In the present invention, if the auto-execution file exists in the external storage medium at the timing when the external storage medium is inserted into the digital camera, it is copied to the internal ROMDISK, and at the timing when the external storage medium is detached from the digital camera. It is possible to load and execute the auto-execution file in the external storage medium at a high speed at startup by configuring so as to delete the auto-execution file. The timing for loading the automatic execution file at the start-up has been described in
[0078]
Virtual IO port
Custom devices are used for BUS of digital cameras. If custom devices can be produced cheaper, digital cameras can also be produced cheaply. To reduce the cost of peripheral custom devices, I would like to install many functions with as few gates as possible. By controlling several functions with a single address decoding circuit, and by making the control register only write function (cannot be read from the CPU), the number of peripheral custom device gates can be considerably reduced, but control Software design becomes difficult. In this embodiment, by configuring a virtual IO port with a readable / writable buffer and sharing it between software modules, it is possible to configure software equivalent to the case where there is a read function to the control port of the peripheral custom IC. Yes.
[0079]
FIG. 22 shows the data structure of the virtual IO port. The application controls using the device handle and the register ID number. The API performs read-modify-write on the buffer array specified by the device handle, and writes the contents to the peripheral device using the IO address information stored in pairs with the buffer. This device handle is initialized in
[0080]
FIG. 23 is a flowchart of a bit set function using this virtual device. In
[0081]
If the API of the virtual device includes bit clearing, writing and reading with a bit width specified in addition to the bit set, the control program can be created.
[0082]
An advantage of using a virtual device is that it can be used for debugging purposes such as changing the virtual device API to obtain IO history. Also, when the address of a peripheral device is changed due to a hardware design change, it is easy to manage and change because the scope of the change is only a table value. In other words, it has the effect of reducing development time and costs.
[0083]
Hook management
Callback processing may be performed when an event occurs. When there are an unspecified number of callback requesters, it is convenient to have an API for managing them. In the case of a digital camera, several callback services used by such an unspecified number of people are necessary. This is because exception processing for low battery generation, shutdown processing, etc. requires exception processing for most control programs. In the present invention, an API for managing these hooks is prepared as an operating system service. The hook API is the following service.
1) Creating a hook handle
2) Erasing the hook handle
3) Register function and instance
4) Unregister function (delete from list)
5) Hook execution
[0084]
To create a hook handle, a memory for hook management is allocated, a semaphore is initialized with 1, END_OF_LIST is assigned to the first function, and the memory pointer is passed to the application as a hook handle. Function and instance registration is called by specifying a hook handle, function address, and instance address, registers the function and instance, and returns the function handle. The function handle is used later when it is deleted. FIG. 24 shows a data structure of hook management. Two functions are registered for the hook handle.
[0085]
The function execution acquires the semaphore and executes the function sequentially while following the list. An example of an application using a hook will be described with reference to the flowchart of FIG. The example of FIG. 25 is a control program for the focus motor. In
[0086]
Event procedure
After startup, the called program is a process corresponding to an operation event from the control panel. The event sent from the control panel unit to the main CPU is information indicating which key is pressed or released. By assigning operations such as pressing two buttons or pressing two buttons to various functions, it is possible to have many functions with few keys. The pressed key event is then transmitted to the module that understands the key operation. As a result of understanding the contents of the key operation in the module, the corresponding digital camera function is activated. The function of the digital camera here is a single-function operation such as EraseSingle or SetMacroMode. These functions are managed as a subroutine table that is called when an event occurs, and is called an event procedure. This table stores names and functions in pairs, and such a table is implemented in a text editor such as Emacs that supports a macro language in a personal computer. The digital camera of the present invention creates an event procedure table at startup. Therefore, it is possible to change a part of the function of the digital camera by replacing a specific event procedure with the automatic execution file.
[0087]
Main power manager
When the system starts up in this way, control is performed in response to an event from the control panel. When the shooting and recording process is completed, if the system is turned off without fail, the time lag between startup and shutdown time, the process of flushing the DISK cache, etc. will be performed each time, resulting in poor response to continuous operations. turn into. Also, it is desirable to design the DISK cache and EF charging system separately from applications such as recording. However, in order to turn off the power, the operating state of such a subsystem must be managed. In addition, it is necessary to consider extending the camera functions with auto-executable files and performing recording and shooting operations by remote control from a personal computer. It is very difficult to design a program for powering down such a system in the flow of the main sequence.
[0088]
The present invention solves the above problems by preparing a mechanism for turning off the main power of the digital camera.
[0089]
Main power manager API
1) Power lock
2) Power unlock
3) Setting the auto shutdown time
[0090]
The highest program in each application locks the power supply to the main power manager. For example, since the DISK cache and EF charge are designed as independent applications, the main power supply is locked. The main power manager guarantees that the main power is supplied whenever the main power is locked. The main power manager counts the number of locks and measures the auto shutdown time from the timing when the number of locks becomes zero. When the time when the number of locks reaches 0 reaches N consecutive milliseconds, the shutdown sequence is entered. If the lock counter becomes non-zero within N milliseconds after the number of locks becomes zero, the main power supply is guaranteed again. However, when the low battery detection system detects a low battery, the main power supply is exceptionally cut off.
[0091]
FIG. 27 is a time chart showing the state of the power lock counter and the auto shutdown timer. The top line shows how long the photographic application is locking power. The dotted line for shooting is the exposure timing. Before that, it is a period of waiting while performing AF or AE. Since a strobe was used during exposure, EF charging started and the EF charge program locked the main power supply. The number of the lock counter is written in the bottom line. At this time, since the photographing program and the EF charge lock the main power supply, the lock counter is 2. After a while, the exposed image is processed and stored in the storage medium as an image file. Therefore, the DISK cache starts to operate and the main power supply is locked. The lock counter at this time is 3. Next, the photographing program finishes all the processing, but the lock counter is 2 because the DISK cache and the EF charge are still in operation. All data held in the DISK cache is written to the DISK, and when the EF charge finishes charging enough power for the next shooting from the main power supply to the flash unit, the lock counter becomes 0 and the auto shutdown timer measures the time. To start. However, since the preparation for shooting is started again before sufficient time has passed, the lock counter changes to 1 without shutting down. The lock counter then changes from 1 → 2 → 3 → 2 → 1 → 0, the auto shutdown timer operates, and the shutdown starts after N milliseconds have elapsed.
[0092]
Shutdown processing
The shutdown process depends on the application that is currently running. Also, the processing when there is an additional program is different. Therefore, the process itself is preferably performed by executing a hook. However, the order relationship with other shutdown processes may be important. The database shutdown process closes the file, but if the file system has already shut down, it cannot even close the file. In the digital camera of the present invention, the above problem is solved by performing shutdown by executing hooks and dividing the shutdown process into three layers and executing them in order.
[0093]
Shutdown layer
1) Application layer
1) System layer
2) Device layer
[0094]
A hook handle is prepared and released for each layer above during startup. In the
[0095]
Processing during FATALERROR
When a failure such as a hardware failure is detected, the digital camera needs to display an error and stop the system. Since the system is designed separately for each module, it is difficult to define the process after the detection of a fault at the time of design. Even if processing after failure detection is defined, there is a possibility that a problem may occur if a program such as an automatic execution file is added. In the present invention, in order to solve such a problem, a specialized module responsible for error processing is defined, and the processing contents are abstracted. Roughly classify the recovery method after an error occurs, and convey the type of error code. If a double word is defined for the error code, it can handle 4 giga types of errors, but that type of error is not necessary. Therefore, there are no more than about 512 codes for specifying the type of error. In this embodiment, the upper word of the error code is classified as an error and the lower word is used for display. FIG. 28 summarizes the FATALERROR classification in a table.
[0096]
FATALERROR is also defined in the event procedure as an internal event equivalent to key input. The ABORT error is mainly used when there is a failure in a mechanical part such as a shutter or a focus motor. In the case of a shutter or focus motor failure, the system can continue to operate safely, so an error is displayed and the system returns to the mode for accepting the next operation again. For example, if the strobe has a problem, it is possible to shoot during the day, so the user should be able to choose whether to bring it to the service immediately or continue shooting without using the strobe. Operate as much as possible. INIT_DB detects a failure at a timing when there is a possibility that an error may be mixed in the free capacity of the storage medium or the directory information, such as when a failure occurs in the middle of writing the captured image to the disk, or the storage medium is free Used when an error is detected in the capacity or directory information. When the FATAL ERROR module receives this type of error code, it collects the free space of the storage medium, directory information, etc. again. The error code of INIT_SYS is when a failure that may destroy the logical structure of the built-in DISK occurs or when the breakage of the logical structure of the built-in DISK is detected. Important information such as the status information of the digital camera is stored in the built-in DISK. If there is an error in this information, the digital camera cannot be operated safely. Moreover, if the writing to the built-in DISK is continued, the destruction of the logical structure of the DISK may be exacerbated, and there is a possibility that even a captured image file is lost. Therefore, the digital camera is in a mode in which only the built-in DISK image / audio data can be read and the DISK format can be used, and the user has no choice but to perform complete initialization. ASSERT is mainly for the case where it gets caught by internal error or madness detection during development. If the FATALERROR module receives this code, it dumps a log of debug information and enters analysis mode. As a system, a plurality of modules operate in cooperation with each other, so when one module detects an error, another error is often induced. However, the triggering error is often reported first. Therefore, the FATAL error module always displays only the first reported error. But recovery is not the case. Perform recovery by giving priority to the most fatal error. The classification of the figure is described in the order of fatal errors as it goes down.
[0097]
As before, the built-in ROMDISK contains important files necessary for system operation. The operation of the digital camera is determined according to the file. However, if there is a failure in the built-in ROMDISK, that is not the case. Specially designing the processing when a failure occurs in the built-in ROMDISK means that the basic design must be duplicated. In the present invention, when there is a failure in the built-in ROMDISK, a part of the program ROM is used as a read-only file so that the operation when there is a failure in the built-in ROMDISK can be determined. Further, immediately after the built-in ROM DISK is formatted, the file is copied from the program ROM so that continuous operation is possible. FIG. 29 shows a state where a part of the program ROM is used as a file substitute. When reading a file in C language, the read function is used, but reading from the flash ROM is performed using memcpy instead.
[0098]
Symbol management behavior
1. AddSymbol / UnlockAndAddSymbol <symbol registration>
Here, the AddSymbol function and the UnlockAddAddSymbol will be described simultaneously. UnlockAndAddSymbol is an OS call specified in
[0099]
2. FindSymbol <Symbol Search>
FIG. 32 is a flowchart of the symbol search function FindSymbol. In STEP3201, FindSymbol starts. In STEP3202, the symbol database is locked using a technique such as a semaphore. In STEP 3203, the corresponding symbol item is searched. If there is no symbol as a result of the search, a new symbol is created in STEP 3211 and added to the database. If the corresponding symbol item is found in STEP 3203, the process branches to STEP 3204. In STEP 3204, it is determined whether the item contains valid data or a handle of a waiting task. If it has a handle of the waiting task, it branches to STEP3205. After STEP 3211, the process proceeds to 3205 again. In STEP 3205, the symbol database is unlocked and enters a sleep state. Then, a sleep state is entered in STEP 3205 until the time-out period or the wake-up is performed by AddSymbol / UnlockAndAddSymbol. If there is valid data in STEP 3204, the symbol database is unlocked in STEP 3206, and the registration data is returned and returned in
[0100]
FIG. 33 shows the details of the search for the corresponding symbol item in FIG. 32 STEP 3203 and FIG. 31 STEP 3102. In STEP 3301, the search for the corresponding symbol item is started. In STEP 3302, a hash value is calculated from the symbol character string. In STEP 3303, a list of data corresponding to the hash value is searched. If there is no corresponding item, the process branches to STEP 3305, where a data absence code is returned and returned. If there is a corresponding item in STEP 3303, the process branches to STEP 3304. In STEP 3304, a pointer to the item is returned and the process returns.
[0101]
3. LockAndFindSymbol Symbol System Locking and Retrieval FIG. 34 is a flowchart of the LockAndFindSymbol function. In STEP 3401, LockAndFindSymbol is started. In STEP3402, the symbol database is locked exclusively. In step 3403, the corresponding symbol is searched. This is the function described with reference to FIG. If there is no corresponding item, the process branches to STEP 3406, and an error code with no data is returned and returned in STEP 3006. If there is a corresponding symbol in STEP 3403, it is determined in STEP 3404 whether valid data is stored or a handle of the waiting task is stored. If valid data is not stored in STEP 3404, it returns immediately with an error code indicating no data in STEP 3406. If there is valid data in STEP 3404, the data is returned and returned in STEP 3405.
[0102]
Main power manager API
The operation of the main power manager that operates as shown in FIG. 27 will be described using a flowchart. The application calls the LockMainPower function immediately before the power supply needs to be guaranteed, and calls the UnLockMainPower function when the power can be turned off.
[0103]
1. LockMainPower (locking power)
FIG. 35 is a flowchart of LockMainPower. In STEP4001, LockMainPower is started. In STEP 4001, the shared data is exclusively locked using the semaphore. Shared data here refers to data used internally by the main power manager, such as a lock counter and count stop flag. In STEP 4003, it is confirmed whether or not the lock counter is 0. If it is 0, the auto shutdown time count is stopped. Specifically, the count stop flag is set to TRUE. In STEP 4005, the lock counter is incremented. In step 4006, the shared data is unlocked, and in step 4007, the process returns.
[0104]
2. Unlock power
FIG. 36 is a flowchart of UnLockMainPower. In Step 4101, UnLockMainPower is started. In STEP 4102, the shared data is exclusively locked using the semaphore. If the lock counter is 1 in STEP 4103, the process branches to STEP 4104. In STEP 4104, the count of the auto shutdown time is cleared to 0 and the count is started. Specifically, the count stop flag is set to FALSE. In step 4105, the lock counter is decremented, and in step 4106, the shared data is unlocked. The process returns at STEP 4107.
[0105]
3. Auto shutdown time count
FIG. 37 is a flowchart of a task for counting the auto shutdown time. In STEP4201, the task is started. In STEP 4202, the shared data is exclusively locked. In step 4203, the count stop flag is checked. If TRUE, the count operation is skipped and the process jumps to step 4206. If FALSE, the counter is incremented in STEP 4204. In STEP 4205, the time-out time is compared with the set value. If the time-out time is matched, the process branches to STEP 4207. In STEP 4207, a shutdown sequence is activated. If the result of comparison with the timeout time in STEP 4205 does not match, the process proceeds to STEP 4206. In STEP 4206, the shared data is unlocked. In STEP 4208, the task is put into a sleep state for a predetermined time, and then the process returns to STEP 4202. Thereafter, the steps from STEP 4202 to STEP 4208 are repeated.
[0106]
Operation of program ROM manager
The operation of the program ROM manager will be described for each service using a flowchart.
[0107]
1. Specify a module name and get its address
FIG. 38 is a flowchart of the function FindModule for obtaining the module address from the module name. In STEP5001, FindModule is started, and in STEP5002, an exclusive lock for module search is performed. A semaphore or the like is used for the exclusive lock. While this task is searching for a module, if another task invalidates or adds a module, a malfunction occurs in the operation, so an exclusive lock is performed. In STEP5003, a module is searched. STEP 5003 will be described in more detail in FIG. In STEP5004, the module search exclusive lock is released, and in STEP5005, the address or error value which is the return value of STEP5003 is returned.
[0108]
Next, the module search procedure in FIG. 38 STEP5003 will be described with reference to FIG. In STEP 5101, module search is started. In STEP5102, a pointer is set to the head address of the flash ROM. The module is searched while advancing this pointer. Next, in STEP 5103, the used flag of the module pointed to by the pointer is checked. If the used flag is TRUE, the process branches to STEP 5107, and if it is FALSE, the process proceeds to STEP 5104. In STEP 5104, it is confirmed whether or not the module name matches the name being searched and at the same time whether it is an unused area. If the names do not match, the process branches to STEP 5107. That is, if the used flag is TRUE or the names do not match, STEP 5107 is executed. In STEP 5107, the start address of the next module is calculated, and the process returns to 5103 again. Thus, the search continues while the names do not match or the used flag is TRUE. If the names match in STEP 5104, the address is returned in STEP 5105, and the process returns to the caller. If an unused area is detected in STEP 5104, the process branches to STEP 5106, returns an error to the caller, and returns.
[0109]
2. Specify the file name and perform additional writing
FIG. 40 is a flowchart of WriteMule for performing additional writing by specifying a file name. In STEP5201, WriteMduule is started. In STEP5202, the module search exclusive lock is performed. In STEP5203, a module is searched. The module search here uses the subroutine described with reference to FIG. If the module can be found, the process branches to STEP 5204, and TRUE is written to the used flag in FIG. Then, if the module cannot be found in STEP 5203 and after STEP 5204, the process branches to STEP 5206. In STEP 5206, the address of the free area is searched. The free area search is very similar to the module search, and the description is omitted. If it is detected in STEP 5206 that the free space is insufficient, the process branches to STEP 6210, the module search exclusive lock is released, and a free space shortage error is returned and returned in STEP 6211. After the empty area address is known in STEP6202, module loading and mapping are performed in STEP5206. Since the address at which the module is written is determined in STEP 5206, the program is loaded from the file into the main memory, and the absolute addressed portion is rewritten to the actual address to make it executable. In STEP 5207, the program is actually written into the flash ROM. Then, in STEP 5208, the module search exclusive lock is released, and in STEP 5209, an error-free code is returned to return.
[0110]
3. Disable a specified module name
FIG. 41 is a flowchart of the KillModule function that designates a module name and invalidates the module. In STEP 5301, KillModule is started. In STEP 5302, an exclusive lock for module search is performed, and in STEP 5303, a module is searched. This is the routine described in FIG. If a module is found, the process branches to STEP 5304, and the used flag (see FIG. 7) of the module is set to TRUE. If no module is present in STEP 5303 and after 5304, STEP 5305 is executed. In STEP 5305, the exclusive lock for module search is released, and the process returns in STEP 5306.
[0111]
In addition, the present invention supplies a storage medium storing software program codes for realizing the functions of the above-described embodiments to a system or apparatus, and the computer (or CPU or MPU) of the system or apparatus stores the storage medium. Needless to say, this can also be achieved by reading and executing the stored program code.
[0112]
In this case, the program code itself read from the storage medium realizes the novel function of the present invention, and the storage medium storing the program code constitutes the present invention.
[0113]
As a storage medium for supplying the program code, for example, a floppy disk, a hard disk, an optical disk, a magneto-optical disk, a CD-ROM, a CD-R, a magnetic tape, a nonvolatile memory card, a ROM, and the like can be used.
[0114]
Further, after the program code read from the storage medium is written to a memory provided in a function expansion board inserted into the computer or a function expansion unit connected to the computer, the function expansion is performed based on the instruction of the program code. The CPU of the board or the function expansion unit performs part or all of the actual processing, and the functions of the above-described embodiments can be realized by the processing.
[0115]
Note that the present invention can also be applied to a case where the program is distributed to a requester via a communication infrastructure such as personal computer communication from a storage medium in which the program code of software that realizes the functions of the above-described embodiments is recorded. Needless to say.
[0116]
【The invention's effect】
According to the present invention, a part of the function can be extended by additional software, and further, it is possible to develop additional software independent of the firmware version.
[Brief description of the drawings]
FIG. 1 is a block diagram illustrating the present invention.
FIG. 2 is an explanatory diagram of a memory manager.
FIG. 3 is a diagram for explaining the procedure of allocation operation;
FIG. 4 is an explanatory diagram of a memory block.
FIG. 5 is a diagram for explaining the procedure of memory release operation;
FIG. 6 is a diagram for explaining the procedure of the operation of the reset allocation pointer.
FIG. 7 is a diagram illustrating the format of a program stored in ROM
FIG. 8 is a diagram for explaining module rewriting.
FIG. 9 is a diagram for explaining an address table;
FIG. 10 shows a file format.
FIG. 11 is a diagram for explaining a record type
FIG. 12 is a diagram for explaining a program file
FIG. 13 is a diagram illustrating a record format
FIG. 14 is an explanatory diagram of a shared library stored in the main storage unit
FIG. 15 is an explanatory diagram of a shared library stored in the main storage unit and the flash ROM.
FIG. 16 is a diagram for explaining symbol management;
FIG. 17 is a diagram illustrating the internal structure of a symbol management system
FIG. 18 is a diagram for explaining the internal structure of the symbol management system;
FIG. 19 is a diagram for explaining a processing procedure of an operation for initializing shared data;
FIG. 20 is a diagram for explaining a startup sequence processing procedure;
FIG. 21 is a diagram for explaining a startup task processing procedure;
FIG. 22 is a diagram for explaining the data structure of a virtual IO port
FIG. 23 is a diagram for explaining the processing procedure of the bit set function;
FIG. 24 is a diagram illustrating the data structure of hook management
FIG. 25 is a diagram for explaining focus control;
FIG. 26 is a diagram for explaining focus control;
FIG. 27 is an explanatory diagram of focus operation.
FIG. 28 shows a classification of FATALERROR
FIG. 29 shows a part of the program ROM replaced with a file.
FIG. 30 is a diagram showing the processing procedure of AddSymbol.
FIG. 31 is a diagram showing a processing procedure of UnlockAndAddSymbol.
FIG. 32 is a diagram showing a processing procedure of a symbol search function.
FIG. 33 is a diagram showing a processing procedure for searching for a symbol item;
FIG. 34 is a diagram showing a processing procedure of LockAndFindSymbol.
FIG. 35 is a diagram showing a LockMainPower processing procedure.
FIG. 36 is a diagram showing a processing procedure of UnlockMainPower.
FIG. 37 is a diagram showing a processing procedure of a task for counting the auto shutdown time.
Fig. 38 is a diagram showing the FindModule processing sequence.
FIG. 39 is a diagram showing a processing procedure for module search;
FIG. 40 is a diagram showing the processing procedure of WriteModule.
FIG. 41 is a diagram showing a processing procedure of KillModule.
[Explanation of symbols]
1 lens
2 CCD unit
3 A / D converter
4 SSG unit that supplies synchronization signal to CCD and A / D converter
5 Central processing unit of camera system
6 Accelerator for high-speed signal processing
7 batteries
8 DC / DC converter for supplying power to the entire system
9 Power supply controller unit for controlling DC / DC converter
10 Microcomputer that controls panel operation, display device, and power supply
11 Display device that displays information to the user
12 Control panel including release SW operated directly by the user
13 ROM containing system programs such as OS
14 DRAM, the main memory of the camera system
15 Flash ROM used as a built-in storage medium
16 PCMCIA card interface
17 ATA hard disk and other external recording media
18 Expansion bus interface
19 PC communication interface
20 DMA controller
21 Strobe
22 Personal computer
Claims (4)
該割当手段による割当後に前記ポインタを当該割り当てられたブロックの直後の位置に更新する更新手段と、
所定動作の実行後に発せられるアプリケーションからの要求に応じて、前記ポインタを前記メモリの先頭位置へ初期化する初期化手段とを備えることを特徴とする情報処理装置。An allocation means for starting a search from a memory pointer and allocating the empty block from an area where an empty block of the requested size is first found ;
Updating means for updating the pointer to a position immediately after the assigned block after assignment by the assigning means;
An information processing apparatus comprising: an initialization unit configured to initialize the pointer to a head position of the memory in response to a request from an application issued after execution of a predetermined operation.
該割当工程による割当後に前記ポインタを当該割り当てられたブロックの直後の位置に更新する更新工程と、
所定動作の実行後に発せられるアプリケーションからの要求に応じて、前記ポインタを前記メモリの先頭位置へ初期化する初期化工程とを備えることを特徴とする情報処理方法。An allocation step of starting a search from a memory pointer and allocating the empty block from an area where an empty block of the requested size is first found ;
An update step of updating the pointer to a position immediately after the assigned block after the assignment by the assignment step;
An information processing method comprising: an initialization step of initializing the pointer to a head position of the memory in response to a request from an application issued after execution of a predetermined operation.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP18973497A JP3832933B2 (en) | 1996-07-19 | 1997-07-15 | Information processing apparatus and method, operating system, and storage medium |
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP19080896 | 1996-07-19 | ||
| JP8-190808 | 1996-07-19 | ||
| JP18973497A JP3832933B2 (en) | 1996-07-19 | 1997-07-15 | Information processing apparatus and method, operating system, and storage medium |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH1083342A JPH1083342A (en) | 1998-03-31 |
| JP3832933B2 true JP3832933B2 (en) | 2006-10-11 |
Family
ID=26505652
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP18973497A Expired - Fee Related JP3832933B2 (en) | 1996-07-19 | 1997-07-15 | Information processing apparatus and method, operating system, and storage medium |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3832933B2 (en) |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH10258339A (en) * | 1997-03-18 | 1998-09-29 | Mitsubishi Heavy Ind Ltd | Twin roll type continuous casting method |
| JP3519913B2 (en) * | 1997-06-10 | 2004-04-19 | 三洋電機株式会社 | Digital still camera |
-
1997
- 1997-07-15 JP JP18973497A patent/JP3832933B2/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JPH1083342A (en) | 1998-03-31 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US6470413B1 (en) | Information processing apparatus and method in which an executable file in an incorporated memory is loaded and executed at startup | |
| US6604168B2 (en) | Flash eeprom management using ratio of used to unused sectors | |
| US7702894B2 (en) | System and method for loading programs from HDD independent of operating system | |
| US6401198B1 (en) | Storing system-level mass storage configuration data in non-volatile memory on each mass storage device to allow for reboot/power-on reconfiguration of all installed mass storage devices to the same configuration as last use | |
| US5363487A (en) | Method and system for dynamic volume tracking in an installable file system | |
| JP3593241B2 (en) | How to restart the computer | |
| KR100924497B1 (en) | System and method for booting from a non-volatile application and file storage device | |
| JP3109054B2 (en) | Error recovery subsystem and error recovery method | |
| KR100233178B1 (en) | Method and system for updating mass storage device configuration records | |
| JP3727982B2 (en) | Flash ROM management method and apparatus | |
| JP3832933B2 (en) | Information processing apparatus and method, operating system, and storage medium | |
| JPH0997218A (en) | Method and device for managing flash rom and computer control equipment | |
| CN114020308A (en) | Camera equipment upgrading method, device, equipment and medium | |
| JPH0997207A (en) | Method, device for managing flash rom and computer control equipment | |
| JPH0997206A (en) | Method, device for managing flash rom and computer control equipment | |
| JPH0997205A (en) | Method, device for managing flash rom and computer control equipment | |
| JP4351328B2 (en) | Information processing apparatus and system activation management method | |
| JPH0997217A (en) | Method and device for managing flash rom and computer control equipment | |
| JP3919261B2 (en) | Memory control device and memory access method | |
| US7430687B2 (en) | Building-up of multi-processor of computer nodes | |
| TWI798743B (en) | Method for performing multi-system log access management, associated system on chip integrated circuit and non-transitory computer-readable medium | |
| JPH0997199A (en) | Method and device for flash rom management and computer controller | |
| JPH0997314A (en) | Ic card device | |
| CN1235147C (en) | Information management system and method for application device | |
| JPH0993523A (en) | Electronic camera |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040715 |
|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20040715 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20060417 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20060425 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060626 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20060711 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20060718 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090728 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100728 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100728 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110728 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120728 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120728 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130728 Year of fee payment: 7 |
|
| LAPS | Cancellation because of no payment of annual fees |