JP2012146052A - 電子機器、電子カメラ - Google Patents

Abstract

【課題】 本発明は、起動時間の異なる複数のＯＳに関し、複数のＯＳの起動時間の効率化を図る手段を提供する。
【解決手段】 電子機器は、起動時間の異なる複数のＯＳ（Operating System）と、複数の制御部とを備える。複数の制御部は、複数のＯＳの何れかを選択して演算処理を実行する。複数の制御部のうちの主制御部は、複数のＯＳのうちで起動時間の速い第１のＯＳを起動して、システム状態を示す動作モードを第１のＯＳに検出させると共に、第１のＯＳによる検出結果に基づいて、主制御部とは異なる他の制御部で起動するＯＳとして、第１のＯＳよりも起動時間の遅い他のＯＳを選択する。
【選択図】 図１

Description

本発明は、電子機器、電子カメラに関する。

従来より、オペレーティングシステム（以下「ＯＳ」という）を搭載した電子機器が知られている（例えば、特許文献１参照）。また、近年、電子カメラでは、操作形態の多様化、高性能化に伴い、高機能な汎用ＯＳを搭載する方向に進んでいる。一方、従来から、電子カメラでは、例えば、タスクの実行時間を管理するリアルタイムＯＳ（以下「ＲＴＯＳ」という）が搭載されている。

特開２００７−１５６８５５号公報

ところで、例えばＲＴＯＳと汎用ＯＳとを電子カメラ等に搭載した場合、汎用ＯＳが起動を開始してから完了するまでに要する時間が、ＲＴＯＳに比較して長時間要する。そのため、ユーザは電子カメラの電源をオンした後、汎用ＯＳが起動終了して使用開始状態になるまで待たされるおそれが生じる。すなわち、起動時間の異なる複数のＯＳの取り扱いが問題となる。

そこで、本発明は、上記事情に鑑み、起動時間の異なる複数のＯＳに関し、複数のＯＳの起動時間の効率化を図る手段を提供することを目的とする。

第１の発明に係る電子機器は、起動時間の異なる複数のＯＳ（Operating System）と、複数の制御部とを備える。複数の制御部は、複数のＯＳの何れかを選択して演算処理を実行する。複数の制御部のうちの主制御部は、複数のＯＳのうちで起動時間の速い第１のＯＳを起動して、システム状態を示す動作モードを第１のＯＳに検出させると共に、第１のＯＳによる検出結果に基づいて、主制御部とは異なる他の制御部で起動するＯＳとして、第１のＯＳよりも起動時間の遅い他のＯＳを選択する。

第２の発明は、第１の発明において、他のＯＳは、汎用ＯＳである。主制御部は、検出結果が汎用ＯＳを起動する第１動作モードの場合、他の制御部で起動する汎用ＯＳを選択する。

第３の発明は、第２の発明において、汎用ＯＳは、その汎用ＯＳの起動時間を短縮するスナップショットイメージとしてメモリに記録されている。他の制御部は、スナップショットイメージを起動する。

第４の発明は、第１の発明において、他のＯＳは、タスクの実行時間を管理するリアルタイムＯＳである。主制御部は、検出結果がリアルタイムＯＳを起動する第２の動作モードの場合、他の制御部で起動するリアルタイムＯＳを選択する。

第５の発明は、第１の発明において、他のＯＳは、汎用ＯＳとタスクの実行時間を管理するリアルタイムＯＳとである。主制御部は、検出結果が汎用ＯＳとリアルタイムＯＳとを起動する第３動作モードの場合、第１の他の制御部で起動する汎用ＯＳと第２の他の制御部で起動するリアルタイムＯＳとを選択する。

第６の発明は、第１の発明において、他のＯＳは、汎用ＯＳである。主制御部は、検出結果が汎用ＯＳを複数の他の制御部で共有して管理する第４動作モードの場合、複数の他の制御部で起動する汎用ＯＳを選択する。

第７の発明は、第６の発明において、第４動作モードは、並列処理方式の対称型マルチプロセッシング（ＳＭＰ：Symmetric Multiprocessing）である。

第８の発明は、第１から第７の何れか１の発明において、主制御部は、第１のＯＳの起動後、他のＯＳの起動中に中断事由又は中止事由を第１のＯＳが検出した場合、他のＯＳの起動を中断又は中止する。

第９の発明は、第８の発明において、主制御部は、他のＯＳの起動中に電源システムの異常状態を第１のＯＳが検出した場合、他のＯＳの起動を中断する。主制御部は、電源システムの正常状態を第１のＯＳが再度検出した場合、他のＯＳの起動を再開する。

第１０の発明は、第８の発明において、主制御部は、他のＯＳの起動中に動作モードの変更を第１のＯＳが検出した場合、起動中の他のＯＳを強制終了する。他の制御部は、動作モードに適した変更用の他のＯＳ又は予めメモリに記録されている変更用の他のＯＳの起動時間を短縮するスナップショットイメージを起動する。

第１１の発明に係る電子カメラは、撮影光学系からの被写体光を撮像して画像を生成する撮像素子と、請求項１から請求項１０の何れか１項記載の電子機器とを備える。

第１２の発明は、第１１の発明において、主制御部は、他のＯＳの起動中に静止画撮影又は動画撮影の指示入力を検出した場合、他のＯＳの起動を中断する。主制御部は、静止画撮影又は動画撮影の実行後に、他のＯＳの起動を再開する。

第１３の発明は、第１１又は第１２の発明において、第１のＯＳは、撮影光学系が有するレンズ情報を解析する。他の制御部は、レンズ情報の解析結果に基づいて、汎用ＯＳとタスクの実行時間を管理するリアルタイムＯＳとの何れか一方を起動する。

本発明によれば、起動時間の異なる複数のＯＳに関し、複数のＯＳの起動時間の効率化を図る手段を提供できる。

