(57)【要約】【課題】  フラッシュロム上にダウンロードファイルを格納・管理するシステムで、ダウンロードの待ち時間が一定になるようにしたダウンロード方法を提供する。【解決手段】  ローカルＰＣ２０からＦＴＰでダウンロードプログラムファイルを受信して、主メモリ３上に形成したワークエリア１３に全てのデータを書き込み、フラッシュロム１４の管理領域の管理情報を参照して、以前のダウンロードプログラムファイルのデータが書き込まれている場合には、当該データを削除して管理情報の使用駒切れ情報、使用合計、空き駒切れ情報、空き合計を更新し、更に最新の管理情報を参照して、空きがあればダウンロードファイル名を登録し、空き駒切れ情報から空きセクターにデータの書き込みを行い、管理情報の使用駒切れ情報、使用合計、空き駒切れ情報、空き合計を更新し、ワークエリア１３を開放するものである。【選択図】        図５
2006318198.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークに接続する情報処理システムにおいて、ローカル装置からダウンロードプログラムファイルを受信してフラッシュロムに書き込むダウンロード方法であって、
主メモリ上に形成したワークエリアに全てのデータを書き込み、フラッシュロムの管理領域の管理情報を参照して、以前のダウンロードプログラムファイルのデータが書き込まれている場合には、当該データを削除して管理情報の使用駒切れ情報、使用合計、空き駒切れ情報、空き合計を更新し、更に管理情報を参照して、空きがあればダウンロードファイル名を登録し、空き駒切れ情報に基づいて空きセクターにデータの書き込みを行い、管理情報の使用駒切れ情報、使用合計、空き駒切れ情報、空き合計を更新し、ワークエリアを開放することを特徴とするダウンロード方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、フラッシュロム上にプログラムファイルをダウンロードする方法に係り、特に、ダウンロード時間を一定にするダウンロード方法に関する。
【背景技術】
【０００２】
ジャーナルフラッシュファイルシステム（ＪＦＦＳ：Journal Flash File System）はＵＮＩＸ（登録商標）系オペーティングシステム（ＯＳ）でフラッシュロムデバイス上に搭載されるファイル管理システムとして一般に知られている。
【０００３】
このＪＦＦＳによりＵＮＩＸ（登録商標）系ＯＳを搭載したシステムを利用するユーザはフラッシュロム上にファイルを作成すること、フラッシュロム上のファイルを参照・更新すること、フラッシュロム上のファイルを削除することは通常のディスクデバイス上のファイルと同様に扱うことができる。
【０００４】
近年組み込み型マイコンシステムにおいてもＵＮＩＸ（登録商標）系ＯＳが搭載され、ファイルの管理・プログラムの実行管理はＯＳを利用して行われるケースが増えている。
【０００５】
組み込み型マイコンシステムにおいては、一般にプログラムファイルはダウンロードプログラムによりローカルＰＣ（Personal Computer）からシステムに転送され、フラッシュロム上に格納される。
【０００６】
ＯＳを搭載した組み込み型マイコンシステムにおいても同様で、プログラム実行ファイルはＦＴＰ（File Transfer Protocol）というＯＳの機能を利用したファイル転送プログラムによりローカルＰＣ上のプログラムファイルをシステム内のフラッシュロムに格納している。
【０００７】
フラッシュロムにプログラムファイルを格納する時、このＪＦＦＳを利用している。従来のフラッシュロムへのプログラムファイルの格納について図１０を参照しながら説明する。図１０は、従来のフラッシュロムへのプログラムファイルの格納方法の概略図である。
従来のプログラムファイルの格納方法を実現する構成は、ソケットポインタ１１と、２５６ｂｙｔｅバッファ１２と、フラッシュ（Flash）ＲＯＭ１４を備える本体と、本体と外部とのインタフェースとなるＨＣＩ（Human Computer Interface）１０と、ローカルＰＣ２０とを有するシステムである。
【０００８】
上記従来のシステムでは、ローカルＰＣ２０のプログラムファイルから２５６ｂｙｔｅのデータがＦＴＰで転送され、ソケットポインタ１１が受信（ソケットｒｅａｄ）して２５６ｂｙｔｅバッファ１２に格納する。
そして、ＪＦＦＳは、２５６ｂｙｔｅバッファ１２から読み込んでフラッシュＲＯＭ１４に書き込む（フラッシュｗｒｉｔｅ）する。
従来のシステムでは、プログラムファイル終了まで、２５６ｂｙｔｅ単位のソケットｒｅａｄとフラッシュｗｒｉｔｅを繰り返すようになっている。
【０００９】
フラッシュロムデバイスは磁気ディスクデバイスと異なり１度書かれたデータの内容を変更するのに必ずイレーズ処理が必要となる。このためＪＦＦＳはフラッシュロムのイレーズ処理とガーベージコレクション処理（不要になったオブジェクトを集め再利用可能な状態に管理する機能）を内部に持っている。
【００１０】
そして、フラッシュロムの使用領域がなくなると使用不能領域のイレーズ処理を行い、ガーベージコレクションにより使用可能領域を作り出している。この処理に時間がかかるため磁気ディスクを持たない組み込み型マイコンシステムにおいてはフラッシュロムにはプログラムファイルと更新が入らない各種設定ファイルが置かれ、プログラムが実行中に使用する一時ファイルはラムディスク（ＲＡＭ上に作られたディスク）に置かれる。
【００１１】
イレーズ処理だけでもセクター当たり約１秒の時間がかかる。従って、ダウンロード中に使用領域がなくなると、このイレーズ処理とガーベージコレクション処理により、数秒から数十秒待たされ、この間ダウンロード処理が止まることになる。
【００１２】
次に、従来のフラッシュロムの領域におけるイレーズ処理とガーベージコレクション処理の発生例について図１１、図１２及び図１３を参照しながら説明する。図１１は、従来のフラッシュロムの領域の概略図であり、図１２は、無線通信プログラム実行ファイルの内容を示す図であり、図１３は、フラッシュのイレーズ処理とガーベージコレクション処理の発生例を示す概略図である。
【００１３】
図１１に示す、従来のフラッシュロムの領域は、８Ｍｂｙｔｅのフラッシュロム２個使用しており、全てＪＦＦＳの管理下に置かれていることを示している。
図１２では、無線通信プログラムの実行ファイルの内容と実行ファイル容量を示しており、容量の合計は５９９０Ｋｂｙｔｅである。
【００１４】
図１３では、イレーズ処理とガーベージコレクション処理が発生するタイミングを示すものである。ファイルの削除ではイレーズ処理は行われず、使用不能領域としているだけである。そして使用領域がなくなったとき初めてイレーズ処理・ガーベージコレクション処理が実行され、使用領域を確保している。
【００１５】
具体的には、フラッシュロムの領域で無線通信プログラム実行ファイル（以下、「実行ファイル」とする）を全て（５９９０Ｋｂｙｔｅ）を格納すると、余りは２０１０Ｋｂｙｔｅとなる。そして、ＬＡＮ（Local Area Network）  ＩＦ（Interface）サーバのプログラム変更が発生し、ダウンロードを実施すると、旧ＬＡＮ  ＩＦサーバの実行ファイルが削除され、新しいＬＡＮ  ＩＦサーバの実行ファイルが作成される。
【００１６】
ここで、図１３に示すように、新ＬＡＮ  ＩＦサーバの実行ファイルが１１５２Ｋｂｙｔｅであるとすると、旧ＬＡＮ  ＩＦサーバの実行ファイルの格納領域における１１５２Ｋｂｙｔｅを使用不能領域とし、余り部分（２０１０Ｋｂｙｔｅ）の内、１１５２Ｋｂｙｔｅを新ＬＡＮ  ＩＦサーバの実行ファイルの格納領域に割り当てる。すると、余りは、８５８Ｋｂｙｔｅとなる。
【００１７】
再度、ＬＡＮ  ＩＦサーバのプログラム変更が発生し、ダウンロードを実施する場合、前回作成された新ＬＡＮ  ＩＦサーバの実行ファイルが削除され、当該実行ファイルの格納領域が使用不能領域となる。
【００１８】
そして、余り領域８５８Ｋｂｙｔｅに、新々ＬＡＮ  ＩＦサーバの実行ファイルを作成しようとするが、当該実行ファイルが１１５２Ｋｂｙｔｅもあって余り領域に作成するには容量が不足するため、ここで、使用不能領域のイレーズ処理を行い使用可能にし、ガーベージコレクション処理を行うものである。
【００１９】
図１４には、図１１の環境で図１３に示したダウンロードを行った場合、ＬＡＮ  ＩＦサーバ実行ファイルの更新にかかった時間を示している。図１４は、イレーズ処理とガーベージコレクション処理に要する時間を示す説明図である。
図１４のダウンロード回数１回目は、図１３の中段の状況に相当し、以降ＬＡＮ  ＩＦサーバ実行ファイルのダウンロードが繰り返されている。
【００２０】
図１４からフラッシュロム上に十分な使用領域がある場合は、ダウンロードは５秒で終わり、ない場合はイレーズ処理とガーベージコレクション処理が発生し、この処理パターンには８秒で終わるパターン１と、１２秒で終わるパターン２と、１４０秒で終わるパターン３の３種類ある。イレーズ処理を含めたガーベージコレクション処理はいつも同じ処理を行っているのでなく、状況に応じて処理内容が変わっている。
【００２１】
つまり、フラッシュロムを用いているため、使用領域がなくなればイレーズ処理を行わなければならないが、セクター（１２８Ｋｂｙｔｅ）当たりイレーズ処理が約１秒とすると、使用不能となった１１５２ＫｂｙｔｅのＬＡＮ  ＩＦサーバ実行ファイルをイレーズするのに計算上では約１０秒かかる。
【００２２】
図１４の８秒と１２秒のイレーズ処理・ガーベージコレクション処理は、上記１０秒に近い値であるが、５回目の１４０秒と１０回目の１４２秒は異常な値である。ガーベージコレクション処理に多大な時間を要していると考えられるが、一般にシステムの特性を考慮しないガーベージコレクションを組み込むとシステムの速度低下を招くことが多いとされている。
【００２３】
尚、ソフトウェアのダウンロードに関する先行技術としては、特開２００４−１１８２９１号公報「ソフトウェア管理システム及び障害管理装置」がある。
この先行技術は、メーカサーバにおいて製品情報に対応するソフトウェアの情報及びソフトウェア自体を予め保持し、ソフトウェア提供手段が、任意のユーザパソコンからの接続に対応し、ユーザパソコンから送信される個人情報、電子メールアドレス及び製品情報を管理し、製品情報に対応するソフトウェアの情報から対応するソフトウェア自体をユーザパソコンにダウンロードし、バージョンアップ通知手段が、バージョンアップされたソフトウェアをダウンロードしたユーザパソコンに関するユーザパソコンの電子メールアドレス宛にバージョンアップを知らせるメールを送信するものとなっている（特許文献１）。
【００２４】
【特許文献１】特開２００４−１１８２９１号公報
【発明の開示】
【発明が解決しようとする課題】
【００２５】
ＪＦＦＳにどのようなガーベージコレクションが組み込まれているか詳細はわからないが、もしこれを変更するとなればファイル管理システムというシステムの一部を変更することになり、ＯＳ全体の構造を把握していないと不可能であり、更に使用するフラッシュロムデバイスの種類によっても最適なガーベージコレクションが変わってくることを考えれば、技術的な面及び変更工数に多大な負担がかかり事実上不可能といえる。しかし、ダウン口−ドがあるタイミングで１４０秒待たされることはシステム的に大きな問題である。
【００２６】
本発明は上記実情に鑑みて為されたもので、ＵＮＩＸ（登録商標）系ＯＳ及びＪＦＦＳを使ってフラッシュロム上にダウンロードファイルを格納・管理するシステムにおいて、フラッシュロム上の使用領域がなくなるとイレーズ処理・ガーベージコレクション処理が発生する場合に、あるタイミングでダウンロード処理が長い間待たされてしまうという問題を解決し、ダウンロードの待ち時間の変動をなくして常に待ち時間が一定になるようにしたダウンロード方法を提供することを目的とする。
【課題を解決するための手段】
【００２７】
上記従来例の問題点を解決するための本発明は、ネットワークに接続する情報処理システムにおいて、ローカル装置からダウンロードプログラムファイルを受信してフラッシュロムに書き込むダウンロード方法であって、主メモリ上に形成したワークエリアに全てのデータを書き込み、フラッシュロムの管理領域の管理情報を参照して、以前のダウンロードプログラムファイルのデータが書き込まれている場合には、当該データを削除して管理情報の使用駒切れ情報、使用合計、空き駒切れ情報、空き合計を更新し、更に管理情報を参照して、空きがあればダウンロードファイル名を登録し、空き駒切れ情報に基づいて空きセクターにデータの書き込みを行い、管理情報の使用駒切れ情報、使用合計、空き駒切れ情報、空き合計を更新し、ワークエリアを開放することを特徴とする。
【発明の効果】
【００２８】
本発明によれば、ネットワークに接続する情報処理システムにおいて、ローカル装置からダウンロードプログラムファイルを受信してフラッシュロムに書き込むダウンロード方法であって、主メモリ上に形成したワークエリアに全てのデータを書き込み、フラッシュロムの管理領域の管理情報を参照して、以前のダウンロードプログラムファイルのデータが書き込まれている場合には、当該データを削除して管理情報の使用駒切れ情報、使用合計、空き駒切れ情報、空き合計を更新し、更に管理情報を参照して、空きがあればダウンロードファイル名を登録し、空き駒切れ情報に基づいて空きセクターにデータの書き込みを行い、管理情報の使用駒切れ情報、使用合計、空き駒切れ情報、空き合計を更新し、ワークエリアを開放するものであり、フラッシュロムへのダウンロードの待ち時間を一定にしてダウンロードに長く待たされることを回避できる効果がある。
【発明を実施するための最良の形態】
【００２９】
本発明の実施の形態について図面を参照しながら説明する。
本発明の実施の形態に係るフラッシュロムへのダウンロード方法は、ローカルＰＣからＦＴＰでダウンロードプログラムファイルを受信して、主メモリ上に形成したワークエリアに全てのデータを書き込み、フラッシュロムの管理領域の管理情報を参照して、以前のダウンロードプログラムファイルのデータが書き込まれている場合には、当該データを削除して管理情報の使用駒切れ情報、使用合計、空き駒切れ情報、空き合計を更新し、更に最新の管理情報を参照して、空きがあればダウンロードファイル名を登録し、空き駒切れ情報から空きセクターにデータの書き込みを行い、管理情報の使用駒切れ情報、使用合計、空き駒切れ情報、空き合計を更新し、ワークエリアを開放するものであり、これにより、フラッシュロムへのダウンロードの待ち時間を一定にしてダウンロードに長く待たされることを回避できるものである。
【００３０】
本発明の実施の形態に係るＵＮＩＸ（登録商標）系ＯＳ及びＪＦＦＳを使ってフラッシュロム上にダウンロードファイルを格納・管理するシステムにおいて、主装置のコンピュータの内部構成について図１を参照しながら説明する。図１は、主装置のコンピュータの内部構成ブロック図である。
主装置のコンピュータは、プログラムファイルのダウンロード処理を実行する主制御部（ＭＰＵ：Micro Processing Unit）１と、ＬＡＮに接続するＬＡＮインタフェース２と、後述するバッファとワークエリアが設けられるメインメモリ（ＳＤＲＡＭ：Synchronous DRAM）３と、ダウンロードされたプログラムファイルが格納されるフラッシュロム（ＦＬＡＳＨ）４と、それらを接続するバス５とを基本的に有している。
尚、ＬＡＮインタフェース２は、ネットワークを介して外部のローカルＰＣに接続している。
また、フラッシュロム４は、図１に示すように、複数個によって構成されている。
【００３１】
本発明の実施の形態に係るダウンロード方法において、ダウンロードファイルはプログラムを実行するとき一度リードされ、それ以降はアクセスされないものである。更新は、プログラムの変更が入る時のみダウンロードで更新される。このことを考慮すればダウンロードファイルはＪＦＦＳを使ってファイル管理システムのもとで管理する必要性はないものである。
【００３２】
本発明の実施の形態におけるフラッシュロムの領域について図２を参照しながら説明する。図２は、本発明の実施の形態に係るフラッシュロムの領域を示す概略図である。尚、図２では、８Ｍｂｙｔｅのフラッシュロムデバイス２個を用いた例を示している。
図２に示すように、本発明の実施の形態におけるフラッシュロムの領域は、８Ｍｂｙｔｅずつアプリケーションから直接制御する領域と、ＪＦＦＳ管理領域とに分けている。
【００３３】
アプリケーションから直接制御する領域には更新が入るプログラムの実行ファイルを置き、ＪＦＦＳ管理領域にはサービスプログラムやＯＳがアクセスする各種設定ファイルを置くようにする。
このアプリケーションから直接制御する領域を１６ｋｂｙｔｅが８個、１２８ｋｂｙｔｅが６３個に分割（セクター単位で分割）し、最初の１２８ｋｂｙｔｅに管理情報を置き、１６ｋｂｙｔｅの駒切れ８個と１２８ｋｂｙｔｅの駒切れ６２個の管理を行う。以降、管理情報が格納された最初の１２８ｋｂｙｔｅの領域を単に「管理領域」と呼ぶ。
【００３４】
次に、アプリケーションから直接制御する領域における最初の１２８ｋｂｙｔｅの管理領域とデータが格納されるデータ領域の関係について、図３を参照しながら説明する。図３は、管理領域とデータ領域を示す概略図である。
管理情報は、どのファイルがどの駒切れを何ｂｙｔｅ使用中であるか、複数の駒切れを使用中であればどの順番で使用しているのか、現在未使用の駒切れは何かを明確にするものである。
【００３５】
図３では、管理情報における使用情報として、格納されるファイル名に対してその容量と、使用駒切れの情報（１２８ｋｂｙｔｅの駒切れ（１）〜（９）の順で使用中であることを示す情報）が設定され、未使用情報として、空き駒切れの情報（１２８ｋｂｙｔｅの駒切れ（１０）〜（６２）と１６ｋｂｙｔｅの駒切れ［１］〜［８］）が設定されている。
また、データ領域では、管理情報に従って使用中の駒切れの領域と未使用の駒切れ領域とを含んでいる。
【００３６】
従来のダウンロード方法におけるフラッシュロムへの書き込み（フラッシュライト）は、ＯＳとＪＦＦＳの機能を利用しているが、本発明の実施の形態では、これに代わるプログラム（以下、「フラッシュファイル制御関数」と呼ぶ）を作成し、当該フラッシュファイル制御関数に基づいて制御部のＭＰＵが制御を行うものである。
【００３７】
フラッシュファイル制御関数の種類と内容について図４を参照しながら説明する。図４は、フラッシュファイル制御関数の種類と内容を示す図である。
フラッシュファイル制御関数は、図４に示すように、フラッシュファイルオープンと、フラッシュファイルライトと、フラッシュファイルクローズと、フラッシュファイルデリートと、フラッシュファイルリードがあり、それら関数の内容に従って制御部のＭＰＵが処理を実行するものである。
【００３８】
フラッシュファイルオープンは、フラッシュロムの管理領域における管理情報から空き領域の合計を調べ、空き領域があればファイル名にダウンロードファイル名を登録する処理を実行させる関数である。
【００３９】
フラッシュファイルライトは、フラッシュロムの管理領域における管理情報の空き駒切れ情報から空きセクターを見つけてデータをライト（書き込み）し、ライトしたら管理領域の管理情報に空き駒切れ・空きの合計・使用駒切れの値を更新する処理を実行させる関数である。
【００４０】
フラッシュファイルクローズは、フラッシュロムの管理領域における管理情報の使用駒切れの合計を計算し、その容量を設定する処理を実行させる関数である。
【００４１】
フラッシュファイルデリートは、フラッシュロムの管理領域における管理情報の使用駒切れに該当するセクターをイレーズ（消去）して、空き駒切れに戻し、管理領域における管理情報のファイル名・容量・使用駒切れをクリアし、空き駒切れ・空き領域を更新する処理を実行させる関数である。
【００４２】
フラッシュファイルリードは、フラッシュロムの管理領域における管理情報の使用駒切れに該当するセクターを順番に読んでラムディスク上の該当ファイルに書き込んでいく処理を実行させる関数である。
【００４３】
本発明の実施の形態に係るダウンロード方法について図５を参照しながら説明する。図５は、本発明の実施の形態に係るフラッシュロムへのプログラムファイルの格納方法の概略図である。
本発明の実施の形態に係るプログラムファイルの格納方法を実現する構成は、ソケットポインタ１１と、２５６ｂｙｔｅバッファ１２と、ワークエリア１３と、フラッシュ（Flash）ＲＯＭ１４を備える本体と、本体と外部とのインタフェースとなるＨＣＩ（Human Computer Interface）１０と、ローカルＰＣ２０とを有するシステムである。
ここで、２５６ｂｙｔｅバッファ１２とワークメモリ１３は、図１の主メモリ３に設けられるものである。
【００４４】
上記本発明の実施の形態に係るシステム（本システム）におけるダウンロード方法（本ダウンロード方法）は、図５に示すように、ローカルＰＣ２０のプログラムファイルから２５６ｂｙｔｅのデータがＦＴＰで転送され、ソケットポインタ１１が受信（ソケットｒｅａｄ）して２５６ｂｙｔｅバッファ１２に格納する。
【００４５】
そして、ＭＰＵ１は、２５６ｂｙｔｅバッファ１２からダウンロードプログラムファイルを一旦主メモリ３上のワークエリア１３に格納（ｗｒｉｔｅ）する。２５６ｂｙｔｅバッファ１２からデータがワークエリア１３に格納されると、ソケットｒｅａｄして、２５６ｂｙｔｅバッファ１２からワークエリア１３へのデータ格納を繰り返す。
【００４６】
すべてのデータのワークエリア１３への格納が終了した後に、ワークエリア１３からフラッシュロム（Flash Rom）１４におけるアプリケーションから直接制御する領域にフラッシュファイル制御関数を使用してデータを移動する。
データの移動が終了すると、主メモリ３上のワークエリア１３内のデータを消去する。
【００４７】
次に、本ダウンロード方法について図面を用いて説明する。
本ダウンロード方法を説明する前に、比較参考のため、従来のダウンロード方法について図６を参照しながら説明する。図６は、従来のダウンロード方法の処理を示すフローチャートである。
従来（現状）のダウンロード方法は、フラッシュロム１４上にダウンロードプログラムファイルを作成し、オープンをかける（Ｓ１）。ローカルＰＣ２０をＦＴＰ接続する（Ｓ２）。そして、ＦＴＰで２５６ｂｙｔｅのデータを受信する（ソケットｒｅａｄ）（Ｓ３）。
【００４８】
次に、受信したデータについて、データ（プログラムファイル）の最後であるか否かを判定する（Ｓ４）。
判定処理Ｓ４で、データの最後でなければ（Ｎｏの場合）、受信したデータをフラッシュロム１４上のダウンロードファイルに書き込む（Ｓ５）。そして、処理Ｓ３に戻る。
【００４９】
また、判定処理Ｓ４で、データの最後であれば（Ｙｅｓの場合）、ローカルＰＣ２０の接続を切断し（Ｓ６）、フラッシュロム１４上のダウンロードプログラムファイルをクローズする（Ｓ７）。
【００５０】
これに対して、本ダウンロード方法について図７及び図８を参照しながら説明する。図７は、本発明の実施の形態に係るダウンロード方法の処理の前半を示すフローチャートであり、図８は、本発明の実施の形態に係るダウンロード方法の処理の後半を示すフローチャートである。尚、図７の（Ａ）と図８の（Ａ）は接続するものである。
【００５１】
本ダウンロード方法は、図７及び図８に示すように、主メモリ３上にダウンロードプログラムファイルと同等の容量のワークエリア１３を作成する（Ｓ１１）。
次に、ローカルＰＣ２０をＦＴＰ接続する（Ｓ１２）。そして、ＦＴＰで２５６ｂｙｔｅのデータを受信する（ソケットｒｅａｄ）（Ｓ１３）。
【００５２】
次に、受信したデータについて、データ（プログラムファイル）の最後であるか否かを判定する（Ｓ１４）。
判定処理Ｓ１４で、データの最後でなければ（Ｎｏの場合）、受信したデータを主メモリ３上のワークエリア１３に書き込む（Ｓ１５）。そして、処理Ｓ１３に戻る。
【００５３】
また、判定処理Ｓ１４で、データの最後であれば（Ｙｅｓの場合）、ローカルＰＣ２０の接続を切断し（Ｓ１６）、フラッシュファイルデリート関数（引数にダウンロードファイル名を指定）をコールし、フラッシュロム１４上に作成されている現状のダウンロードファイルデータを削除する（Ｓ１７）。
【００５４】
続いて、フラッシュファイルオープン関数（引数にダウンロードファイル名を指定）をコールし、フラッシュロム１４上の管理領域にダウンロードファイル名を登録する（Ｓ１８）。
なお、オープンの前に、フラッシュロムの管理領域における空きの合計を調べて、空きがある場合に、ダウンロードファイル名の登録が為されるものである。
【００５５】
そして、フラッシュファイルライト関数（引数にダウンロードファイル名と主メモリ３上のワークエリア１３の先頭アドレスと受信データのトータル数を指定）をコールし、フラッシュロム１４上のデータ領域にダウンロードファイルの全てのデータを書き込む（Ｓ１９）。
この書き込みの際には、管理領域の駒切れ情報から空きセクターを見つけて、書き込み対象のセクターを特定し、ライトしたら管理領域の空き駒切れ、空きの合計、使用駒切れの値を更新するようになっている。
【００５６】
次に、フラッシュファイルクローズ関数（引数にダウンロードファイル名を指定）をコールし、フラッシュロム１４上の管理領域にダウンロードファイルのデータ容量を書き込む（Ｓ２０）。
そして、先頭の処理Ｓ１１でとった（作成した）ワークエリア１３を開放する（Ｓ２１）。
このようにして、本ダウンロード方法の処理が為される。
【００５７】
以上、ダウンロードプログラムファイルをフラッシュロム１４上のアプリケーションから直接制御する領域に格納する方法を述べたが、次に、フラッシュロム１４上のアプリケーションから直接制御する領域に書かれたダウンロードプログラムの起動方法について図９を参照しながら説明する。図９は、ダウンロードプログラムの起動方法を示す概略図である。
【００５８】
起動は以下の手順に従う。
第１のステップとして、主メモリ３のラムディスク（ＲＡＭＤＩＳＫ）上にフラッシュロム１４にあるダウンロードされた実行ファイルを格納するファイル１５を作成する。
第２のステップとして、引数にダウンロードファイル名と、第１のステップで作成したラムディスク上のファイル名を指定してフラッシュファイルリード関数をＭＰＵ１のＨＣＩ１０がコールし、実行ファイルをラムディスク上のファイル１５にコピーする。
【００５９】
第３のステップとして、ラムディスク上に作成された実行ファイルを起動する。起動はＯＳの起動コマンドを使用する。
第４のステップとして、起動が終了したらラムディスク上に作成した実行ファイルを削除する。
以上の処理はＨＣＩ１０が行うものとする。
【００６０】
次に、本発明の実施の形態に係る方法と従来技術で説明したイレーズ処理とガーベージコレクション処理が短時間（８秒又は１２秒）で終了するパターンを比較する。
本発明の実施の形態に係る方法ではＦＴＰで取得したデータを一旦主メモリのワークエリアに格納しているため、この分時間のロス（１）が発生している。また、プログラム起動時にＯＳの起動コマンドが使用できるようにするため、ラムディスク上にファイル管理システムがアクセスできるプログラム実行ファイルを作成している。
【００６１】
ここで時間のロス（２）が発生している。ロス（１）とロス（２）の合計時間は従来技術のイレーズ処理・ガーベージコレクション処理にかかる時間と同レベルか、それ以下である。
更に、ロス（１）とロス（２）の合計時間がシステムに与える影響は従来技術の説明で記述したパターン３のイレーズ処理とガーベージコレクション処理でダウンロードが待たされる時間に比べれば極めて小さいと言える。
また、図９に示したフラッシュファイル制御関数はフラッシュロムデバイスメーカが出しているデータシート（仕様を記載）を見れば容易に作成できるものである。
【００６２】
本ダウンロード方法によれば、ＯＳを搭載した組み込み型マイコンシステムにおいてダウンロードファイルをフラッシュロム上に持つ場合、ＦＴＰと本発明の実施の形態に係るフラッシュファイル制御関数を使用することにより、ダウンロード時間を一定にすることができる効果がある。
これにより、従来のダウンロード方法において、ＦＴＰとＪＦＦＳを使用してダウンロードを行った時に発生する長いダウンロード待ち時間を回避することができる効果がある。
【産業上の利用可能性】
【００６３】
本発明は、フラッシュロム上にダウンロードファイルを格納・管理するシステムにおいて、ダウンロードの待ち時間の変動をなくして常に待ち時間が一定になるようにしたダウンロード方法に好適である。
【図面の簡単な説明】
【００６４】
【図１】主装置のコンピュータの内部構成ブロック図である。
【図２】本発明の実施の形態に係るフラッシュロムの領域を示す概略図である。
【図３】管理領域とデータ領域を示す概略図である。
【図４】フラッシュファイル制御関数の種類と内容を示す図である。
【図５】本発明の実施の形態に係るフラッシュロムへのプログラムファイルの格納方法の概略図である。
【図６】従来のダウンロード方法の処理を示すフローチャートである。
【図７】本発明の実施の形態に係るダウンロード方法の処理の前半を示すフローチャートである。
【図８】本発明の実施の形態に係るダウンロード方法の処理の後半を示すフローチャートである。
【図９】ダウンロードプログラムの起動方法を示す概略図である。
【図１０】従来のフラッシュロムへのプログラムファイルの格納方法の概略図である。
【図１１】従来のフラッシュロムの領域の概略図である。
【図１２】無線通信プログラム実行ファイルの内容を示す図でである。
【図１３】フラッシュのイレーズ処理とガーベージコレクション処理の発生例を示す概略図である。
【図１４】イレーズ処理とガーベージコレクション処理に要する時間を示す説明図である。
【符号の説明】
【００６５】
１…ＭＰＵ、  ２…ＬＡＮインタフェース、  ３…主メモリ、  ４…フラッシュロム、  ５…バス、  １０…ＨＣＩ、  １１…ソケットポインタ、  １２…２５６ｂｙｔｅバッファ、  １３…ワークエリア、  １４…フラッシュロム、  １５…実行ファイル、  ２０…ローカルＰＣ
【図１】
2006318198.tif 000003
【図２】
2006318198.tif 000004
【図３】
2006318198.tif 000005
【図４】
2006318198.tif 000006
【図５】
2006318198.tif 000007
【図６】
2006318198.tif 000008
【図７】
2006318198.tif 000009
【図８】
2006318198.tif 000010
【図９】
2006318198.tif 000011
【図１０】
2006318198.tif 000012
【図１１】
2006318198.tif 000013
【図１２】
2006318198.tif 000014
【図１３】
2006318198.tif 000015
【図１４】
2006318198.tif 000016