まどかの 日記

[2004/01/26〜2004/02/01の日記]
[2004/02/02〜2004/02/08の日記]
[2004/02/09〜2004/02/15の日記]
[2004/02/16〜2004/02/22の日記]
[2004/02/23〜2004/02/29の日記]
[2004/03/01〜2004/03/07の日記]
[2004/03/08〜2004/03/14の日記]
[2004/03/15〜2004/03/21の日記]
[2004/03/22〜2004/03/28の日記]
[2004/03/29〜2004/04/04の日記]
[2004/04/05〜2004/04/11の日記]
[2004/04/12〜2004/04/18の日記]
[2004/04/19〜2004/04/25の日記]
[2004/04/26〜2004/05/02の日記]
[2004/05/03〜2004/05/09の日記]
↑過去3ヶ月くらいの日記はこちら↑

まどかは「P/ECE Hand Book」を応援しています


0947
2004/05/16()
 ついにやりました\(T^T)/
 はい、今日はお昼くらいまでのんびり寝て、起きてからは早速P/ECEのMMC対応カーネルの続き。

 途中お腹が空いたので、雨の中近くの焼肉屋に昼食に行き、帰ってからはまたP/ECEの続き。
 今日は昨日までで判明したMMCからデータを読み込む部分の不具合を修正すべく、読み込みルーチンを重点的に見直して修正していった結果、なんとMMCからのpexファイルの起動に成功いたしました!

 バンザーイ!! <喜びすぎ(^^;

 読み込み部分の不具合は結構イージーミス的な計算間違いによるものでしたが、今となってはそんなことはどうでもよくて、MMC上のpexファイルが起動したという事実に喜び浮かれずにはいられないってなもんですよ!

 喜びながら相撲を見ている嫁さんのところに飛んでいって、成功をアピールしましたが、「はいはい、よかったね」で一蹴され、一時的にテンションが下がってしまいましたが、その程度でこの喜びの興奮は冷め切れるわけもなく、すぐさままたハイテンションに戻り、踊り狂ってました(^^; <おおげさ

 で、喜びもつかの間、色々pexファイルを起動していて確認をしていると、どうもある文字フォントだけが正しく表示されていない不具合発生。

 はじめは喜びの余韻で、それくらいは良しとするか! と、いきなり妥協してしまいましたが、だんだん冷静になってくると、そんな不具合は許されないということを思い出し、調査開始。

 どうも、8x16のASCII拡大フォントが化けているようで、このフォントはいぢっていないはずなので、化けるはずもないのですが、念のためフォントをインストールしなおしてみると、「書き込み中」の画面でフリーズしてしまうが、慎重に数分待ってからリセットしてみると、フォントが正しく直っていました。

 詳しい原因はよくわかりませんが、5x10&10x10の通常フォントを再配置してインストールすると、拡大フォントの領域まで破壊してしまうようですね。縮小フォントは影響無しです。

 というわけで、これでMMC対応カーネルは一応完成。

 それから勢いで、MMC対応MP3プレイヤーをMMC対応カーネル用に修正し始めたのですが、MP3プレイヤーは結構ややこしいことになっていて、起動時のヒープ領域が4096バイトしかないので、ヒープからMMC用のワークエリアを取ることができません。

 なので、カーネルのAPIを利用するのはやめて、前と同じようにpex内にMMCライブラリを組み込んで再コンパイル。今度はMMC対応カーネル側で見つかった不具合を修正したバージョンでのライブラリなので、なんと以前は全然鳴らなかったIODATAの128MBのMMCにも対応成功!!

 バンザーイ!! 
 
 これで、奮発して買った128MBのMMCが無駄にならずに済みます(T^T
 今日だけで2つもの目標が達成できて、もう、嬉しくてたまりません。

 ドキュメントがまだ全然できていないので、公開するのは数日後(または1週間くらい後かな(^^;)になってしまいますが、まずは喜びの報告まで。

 これでMP3もP/ECEのゲームもいーっぱい持ち歩けるようになるぞー! やったね。
 MMC上にデータファイルのセーブはできませんが、アクアプラスのコンテスト全作品とかが1枚のMMCに余裕で収まっちゃうのはすごいことだと思います。これで、デモにもかなり有効活用できるね。

 というわけで、今日はここまで。
 明日は勉強会の宿題と、仮称エスパーな仕事での新しい段階に進んでいこうと思います。
 もちろん、会社でもこの作品の成果を発表してこようと思います。

 それでは、おやすみなさーい。

0946
2004/05/15()
 色々と不具合を発見(^^;
 はい、今日は昼くらいから嫁さんと近くのショッピングセンターにお昼&お買い物。
 帰り道の薬局で米を買って家に戻り、そこからは嫁さんは相撲に見入り、私はP/ECEの続き(^^;

 で、今日はこの前ヒープの確保に失敗してて、mmcInitから先に全然進んでいなかったので、ヒープの最大容量を調査するところか入りました。

 そして、分かったのは、カーネル内でアプリを起動する際に確保できるヒープの容量はINITAPPEXTBUFF(0x13E000)からSRAMの最後(0x140000)までの約8KB分しかないということ。
 
 また、pexをSRAMに展開する際にpceZlibExpandで必要となるワークエリアも約8KBなので、結局MMC用のワークエリアの入る部分は全然なーい! ということが分かりました(j−j

 あと、このヒープの容量を調べている際に、MMCライブラリ内の確保する最大ヒープサイズを保存しておくグローバル変数の値が何度書き換えても初期化した値から変化しないという現象に悩まされ、色々調べていくと、ソース中でグローバル変数を以下の様に初期値付きで定義した場合、そのグローバル変数はRAM上のBSS(未初期化領域)セクションではなく、フラッシュメモリ上のDATAセクションに置かれてしまい、固定値として扱われてしまいます。
 
 <DATAセクションに置かれてしまうグローバル変数>
 unsigned long g_ulMaxFileSize = MMC_FILESIZE_MAX;
 
 ※MMC_FILESIZE_MAXは#defineで定義された定数です

 というわけで、そのグローバル変数は、ソース上では書き換え可能であっても、デバイス上では書き換え不能な変数となってしまうわけです。いやー、摩訶不思議ですねぇ(^^; <おい

 ちなみに、この変数の配置を示す.symファイルでは、

Symbol File Section Type Address
mmcFileReadMMCSct mmc_api.o code global 00c0bbf0
mmcFileClose mmc_api.o code global 00c0bca0
InitMMC_API mmc_api.o code global 00c0bcb8
mmcAppExecFile mmc_api.o code global 00c0bd74
g_ulMaxFileSize mmc_api.o data global 00c0c0cc
g_tMMCInfo mmc_api.o bss global 00000d30
g_tFS_Info mmc_api.o bss global 00000d54

 というように、dataセクションに置かれ、アドレスは512KBフラッシュメモリ上を指す0x00C00000以降となっています。

 話を戻しまして、結局のところヒープ領域が足りなくて、MMC用のワークエリアが確保できないということになるのですが、これが結論では今までやってきた苦労が全て水の泡となって非常に悲しいので、往生際の悪い私は、もうちょっとなんとかならないものかと、色々調べてみました。

 その結果…… なんとかなりました(^^;

 アプリ起動時に使用できるヒープの領域は、\PIECE\sysdev\pcekn\runapp.c内のAppStartという関数内で呼び出されるResetHeap関数によってSRAMのどのアドレス以降をヒープとして利用するかを設定するのですが、通常この関数には先述のINITAPPEXTBUFF(0x13E000)を設定して、アドレス0x13E000からSRAMの最後(0x140000)までの約8KBの領域を確保します。

 ここまではさっきも同じことを書いたので、どうでもいいことなのですが、ここからMMC用のワークエリアを確保するには、最低でもmmcFileReadSct等で利用するP/ECEの1セクタ分(4096)プラスαの約5KBが必要です。
 では、その5KBもの領域をどこから確保すればよいのでしょうか。

 と、ここでごちゃごちゃと説明してもアレなので、結論を言いますと、その答えはINITAPPEXTBUFF(0x13E000)の手前の領域ありました。

 ResetHeap関数では、引数で指定されたアドレスからSRAMの最後までをヒープ領域として設定するので、ヒープ領域を増やしたい場合は、INITAPPEXTBUFFよりも手前のアドレスを設定してやればいいのです。
 しかし、INITAPPEXTBUFFよりも手前の領域が常にどこかで使用される領域だった場合、ヒープを使用することによりその領域が破壊されてよろしくありません。

 が、幸いなことに、P/ECEではINITAPPEXTBUFFより手前の領域は\PIECE\sysdev\pcekn\pcekn.hに、

 #define SYSERRVBUFF ((unsigned char *)0x13c000)

 と、定義されているように、APIErrなどのエラートラップで表示されるエラー画面のVRAM用として予約されています。
 ここまでくればみなさんもおわかりの通り、この領域はエラーがトラップされない限りは使用されない部分です。ということは、通常は使われない領域として存在していることになり、ここを一時的に(アプリを起動する時にだけ)使用しても特に問題ないことが分かります(^^

 というわけで、アプリ起動時にだけ一時的にヒープ領域を0x13C000からに設定することにより、めでたくさらに8KBの領域(0x13E000 - 0x13C000 = 0x2000 = 8192bytes)を確保することができました。バンザーイ\(^o^)/

 これで、ようやくワークエリア確保に苦労しなくてよくなり、万事解決かと思っていたのですが、さらに先にはまた落とし穴が待っていたということで、またまた色々と不具合を見つけてしまいました(j−j

 ワークエリアの問題が解決したところで、実行時の各処理もすんなり通るのですが、どうもSRAMに展開されたデータが正しくない感じがしたので、MMCから読み込んだ時点でのデータをpceFileWriteSct等を使ってP/ECEのフラッシュメモリ上に書き出して、それをPCに取り込んで確認するという方法でチェックしたところ、どうも1クラスタ以降のデータをちゃんと読めていないことが判明しました(j−j ガーン。

 このバグはIODATAの128MBのMMCを利用している際に起こるもので、同じMMCでも64MBと128MBでは、1クラスタあたりのセクタ数が違ってくるので、その違いによる計算間違いで私のMMCからの読み出しルーチンにバグがあったようです。

 MP3プレイヤーを作っていた頃は、早く完成させたいという想いから、128MBで正しく再生されない理由をIODATAの128MBMMCが20MHzを超える通信速度に対応しきれていないからという結論を出して、それ以上の不具合原因の追求をしなかったのですが、今思えば、このバグにより上手く読み込めていなくて正常に再生できなかったのかも(--; 

 一応テキストデータを読み込んで試してみたのですが、それは128MBのMMCの1クラスタ内に収まるサイズだったので、今回の不具合が発生しないまま確認を終了してしまったみたいです。考えが甘かったようですね。反省(--;

 というわけで、新たにMMC制御ルーチンでのバグが判明したところで今日は時間がきてしまいました。
 明日はその辺りを重点的に見直していこうと思います。

 この不具合が直って、128MBのMMCがMP3プレイヤーで使えるようになったら、今までの倍の容量でMP3が持ち歩けるようになるの万々歳ですね(^^ よーし、がんばるぞー。

 というところで、今日はおしまい。
 それでは、おやすみなさーい。

0945
2004/05/14()
 今日は紫禁城(^^;
 えー、今日は午前中に新人K君と勉強会を開き、宿題の成果を発表し合って、今回は意味が良く分からない専門用語の意味調べをやりました。

 で、午後からはちょっと仮称エスパーな仕事の続きをやって、GDIオブジェクトを6000個ほど作るとシステムリソースが底をついて画面がすごいことになることが判明(--;
 ……設計し直しですね(j−j
 今回は非常に多くの細かいボタンをBMPで管理し、それぞれにイベント機能もつけるので、結構な数のGDIオブジェクトを使う仕様なのですが、余計なBMPが無くなるようにGDIオブジェクトを節約する仕組みが必要ですね。

 と、いうことが分かったところで、社長の講義が始まって、2時間半ほどのちょっと長い講義が終った後、ちょっとラジオのアンテナの話で盛り上がりました(^^; 私の社長の2人の中だけですが。

 で、今日はそのまま家に帰って夕飯を食べ、ファミコンの紫禁城の続き。
 今日は全150面中の146面まで来たのですが、どうにもこうにも進めず、今日はここで諦めました(j−j
 始めは、全100面だと思って頑張っていたのですが、100面を超えても一向に終る気配が無いので、ネットで調べたら全150面ということが判明し、微妙な気分になりました(--;

 今日は紫禁城を遅くまでやっていたので、P/ECEの続きは無し。
 明日は昼から嫁さんとお買い物に行く予定です。
 それでは、おやすみなさーい。

0944
2004/05/13()
 やっぱりヒープが足りない模様(- -;
 今日は午前中まで仮称エスパーの仕事の続きをやって、午後から外注さんとの打ち合わせ。
 
 で、またちょっと仮称エスパーの仕事の続きをやって、明日の勉強会の宿題をやりました。
 勉強会の宿題が意外に時間がかかってしまい、ちょっと遅くなってしまいましたが、家に帰ってからまたちょっとだけP/ECEの続きをやりました。

 今日は、昨日SRAMへの展開が上手く行っていないことから、その辺りを中心に見直しをしていったのですが、どうも、色々直していくうちにmmcInitでヒープをちゃんと確保できずにエラーで返ってきて、その先に進んでいなかったことが判明(j−j

 また調査は振り出しに戻るのですが、何回調整してもヒープ領域が足りなくてエラーになってしまふ。
 うーん、どうしたものか。

 というところで、時間が来てしまったので、続きはまた今度。

 明日は新人K君との勉強会と、社長に今回の仮称エスパーの仕事についての講義をしてもらうことになってます。
 というわけで、今日はここまで。
 それでは、おやすみなさーい。

0943
2004/05/12()
 青森出張決定(^^;
 えー、今日はまた普通に仮称エスパーな仕事の続きをやってました。

 で、今日は上の会社の人から連絡があって、今度の仕事で私一人で青森に出張することが決定しました(^^;
 しかも、お昼くらいに現地入りしようと思うと、朝一番の飛行機しか手段が無いことが判明し、初めて出張で飛行機を利用することになりました。飛行機は好きなんですが、色々と搭乗するまでが面倒なんですよねぇ(^^;

 で、なんだかんだでまたキリが上手く付けられなくて、結局ちょっと遅くなってしまい、家に帰ったらちょっとだけP/ECEの続きをして今日はおわり。
 今日はこの前のFATチェインテーブル解放のバグが直ったので、その先の処理を見直していたのですが、どうもSRAMへの展開が上手くいっていないようです。
 pceZlibExpandというAPIからはちゃんと制御が返ってくるので、展開処理自体は上手く動いているようです。それなのに展開後のデータがおかしいということは、展開元のデータがすでにおかしいということなのかな?
 P/ECEのようなマイコン関連のプログラミングはエミュレータが無い場合、ソースコードデバッグができないので、なかなかデータの途中の状態を見ることができず、デバッグは困難ですよね(^^;

 最近気付いたのですが、1つの整数型変数に限りますが、APIErrという関数を使えば、処理がそこで無限ループに入って止まってしまいますが、無理やり画面に値を出すことができます。
 使い方は APIErr(0,表示したい整数値); でOKです。pcekn.hをインクルードすると使えます。
 ただ、このやり方はカーネル内でしか使えないかも(^^; 

 明日は仮称エスパーな仕事の関連で外注さんと打ち合わせをする予定と、次の勉強会が明後日に迫っているので、その資料作りというか宿題をやらないといけないんです。
 
 というわけで、今日はここまで。
 それでは、おやすみなさーい。

0942
2004/05/11()
 なかなかキリが付けられない(−−;
 えー、今日は朝から新幹線に乗り、東京から名古屋に帰ってきました。
 お昼頃には会社に戻り、仮称エスパーな仕事の続きをやり始めました。

 で、夕飯時にはいったん家に帰って、また戻ってきて続きをやって、今日はなかなかキリがつけられなかったので、ちょっと残業して家に帰りました。

 今日はちょっと遅くなってしまったので、P/ECEの続きはなし。
 明日も仮称エスパーな仕事の続きをする予定です。
 それでは、おやすみなさーい。

0941
2004/05/10()
 今回も無事収録終了
 えー、今日は朝の6時半に家を出て、某歌番組の収録のため新幹線で東京・渋谷へ。
 9時半頃に現地入りして、収録の準備開始。

 今回から予算の都合で人員削減の為、弊社からは私が一人で行くわけですが、弊社のシステムは安定して動いているため、特に人が来なくても良くなっているので、お昼くらいまでで設置&調整をして、あとはカメラリハーサル→本番を待つだけに。

 この仕事は結構待ち時間が多く、何もトラブルが無い場合はかなり暇なので、一緒に来て頂いている上の会社の社長さんと、お互いの近況報告だとか、なんか面白いものはつくれないものだろうかと、微妙に企画会議みたいな話をして時間を潰します(^^;

 今回は、ホテルで開発を進めようと思ってP/ECEセットを持ってきていたので、暇つぶしの一環として、MMCでのMP3プレイヤーを見てもらいました。
 社長さんの反応は、想像していたよりもちゃんと聴けるとのことで、なかなかの好感触でした(^^

 そんなことをしながら、リハーサル・本番を迎え、今回も何事も無く収録終了。
 
 収録は9時半くらいに終って、後は撤収。だいたい10時〜10時半には現地をあとにします。
 今日はほんとは上の会社の社長と飲みに行きたいと思っていたのですが、社長さんは明日が微妙に早いとのことなので、今回は見送り(j−j

 というわけで、一人寂しく(笑)夕飯を適当にとって、ホテルでP/ECEの続き。
 今日は、ヒープ領域の最大容量を調べようかと思っていたのですが、ちょっとソースを見直しているうちに、他の個所でバグを発見し、そこを直したら途中でリブートしてしまうという現象が直りました(^^;

 原因は、以前はMMCからファイルを読み込むために必要なFATチェインテーブルを作るのに、FATチェインテーブルの大きさはファイルサイズによって異なるので、mmcFileOpen時にファイルサイズに応じてヒープから確保し、mmcFileCloseで解放していたのですが、この方法だと、ヒープの構造が乱れていって、小さいファイルの次に大きいファイルを読もうと思うと、ヒープが確保できない場合が多いので、mmcInit内で最大容量のFATチェインテーブルの領域をヒープから確保するようにしたんです。
 で、今回はバグは、そのmmcFileCloseの部分でFATチェインテーブルを解放するという処理が残ったままだったので、知らない間に解放されていたのでした(^^; あー、恥ずかしい。


 というバグを発見して修正したところで眠くなってきたので、今日はヒープの最大容量を確認するのをやめて、寝ることにしました。

 明日はお昼くらいまでに名古屋の会社に戻り、仮称エスパーの仕事の続きをやります。
 それでは、おやすみなさーい。