本実施形態の電子カメラ１００の構成例を説明するブロック図 各動作モードにおけるシステム構成例の概念図 各動作モードにおけるシステム構成例の概念図 電子カメラ１００の電源オン時における動作の一例を示すフローチャート 汎用ＯＳの起動処理のサブルーチンを示すフローチャート 第１の汎用ＯＳ１６ｃの起動処理を説明する概念図

以下、図面に基づいて本発明の実施の形態を詳細に説明する。図１は、本実施形態の電子カメラ１００の構成例を説明するブロック図である。本実施形態の電子カメラ１００は最初に起動したＯＳが起動条件を検出し、その後に起動するＯＳを決定するマルチコアシステムを有する。このマルチコアシステムの一例は、後述するフローの処理により実現される。

電子カメラ１００は、図１に示す通り、撮影光学系１０と、レンズ制御部１１、撮像素子１２と、信号処理部１３と、カードインターフェース部（以下「カードＩ／Ｆ部」という）１４と、ＵＳＢ（Universal Serial Bus）インターフェース部（以下「ＵＳＢＩ／Ｆ部」という）１５と、フラッシュメモリ１６と、ＳＤＲＡＭ（Synchronous Dynamic Random Access Memory）１７と、表示モニタ１８と、操作部１９と、レリーズ釦２０と、電源２１と、通信インターフェース部（以下「通信Ｉ／Ｆ部」という）２２と、ＡＳＩＣ（Application Specific Integrated Circuit）２３と、データバス２４とを備える。

このうち、信号処理部１３、カードＩ／Ｆ部１４、ＵＳＢＩ／Ｆ部１５、フラッシュメモリ１６、ＳＤＲＡＭ１７、表示モニタ１８、通信Ｉ／Ｆ部２２及びＡＳＩＣ２３は、データバス２４を介して互いに接続されている。また、レンズ制御部１１、撮像素子１２、信号処理部１３、操作部１９、レリーズ釦２０及び電源２１は、ＡＳＩＣ２３に接続されている。

撮影光学系１０は、ズームレンズとフォーカスレンズとを含む複数のレンズ群で構成されている。なお、簡単のため、図１では、撮影光学系１０を１枚のレンズとして図示する。レンズ制御部１１は、撮影光学系１０内でズームレンズやフォーカスレンズのレンズ位置をＡＳＩＣ２３の指示に応じて光軸方向に調整する。

撮像素子１２は、被写体の像を撮像し、アナログの画像信号を出力する。そして、撮像素子１２が出力するアナログの画像信号は、信号処理部１３に入力される。なお、撮像素子１２の撮像面には、Ｒ（赤）、Ｇ（緑）Ｂ（青）の３種類のカラーフィルタが例えばベイヤー配列で配置されている。また、撮像素子１２の電荷蓄積時間及び画像信号の読み出しは、タイミングジェネレータ（不図示）によって制御される。

ここで、撮像素子１２は、電子カメラ１００の撮影モードにおいて、レリーズ釦２０の全押し操作に応答して記録用の静止画像（本画像）を撮像する。また、撮像素子１２は、撮影待機時にも所定間隔毎に観測用の画像（スルー画像）を連続的に撮像する。なお、撮像素子１２は、ＣＣＤ（Charge Coupled Device）型又はＣＭＯＳ（Complementary Metal-Oxide Semiconductor）型のイメージセンサである。

信号処理部１３は、撮像素子１２が出力する画像信号に対してアナログ信号処理を施すアナログフロントエンド回路（ＡＦＥ）と、そのＡＦＥでアナログ信号処理が施された画像信号に対して、デジタル信号処理を施すデジタルフロントエンド回路（ＤＦＥ）とを有する。ここで、信号処理部１３のＡＦＥは、アナログの画像信号に対して相関二重サンプリングやゲイン調整をした後、アナログの画像信号をデジタルの画像信号に変換する（Ａ／Ｄ変換）処理等を行なう。また、信号処理部１３のＤＦＥは、Ａ／Ｄ変換されたデジタルの画像信号におけるノイズ成分の除去等を行なう。この信号処理部１３が出力する画像信号は、ＲＧＢ信号の画像データとしてＳＤＲＡＭ１７に一時的に記録される。

カードＩ／Ｆ部１４には、着脱自在の記録媒体３０を接続するためのコネクタ（不図示）が形成されている。そして、カードＩ／Ｆ部１４は、そのコネクタに接続された記録媒体３０にアクセスして画像の記録処理等を行なう。この記録媒体３０は、例えば、不揮発性のメモリカードである。図１では、コネクタに接続された後の記録媒体３０を示している。

ＵＳＢＩ／Ｆ部１５には、カードＩ／Ｆ部１４と同様、着脱自在の記録媒体３１を接続するためのコネクタ（不図示）が形成されている。そして、ＵＳＢＩ／Ｆ部１５は、そのコネクタに接続された記録媒体３１にアクセスして画像の記録処理等を行なう。この記録媒体３１は、例えば、不揮発性のＵＳＢメモリである。図１では、コネクタに接続された後の記録媒体３１を示している。

フラッシュメモリ１６は、不揮発性メモリであって、複数のＯＳや複数のスナップショットイメージが格納される。図１では、簡単のため、フラッシュメモリ１６は、第１のリアルタイムＯＳ（以下「第１のＲＴＯＳ」という）１６ａ、第２のリアルタイムＯＳ（以下「第２のＲＴＯＳ」という）１６ｂ、第１の汎用ＯＳ１６ｃ、第２の汎用ＯＳ１６ｄを格納している。ここで、第１のＲＴＯＳ１６ａは、例えば、タスクの実行時間を管理するリアルタイムＯＳである。第２のＲＴＯＳ１６ｂは、第１のＲＴＯＳ１６ａよりも起動時間の遅いＲＴＯＳである。第１の汎用ＯＳ１６ｃは、例えばＬｉｎｕｘ（登録商標）等の汎用ＯＳである。第２の汎用ＯＳ１６ｄは、例えばＬｉｎｕｘとは異なる汎用ＯＳである。

