| まどかの | 自 | 己 | 満 | 足 | 日記 |
まどかは「P/ECE Hand Book」を応援しています
|
1120 |
2004/11/07(日)■ | |
| 今日も休日出勤 | ||
| 今日は、午前中に嫁さんとカラオケに行って、お昼をインド料理屋のナンカレーで済ませてから、会社に向かい、VBアプリの続きを作ってました。 で、午後９時くらいまで仕事して家に帰って、P/ECEネタの続き。 今日はちょっとだけ進んで、P/ECE側での簡単なテストアプリを作ってました。 と、そんなことをしている間に、嫁さんがビーズでP/ECEの2作目（ブルー）を製作。  だんだん増えていきますよ（＾＾ というわけで、今日はおしまい。 それでは、おやすみなさーい。 | ||
| 2004/11/06(土)■ | ||
| MMC対応カーネルVer.1.26を公開しました | ||
| 今日は11時くらいから会社に出かけて、アルバイトにやってもらうはずだったVBアプリをせっせこ作ってました（＾＾； このVBアプリは仮称エスパーな仕事のアプリよりは何十倍も仕様が簡単なので、特に悩むことも無くサクサク進みます（笑） でも、期間が無い上に、仮称エスパーの仕事の方が優先度が遥かに高いので、一気に作ってしまわないと仮称エスパーな仕事に影響してくるので、休日出勤で頑張ってる次第でした。 で、今日1日でだいたい3分の2くらいは済んだので、明日とかでとりあえず形にはなると思います。が、このアプリでの最大の難関は表示に使用するデータの作成で、決まったフォーマットのCSVファイルを読み込んで利用するのですが、そのデータの量がちょっと多くて、データ作成ツールを作らないといけないので、結構大変なんですよ。 というところで、仕事の話は終わりにして、今日は家に帰ってから先日のnsawaさんのご報告にあった内容を反映し、MMC対応カーネルVer.1.26としてサポートページで公開しました（＾＾ ソースをよく読み返してみると、16bitCRCのチェックとかはCID以外のところはちゃんと考慮してダミークロックを送ってたので、ここだけうっかり忘れていたのですね。あーあ、もっとちゃんと読み直すんだった。反省。 ところで、本日nsawaさんが公開されたバージョンアップ版MMC/SDカードリーダーライターを私も使ってみました。 当方のWindows2000SP4では、当然かもしれませんが正常に認識され、ファイルの書き込みもちゃんと行えました。書き込みバイト数の表示がいい感じのスピードで更新されるようになったのは気分的にすごくいいです（＾＾ さて、本日はもうひとつ紹介したいネタがありまして、実は昨日家に帰ったときに嫁さんが趣味のビーズでこんなものを作っちゃいました（＾＾  じゃーん。ビーズでできたP/ECEです！（＾＾  ちゃんと裏は黒いツートンカラー！  しかもUSB端子（左の白いの）と赤外線LED（右の透明なの）も付いて完璧！  真正面から見るとこんな感じ。 どうです？ P/ECEそっくりでしょ！？ というわけで、昨日は帰るなりこれを見せられて私はおおはしゃぎ！ 早速今日会社で自慢してきました（笑） 反応が多ければ、受注生産するかも……（笑） というわけで、今日はおしまい。 それでは、おやすみなさーい。 | ||
|
1118 |
2004/11/05(金)■ | |
| ああ、来週は激忙しそうだなぁ（- -； | ||
| 今日も仮称エスパーな仕事を一生懸命やっていました。 再来週の展示会や、2回目の納品に向けてラストスパートな時期なので、正直かなり忙しく、ヒーコラ言っております（＾＾； と、うなっている中、またnsawaさんがMMC/SDカードリーダーライターのバージョンアップ版を公開されました。 今回のバージョンアップでなんとフォーマットまでサポートされてしまいました（＾＾； これで、市販のカードリーダーライターが無くても、接続基板さえ作れば、MMCやSDカードをP/ECEで自由に扱うことができますね。すごい。 私がMMC版MP3プレイヤーを作っていた当初に考えていたネタが、さらに高度な技術によって現実のものとなりました。 私の場合、P/ECEをリムーバブルディスクとしてPCに認識させることなんて思い付きもしなかったので、こんなことができるという素晴らしいお手本を示してくださったnsawaさんにはとても感謝しています。 あと、構造体のアライメントについての超解かり易い解説ありがとうございます。 なんかP/ECEのgccの構造体パックに問題発生とのことで、続きが非常に気になります（＾＾； また、構造体パックの件は、ご教示いただいた通り、パックを使わず、固定サイズを指定して受信し、ダミークロックを発行するという方法で修正したいと思います。 以下、nsawaさんの2004/11/06の日記から引用 ＞いつもなら即日対応で本家MMCカーネルにも書き込み機能を！ と行きたいところなのですが、ちょっと今回は様子を見させていただこうかな（＾＾； はい、通常のアプリケーションでファイル書き込み機能を使うことは少なそうなことと、残り少ないカーネル領域には収まりそうもないことから、 将来もし書き込み機能に対応するとしても、ファイルシステムの処理はライブラリで対処するのが良いと思います。(修正の頻度も高そうだし…(^^;) MMC/SDカードリーダーライターは、セクタ単位の読み書き機能を提供しているだけで、ファイルシステムの管理はPCがやってくれるから楽なのですけれど、 P/ECEから自力でDOSファイルシステムへの書き込み処理を作るとなると、既存のプログラム等を参考にするにしても、なかなか簡単ではなさそうです。 というわけで、なんかヅが付く方にえらい期待されておりますが、書き込み機能のMMC対応カーネルへの組み込みはちょっとおあずけって感じかな（＾＾； 仕事が忙しくて、まだnsawaさんのライター機能部分のソースには目を通していませんが、ファイルシステムの管理はPC側でしてくれているんですね。 FATでのファイルの管理は、FAT（ファイル・アロケーション・テーブル）にファイルのクラスタ単位でのチェーン状況を記述していかないといけないとか、ディレクトリエントリとかの書き込みがちょっと面倒なので、なかなか大変なんですよねぇ。 とりあえず、MMC対応カーネルとしては、次のVer.1.26でnsawaさんのスーパーフロッピー形式への対応処理を追加します。あと、受信時の構造体サイズの修正も。 明日も休日出勤なのですよ（- -； それでは、おやすみなさーい。 | ||
|
1117 |
2004/11/04(木)■ | |
| 早朝から出張に行ってきました | ||
| 今日は6時半くらいに家を出て、神奈川の某施設に行ってきました。 現地で作業できる時間が限られているため、現場につくなりすぐさま調査を開始し、1時間半ほどで作業終了。 で、会社に戻るのですが、ちょっと交通の便が悪いところなので、名古屋に帰るのに、待ち時間を含めて約3時間くらいかかります（- -； そして会社に着いてからも仮称エスパーの仕事の続きをやったりして、結局帰りが遅くなってしまいました。 と、そんなことをやっている間に、またnsawaさんが新たな作品を公開されました。 今回の作品は「MMC/SDカードリーダーライター」。 一瞬前回と何が違うのか判らず、「？」と思ってしまったのですが、ついにやってしまわれました（＾＾； 市販のカードリーダーを使わずして、MMCにファイルが書き込めてしまいます。 まだフォーマットはできない様なので、市販のカードリーダーを使うメリットはあるのですが、それも時間の問題かも……（＾＾； それにしても、私は書き込みまでサポートするのはちょっと面倒なので、初めに公開する段階では許してもらおうと妥協したMMCへの書き込み処理ですが、さすがnsawaさん、あっとゆー間に対応されてしまいましたね。 いつもなら即日対応で本家MMCカーネルにも書き込み機能を！ と行きたいところなのですが、ちょっと今回は様子を見させていただこうかな（＾＾； さて、nsawaさんのカードライターの他に、MMCカーネルへの報告（っていうかダメだしですね（- -；）もあったので、それについてコメントを。 ・スーパーフロッピー形式について こんな形式があったなんて、全然知りませんでした（＾＾； ちょっと前にあった（今でもあると思いますが）スーパーDISKの形式かと思って、ちょっと調べてみたら、MOとかでよく使われるフォーマットみたいですね。 しかも、Windowsではこの形式でフォーマットできないとか書いてあるけど、ほんとなのかなぁ？ もし、そうなら私のところではちょっと検証できないので、MMCカーネルへの組み込みはどうしよう。 まぁ、nsawaさんに検証していただいたコードですので、大丈夫でしょう（＾＾ ちなみに、FAT12でもないのにP/ECEで読めなかったSDカードとかは私もいくつか遭遇してまして、ビデオカメラに付いてきたSDとか、新品のIODATA128MB MMCとかは、そのままだとカードリーダーでは使えるけど、P/ECEでは認識できなかったので、恐らくスーパーフロッピー形式だったのでしょう。 nsawaさんのコードをMMCカーネルに組み込めば、買ってきてすぐのカードとかも使えるようになると思うので、近日中に対応したいと思います。（土日でできるかなぁ（- -；） ちなみに、本当にWindowsでスーパーフロッピー形式でフォーマットする方法ってないのでしょうか？ なんかLinuxだとやり方が書いてあるページとかはあったんですけどね。 ・構造体のアライメントについて この件に関しましては、はっきり言って、私のミスです。 情けない話ですが、私の経験の浅さ（詰めの甘さ）が出てしまったようです（ｊ−ｊ ちなみに、構造体のアライメントなどの知識は一応知ってはいたのですが、実際に注意して使うことはあまりなかった（あったとしても、上手く動いてしまっていた場合が多いと言った方がいいかな？）ので、今回のカーネルでも、アライメントを考慮せずにコードを書いてしまっていました。 nsawaさん、厳しい添削ありがとうございます。 確かに、他のデバイスとの通信の時には、厳密にやり取りするデータのサイズを考慮してコードを書かないといけませんね。勉強になりますm(-_-)m これって、対応するには、構造体の宣言のところを #pragma pack(1) 構造体 #pragma pack( ) って感じで囲って、1バイト境界にするとかで良いのでしょうか？ それとも、nsawaさんの様に読み込みのサイズで16バイトと明示的に書いた方が良いのかな。どうせ、1つずつメンバに代入しているので。 余分な4バイトのうち、最初の2バイトが16ビットCRCの受信になっていた、というわけです。 (意図してそういうふうにしてあったのだとしたら、ごめんなさい) これに関してですが、今仕様書などを読み返して考えてみると、CRCって、コマンド自体についてくるSPIコミュニケーションでの16bitCRCと、CSD/CIDのデータ本体についている7bitCRCって別物だったんですね（＾＾； 私はCRCって書いてあることだけに注目して、「あ、これはCRCも含めて16バイトなんだな」と勘違いし、SPIコミュニケーションでの16bitCRCの存在をすっかり忘れていました（- -； なので、CSDの取得のところでは、 //なにか来てるみたいだし（--； CRC? なんていうとんちんかんなコメントを書いていたのでした。 と、いうことは、他のコマンドのやりとりのところでもこんなポカをやっている可能性があるので、スーパーフロッピーに対応する時にちょっと見直してみることにします。 CSDのところみたいに、CRCを受信しないことで通信が不安定になることがあれば、CIDのところでもちゃんと気付いて、構造体のパディングとかにも気が付いたかもしれませんが、CIDではたまたま上手く動いちゃったものですから、全然気が付きませんでした。情けないですね（ｊ−ｊ nsawaさんみたいにちゃんと仕様書はよく読んで理解して作っていかないといけないことを身に染みて痛感しております。今回も貴重なご報告ありがとうございました。 なんか、nsawaさんみたいな技術力のある方にソースを見ていただいて、なおかつダメだしまでしていただけるなんて、P/ECEを始めてほんとに良かったと思います。色々勉強させていただいております＞ALL ちなみに、かなり身勝手なお願いですが、nsawaさんとはもっとお話もさせていただきたいと思っておりますので、もし今度の某冬のイベントにも来られるようでしたら、一緒にお食事でもどうでしょうか？（＾＾； なんて、書いてみたり。 P/ECEもすごく奥が深くて、内蔵RAMを使って高速化だとか、まだまだ理解しないといけないことがたくさんあります。こんなに小さいデバイスなのに、中身はなんて広大なんだ。やっぱりP/ECEってサイコーです（＾＾ というところで、今日はおしまい。 あ、そうだ、突然ですがヅラChuさんに私信。 例のもの、昨日郵便で（嫁さんが）送りました。多分明日くらいに着くんじゃないかな？ それでは、おやすみなさーい。 | ||
|
1116 |
2004/11/03(水)■ | |
| 出張の準備をしてました | ||
| 今日は11時頃に出社し、明日の出張の準備とか、アルバイトに頼む予定だったアプリを私が作ることになったので、その打ち合わせとか素材の準備とかで忙しく1日が過ぎていきました。 で、いつもよりはちょっと早めに帰って、P/ECEネタの続き。まだまだ勉強中＆アルゴリズムの考え中。1日数時間しかP/ECEネタに時間が割けないので、牛歩のごとく進みません（- -； でも、今日は今まで調べていたこととは別のアプローチで調べてみたら、ちょっと解決のきっかけになるような資料が見つかったので、それらをDLして今日はおしまい。明日以降に読んで理解しよう。 それでは、おやすみなさーい。 | ||
|
1115 |
2004/11/02(火)■ | |
| MMC対応カーネルのVer.1.25を公開しました（＾＾ | ||
| 今日は、普通に仮称エスパーな仕事をやって、やっと今日である設定画面の基本となる処理の基礎ができあがり、ちょっと嬉しい気分です。さぁ、これでだいぶ先に進めるぞ！ で、急な話で高卒の新人が担当している開発用に、ちょっとActiveXを作り直すことが決まったり、急ですが、明後日にはまた神奈川の方に出張が決まったり、ちょっとばたばたしています。 しかも、学生のアルバイトをやとって作ってもらおうと思っていたアプリが、学生が全然集まらないので、私が作ることになり、また忙しくなりそうです。 で、そんな中、本日nsawaさんが、MMCを接続しているP/ECEをリムーバブルディスクとしてPCに認識させ、PCのエクスプローラ上から、MMCのファイルが読めてしまうというすごいアプリを公開されました。 2004/11/02の日記のMMC/SDカードリーダーです。 これは以前にUSBストレージとして公開されたものをATAPIリムーバブルデバイスのプロトコルに変更し、MMCに対応したものらしいです。 それはそうと、P/ECEでのUSBの通信がフックできるなんて知りませんでした（＾＾； 以前のUSBストレージの時は、ヅラChuさんの簡易Webサーバみたいに、Windows側のアプリからUSB通信でそういうことをやっているものだと思って（勘違いして）よく見なかったのですが、今回ソースを見ると、あらビックリ。 こういうことができるんなら、いろいろ他の使い方も出来そうだということで、nsawaさんからご要望があった、mmcReadSectorをAPIに追加して、MMC対応カーネルVer.1.25をサポートページで公開しました（＾＾ 一応、nsawaさんのMMC/SDカードリーダーのソースを改造し、MMC対応カーネルのAPIを使うようにして動作を確認しました。 動作環境はnsawaさんと同じWindows2000 SP4なので、あまり役には立たないかもしれませんが、ちゃんとMMCからのファイルのコピーも行えたし、複数選択してのコピーもバッチリ。 MMC上からのMP3の再生も行えたので、正常に動作していると思います。すごい。 以下nsawaさんの日記から引用 今回の『MMC/SDカードリーダー』は、「MMC対応カーネル」のAPIを呼び出していません。 MMC/SDカードをセクタ単位で読み込むために、「MMC対応カーネル Ver 1.24」のソースを少し改変して使わせていただきました。 もしできれば、mmcReadSector()関数もAPIとしてエクスポートしてくださると嬉しいのですけれど… 早速対応させて頂きました。ご提案ありがとうございます。 mmcReadSectorAPIはMMC制御の低レベルなAPIとなるので、これを利用して、今回のnsawaさんのような作品が出てくるといいですね。 というわけで、今日はここまで。明日は休日出勤なのですよ（- -； それでは、おやすみなさーい。 | ||
|
1114 |
2004/11/01(月)■ | |
| 今日から11月ですね | ||
| はい、今日から11月ということで、気持ちも新たに…… なることもなく、普通にいつも通りの仮称エスパーな仕事をがんばっていました。 いつも通りって言っても、内容はちゃんと進んでいますので、同じ事ばかりやってるなどとは思わないよーに（＾＾； 仕事を終えて、家に帰ってからは、P/ECEネタの続き。 でも、今日は今作ろうとしている作品が扱うデータ量などを計算して、あまりの多さにちょっと途方に暮れてしまいました（- -； ってなわけで、今日は全然進まず。締め切りの12月末まで、あと2ヶ月か。がんばろ。 というわけで、今日はおしまい。 それでは、おやすみなさーい。 | ||