JP3832933B2 - 情報処理装置およびその方法、オペレーティングシステム、記憶媒体 - Google Patents
情報処理装置およびその方法、オペレーティングシステム、記憶媒体 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
Landscapes
- Stored Programmes (AREA)
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の処理手順を示す図
【符号の説明】
１ レンズ
２ ＣＣＤユニット
３ Ａ／Ｄコンバータ
４ ＣＣＤとＡ／Ｄ変換器に同期信号を供給するＳＳＧユニット
５ カメラシステムの中央演算器
６ 信号処理を高速に実現するためのアクセラレータ
７ 電池
８ システム全体へ電源を供給するためのＤＣ／ＤＣコンバータ
９ ＤＣ／ＤＣコンバータをコントロールする電源コントローラユニット
１０ パネル操作・表示装置・電源のコントロールを行うマイクロコンピュータ
１１ ユーザーへ情報を表示する表示装置
１２ ユーザーが直接操作するレリーズＳＷを含むコントロールパネル
１３ ＯＳ等システムプログラムが入ったＲＯＭ
１４ カメラシステムの主記憶であるＤＲＡＭ
１５ 内臓記憶媒体として使用するフラッシュＲＯＭ
１６ ＰＣＭＣＩＡカードのインターフェース部
１７ ＡＴＡハードディスクなどの外部記録媒体
１８ 拡張バスインターフェース
１９ ＰＣ通信インターフェース
２０ ＤＭＡコントローラ
２１ ストロボ
２２ パーソナルコンピュータ
【発明の属する技術分野】
本発明は、任意の機能を後から追加可能な情報処理装置およびその方法に関するものである。
【０００２】
【従来の技術】
従来のカメラシステムでは、メモリの利用目的とアドレスの関係はコンパイル＆リンク時に決定するのが一般的である。したがって、メモリマネージャそのものが搭載されていなかった。メモリマネージャを搭載して、ダイナミックにアロケーションするカメラシステムと従来のシステムを比較すると以下の様な特徴がある。
【０００３】
メモリマネージャを搭載しない場合、追加プログラムが利用するメモリは、あらかじめ予約しておく必要がある。カメラのＲＯＭのバージョンとメモリの配置が強く依存しているので、互換性を確保する為には追加プログラム用の予約領域は少なめに設定する必要がある。一方、メモリマネージャを利用する場合は、同時に利用するメモリの最大量が物理的なメモリ容量を越えない様に注意するだけで良いので、メモリを最大限利用可能である。仮想記憶のシステムが無い場合のメモリマネージメント手法は、大別してビットマップを利用したもの、メモリ管理ブロックによって可変長のメモリを分割して利用するものがある。ビットマップを利用する方法は、要求されたサイズの空きメモリを検索するのに時間がかかる為、実際のコンピュータシステムでもあまり利用されていない。可変長のメモリを分割して利用する場合はさらに、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の処理手順を示す図
【符号の説明】
１ レンズ
２ ＣＣＤユニット
３ Ａ／Ｄコンバータ
４ ＣＣＤとＡ／Ｄ変換器に同期信号を供給するＳＳＧユニット
５ カメラシステムの中央演算器
６ 信号処理を高速に実現するためのアクセラレータ
７ 電池
８ システム全体へ電源を供給するためのＤＣ／ＤＣコンバータ
９ ＤＣ／ＤＣコンバータをコントロールする電源コントローラユニット
１０ パネル操作・表示装置・電源のコントロールを行うマイクロコンピュータ
１１ ユーザーへ情報を表示する表示装置
１２ ユーザーが直接操作するレリーズＳＷを含むコントロールパネル
１３ ＯＳ等システムプログラムが入ったＲＯＭ
１４ カメラシステムの主記憶であるＤＲＡＭ
１５ 内臓記憶媒体として使用するフラッシュＲＯＭ
１６ ＰＣＭＣＩＡカードのインターフェース部
１７ ＡＴＡハードディスクなどの外部記録媒体
１８ 拡張バスインターフェース
１９ ＰＣ通信インターフェース
２０ ＤＭＡコントローラ
２１ ストロボ
２２ パーソナルコンピュータ
Claims (4)
- メモリのポインタから探索を開始して、要求されたサイズの空ブロックが最初に見つかった領域から当該空ブロックを割り当てる割当手段と、
該割当手段による割当後に前記ポインタを当該割り当てられたブロックの直後の位置に更新する更新手段と、
所定動作の実行後に発せられるアプリケーションからの要求に応じて、前記ポインタを前記メモリの先頭位置へ初期化する初期化手段とを備えることを特徴とする情報処理装置。 - 撮影手段を更に備え、前記所定動作は当該撮影手段による撮影動作であることを特徴とする請求項１に記載の情報処理装置。
- 録音手段を更に備え、前記所定動作は当該録音手段による録音動作であることを特徴とする請求項１に記載の情報処理装置。
- メモリのポインタから探索を開始して、要求されたサイズの空ブロックが最初に見つかった領域から当該空ブロックを割り当てる割当工程と、
該割当工程による割当後に前記ポインタを当該割り当てられたブロックの直後の位置に更新する更新工程と、
所定動作の実行後に発せられるアプリケーションからの要求に応じて、前記ポインタを前記メモリの先頭位置へ初期化する初期化工程とを備えることを特徴とする情報処理方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP18973497A JP3832933B2 (ja) | 1996-07-19 | 1997-07-15 | 情報処理装置およびその方法、オペレーティングシステム、記憶媒体 |
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP19080896 | 1996-07-19 | ||
| JP8-190808 | 1996-07-19 | ||
| JP18973497A JP3832933B2 (ja) | 1996-07-19 | 1997-07-15 | 情報処理装置およびその方法、オペレーティングシステム、記憶媒体 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH1083342A JPH1083342A (ja) | 1998-03-31 |
| JP3832933B2 true JP3832933B2 (ja) | 2006-10-11 |
Family
ID=26505652
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP18973497A Expired - Fee Related JP3832933B2 (ja) | 1996-07-19 | 1997-07-15 | 情報処理装置およびその方法、オペレーティングシステム、記憶媒体 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3832933B2 (ja) |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH10258339A (ja) * | 1997-03-18 | 1998-09-29 | Mitsubishi Heavy Ind Ltd | 双ドラム式連続鋳造方法 |
| JP3519913B2 (ja) * | 1997-06-10 | 2004-04-19 | 三洋電機株式会社 | ディジタルスチルカメラ |
-
1997
- 1997-07-15 JP JP18973497A patent/JP3832933B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JPH1083342A (ja) | 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 (ja) | 計算機の再起動方法 | |
| JP3109054B2 (ja) | エラー回復サブシステムおよびエラー回復方法 | |
| KR100233178B1 (ko) | 대용량 저장장치 구성 레코드들을 갱신하기 위한 방법 및 시스템 | |
| KR20040019260A (ko) | 비-휘발성 어플리케이션 및 화일 저장 디바이스로부터부팅시키기 위한 시스템 및 방법 | |
| JPH0997139A (ja) | フラッシュｒｏｍ管理方法及び装置及びコンピュータ制御装置 | |
| JP3832933B2 (ja) | 情報処理装置およびその方法、オペレーティングシステム、記憶媒体 | |
| JPH0997218A (ja) | フラッシュｒｏｍ管理方法及び装置及びコンピュータ制御装置 | |
| CN114020308A (zh) | 一种摄像设备升级方法、装置、设备及介质 | |
| JPH0997207A (ja) | フラッシュｒｏｍ管理方法及び装置及びコンピュータ制御装置 | |
| JPH0997206A (ja) | フラッシュｒｏｍ管理方法及び装置及びコンピュータ制御装置 | |
| JPH0997205A (ja) | フラッシュｒｏｍ管理方法及び装置及びコンピュータ制御装置 | |
| TWI841160B (zh) | 存儲控制器的驅動管理方法及相關設備 | |
| JP4351328B2 (ja) | 情報処理装置及びシステム起動管理方法 | |
| JPH0997217A (ja) | フラッシュｒｏｍ管理方法及び装置及びコンピュータ制御装置 | |
| TWI798743B (zh) | 用來進行多系統日誌存取管理之方法、系統單晶片積體電路以及非暫態計算機可讀取媒體 | |
| JPH0997199A (ja) | フラッシュｒｏｍ管理方法及び装置及びコンピュータ制御装置 | |
| JPH0997314A (ja) | Ｉｃカード装置 | |
| JPH0993523A (ja) | 電子カメラ | |
| CN1235147C (zh) | 应用装置的装置信息管理***及方法 | |
| JPH1050084A (ja) | メモリ制御装置およびメモリアクセス方法 |
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 |