また、フラッシュメモリ１６は、例えば第１の汎用ＯＳ１６ｃの起動時間を短縮する第１のスナップショットイメージ（以下「第１のＳＰ」という）１６ｅや第２のスナップショットイメージ（以下「第２のＳＰ」という）１６ｆを格納している。ここで、第１のＳＰ１６ｅ及び第２のＳＰ１６ｆは、ＯＳの一形態である。

なお、Ｌｉｎｕｘ等の汎用ＯＳの場合、ハードウエアを直接管理する処理を行なう中心的な機能を有するソフトウェアをカーネルと称し、カーネル以外の部分（例えば、ファイルシステムやファイル操作コマンド、シェルなどの基本的なソフトウェア群）をユーザランドと称している。本実施形態では、例えば、第１のＳＰ１６ｅ及び第２のＳＰ１６ｆは、ユーザランドのスナップショットイメージとする。汎用ＯＳのユーザランドをロードする場合、ユーザランドのファイルのサイズに応じて、起動時間がかかる。そこで、本実施形態では、予めユーザランドのスナップショットイメージを作成しておくことにより、起動時間を高速化することができる。

また、本実施形態で使用するＯＳは、工場出荷時に予めインストールされていることとする。ただし、電子カメラ１００では、記録媒体３０、記録媒体３１、又は通信Ｉ／Ｆ部２２を介して、汎用ＯＳのソフトウェア（バージョンアップも含む）をインストールするようにしても良い。

ＳＤＲＡＭ１７は、画像データやＯＳ等のプログラムを一時的に記録する揮発性のバッファメモリである。ここで、ＡＳＩＣ２３は、フラッシュメモリ１６に格納されている第１のＲＴＯＳ１６ａ、第２のＲＴＯＳ１６ｂ、第１の汎用ＯＳ１６ｃ、第２の汎用ＯＳ１６ｄ、第１のＳＰ１６ｅ及び第２のＳＰ１６ｆを必要に応じて読み出し、ＳＤＲＡＭ１７にロードして起動する。これにより、各ＯＳは、ＳＤＲＡＭ１７に一時的に記録される。なお、図１に示すＳＤＲＡＭ１７では、一例として、工場出荷時の状態を例示しているため、ロード前の状態として点線枠で示している。

表示モニタ１８は、例えば液晶表示媒体により構成される。そして、表示モニタ１８は、記録用の画像、スルー画像、電子カメラ１００の操作メニュー等を表示する。

操作部１９は、電子カメラ１００を操作するための指示入力を受け付ける複数の釦（不図示）を有している。レリーズ釦２０は、半押し操作（撮影前におけるオートフォーカス（ＡＦ）や自動露出（ＡＥ）等の動作開始の指示入力）と全押し操作（記録用画像を取得するための撮像動作開始）との指示入力とを受け付ける。電源２１は、電子カメラ１００の各機能ブロック等に電力を供給する。電力の供給開始及び供給停止は、ＡＳＩＣ２３から指示により行なう。

ＡＳＩＣ２３は、各種演算及び電子カメラ１００の制御を行なう。また、ＡＳＩＣ２３は、画像データに各種の画像処理（例えば、輪郭強調処理、色補間処理等）を施す。さらに、ＡＳＩＣ２３は、複数のＣＰＵ（Central Processing Unit）コアを搭載してＣＰＵの高速化を実現するマルチコアシステムを採用している。マルチコアシステムでは、ＣＰＵをＮ個（Ｎは自然数）搭載するが、本実施形態では、説明の便宜上、一例として３つのＣＰＵコアを搭載する。

また、本実施形態では、最初に起動した第１のＯＳ（第１のＲＴＯＳ１６ａ）が、システム状態（例えば起動条件）を示す動作モードを検出して、それ以降に起動するＯＳを決定する。具体的には、本実施形態では、複数のＣＰＵのうちで主となる第１ＣＰＵ１（主制御部）を設定する。これにより、第１ＣＰＵ１（マスター側）と第２ＣＰＵ２、第３ＣＰＵ３とは、主従関係を形成する。例えば、第１ＣＰＵ１は、第２ＣＰＵ２、及び第３ＣＰＵ３が起動するＯＳを選択する。

また、第１ＣＰＵ１は、複数のＯＳのうちで起動時間の速い第１のＯＳ（第１のＲＴＯＳ１６ａ）を起動して、システム状態を示す動作モードを第１のＯＳに検出させる。この場合、第１のＯＳは、電子カメラ１００の制御系の機能を管理するＲＴＯＳであって、最初に予め定められた時間内で処理可能なＯＳである。また、第１のＯＳは、複数のＯＳのうちで最速のＯＳである。そして、第１ＣＰＵ１は、第１のＯＳによる検出結果に基づいて、第１ＣＰＵ１とは異なる他のＣＰＵで起動するＯＳとして、第１のＯＳよりも起動時間の遅い他のＯＳを選択する。本実施形態の他のＯＳは、第２のＲＴＯＳ１６ｂ、第１の汎用ＯＳ１６ｃ、第２の汎用ＯＳ１６ｄ、第１のＳＰ１６ｅ、第２のＳＰ１６ｆが該当する。なお、第１ＣＰＵ１は、１つのＣＰＵで起動するＯＳとして複数のＯＳを選択しても良い。

図２、図３は、各動作モードにおけるシステム構成例の概念図である。図２及び図３に示す概念図では、フラッシュメモリ１６に格納されているＯＳと、ＡＳＩＣ２３内の第１ＣＰＵ１〜第３ＣＰＵ３との対応関係を動作モード毎に示している。なお、図２、図３では、第１の汎用ＯＳをＬｉｎｕｘとして例示している。

図２（ａ）は、動作モード０のシステム構成例を示す概念図である。動作モード０は、第１のＲＴＯＳ１６ａを起動する動作モードである。第１ＣＰＵ１は、複数のＯＳのうちで起動時間の速い第１のＲＴＯＳ１６ａ（第１のＯＳ）を起動して、システム状態を示す動作モードをその第１のＲＴＯＳ１６ａに検出させる。動作モードの検出結果が、動作モード０の場合、第１ＣＰＵ１は、フラッシュメモリ１６に格納されている第１のＲＴＯＳ１６ａを図１に示すＳＤＲＡＭ１７にロードして起動する。図２（ａ）では、第１ＳＤＲＡＭ１７にロードされた第１のＲＴＯＳ１６ａを第１ＣＰＵ１が使用することを概念的に表している。つまり、動作モード０では、最初に起動時間が最速の第１のＲＴＯＳ１６ａを起動することで、起動時間の効率化を図る。

図２（ｂ）は、動作モード１のシステム構成例を示す概念図である。動作モード１は、第１のＲＴＯＳ１６ａと、第１の汎用ＯＳ１６ｃ（Ｌｉｎｕｘ）を起動する動作モードである。ここで、動作モードの検出結果が動作モード１の場合、第１ＣＰＵ１は、第２ＣＰＵ２で起動する第１の汎用ＯＳ１６ｃを選択する。これにより、第１ＣＰＵ１は、第１のＲＴＯＳ１６ａを起動し、第２ＣＰＵ２は、その第１のＲＴＯＳ１６ａよりも起動時間の遅い第１の汎用ＯＳ１６ｃを起動する。

具体的には、第１ＣＰＵ１は、図２（ａ）に示す動作モード０と同様、第１のＲＴＯＳ１６ａを起動する。また、第２ＣＰＵ２は、フラッシュメモリ１６に格納されている第１の汎用ＯＳ１６ｃをＳＤＲＡＭ１７にロードして起動する。図２（ｂ）では、第１ＳＤＲＡＭ１７にロードされた第１のＲＴＯＳ１６ａを第１ＣＰＵ１が使用し、ＳＤＲＡＭ１７にロードされた第１の汎用ＯＳ１６ｃ（Ｌｉｎｕｘ）を第２ＣＰＵ２が使用することを概念的に表している。

なお、動作モード１の場合、第２ＣＰＵ２は、第１のＲＴＯＳ１６ａよりも起動時間の遅い他の汎用ＯＳを起動しても良い。つまり、動作モード１では、起動時間が最速の第１のＲＴＯＳ１６ａを起動し、続いて、高機能な汎用ＯＳを起動することにより、起動時間の効率化を図ることができる。

また、動作モード１では、第１の汎用ＯＳの起動中に第１のＲＴＯＳ１６ａ側で発生した優先タスクの起動に応じて、第１の汎用ＯＳの起動を中断又は中止することができる（詳細は後述する）。また、動作モード１では、電子カメラ１００の撮影光学系１０の制御や、撮像素子１２の撮像制御、信号処理部１３内での画像信号の処理については、第１のＲＴＯＳ１６ａで実行する。一方、ＡＳＩＣ２３は、例えば、信号処理部１３が出力した画像データの画像処理については、第１の汎用ＯＳで実行する。すなわち、動作モード１では、ＡＳＩＣ２３の処理に応じて、ＯＳを使い分けることができる。

図２（ｃ）は、動作モード１のシステム構成例（変形例）を示す概念図である。動作モードの検出結果が動作モード１の場合、第１ＣＰＵ１は、第１のＲＴＯＳ１６ａを起動し、第２ＣＰＵ２は、例えば第１のＳＰ１６ｅと第１の汎用ＯＳ１６ｃのカーネル部分とを起動しても良い。

具体的には、第１ＣＰＵ１は、第１のＲＴＯＳ１６ａをＳＤＲＡＭ１７にロードして起動する。また、第２ＣＰＵ２は、フラッシュメモリ１６に格納されている第１のＳＰ１６ｅ（ユーザランド部分）と第１の汎用ＯＳ１６ｃのカーネル部分とをＳＤＲＡＭ１７にロードして起動する。図２（ｃ）では、第１ＳＤＲＡＭ１７にロードされた第１のＲＴＯＳ１６ａを第１ＣＰＵ１が使用し、ＳＤＲＡＭ１７にロードされた第１の汎用ＯＳ１６ｃ（カーネル部）及び第１のＳＰ１６ｅ（ユーザランド部分）からなるＬｉｎｕｘを第２ＣＰＵ２が使用することを概念的に表している。

なお、第２ＣＰＵ２は、必要に応じてフラッシュメモリ１６に格納されている第１のＳＰ１６ｅ或いは第２のＳＰ１６ｆをＳＤＲＡＭ１７にロードして起動しても良いし、又は、第２ＣＰＵ２は、必要に応じて第１のＳＰ１６ｅ、第２のＳＰ１６ｆをＳＤＲＡＭ１７にロードして起動しても良い。つまり、動作モード１の変形例では、汎用ＯＳの起動の高速化を実現できる。

図３（ａ）は、動作モード２のシステム構成例を示す概念図である。動作モード２は、第１のＲＴＯＳ１６ａ及び第２のＲＴＯＳ１６ｂを起動する動作モードである。ここで、動作モードの検出結果が動作モード２の場合、第１ＣＰＵ１は、第２ＣＰＵ２で起動する第２のＲＴＯＳ１６ｂを選択する。これにより、第１ＣＰＵ１は、第１のＲＴＯＳ１６ａを起動し、第２ＣＰＵ２は、その第１のＲＴＯＳ１６ａよりも起動時間の遅い第２のＲＴＯＳ１６ｂを起動する。そのため、動作モード２では、動作モード１と同様、起動時間が最速の第１のＲＴＯＳ１６ａを起動し、続いて、第２のＲＴＯＳ１６ｂを起動することにより、起動時間の効率化を図ることができる。具体的には、第１ＣＰＵ１は、第１のＲＴＯＳ１６ａをＳＤＲＡＭ１７にロードして起動する。また、第２ＣＰＵ２は、フラッシュメモリ１６に格納されている第２のＲＴＯＳ１６ｂをＳＤＲＡＭ１７にロードして起動する。図３（ａ）では、第１ＳＤＲＡＭ１７にロードされた第１のＲＴＯＳ１６ａを第１ＣＰＵ１が使用し、ＳＤＲＡＭ１７にロードされた第２のＲＴＯＳ１６ｂを第２ＣＰＵ２が使用することを概念的に表している。なお、第２のＲＴＯＳ１６ｂは、例えば、高精度なレンズ駆動やＡＦ演算等の処理を行なう。つまり、動作モード２では、動作モード１と同様、ＡＳＩＣ２３の処理に応じて、ＯＳを使い分けることができる。

図３（ｂ）は、動作モード３のシステム構成例を示す概念図である。動作モード３は、第１のＲＴＯＳ１６ａ、第２のＲＴＯＳ１６、第１の汎用ＯＳ１６ｃを起動する動作モードである。動作モードの検出結果が動作モード３の場合、第１ＣＰＵ１は、第１のＲＴＯＳ１６ａを起動し、第２ＣＰＵ２は、第２のＲＴＯＳ１６ｂを起動し、第３ＣＰＵ３は、第１の汎用ＯＳ１６ｃを起動する。

具体的には、第１ＣＰＵ１は、第１のＲＴＯＳ１６ａをＳＤＲＡＭ１７にロードして起動する。また、第２ＣＰＵ２は、第２のＲＴＯＳ１６ｂをＳＤＲＡＭ１７にロードして起動する。さらに、第３ＣＰＵ３は、第１の汎用ＯＳ１６ｃをＳＤＲＡＭ１７にロードして起動する。

図３（ｂ）では、第１ＳＤＲＡＭ１７にロードされた第１のＲＴＯＳ１６ａを第１ＣＰＵ１が使用し、ＳＤＲＡＭ１７にロードされた第２のＲＴＯＳ１６ｂを第２ＣＰＵ２が使用し、ＳＤＲＡＭ１７にロードされた第１の汎用ＯＳ１６ｃ（Ｌｉｎｕｘ）を第３ＣＰＵ３が使用することを概念的に表している。つまり、動作モード３では、動画撮影等の処理の機能を第１の汎用ＯＳ１６ｃを用いて実行するのに適している。また、一例として、高精度なレンズ駆動やＡＦ演算等の処理、撮影された記録用の画像を無線ＬＡＮ通信で外部に送信する送信処理を行なう場合には、第３のモードを選択することが好ましい。すなわち、動作モード３では、高精度なレンズ駆動やＡＦ演算等の処理を行なうため、第２のＲＴＯＳ１６ｂを起動し、送信処理を行なうため、第１の汎用ＯＳ１６ｃ（Ｌｉｎｕｘ）を起動しても良い。また、動作モード３では、第１のＲＴＯＳ１６ａは、撮影光学系１０が有するレンズ情報を解析しても良い。第２ＣＰＵ２は、レンズ情報の解析結果に基づいて、第２のＲＴＯＳ１６ｂと第１の汎用ＯＳ１６ｃ（Ｌｉｎｕｘ）との何れか一方を起動しても良い。従って、動作モード３では、各々の処理に適したＯＳを効率良く使い分けて起動できる。

図３（ｃ）は、動作モード４のシステム構成例を示す概念図である。動作モード４は、第１の汎用ＯＳ１６ｃを複数の制御部（第２ＣＰＵ２及び第３ＣＰＵ３）で共有して管理（使用）する動作モードである。ここで、動作モードの検出結果が動作モード４の場合、第１ＣＰＵ１は、複数の制御部（第２ＣＰＵ２及び第３ＣＰＵ３）で起動する第１の汎用ＯＳ１６ｃを選択する。これにより、第１ＣＰＵ１は、第１のＲＴＯＳ１６ａを起動し、第２ＣＰＵ２及び第３ＣＰＵ３は、第１の汎用ＯＳ１６ｃを起動する。ここで、動作モード４は、例えば、個々のＣＰＵが対等の条件でメモリを共有する並列処理方式の対称型マルチプロセッシング（ＳＭＰ：Symmetric Multiprocessing）である。

図３（ｃ）では、第１ＳＤＲＡＭ１７にロードされた第１のＲＴＯＳ１６ａを第１ＣＰＵ１が使用し、ＳＤＲＡＭ１７にロードされた第２のＲＴＯＳ１６ｂを第２ＣＰＵ２及び第３ＣＰＵ３が対称型マルチプロセッシングにより使用することを概念的に表している。なお、第１ＣＰＵ１は、第２ＣＰＵ２及び第３ＣＰＵ３で起動する汎用ＯＳとして、例えば、第１のＳＰ１６ｅ、第２のＳＰ１６ｆの何れかを選択しても良い。

具体的には、第１ＣＰＵ１は、第１のＲＴＯＳ１６ａをＳＤＲＡＭ１７にロードして起動する。また、第２ＣＰＵ２及び第３ＣＰＵ３は、第１の汎用ＯＳ１６ｃをＳＤＲＡＭ１７にロードして起動する。そのため、動作モード４では、動作モード１と同様、最初に起動時間が最速の第１のＲＴＯＳ１６ａを起動し、続いて、第１の汎用ＯＳ１６ｃを起動することにより、起動時間の効率化を図ることができる。つまり、動作モード４は、例えば、第１の汎用ＯＳ１６ｃの並列処理に優れている。

次に、本実施形態の電子カメラ１００におけるＯＳの起動処理の一例を説明する。図４は、電子カメラ１００の電源オン時における動作の一例を示すフローチャートである。ここで、操作部１９が電子カメラ１００の電源オンの指示入力を受け付けた場合、ＡＳＩＣ２３の第１ＣＰＵ１は、図４に示すフローの処理を開始させる。図４では、動作モード１の場合について例示する。そのため、先ず第１ＣＰＵ１側のフローの処理を説明した後、第２ＣＰＵ２側のフローの処理を説明する。なお、動作モード２〜４の場合についても、基本的に動作モード１の場合のフロー処理と同様である。

ステップＳ１０１：第１ＣＰＵ１は、ＣＰＵ識別番号（ＣＰＵＩＤ）の確認をし、ＲＴＯＳ１の起動処理を開始する。具体的には、マルチコアシステムを採用しているため、各々のＣＰＵがどの識別番号に属するＣＰＵであるのかを確認する。第１ＣＰＵ１は、フラッシュメモリ１６に記録されているＣＰＵ識別番号を参照し、マスター側のＣＰＵであることを確認する。これにより、第１ＣＰＵ１は、第１のＲＴＯＳ１６ａの起動処理を開始する。すなわち、第１ＣＰＵ１は、フラッシュメモリ１６に格納されている第１のＲＴＯＳ１６ａをＳＤＲＡＭ１７にロードして起動する。

ステップＳ１０２：第１ＣＰＵ１は、第１のＲＴＯＳ１６ａの起動終了後に、動作モードを検出する。具体的には、第１ＣＰＵ１は、一例として、ユーザが前回電源をオフした際の、電子カメラ１００の動作モードをフラッシュメモリ１６に記録しておく。第１ＣＰＵ１は、第１のＲＴＯＳ１６ａの起動終了後に、フラッシュメモリ１６に記録されている動作モードを参照することにより検出する。

ステップＳ１０３：第１ＣＰＵ１は、動作モードに基づいて、ＯＳを選択し、起動するＣＰＵに起動許可通知を送信する。例えば、第１ＣＰＵ１は、動作モード１を検出する。これにより、第１ＣＰＵ１は、第２ＣＰＵ２で起動する第１の汎用ＯＳ１６ｃを選択する。そして、第１ＣＰＵ１は、第２ＣＰＵ２に起動許可通知を送信する。

ステップＳ１０４：第１ＣＰＵ１は、優先処理タスクの発生の有無を確認する。優先処理タスクは、第１ＣＰＵ１以外の第２ＣＰＵ２又は第３ＣＰＵ３の起動のタスクよりも優先度の高いタスクである。優先処理タスクは、例えば、静止画撮影又は動画撮影の指示入力、動作モードの変更、電源システムの異常状態の検出等がある。

ステップＳ１０５：第１ＣＰＵ１は、優先処理タスクの有無を判定する。優先処理タスクのイベントが発生した場合（ステップＳ１０５：Ｙｅｓ）、第１ＣＰＵ１は、ステップＳ１０６の処理に移行する。優先処理タスクのイベントが発生していない場合（ステップＳ１０５：Ｎｏ）、第１ＣＰＵ１は、ステップＳ１０４の処理を繰り返す。

ステップＳ１０６：第１ＣＰＵ１は、第２ＣＰＵ２に対して起動処理の中断（又は中止）通知を送信する。具体的には、第１ＣＰＵ１は、静止画撮影又は動画撮影の指示入力、電源システムの異常状態の検出の場合、起動処理の中断通知を送信する。一方、第１ＣＰＵ１は、動作モードの変更の場合、起動処理の中止（強制終了）通知を送信する。

ステップＳ１０７：第１ＣＰＵ１は、優先処理タスクの実行を行なう。そして、第１ＣＰＵ１は、優先処理タスクの終了後に第２ＣＰＵ２に対して再開通知の送信を行なう。

ステップＳ１０８：第１ＣＰＵ１は、第２ＣＰＵ２からの起動完了通知の受信待ちの処理を行なう。具体的には、起動完了通知を受信しない場合（ステップＳ１０８：Ｎｏ）、第１ＣＰＵ１は、ステップＳ１０８の処理を繰り返す。一方、起動完了通知を受信した場合（ステップＳ１０８：Ｙｅｓ）、第１ＣＰＵ１は、図４に示す第１ＣＰＵ１側のフローの処理を終了させる。

次に、第２ＣＰＵ２側のフローの処理を説明する。

ステップＳ２０１：第２ＣＰＵ２は、ＣＰＵ識別番号（ＣＰＵＩＤ）を確認する。第２ＣＰＵ２は、フラッシュメモリ１６に記録されているＣＰＵ識別番号を参照し、第１ＣＰＵ１の従属側のＣＰＵであることを確認する。

ステップＳ２０２：第２ＣＰＵ２は、起動許可通知の待ち状態に遷移する。

ステップＳ２０３：第２ＣＰＵ２は、第１ＣＰＵ１からの起動許可通知の受信待ちの処理を行なう。具体的には、起動許可通知を受信しない場合（ステップＳ２０３：Ｎｏ）、第１ＣＰＵ１は、ステップＳ２０３の処理を繰り返す。一方、起動許可通知を受信した場合（ステップＳ２０３：Ｙｅｓ）、第２ＣＰＵ２は、ステップＳ２０４の処理に移行する。

ステップＳ２０４：第２ＣＰＵ２は、汎用ＯＳの起動処理のサブルーチンを実行する（詳細は後述する）。

ステップＳ２０５：第２ＣＰＵ２は、ＯＳ起動完了通知の送信を行なう。そして、第２ＣＰＵ２は、図４に示す第２ＣＰＵ２側のフローの処理を終了させる。

次に、汎用ＯＳの起動処理について説明する。図５は、汎用ＯＳの起動処理のサブルーチンを示すフローチャートである。

ステップＳ３０１：第２ＣＰＵ２は、第１の汎用ＯＳ１６ｃの起動処理を開始する。具体的には、第２ＣＰＵ２は、フラッシュメモリ１６に格納されている第１の汎用ＯＳ１６ｃをＳＤＲＡＭ１７にロードする処理を開始する。

図６は、第１の汎用ＯＳ１６ｃの起動処理を説明する概念図である。第１ＣＰＵ１は、既に第１のＲＴＯＳ１６ａを起動している。そこで、第１ＣＰＵ１は、第１のＲＴＯＳ１６ａ上で動作する第１のアプリケーションプログラム（第１のＡｐｐｌ）を起動して、フラッシュメモリ１６に格納されている第１の汎用ＯＳ１６ｃ（Ｌｉｎｕｘ）のカーネル部分をＳＤＲＡＭ１７にロードする処理を開始する。

続いて、第１ＣＰＵ１は、第１のアプリケーションプログラムを用いて、例えば第１のＳＰ１６ｅと第２のＳＰ１６ｆとの何れか一方のユーザランドをＳＤＲＡＭ１７にロードする処理を開始する。これにより、第２ＣＰＵ２は、Ｌｉｎｕｘ上で動作する第２のアプリケーションプログラム（第２のＡｐｐｌ）を起動する。

ステップＳ３０２：第２ＣＰＵ２は、起動完了を監視する。そして、起動完了した場合（ステップＳ３０２：Ｙｅｓ）、第２ＣＰＵ２は、図５に示すサブルーチンのフローの処理を終了して、図４に示すステップＳ２０５の処理に移行する。一方、起動完了していない場合（ステップＳ３０２：Ｎｏ）、第２ＣＰＵ２は、ステップＳ３０３の処理に移行する。

ステップＳ３０３：第２ＣＰＵ２は、第１ＣＰＵ１側から中止通知を受信したか否かの有無を判定する。中止通知を受信した場合（ステップＳ３０３：Ｙｅｓ）、第２ＣＰＵ２は、ステップＳ３０９の処理に移行する。そして、第２ＣＰＵ２は、第１の汎用ＯＳ１６ｃの起動処理を強制終了する。そして、第２ＣＰＵ２は、図４に示す第２ＣＰＵ２側のフローの処理を終了させる（ステップＳ３０９）。この場合、第１ＣＰＵ１は、中止通知を第２ＣＰＵ２に送信しているので、図４に示すステップＳ１０７の再開通知送信の処理と、ステップＳ１０８の完了通知の受信の処理とをスキップする。一方、中止通知を受信していない場合（ステップＳ３０３：Ｎｏ）、第２ＣＰＵ２は、ステップＳ３０４の処理に移行する。

ステップＳ３０４：第２ＣＰＵ２は、第１ＣＰＵ１側から中断通知を受信したか否かの有無を判定する。中断通知を受信していない場合（ステップＳ３０４：Ｎｏ）、第２ＣＰＵ２は、ステップＳ３０２の処理に戻る。一方、中断通知を受信した場合（ステップＳ３０４：Ｙｅｓ）、第２ＣＰＵ２は、ステップＳ３０５の処理に移行する。

ステップＳ３０５：第２ＣＰＵ２は、第１の汎用ＯＳ１６ｃの起動処理を中断して、再開待ち状態に遷移する。そして、第２ＣＰＵ２は、ステップＳ３０６の処理に移行する。

ステップＳ３０６：第２ＣＰＵ２は、第１ＣＰＵ１側から再開通知を受信したか否かの有無を判定する。再開通知を受信していない場合（ステップＳ３０６：Ｎｏ）、第２ＣＰＵ２は、ステップＳ３０６の処理を繰り返す。一方、再開通知を受信した場合（ステップＳ３０６：Ｙｅｓ）、第２ＣＰＵ２は、ステップＳ３０７の処理に移行する。

ステップＳ３０７：第２ＣＰＵ２は、第１の汎用ＯＳ１６ｃの起動処理を再開する。そして、第２ＣＰＵ２は、ステップＳ３０８の処理に移行する。

ステップＳ３０８：第２ＣＰＵ２は、起動処理の終了を監視する。起動処理が完了していない場合（ステップＳ３０８：Ｎｏ）、第２ＣＰＵ２は、ステップＳ３０８の処理を繰り返す。一方、起動処理が完了した場合（ステップＳ３０８：Ｙｅｓ）、第２ＣＰＵ２は、図５に示すサブルーチンのフローの処理を終了して、図４に示すステップＳ２０５の処理に移行する。

以上、本実施形態の電子カメラ１００は、複数のＯＳの起動時間を効率化するための複数の動作モードを備える。また、電子カメラ１００は、汎用ＯＳのスナップショットイメージを作成して起動することにより、起動時間の高速化を行なうこともできる。さらに、電子カメラ１００は、汎用ＯＳの起動中に上述した優先処理タスクのイベントが発生した場合、汎用ＯＳの起動を中断すると共に、その優先処理タスクの終了後に、汎用ＯＳの起動を再開することができる。

これにより、本発明は、起動時間の異なる複数のＯＳに関し、複数のＯＳの起動時間の効率化を図る手段を提供できる。

（実施形態の補足事項）
（１）上記の実施形態では、汎用ＯＳとして、Ｌｉｎｕｘを用いて説明したが、汎用ＯＳは、Ｌｉｎｕｘに限られず、例えば、Ｗｉｎｄｏｗｓ（登録商標）、ＵＮＩＸ（登録商標）、ＪＡＶＡ（登録商標）等の他の汎用ＯＳであっても良い。

（２）上記の実施形態では、本発明の電子機器を搭載して電子カメラを例示したが、本発明の電子機器は、ＲＴＯＳと汎用ＯＳとを使用する電子機器であれば良く、例えば携帯電話であっても良い。

（３）上記の実施形態では、フラッシュメモリ１８は、内部の基本回路の構成によってＮＯＲ（否定論理和）型とＮＡＮＤ（否定論理積）型との何れかであって良い。なお、ＮＯＲ（否定論理和）型のフラッシュメモリの場合、第１ＣＰＵ１、第２ＣＰＵ２、第３ＣＰＵ３は、ＳＤＲＡＭ１７にロードせずに、ＲＴＯＳや汎用ＯＳを起動することができる。これにより、電子カメラ１００は、起動時間を高速化することができる。

１００・・・電子カメラ、１・・・第１ＣＰＵ、２・・・第２ＣＰＵ、３・・・第３ＣＰＵ、１６ａ・・・第１のＲＴＯＳ、１６ｂ・・・第２のＲＴＯＳ、１６ｃ・・・第１の汎用ＯＳ、１６ｄ・・・第２の汎用ＯＳ、１６ｅ・・・第１のＳＰ、１６ｆ・・・第２のＳＰ

Claims (13)

1. 起動時間の異なる複数のオペレーティングシステム（ＯＳ：Operating System）と、
   複数の前記ＯＳの何れかを選択して演算処理を実行する複数の制御部とを備え、
   複数の前記制御部のうちの主制御部は、複数の前記ＯＳのうちで起動時間の速い第１のＯＳを起動して、システム状態を示す動作モードを前記第１のＯＳに検出させると共に、前記第１のＯＳによる検出結果に基づいて、前記主制御部とは異なる他の制御部で起動するＯＳとして、前記第１のＯＳよりも起動時間の遅い他のＯＳを選択することを特徴とする電子機器。
2. 請求項１に記載の電子機器において、
   前記他のＯＳは、汎用ＯＳであって、
   前記主制御部は、前記検出結果が前記汎用ＯＳを起動する第１動作モードの場合、前記他の制御部で起動する前記汎用ＯＳを選択することを特徴とする電子機器。
3. 請求項２に記載の電子機器において、
   前記汎用ＯＳは、該汎用ＯＳの起動時間を短縮するスナップショットイメージとしてメモリに記録されており、
   前記他の制御部は、前記スナップショットイメージを起動することを特徴とする電子機器。
4. 請求項１に記載の電子機器において、
   前記他のＯＳは、タスクの実行時間を管理するリアルタイムＯＳであって、
   前記主制御部は、前記検出結果が前記リアルタイムＯＳを起動する第２の動作モードの場合、前記他の制御部で起動する前記リアルタイムＯＳを選択することを特徴とする電子機器。
5. 請求項１に記載の電子機器において、
   前記他のＯＳは、汎用ＯＳとタスクの実行時間を管理するリアルタイムＯＳとであって、
   前記主制御部は、前記検出結果が前記汎用ＯＳと前記リアルタイムＯＳとを起動する第３動作モードの場合、第１の前記他の制御部で起動する前記汎用ＯＳと第２の前記他の制御部で起動する前記リアルタイムＯＳとを選択することを特徴とする電子機器。
6. 請求項１に記載の電子機器において、
   前記他のＯＳは、汎用ＯＳであって、
   前記主制御部は、前記検出結果が前記汎用ＯＳを複数の前記他の制御部で共有して管理する第４動作モードの場合、複数の前記他の制御部で起動する前記汎用ＯＳを選択することを特徴とする電子機器。
7. 請求項６に記載の電子機器において、
   前記第４動作モードは、並列処理方式の対称型マルチプロセッシング（ＳＭＰ：Symmetric Multiprocessing）であることを特徴とする電子機器。
8. 請求項１から請求項７の何れか１項記載の電子機器において、
   前記主制御部は、前記第１のＯＳの起動後、前記他のＯＳの起動中に中断事由又は中止事由を前記第１のＯＳが検出した場合、前記他のＯＳの起動を中断又は中止することを特徴とする電子機器。
9. 請求項８に記載の電子機器において、
   前記主制御部は、前記他のＯＳの起動中に電源システムの異常状態を前記第１のＯＳが検出した場合、前記他のＯＳの起動を中断し、
   前記主制御部は、前記電源システムの正常状態を前記第１のＯＳが再度検出した場合、前記他のＯＳの起動を再開することを特徴とする電子機器。
10. 請求項８に記載の電子機器において、
    前記主制御部は、前記他のＯＳの起動中に前記動作モードの変更を前記第１のＯＳが検出した場合、起動中の前記他のＯＳを強制終了し、
    前記他の制御部は、前記動作モードに適した変更用の他のＯＳ又は予めメモリに記録されている前記変更用の前記他のＯＳの起動時間を短縮するスナップショットイメージを起動することを特徴とする電子機器。
11. 撮影光学系からの被写体光を撮像して画像を生成する撮像素子と、
    請求項１から請求項１０の何れか１項記載の電子機器と、
    を備えることを特徴とする電子カメラ。
12. 請求項１１に記載の電子カメラにおいて、
    前記主制御部は、前記他のＯＳの起動中に静止画撮影又は動画撮影の指示入力を検出した場合、前記他のＯＳの起動を中断し、
    前記主制御部は、前記静止画撮影又は前記動画撮影の実行後に、前記他のＯＳの起動を再開することを特徴とする電子カメラ。
13. 請求項１１又は請求項１２に記載の電子カメラにおいて、
    前記第１のＯＳは、前記撮影光学系が有するレンズ情報を解析し、
    前記他の制御部は、前記レンズ情報の解析結果に基づいて、汎用ＯＳとタスクの実行時間を管理するリアルタイムＯＳとの何れか一方を起動することを特徴とする電子カメラ。

Images