ジャンク宿

マティックス

先日TVでやっていた番組が下北沢のお店紹介で、以前にも何度か行った事のある「ザ・スタディールーム」が紹介されていた。

それを見ていた子供が下北沢まで散歩に行きたいと言い出したので、小雨降る中妻と子供と三人でお散歩する事に。ザ・スタディールームは駅の北側だから、歩いて行っても割と近くなんだが、同じ番組で紹介されていた300円均一ショップ「三日月百子」にも行く事になって、そっちは駅の向こう側。

しかも初めて行くので場所が良く分からず、遠回りしてしまった。

「三日月百子」から「ザ・スタディールーム」に移動すると、番組で紹介された効果なのか店内は結構混み合っていた。割れないシャボン玉は紹介されてすぐ売り切れになったらしい。やっぱりTVは宣伝効果高いんだなぁ。

空中に浮くコマを実際に見せて貰ったけど、静止させるには思ったよりも微調整が必要で、台の傾きを調節したりコマに薄い重りを乗せて重量調整しないと、すぐに飛び出してしまう。その分ちゃんと浮けば面白いだろうな。

妻はここで学研のマティックスというゲームを買い、子供は自分のお小遣いでお湯に漬けるとカプセルが溶け、中身が膨らんで恐竜になるという奴を買っていた。昔良く縁日で売ってるのを見たなぁそれ。

マティックスは夜に子供と遊んでみたのだが、親よりも子供のほうが強かった（笑）。私が子供と対戦した時は、マイナスのコマを取らせようとして考えたんだけど、それに拘って自滅というパターン。

ルールは簡単だけど、これはなかなか面白い。

週末は土日のどっちか休日出勤しようと思っていたのだが、午後になっても天気がいまいち。

良い天気の時に休日出勤するのはアレだけど、天気が悪くても行く気にならない（笑）。午後に子供を福祉センターまで送ったあと買い物して家に戻り、仕事は家で進める事にした。

と言ってもハードが無いとデバッグできないので、資料を整理して詳細仕様書みたいなのを黙々と作る。コーディングとデバッグと仕様書作成が同時というのもアレな気はするが、まあこの業界では割と普通（笑）。

首都消失

今日は朝からかなり暖かく、春近しと言う感じなんだけど、そうなるとまた花粉の季節が．．．．今年は軽いと良いなぁ。

自宅からはオペラシティやパークハイアット、都庁がいつもなら良く見えるんだけど、家を出てそっちを見たらオペラシティがうっすらとしか見えず、都庁は濃い霧の中に埋没して完全に見えなくなっていた。

思わず「首都消失．．．．」と呟いたことは言うまでもない（笑）。

あの映画は劇場まで見に行ったんだが、どうも釈然としない終わり方だったなぁ。いつ本題に入るんだろう？と思っていたらそのまま終わってしまったみたいな（笑）。

ちなみに「さよならジュピター」も劇場まで見に行きましたよ、ええ。

武蔵野電波のプロトタイパーズが突然復活して、復帰第一回はなんと「全店制覇! 秋月電子通商のすべて」。

全店制覇って2店しか無いじゃん！と思わずツッコみたくなってしまうタイトルだが、今まで謎に包まれていた秋月の2階倉庫や、6台のリソグラフが並ぶ八潮店のバックヤード、川口通販センターの様子は非常に興味深い。

Web上で開発を行うマイコンボードmbed NXP LPC1768も紹介されていて、twitterのTLでは早速その話題で盛り上がっていたが、これってずいぶん前から着目して何度も呟いていたのに、今頃になって盛り上がるとは。やっぱり秋月での取り扱いは影響力が大きいのだなぁ。

午後は開発中の装置のホスト側を作っている会社の人が来社して、接続試験。通信仕様だけ先に決めてそれぞれ別個に開発していて、接続するのは今日が始めてだったりするのだが、細かいミスはあったものの基本的なところは一発で繋がったので良かった。

ちなみにミスしたのは時間設定で、ローカル時間じゃなくてUTCで設定してしまったせいで9時間ズレていた（笑）。

宇宙ワンダー

官公庁オークションで「着メロ」の商標権が出品されていると話題になっていたので、他に何か面白いモノは無いかと思って探してみたら、恐竜型の家庭用ロボット「番竜」が福岡県から出品されていた。

面白そうだけど落札しても置き場所が無いな（笑）。

他にはなんとあのバーチャレーシングの２人用筐体が。片側の画面がバグっていてゲームできないらしいが、１人用なら遊べるらしい。置き場所があって高知県まで引き取りに行ける手段があればなぁ（笑）。

今作ってる装置はデータを外部のSQL Serverに保存するので、久しぶりにデータベース関係のプログラムを組む。

テスト用にはとりあえずSQL Server 2005 Express Editionをインストールしたんだけど、あまりにも久しぶりだったのでGUIで使えるツールは無いかと探してみると、黒猫 SQL Studioというのが良さそう。

これでSQL Serverに接続してクエリを実行できる所までは確認できたから、この環境でぼちぼちやってみるか。ってぼちぼちやってる余裕は無いんだけど（笑）。

子供と一緒にお風呂に入っている時に、子供が宇宙ステーションの中は無重力なんだよね？と言ったので、実際には地球の重力が働いていて、でも何故落ちないのかという説明を延々とする羽目に（笑）。

ボールを勢いよく投げると、地球を一周して戻ってくるという事は理解しているようなので、宇宙ステーションもそれと同じという話はしたんだが、あまりピンと来ていない様子。

文部科学省がゲームで宇宙を理解する「宇宙ワンダー」というサイトを作っているので、をやらせてみようかな。

セバスちゃん

今日は一日中雨の予報だったので、浸水確実の靴を履いていくのは止めて防水性の高い登山靴を出してきたのだが、ゆるい靴ばっかり履いていたせいかサイズがきつくなっていて、靴べらで無理矢理履こうとしたら靴べらが真ん中から折れた（笑）。

昼休みになっても雨は降り続いていて、今日はあまり外に出たくない感じだったけど、オークションで落札された代金が早々に振り込まれていたので、郵便局まで行って品物の発送を済ませてくる。

午後は新規案件の打ち合わせ。WebサーバとDBを組み合わせたシステムになりそうなんだが、どうも構想だけで具体的にそれをどう実現するのかは誰も考えてない雰囲気が濃厚（笑）。なんかまた苦労しそうだなぁ。

帰りに乗ったバスの中に日本バス協会の吊り広告があって、そこに協会キャラクター「セバスファミリー」というのが描かれていた。セバスっていうのはセーフティーなバスを略したらしいのだが、キャラクターの名前が「セバスちゃん」って（笑）。

セバスチャンと言ったらどう考えても男性名だろう。しかも黒服執事のイメージ（笑）。このネーミングはわざとなのか？

ロジアナ

1000円カットハウスに不衛生という理由で洗髪施設を義務付ける動きが出ているらしいけど、どう考えてもそれは理由に無理があるよなぁ。

洗髪しないことで何が不衛生でどんな問題が発生するのか、何一つ明確になってないし実害の出た例もない。

自分もよく利用してるけど、カット後は家に戻ってシャワー浴びて頭洗うので、店で洗って貰う必要なんか無いしなぁ。それで値段が高くなって待ち時間が長くなるんだったら、利用者には何のメリットもない。

そもそも洗髪しないと不衛生だって言うなら、理髪店でも洗髪を義務付けないとおかしいじゃん。なんかアレなものを感じるぞ。

ストロベリー・リナックスで取り扱いが始まった低価格なロジアナがちょっと気になっていたのだが、メーカーのサイトを見に行ったらプロトコル解析フィルタを自作するためのSDKが提供されていて、より激しく食指が動いてしまった（笑）。

13,800円で16chサンプルレート100MHzのロジアナが買えてしまうとは、良い時代になったもんだなぁ。

とりあえずサイトからSDKをダウンロードしてちょっと眺めてみたんだけど、サンプルプログラムがあるので参考にすればオリジナルのプロトコルフィルタを作るのも難しくは無さそう。

このぐらい値段が安いとかなり手が出し易いので、ユーザの作成したプロトコルフィルタもそのうち出てくるんじゃないかな。

あずさのキップを30%引きの「トクだ値」で取った話を先日書いたが、ちょっと調べてみたらその電車は乗り継ぎが恐ろしく悪くて、駅で一時間以上待たされる事が判明。

それは嫌なのでえきねっとで予約を変更したんだけど、おかげで新宿到着が20時過ぎになってしまった。これは小淵沢の駅で駅弁買って、電車の中で食べるパターンかな。まあそれも良いか。

業務スーパー

VisualStudioでプログラミングする時に、エディット領域はできるだけ広く取りたいので、プロパティウィンドウなんかは分離してデュアルモニタのセカンダリの方に置いたりしている。

それだけで結構広くなるのだが、セカンダリ側でアプリケーションを最大化すると重なってしまうのがイマイチ。

ナナオでモニタの領域を分割して最大化のサイズを制限できるツールを公開しているのだが、ナナオ製のモニタが接続されてないと起動できないので役に立たない。さすがにその為にモニタ買い換えるわけにはいかないし（笑）。

USBサブ液晶を接続して、そこに各種ウィンドウを追い出せば快適に使えるのではないかという気がするけど、少なくても4枚は必要だから気軽には試せない。とりあえず1枚だけ買って様子を見てみるかな。

ツールパレット表示専用で、480x1024ぐらいの細長いUSBサブ液晶とかあれば良いのに（笑）。

昼休みは高円寺のオリンピックまで一輪車を見に行く。

安く売っていたらここで買って持ち帰ろうと思っていたのだが、通販で買うのと大差なかった。バスで持ち帰るのはどう考えても大変そうだから、おとなしくAmazonで買うのが得策か。

一輪車乗れるようになったら買ってあげる、と子供に約束してずいぶん経つので、そろそろ何とかしなくては。

帰りはパル商店街を抜けていくと、途中にあったゲーセンが工事中で「業務スーパー」という看板がかかっていた。ハナマサみたいなのができるのかな？

高円寺に住んでるわけじゃないから、業務スーパーがOpenしても利用できる機会は少なそうだが、とりあえずチェックしておこう。

火事現場

シリアル通信のテストをする時は、シリアルポート2つをクロスケーブルで接続して行うのが定番なんだけど、肝心のクロスケーブルが見あたらない。

しかたがないのでNull-modem emulatorをインストールして、仮想的なクロスケーブルとして使ってみた。

COMポートとして認識されると思っていたのに、デバイスマネージャのポート一覧には何も追加されなくて、変だなぁと思ったらリストの上の方に別デバイスとしてインストールされていた。

初期状態では「CNA0」「CNB0」というデバイス名になっているので、ユーティリティを起動してCOM13とCOM14に名前を変え、TeraTermを2つ起動して試してみると、ちゃんと2つのシリアルポートが仮想的につながっている。

この状態で自作プログラムを起動してCOM14を開き、COM13から文字列を送り込むと、それがtwitterにPostされる所までは確認できた。

これであとは仮想じゃないシリアルポートを使い、そこにArduinoをつなげると、Arduinoからtwitterに何か書き込む事が可能になる。

Arduinoのイーサネットシールドを使えば同じ事が単体でできるけど、そこまで投資せずにお手軽にフィジカル->twitterをやりたいという場合には使えるかも知れない。今のところテストプログラム段階なので、ちゃんとしたツールにまとまったら公開する予定。

昼休みに高円寺の駅前方面まで歩き、古本屋をチェックしてからパル商店街の中を抜けて戻ろうとすると、なんだか妙に焦げ臭い。

22日の朝に高円寺の居酒屋で火災が発生して、何人か亡くなられたのは知っていたけど、このへんだったのか。あれから日が経ってるのに、まだこんなに焦げ臭さが残っているとは。

隣接する商店も休業になっていて、お店の前には献花台があった。火事怖い。

twitter API

以前からやってみようと思っていたtwitter APIを使うプログラムをこの連休中に少しずつ書いていて、昨日はMTM04の会場を歩き回った余波であまり進まなかったから、今日は午前中に本腰を入れてプログラミング。

基本的にtwitter APIはhttpアクセスだから、CInternetSessionクラスを使えばそれほど難しくは無いんだけど、文字コードの扱いが厄介でtwitterにPOSTはできるけど漢字が化け化けという状態になっていた。

Unicodeベースのプロジェクトなので、twitterにPOSTするときはまずUnicode→UTF8の変換を行い、それからUTF8→URL形式への変換という2段階の変更を行う必要があるらしい。ややこしいなぁ。

httpリクエストを行う関数にはリクエストヘッダとリクエスト本体の2つの引数があって、そのうちヘッダの方はLPCTSTR型で定義されているからCStringをそのまま渡せば良いんだけど、リクエスト本体はLPVOID型になっていて、自分で変換してから渡さなければならないというのが、余計にややこしい。

文字コードがUnicodeになったら、この手の面倒なことからは解放されるんじゃなかったのか？（笑）。

とりあえずユーザIDとパスワードと文字列を渡すと、twitterにそれを書き込むクラスは出来上がった。自作のテキストエディタから直接twitterにPOSTするために作ったんだけど、他にも応用は利きそう。

シリアルポートから受信した文字列をtwitterにそのまま投げるプログラムを作れば、Arduino＋何かのセンサーで取得した値を、twitterにPOSTするってのも簡単に作れるじゃないか。やってみよう。

午後は子供が帰ってくるので、その前に秋葉原。

ラジオデパートへ行ったらお休みの店が多くて、そういえば今日は月曜日だったなぁと改めて思った。普通月曜定休でも祝日だったら営業すると思うんだが、さすがは秋葉原のお店だな（笑）。

一昨日とは逆に秋葉原から東京駅まで歩く。中央通りから万世橋、神田駅、竜閑橋、鎌倉橋、大手町、東京駅という道順。新幹線の到着時間までは少しあったから、東京駅地下のGranStaを少し見て歩き、BURDIGALA EXPRESSでパンを買ってみた。

新幹線は秋田で何かあって8分ほど遅れたらしいけど、東京駅到着時には3分遅れになっていて、新幹線って遅れを挽回できる余裕があるんだなぁと感心したりした。

子供を回収して中央線快速に乗ったら、小さい男の子を連れたお母さんが乗ってきたので席を譲ったんだけど、その男の子が頑として席に座ろうとしないから、新宿まで席があいたままという状態に（笑）。

SPI通信

AT90USB162マイコンボードにSPI接続の10ビット2ch ADコンバータMCP3002を接続して使ってみたのだが、どうもうまくデータが受信できない。

いや、受信できるようにはなったんだけど、受信データが何故か1ビットずれている。

10ビットだから値は0～1023。16進なら0x0000～0x03FFの範囲になるはずが、実際のデータは最大値が0x07FEになっていて、MSB側に1ビットずれているのだ。

PDFのデータシートを何度も読み返し、トラ技の特集も参考にしてようやく正常に受信できるようになった。MCP3002に送信するコマンドに問題があると思っていたのだが、実際にはAT90USB162のSPIインタフェースの問題で、クロックの立ち上がり立ち下がりどちらでデータの送受信を行うのかという設定が、マスタとスレーブで食い違っていたのが原因だった。

正常にSPIで受信できるようになったので、可変抵抗を付けて電圧を変化させ、USBのHIDデバイスとしてPCでその値を受信、画面に表示するところまでようやく辿り着いた。

これができるようになると、後から色々と応用が利く。

実際のプログラムは例によって STK526-series2-hidio-2_0_1-doc をベースにして、hid_task.c の必要な部分だけ書き換えて動かしている。

// 定義
#define  SS    (0)
#define  SCK   (1)
#define  MOSI  (2)
#define  MISO  (3)

#define  DEV_ENABLE  (PORTB &= ~_BV(SS))
#define  DEV_DISABLE (PORTB |=  _BV(SS))

// 初期化
void hid_task_init(void) 
{
  // SPI init
  DDRB = _BV(MOSI) | _BV(SCK) | _BV(SS);    // MOSI/SCK/SS OUTPUT
  SPCR = _BV(SPE) | _BV(MSTR) | _BV(SPR0);  // SPI ENABLE, MASTER, F/16
  DEV_DISABLE;
}

// 送受信
void hid_task(void)
{
  if(!Is_device_enumerated())    // Check USB HID is enumerated
    return;

  hid_report_out();
  hid_report_in();
}

void hid_report_out(void)
{
  Usb_select_endpoint(EP_HID_OUT);
  if(Is_usb_receive_out())
  {
    Usb_read_byte();
    Usb_read_byte();
    Usb_ack_receive_out();
  }
}

void hid_report_in(void)
{
  Usb_select_endpoint(EP_HID_IN);
  if(!Is_usb_write_enabled())
    return;            // Not ready to send report

  DEV_ENABLE;
  SPDR = 0b01100000;   // START,SGL=1,ODD=0,MSB=0
  while(!(SPSR & _BV(SPIF)));
  Usb_write_byte(SPDR);
  SPDR = 0b00000000;
  while(!(SPSR & _BV(SPIF)));
  Usb_write_byte(SPDR);
  DEV_DISABLE;

  Usb_ack_in_ready();    // Send data over the USB
}

受信処理は受信だけで何もしていない。デモプログラムは送受信データ長が8バイトなので、usb_description.h のEP_IN_LENGTH、EP_OUT_LENGTH、LENGTH_OF_REPORT_IN、LENGTH_OF_REPORT_OUTを書き換えてデータ長を2バイトにしてある。

MCP3002は2CHのA/Dコンバータを内蔵しているから、このプログラムを拡張すれば両方使えるようにするのも難しくないはず。SPI接続のSRAMをつないで、受信データを蓄積できるようにすればデータロガー的な使い方もできそうだな、色々やってみよう。

今日借りた本

書名	著者
星新一時代小説集 天の巻	星 新一

昨日発生した客先でのトラブルは、プログラムがサーバのデフォルト値に依存ずる作りになっていたことに加えて、サーバの入れ替えによってデフォルトの挙動が違ってしまった事によるコンボで発動した事が判明。

デフォルト値に依存するプログラムなんか作ってはいけないんだが、たまたま動いていたので今まで全く気付かなかった。きちんと初期値を設定するように修正するのが真っ当なんだけど、サーバ側のデフォルト設定が変えられるんなら差し換えの手間が無くて済むので、可能かどうか打診しよう。

プログラムを自動アップデートできるように仕掛けておけば良かったかなぁ。でも余計な事するとそこでまたバグが（笑）。

昼休みに図書館へ行って「数学的帰納の殺人」「猿駅/初恋」を返却。

「数学的帰納の殺人」はミステリなのかなぁ。どうも殺人に対する動機付けが納得できないというか、「カルトだから何をやっても不思議ではない」という筋書きはどうかと思う。

なんか草上仁さんは方向性を間違ってるんじゃないかなぁ。どうしたんだろう？

図書館のあと高円寺駅のマンスリースイーツで「あずみ野菓子工房 彩香」のバウムラスクを買ってくる。

バウムクーヘンを薄切りにしてメープルで味付けして焼いたもの。ベーグルラスクは食べたことがあるけど、バウムクーヘンのラスクは初めてだ。

もともと甘いのに更に味付けてしてあるから、食べてみた感じはほぼ予想通り（笑）。

会社に戻る途中でブックオフを覗くと、発売されたばかりの薄型PS3がもう並んでいて笑った。クレジット枠の現金化で流れてきた奴かなぁ。

まさか薄型PS3を最初に目にするのが、ブックオフになろうとは（笑）。

ビオチャレンジ

寝ている間に発表されたappleの新製品はカメラ内蔵で動画の撮れるiPod nanoらしいけど、いまいち食指が動かない。もちろん誰かくれるって言うなら喜んで貰うけど（笑）。

内蔵されたカメラを使って、また思いもよらないハックが開発される気がするので、そのへんはちょっと楽しそうではある。結局自分の携帯デバイスに対する興味って、その範囲内にしか存在しないのか（笑）。

iPodでLinux動かす話とか最近とんと見なくなった気がするのだが、あのへんってまだ継続してるのかなぁ。

かなり以前に開発したLinuxのシステムで、サーバを入れ替えたらクライアントのシステムが正常動作しなくなったというトラブルが上がってきたので、日中はその調査。

Debianをインストールした玄箱Proを引っ張り出し、テスト環境を構築しようと思ったのだが、いろいろやってるうちにシステムをぶち壊してしまったらしく、何故かaptが起動しない状態に。

しかたがないのでDebianのARMプロジェクトからaptのパッケージをダウンロードしてインストールしようとしたのだが、依存しているライブラリのバージョンが違うと怒られるし。

普通ならapt使ってライブラリを更新するんだけど、そのaptが壊れてるからなぁ（笑）。

テストは別なPCを使って行うことにして、こっちはしばらく放置。この際だからUbuntuに入れ替えてしまうという手もアリかな。

今日中にどうにかトラブルの原因を突き止めたかったので、お昼は買い置きのカップ焼きうどんと冷蔵庫に残っていたダノンのBioヨーグルトで済ませる。いまヨーグルトの上蓋をめくると裏面にシリアルナンバーがついていて、ダノンビオ１ケースが当たるキャンペーンをやってるんだけど、またしてもハズレた。

シリアルナンバーを入力すると画面に三個のヨーグルトが表示されて、そのうちの一つを選ぶんだけど、そうなっているといかにも1/3の確率で当たりそうな気がするんだが、どう考えてもそれは無いよなぁ（笑）。

Web上での抽選はいくらでも細工できてしまうから、なんとなく不信感があるんだけど他の人はそう感じないんだろうか？

まあハガキによる応募だって、本当に「厳正なる抽選」が行われているかどうかは当事者じゃないと分からないんだけどね（笑）。

障害対応

学校閉鎖は昨日までで、子供は今日からやっと登校。

四日間の閉鎖だったけど、その前の夏休み期間中に放課後クラブが一週間閉鎖されてしまったから、実質的には二週間閉鎖されていたのと同じで、色々と大変だった。

子供が奄美大島に行っている間に閉鎖だったら良かったのに（笑）。

組込みでターゲットボードが持ってこられないような仕事以外は、自宅でも進められるからどうにかなるんだけど、在宅勤務になると覿面に体重が．．．．（笑）。

今日は以前に手がけた全く別の仕事からそれぞれ障害報告が上がってきて、一件は割とすぐに原因が判明したんだけど、もう一件が分からない。

ホストから送られてきたデータを表示させるだけの装置で、送られてきていないデータが表示されてしまう現象なのだが、ホスト側と装置側のどちらのログを見ても正常に動作していて、異常なデータが紛れ込んでいる痕跡がない。

しかも謎なことに、そのデータはかなり昔に表示させたデータと同一らしい。表示装置は新しいデータが送られて来た時点で、古いデータは上書きして消してしまうから、どう考えてもそれはあり得ないんだけどなぁ。

ネットワークの一部が時間断層にでも落ち込んでいて、過去のデータが送られてきたのだろうか？（笑）。

もう一件の障害は日付の大小比較ロジックをミスるという単純な原因で、昨日他の人が作ったプログラムの大バグに遭遇して唖然としたんだけど、これもかなりアレなバグなので人のことは言えないな（笑）。

こっちは修正版もすぐにできたのだが、装置が稼働中なのですぐには差し換えができない。利用者の少ない時間帯を聞いてみると、土日の午前中なら比較的少ないとのこと。

なるべく早くプログラムは差し替えたいので、明日の午前中に現地に行って作業してくるしかないなぁ。まあしかたがない。

今日は早く寝よう（笑）。

在宅デバッグ

学校閉鎖で今週二度目の在宅勤務。

明日は登校日だからこれでやっと平常に戻るわけだ。今年の夏休みは長かったなぁ（笑）。

昨日修正して客先に送ったプログラムは、修正部分は問題なく動作するようになったんだけど、予想通りにまた新たな問題点が発覚。悪い予想だけは的確に当たるなぁホント。

子供も家で残った宿題や課題に取り組んでいるので、その間に机上デバッグを進める。

プログラムにAとＢの二つの設定項目があるんだけど、個々に設定する場合は問題がないのに、AとＢの設定を両方変更して装置に書き込むとＡの変更が無かった事になってしまう。どこかでメモリをぶち壊している事は間違いないのだが、これがなかなか見つからなくて閉口する。

昼に子供と一緒にスーパーへ買い物に行って気分転換。充実野菜の「完熟桃ミックス」、栗ご飯の素、牛乳なんかを買ってくる。

充実野菜は子供のリクエストで買ったんだけど、飲んでみると野菜ジュースっぽい風味が完全に隠されていて、これなら野菜ジュース嫌いな子供でも飲めるんじゃないかな。うちはマクドナルドでハッピーセットを頼む時も「野菜生活100」を選ぶくらい野菜ジュース好きだから、特に必要は無いけどね（笑）。

午後も気合いを入れてデバッグ作業の続き。

壊されていると思われるメモリの内容を常にウォッチするようにして、小刻みにプログラムを実行していったら、やっと問題点が特定できた。

メモリ内容を転送する処理で、ある条件でインデックス変数がマイナスになっていたのだ。そのせいで配列の範囲を超えてメモリの転送が行われて、想定外のエリアまでぶち壊すという結果に。

でもプログラムを見ると、インデックス変数がマイナスになった場合の補正処理はちゃんと記述されていて、変だなぁと思ってじっくりその部分を読んでみたら、驚愕の事実が。

変数がマイナスになった時は補正してるのに、補正前の変数をそのまま使っているっ！！（爆）。

思わず噴いたぞ。いやもうなんと言って良いのやら。

夕方に修正ファイルを客先に送付してとりあえず一段落。まだまだバグが残ってる気はするが、もう考えたくない。

立つ鳥跡を濁さず。というのはソフトウェア業界では夢物語なんだろうなぁ（笑）。

ずんだ餅

一昨日から悩んでいたアプリのバグは、ログ出力をあちこちに入れまる原始的な手段でようやく解決。

装置から読み出したデータが一部消失していて、受信処理のバグだろうと思ってその部分を重点的にチェックしていたんだけど、ログを見てみると装置から送られてくる時点で既にデータが消失している。

最初は装置側の不具合を疑ったんだけど、他のツールでは正常に読み書きできているので、アプリの送信処理にログを入れてみたら、途中からデタラメなアドレスにデータを送っている事が判明。

どうやら装置側は正常に書き込まれたデータのみを、次の読み込み要求では返してくる仕様になっているらしい。アドレス異常でデータが飛び飛びにしか書き込まれていなかったから、読み出しでデータが消失しているように見えたのだ。

送信処理を修正して一件落着。

それにしてもこのプログラムはバグ多すぎ。というかハッキリ言って未完成だろこれ。客先から修正依頼が来たけど、作った人が既に辞めているのでどうにかしてくれという事で回ってきたのだが、実際には途中で投げ出されたプログラムをデバッグして完成させているのと同じで、修正なんて言うレベルじゃない。

なんか騙されたような気分。

とりあえず修正したファイルを客先に送って確認して貰う。明日はまた新型インフルエンザによる学校閉鎖で自宅にいなくてはならないから、これで片づいてくれると良いんだけど、まだ他にとんでもないバグが潜んでそうなんだよなぁ．．．．

帰宅すると日曜日に品川駅で買ってきた「ずんだ茶寮」のずんだ餅が解凍されていたので食べる。美味しいんだけど仙台人に言わせると舌触りが滑らかすぎるし、甘すぎる。これでは単なるスイーツではないか（笑）。

品川駅構内のこのお店ってずいぶん前からあるんだけど、店舗案内に含まれていないのは何故だろう？

学校閉鎖

放課後クラブが閉鎖になった時点でこうなるだろうとは思ってはいたけど、予想通り子供の小学校は今日から木曜日まで学校閉鎖。

まだ子供を一人で留守番させておくには不安があるので、今日は在宅勤務という事にした。幸い今抱えてる仕事はPCアプリだけだから、自宅のPCでもどうにか作業はできる。

今日は台風接近で外は大荒れの天気だから、在宅勤務の方がラク．．．．と思ったら学校に学校閉鎖中の生活に関する資料を取りに行く必要が（笑）。

昼前ぐらいに雨がちょっと弱まったので、すかさず学校に向かったのだが、出たとたんに土砂降り。学校に着いたときにはずぶぬれになってしまった。しかも口惜しいことに学校で資料と課題を受け取り、外に出たら小振りになってくるし。ううむ、完全にタイミングを誤ったか。

子供が夏休み中に書く作文の用紙なんかを貰ってきたので、リュックに入れておいたんだけど雨が中まで滲みて濡れてしまった。ビニール袋とか持っていくべきだったなぁ。

そういえばお台場ガンダムの展示は今日が最終日だったけど、最終日に行われるはずだったクロージングセレモニーはこの悪天候ですべて中止になってしまったらしい。実物大ガンダムも台風の進路を変えるまでの力は無かったか（笑）。

午後は自宅に籠もって仕事。

会社を既に辞めてしまった人が作ったバグだらけなアプリに、またもや新たなバグが発覚していて頭を抱える。

実機が無いと動作確認できない部分だったので、プログラムにログを吐くクラスを追加して客先で実行してもらい、メールで送られてきたログを見てプログラムを修正という、超原始的なリモートデバッグをやっていた。

結局原因は分からなかったので、他に上がってきた不具合のうち簡単に直せる部分だけ修正してお茶を濁す。続きは明日なんとかしよう。

出社している時と仕事量はさほど変わらないのに、それプラス子供の面倒見たり土砂降りのなか小学校まで行ったりしていたから、異様に疲れてしまった。明日は妻と交代なので、会社で休もう（笑）。

レンジクック

放課後クラブ閉鎖により本日も自宅勤務。

子供が夏休みの自由研究をするのにセロテープや模造紙が必要との事なので、午前中は笹塚の文房具屋へ買い出し。プリンタ用紙が必要だったのでそれもついでに買ってくる。

午後は家で仕事。

昨日の夜に会社へ行って取ってきたソースファイルを開いて修正を始めたんだけど、既に退社した人が作った壮絶的にスパゲッティなプログラムなもんだから、修正内容は単純なのに恐ろしく手間がかかってしまった。

しかも印刷処理が嘘っぱちで、全ページ同じ内容しか出力されないという壮絶なバグがあり、いいかげんウンザリして帰りたくなってしまったが、今日は自宅勤務だった（笑）。

自宅で仕事してると通勤しなくて済むけど、逃げ場が無くなるんだよなぁ。

それでもどうにか夕方には片づいたので、客先にメールで送って完了。連絡手段をメールに限定しているから、今日みたいに自宅で作業していても客先には気付かれない（笑）。

子供のほうも自由研究をまとめるのに飽きてきたようなので、一緒にスーパーへ買い物に行き、PARMや牛乳なんかを買ってくる。

キユーピーの「レンジクック」シリーズに新しいのが出ていて、「チキンのトマト煮込み」「チキンのカレー煮込み」なんかはちょっと試してみたい気がするんだけど、使わなくても同じモノが作れると思うとなかなか手が出せない。

要するに電子レンジ対応の耐熱パックにソースが入っていて、そこに肉や野菜を入れて電子レンジでチンして作るわけだから、使えそうなパックを探してソースを作り、冷凍しておけば便利じゃないかという気がしている。

必要な時に冷凍庫から出して肉と野菜を入れ、パックのまま電子レンジで解凍加熱すれば出来上がり。

既にやってる人がいそうな気がするので、調べてみよう。

E8a

以前に開発した装置のプログラムを、そっくりそのままルネサスの新しいコンパイラで再コンパイルしたら、なぜか微妙に挙動が違う。

机上デバッグでは原因が掴めなかったので、最終兵器（笑）のデバッガを使うことにした。

以前にH8のデバッグ用として使っていた奴はインタフェースがPCMCIAだったから、わざわざノートPCをそれ専用に使っていたのだが、新しいE8aデバッガはUSB接続なので使うのが楽。

値段も結構安いらしい。atmelもAVR向けに同じようなデバッガ出してくれると良いのにな。

それにしてもこのデバッガ、色合いと大きさからどうしてもファミコンのコントローラを連想してしまう（笑）。特に裏側から見るとそっくり。わざと作ってないかこれ？

ドライバをインストールすると「E8a Self Check Program」というのがHEWのスタートメニューに追加されたので、実行してみるといきなりエラー。PDFのマニュアルを読むとセルフテストの時はターゲットに接続するケーブルをデバッガ自身の側面にあるコネクタにつなげと書いてあった。

やっぱりマニュアルは先に読まないとダメだな（笑）。

デバッガを使ってステップ実行させると机上デバッグでは分からなかったバグも一発。うっかり配列の領域を越えるアクセスをしている所があって、以前のコンパイラではたまたまそこに有意なデータが無かったのが、新しいコンパイラではメモリの配置が変わってデータとして解釈されるデータがあったせいで、動きが異なっていたのだ。

たまたま顕在化しなかっただけで、バグなのは間違いないから発覚して良かった。次に出荷するバージョンからこっそり直しておこう（笑）。

暗号解読

7月に下巻が出るコミック版「数学ガール」の上巻をいまごろ購入。

発売された当初はミルカさんとテトラちゃんのイメージがずいぶん違うなぁと思っていたんだけど、今見るとそれほど違和感が無い。原作読んでいた時はテトラちゃんが柊つかさのイメージだったからなぁ（笑）。

辞めてしまった人が作ったプログラムの修正依頼がまわってきたので、午後はそれの解読作業。

他人の作ったプログラムなんてただでさえ読みにくいのに、それが元々はPC-98で動いていたMS-DOSのプログラムを、無理矢理Windowsに移植した代物だったので、ソースを開いた瞬間ゴミ箱に叩き込みたくなってしまった（笑）。

と言うわけにもいかないのでプログラムの解読を始めたのだが、WindowsアプリでDOSアプリのようなUIを無理矢理実装してるもんだから、あちこち無理があって恐ろしく複雑怪奇なプログラムになっている。ほとんど暗号解読の領域。

なんとか解読できても、今度はそれに対して修正依頼の内容を適用させなくてはならなくて、ロジック的なバグ修正ならまだどうにかなるんだけど、UIの変更まで含まれていて目の前が真っ暗に。

DOSアプリっぽい操作にするために色々とねじ曲がった実装になっているのに、それを更に変更ってマジに止めて欲しいぞ。

それならもう全部捨てて最初から作り直したい所なんだが、時間が無いのでそうも行かない。結局ねじ曲がった実装を更にねじ曲げるような方法で、無理矢理変更してしまった。

ねじ曲がった所を更にねじ曲げれば、一周して元に戻りそうなものだけど、実際には更にあさっての方向に行ってしまうんだよなぁ（笑）。ねじれは加算しても相殺されず、それどころか累積されるのであった。

諸行無常。

仮想+仮想

開発用に普段のPCとは別のPC環境を用意する必要があった時に、今まではサブPCに開発環境をセットアップして使っていたんだけど、メインPCがCore2Duoマシンになったので、VirtualBoxで仮想PC上に開発環境を構築するのをちょっと前から試している。

以前のPCではCPUパワーもメモリも足りなくて、仮想PCでの開発は苦しい部分があったのだが、さすがにデュアルコアCPUならそのへんもかなり楽で、あまり違和感なく使える。

仮想PCを今まで開発に使ってこなかったのは、制御系のプログラムを開発する時に外部機器との接続が不可能か、できても色々と問題が多いという理由があったからなんだけど、VirtualBoxはホストPCに接続された機器がある程度利用できるので、USBシリアル変換アダプタを使えないか試してみた。

最初はホストPC側のCOMポートをそのまま使用する方法を試してみたのだが、ポートモードの設定を「ホストにパイプ」「ホストデバイス」のどちらに設定してもダメで、仮想PCがエラーで起動しなくなってしまう。

そこで今度はUSBコントローラを有効化させて、USBデバイスフィルタに「FTDI USB <-> Serial」を選択して起動すると、その瞬間にホストPCのデバイスマネージャからUSBシリアルアダプタが消えて仮想PC側で新しいハードウェアが検出された。

FTDIのドライバをインストールすると、ちゃんと仮想COMポートとして認識される。

この状態でプログラムを起動して、追加された仮想COMポートに接続してコマンドを送ると、USBシリアル変換アダプタに接続されている装置が動いて、モーターが回ったりする事も確認できた。

これなら制御系の開発にもある程度なら使えそうだ。

プログラムは仮想PCの仮想シリアルポートに接続しているわけで、言ってみれば二重の仮想状態なんだけど、それが現実世界のデバイスを制御しているというのは、なんとなく奇妙な感じがする。

まあ仮想PCも仮想COMポートも外部から見ればPCのプログラムに過ぎないから、PC上のプログラムが外部デバイスを制御しているだけで何の不思議も無いんだけどねぇ。

仮想Gainer

以前から試してみようと思っていたGainer(Pepper)を先日ようやく使い始めたので、開発環境であるProcessingもちょこちょこいじって遊んでいる。

フィジカルコンピューティングうんぬんを抜きにしても、かなりお手軽にグラフィックが扱えるので、これはこれで面白い。Processingでデータを可視化するというお題目は何度か目にしていたが、こういうことか。納得。

GainerはUSBシリアルでPCと接続されているんだけど、サンプルプログラムを見ると接続する時にポート番号を指定している部分がない。

このへんの処理がどうなっているのかちょっと気になったので、Gainer用ライブラリのGainer.javaとClient.javaの中身を読んでみた。

Gainerとの接続を行うメソッドはClientクラスのfindGainer()で、この中で存在するCOMポートをリストアップし、順番にポートを開いてGainerのバージョンコマンドを投げ、応答をチェックするという事をやっていた。思ったより力業だなぁ（笑）。

でもおかげでUSBのベンダIDとか関係なく使える訳か。

シリアル通信で決められたコマンドに対して応答を返せば、マイコン側はPSoCだろうがAVRだろうがPICだろうが何でも良いって事だから、仮想的なGainerも作れそうだ。

Processing側からはGainerにスイッチやセンサがつながっているように見えるけど、実際には画面上のボタンやマウス入力に置き換えられていて、ハードウェアを用意しなくても色々と試すことができる。

動くようになったら実際にGainerをつないで、仮想Gainerのほうはデバイスを無効にしてしまえば良い。

って何も調べずに書いてるけど、もう既にありそうな気が（笑）。

逆接続

ソフトウェアのみでAVRマイコンをUSBデバイスにしてしまうAVR-USBは、いつのまにかV-USBと名称が変わったらしい。

Atmel社の登録商標との対立を避けるために、名称変更を行ったと公式サイトに書かれていた。

以前に作ったAttiny45を使ったマイコン基板がこのV-USBをベースにしている。

先日Arduinoでちょっと動かしてみたシャープの距離モジュールを、今度はこっちに接続して動かしてみようとしたんだけど、A/Dコンバータからの入力をUSBキーボードとしてPCに送るようにファームを書き換えて試してみたところ、どうも正しい値が出てこない。

チェックしてみるとVCCのピンに3.3Vしか出ていない。この基板ってそもそもAttiny45を3.3Vで動作させるように作っていた事を、すっかり忘れていた（笑）。

距離モジュールは5V動作だから、この電圧では正しく動かなくて当たり前。

もあさんのPepperが同じ箱の中に入っていて、こっちは+5Vで動作しているからファームを書き換えてしまえば代わりに使えるはず。と思ったんだけど、せっかくGainer互換機として動いているんだから、この機会にGainerの開発環境も試してみることにした。

かくして当初の目的からどんどんズレていく事に。まあいつもの事だけどね（笑）。

とりあえずPepperがちゃんと動くこと確認しようと思って、まずはそのままPCに挿してみたのだが、デバイスが自動検出されてドライバを読み込み、仮想シリアルポートとして認識されるまでは良かったんだけど、通信ソフトでコマンドを送っても何の反応もない。

念のため先日MTM03で購入したPepperキットのAttiny85に差し替えても結果は同じ。

AVR-USB(V-USB)はUSBハブ経由だとうまく動かない事がある。という話を以前に読んだことをふと思い出して、液晶モニタのUSBポートから本体のUSBポートに挿し直してみると、今度はちゃんと動作した。

USBハブ経由だと電流が足りないんだろうか？でもUSBデバイスとしては認識されてるんだよなぁ。謎だ。

Gainerの開発環境としてはFlashやMax/MSP、Processingなどがあって、お馴染みArduinoの開発環境はそのProcessingをベースにして作られている。

エレキジャックにもあさんが「Ginger/Pepper/Sugarでフィジカル・コンピューティング」という記事を書かれていて、その中でProcessingについても紹介されていたので、それを参考に試してみた。

Processingの最新版を入れてしまったせいで最初Gainer(Pepper)を認識してくれなかったが、ProcessingのLibraryに含まれる

• librxtxSerial.jnilib
• librxtxSerial.so
• RXTXcomm.jar
• rxtxSerial.dll

をGainerのフォルダに上書きコピーしたら、ちゃんと認識されるようになった。

やっと準備ができたので距離モジュールをアナログ入力ポートにつなぎ、テストプログラムを走らせてみたのだが、それでも値が正しく取得できない。

回路をチェックするとPepperのピン番号を逆に数えていて、距離モジュールへの電源が逆接続になっていた。ヤバいと思ってすぐ元に戻したのだが、もうあとの祭り。あっさりとお亡くなりになってしまった。

念のために可変抵抗をつないでみると、こっちは正常に値が出てくるから、距離モジュールが死んでいるのは間違いない。赤外線LEDは光ってるんだけど、受光用の素子がダメになったようだ。

これだけ回り道して結局最初の目的にたどり着けなかったとは、トホホ。

まあ壊れてしまったものは仕方がない。Processingはなかなか良いオモチャになりそうだから、また秋月に行って距離モジュールを買ってくるまではそれで遊んでいよう。

AT90USB162マイコンボード開発メモ【4】

最近はArduinoとかAttiny13Aで遊んでいて、AT90USB162マイコンボードのほうは放置気味だったけど、こっちのボードでもやりたいことが出てきたので再開。

CDCデバイスとして動かす所まではできたから、今回は汎用HIDデバイスとして動かしてみる。

例によってAVR USB Software Packagesから汎用HIDデバイスのデモプログラム STK526-series2-hidio-2_0_1-doc.zip をダウンロードして解凍、クロック周波数を書き換えて、あとは hid_task.c に独自の入出力処理を記述すればいい。

void hid_task_init(void)
{
   PORTB = 0;
   PORTD = 0xff;
   DDRB  = 0xff;
   DDRD  = 0;
}

void hid_report_out(void)
{
   Usb_select_endpoint(EP_HID_OUT);
   if(Is_usb_receive_out())
   {
      PORTB = Usb_read_byte(); // Recv data
      Usb_read_byte();    // Dummy (not used)
      Usb_read_byte();    // Dummy (not used)
      Usb_read_byte();    // Dummy (not used)
      Usb_read_byte();    // Dummy (not used)
      Usb_read_byte();    // Dummy (not used)
      Usb_read_byte();    // Dummy (not used)
      Usb_read_byte();    // Dummy (not used)
      Usb_ack_receive_out();
   }
}

void hid_report_in(void)
{
   U8 in = PIND;
   Usb_select_endpoint(EP_HID_IN);
   if(!Is_usb_write_enabled())
      return;                                // Not ready to send report
   if(in == g_last_in)
      return;
   g_last_in = in;
   Usb_write_byte(g_last_in);
   Usb_write_byte(GPIOR1);     // Dummy (not used)
   Usb_write_byte(GPIOR1);     // Dummy (not used)
   Usb_write_byte(GPIOR1);     // Dummy (not used)
   Usb_write_byte(GPIOR1);     // Dummy (not used)
   Usb_write_byte(GPIOR1);     // Dummy (not used)
   Usb_write_byte(GPIOR1);     // Dummy (not used)
   Usb_write_byte(GPIOR1);     // Dummy (not used)
   Usb_ack_in_ready();             // Send data over the USB
}

元のデモプログラムはLEDやスイッチの処理が分かり難かったので、PortBが8bit出力、PortDを8bit入力という単純なパターンに書き換えてみた。

ダミーのread/writeがくっついてるのはレポートディスクリプタのIN/OUT長が8バイトになっていて、単にそれに合わせただけだから実際には無くても良い。

PC側のアプリケーションは2バイトデータでLEDのOn/Offを指定するようになっているから、そっちも書き換えなくてはならないのだが、generic_usb_hid_2008-11-19.zip に入っているWindows用のソースはVisualStudio 6.0用の古いプロジェクトで、そのまま使うには色々と不都合がある。

なので今後自分で色々といじる為の雛形として、新規にテストアプリも作成。

と言ってもUSBに関する処理は AtUsbHid.dll が全部受け持つから、内容的には結構簡単で、思ったよりもあっさりとできた。大部分は元のデモアプリから切り貼りしたし（笑）。

でも一箇所だけ良く分からない所があって、プログラムの最後に

hidUnregisterDeviceNotification

をCALLしてDLLに登録した通知用のウィンドウハンドルを解除してるんだけど、そこでアクセス違反が発生してしまう。

AtUsbHid.dll のソースがあればデバッグできるんだが、ソースは提供されていないのでお手上げ。その直後に FreeLibrary() でDLLをアンロードしているから、ウィンドウハンドルの解除は行わなくても実害は無いと思うけど、ちょっと気に入らない。

ちなみにこのUSB基板を使ってやってみたい事って、シャープの距離モジュールをつないでUSBでデータを取ることだったんだけど、よく考えたらAT90USB162にはA/Dコンバータが無かった（笑）。

秋月で200円で売っている10ビットのA/Dコンバータを外付けする手はあるけど、それだったら千石で300円で買えるAttiny85を使って、AVRUSBのファームを改造して使った方が無難かも。

Runtime Error!

先週の金曜日にやった仕事の続きをしようと思って、Visual Studio2005でプロジェクトを開き、リソースビューでダイアログを修正しようとしたとたん、ランタイムエラーでVisual Studioが落ちてしまった。

先週の時点では何ともなかったのに、何故？

その後何度繰り返しても同じ症状で、リソースが開けない。

でもプロジェクトを丸ごと他の人のPCに移して試して貰うと、そっちでは問題なく開くことができる。むぅ。

更に良く分からない事に、コピーしたプロジェクトをネットワーク越しに開くとこっちでも開けるのに、それをローカルにコピーしてくるとランタイムエラーが発生する。なんだこれは？

違いはVisual Source Safeのバインドぐらいだから、試しにローカルプロジェクトのバインドを完全に解除し、ソリューションを保存してから開き直すと、今度はちゃんと開けるようになった。

簡単に書いてるけどここに至るまでに色々と試行錯誤して、VSSが原因だと判明するまで一時間以上かかっている。ぐったり。

でも根本的な原因は未だに不明なまま。

たぶんVSSのデータベースに何らかの異常が発生したのだと思うが、ANALYZEユーティリティでデータベースの分析を行っても、異常は検出されない。何かミスってソースファイルをぶち壊してしまった時に、バックアップ目的としてVSSを使っているのに、そっちがぶち壊れては話にならんなぁ。

古いバージョンのVSSで作ったデータベースを、今まで引き継いで使っていたから、どこかに無理があったのかも知れない。

ぜんぶクリアして最初から作り直すべきだろうか？

いっそのこと違うソース管理ツールに乗り換えるのも手かもなぁ。ちょっと検討してみよう。

Star Ruby

RubyとC#の二つはだいぶ前から習得したいと思っていて、今までにも何度か仕事が空いた時に自習していたりするのだが、ある程度進んだ所で仕事が忙しくなって、結局いつまで経っても学習度合いが中途半端という状態になってしまっている。

両方ともある程度のモノは作れるんだけど、仕事で使えるレベルまではあと一歩という所。たぶんRubyもC#も仕事で何か一本作れば突破できるんだろうと思うが、それって玉子が先か鶏が先かという（笑）。

C#のほうはデータベースがらみの仕事でちょっと使ってみるつもりで、先週ぐらいからちまちまとアプリケーションを作り始めているので、そっちのうほうはどうにかなりそうな感じにはなってきた。

同じVisualStudioでもC#だとIDEがだいぶ改良されていて、C++よりも使いやすくなってるんだけど、メソッドとフィールドがクラスビューの右クリックメニューから追加できない仕様なのはいまいち解せない。いちいちクラスデザイナー使うのって不便じゃないかなぁ？

Rubyのほうは先日知ったRuby用の2Dゲームライブラリ「Star Ruby」が面白そうなので、これで何かゲームっぽいものでも作ってみようかと考えている。

このゲームライブラリはなかなか良くできていて、適当なキャラクターを動かしてそれっぽいものを作るのは簡単そうなんだけど、私にはゲームとして仕上げるための音楽的素養がゼロという重大な問題が（笑）。

自動的に音楽を生成してくれるツールというのを以前に見たことがあるけど、そのへんの分野って最近はもっと進歩してたりするんだろうか。

ゲームを実行させるとそれを認識して、適切なBGMを自動生成してくれたら最高なんだが、さすがにそこまでは進歩してないだろうなぁ（笑）。

EBCDIC

いま仕事で作っているアプリケーションは複数の元データを読み込んで、それを比較結合するような内容なんだけど、何故かその元データがEBCDICでエンコードされている。

EBCDICのファイルを見たのはミニコンの仕事していた時以来だから、扱うのは十数年ぶりじゃないか？（笑）。

プログラムのデバッグする時はデータを色々と変えて動作を試すんだけど、元データがEBCDICになっているとこれがやり難い。EBCDICとASCIIを相互変換するツールは作ったのだが、ASCIIに変換してからデータを変更し、またEBCDICに戻してテストというのは手間がかかりすぎる。

要はEBCDICをそのまま扱えるテキストエディタがあれば良いわけで、探してみるとTextplorerというツールが見つかった。このツールを使えばEBCDICのファイルをそのまま開いて編集し、書き戻すことができる。

でもこれって個人使用に限りフリーウェアで、商業利用は有料というライセンス形態になっているから、仕事で使うわけにはいかない。

他に無いか？と更に探すと、テキストエディタではなくバイナリエディタなのだが、StirlingというツールがEBCDIC対応らしい。早速ダウンロードして使ってみると、バイナリデータを構造体として表示する機能があったり、なかなか使い易かった。

割と昔からあるツールらしいけど、知らなかったな。やはりネットは広大だ（笑）。

Dos版

昨日奥歯が折れてしまった件でかかりつけの歯科医に朝イチで電話したら、今日は予約がいっぱいで診て貰えるのは明日の昼になってしまった。それまではこのまま我慢するしかないのか。

痛くはないんだが食べ物が入り込むのでどうにも不愉快。折れた歯を瞬間接着剤でくっつけておいたら、先生に怒られるかなぁ（笑）。

連休前に客先へ送ったデータ変換ツールの変更依頼が来ていて、メールを読んでみると細々とした変更箇所に加えて、WindowsのDos窓からでも動かせるようにして欲しいと書いてあった。

ダイアログベースのWindowsアプリとして作ったのに、今更そんな事言われても．．．．と思ったら仕様書にその事もちゃんと書かれていた（笑）。おもいっきり見落としていたよ。

最初はダイアログベースのアプリに手を加えて、コマンドラインで起動された時は処理を切り替えるようにしようと思ったのだが、Dos窓に対してメッセージを出力することができなくて困ってしまった。printfで出力しても何も出てこないし、AllocConsole関数で割り当てると新しいコンソールになってしまう。

仕方がないので元のプログラムから変換処理を分離してクラス化し、新たにコンソールベースのアプリを作成して、プログラムをWindows版とDos版の二本立てにした。

変換処理は同じクラスをソースコードレベルで共有するようにしたので、これなら変換ロジックに何か変更があった場合でも修正は一ヶ所で済む。

元のプログラムがMFCアプリだったから、Dos版もMFCのライブラリを使わざるを得なくて、プログラムサイズが300Kbyteになってしまったのがちょっとアレだな。MS-DOSのメインメモリが640Kbyteだった時代を経験しているから、Dosのプログラムというとどうもまだそのイメージが（笑）。

モンキーテスト

以前に開発した装置で客先から確認の依頼が来たので、現地までUSBメモリ持参で行って、トレースログをコピーして持ち帰ってきた。

何故か現地に連絡が行っていなくて、思いっきり不審がられてしまったが、まあ連絡も無しにやってきた男がいきなり現金の入っている装置の鍵を開けてくれと言ったら不審に思うのは当然だわなぁ（笑）。

これだから中間に複数の会社が入っている仕事は嫌なんだ。重要なことが伝言ゲームで伝わらないし。ぶつぶつ。

デバッグ用のトレースログって通常はプログラムの処理毎に出力するんだけど、今回は一般客が操作する端末装置で、トラブルが起きた時にどんな操作が行われていたのかが分からないと解析が困難になるから、どのタイミングで画面上のどのボタンがクリックされたのかという所まで記録するようにしてある。

会社に戻ってログを解析してみると、客先から確認依頼のあった件については特に問題のない事が分かったのだが、それとは違う部分に問題があったことが発覚。

ログで当該する部分の操作を再現してみると、お客さんが本来は必要のない無駄な操作をしていて、その時にデータが一部おかしくなる事が確認できた。

ログにボタンクリック操作まで記録しておいたのが、早速役に立つとは（笑）。

開発した人間って無意識のうちに無駄な操作をしなくなってしまうから、何度もその部分はチェックしたはずなのに全く気付かなかった。それなのにあっさりとそのバグを叩き出してしまうとは、素人のお客さんって怖いよなぁ（笑）。

モンキーテストと言って、でたらめに操作された場合に誤動作を起こさないか確認する作業が開発の最終段階には必ずあって、もちろん今回もそのテストは行っていたのだが、まったくのでたらめではなくて正しい操作なんだけど無駄のある遠回りというパターンには対処できていなかった。

以前にどこかで読んだ話で、ソフトハウスでプログラムが全くできない中年男性が高給を貰っていて、何故かと言うとその人がシステムを操作すると必ず誰も気付かなかった穴が発覚するから非常に重宝している、というのがあった。

確かにそんな人がいたら、うちでも雇ってみたいぞ（笑）。

静的トレース

3年前に開発した組み込みLinuxのプログラムについての質問が客先から突然来たんだけど、そんな大昔に作ったプログラムの内部動作なんて、当然ながら覚えているわけがない。

1年前に開発したシステムの事だって、覚えているかどうか危ないのに（笑）。

既に実機も開発環境も残って無いので、プログラムを読み直すのにVisual Studioにプロジェクトをインポートして、main()関数からソース上で動作を脳内トレースした。

もちろんVisual Studioでコンパイルなんかはできないのだが、ソースコード上で右クリックして他のファイルの関数へ飛んだり、また元に戻ったりという機能は使えるので、動作をトレースするのには役に立つ。

と言うかその機能がないともうトレースなんかできません（笑）。

昔はまだ今ほど脳がすり切れてなくて、テキストエディタでソースをトレースして脳内スタックで元に戻ったりできたのだが、今はもうダメ。あっという間にスタックが尽きて迷子になってしまうことはほぼ確実だ。

今回はVisual Studioを使ってどうにか記憶を掘り起こすことができたけど、この手の静的トレース作業に特化したツールって何か無いのだろうかと思って探してみると、Understandというツールが見つかった。

プログラムの構造をグラフィカルに表示できる機能があって、こんな感じのあれば良いなと思っていたものに近いのだが、いちばん安いEngineer Editionでも98,000円する。

ICEとかのどうしても必要な開発ツールなら会社で購入してもらえるけど、これは難しいだろうなぁ。

脳の機能を強化してスタックを増やしたり、集中力を高めたりできる増設カートリッジがあれば、そっちの方が欲しいけどね（笑）。エフィンジャーの小説に出てきたような奴。

同じような効果がある危ない薬もありそうだけど、そっちは勘弁。まあ脳の増設カートリッジも危険度で言ったらあんまり変わらないか？

米菓まつり

今週も日曜日は休日出勤。まあ週休1日制だと思えば（笑）。

作業量は多いんだけど、とにかく手を動かしていけば終わるタイプの仕事なので、頭をそっちの作業モードに切り替えてバリバリとコードを書いていく。

画面が35枚もあるプログラムで、他の画面で似たような処理をしている部分はコードを切り貼りして作れるんだけど、VisualStudioはマルチ画面に対応していないのでこんな作業の時はちょっと面倒。3画面でソースとヘッダとダイアログがそれぞれ同時に開けたりすると、かなり便利だと思うんだけどなぁ。

無理矢理ウィンドウ枠を広げて並べる手もあるんだけど、それぞれの画面で独立しているほうが使い易い。できればそれぞれの画面で更にタブで切り替えできれば完璧。

VisualStudioがあと10回ぐらいバージョンUPすればそうなるかな（笑）。

今日も夕方に子供を迎えに行くので、急ピッチで仕事を進めたら午後2時過ぎにはとりあえず片づいた。

まだ残ってる仕事もあるんだけど、そっちに手を付けるとあと2時間では終わらないのが確実だから、ここで切り上げ。

ちょっと時間ができたので、帰りは新宿経由。

新宿西口イベント広場の前を通りかかると、米菓まつりというのが開催されていて結構賑わっていた。

おせんべいやおかき類は大好きなので、その中でしばらくうろうろ。

思わず多量に買い込んでしまいそうになったが、冷静になってみると地元のスーパーでも買えるものばっかりで、多少は安かったんだけど自宅にまだおせんべい類のストックが大量にあるので自粛。

ばかうけのキャラクターグッズがおまけに付いていたら、危なかったかも（笑）。

画面サイズ

今日は朝から休日出勤。

開発中の装置をデモすることになったので、目に付く箇所を色々と手直ししてから実機にコピーしてちょっと動かしてみたんだけど、なんか画面のコントロールが微妙に上に偏っている。

実機の画面サイズに合わせてウィンドウの大きさを設定したはずなのに、なんでズレてるんだ？と思って調べてみると、どうやら最初にウィンドウサイズを合わせた時にタイトルバーの高さまで含めて設定してしまったらしい。

実際にはタイトルバー無しのフルスクリーン表示だから、その分だけコントロールの位置が上にズレてしまったのだ。

でも単純にその分だけ下げてしてしまうと全体のバランスが崩れるので、20枚ぐらいあるウィンドウのコントール位置を全部手作業で調整する羽目に。こんな作業のために休日出勤したわけじゃないのになぁ（笑）。

今日は子供がスポーツ少年団のイベントで渋谷区スポーツセンターへ行っていて、夕方に迎えに行くことになっているから、仕事は早めに片づけて撤収。

スポーツセンターへは終了予定時刻より30分ぐらい早めに着いてしまったけど、中に入ると閉会の挨拶をしている所だったから、丁度良かった。

帰りに駅前のグルメシティで焼き芋を買って、ライフで夕食の買い物をしてから帰宅。グルメシティで夕食の買い物をしなかったのは、ポイントカードを持っていなかったから（笑）。

ライフでも焼き芋を売ればいいのにな。

不正な処理

プログラムの資料を朝からEXCELで作っていて、あとはちょっとセルを並び替えれば完成というところまできたというのに、そこでいきなり不正な処理が発生。途中で一回しか保存していなかったから、まるまる一時間分の作業が泡と消えた。

作業中の一時ファイルがどっかに残ってるんじゃないかと思って探してはみたんだけど、それらしいのは見つけられなかった。

もうやる気が一気に120%ぐらい減退。

と言ってメゲているわけにも行かないので、記憶がまだ新しいうちに消えてしまった部分を再入力。

以前の入力内容を思い出しながら入力して、あとはちょっとセルを並び替えれば完成というところまできたら．．．．またEXCELが不正な処理で落ちた。

どうも結合したセルの移動とそのUndoで発生するらしいのだが、消えてしまった内容を出来る限り正確に再現しようとしたせいで、不正な処理に陥るパターンまで再現してしまったらしい。なんてこったい。

今度はこまめに保存しておいたから大丈夫だったけどね。

会社のPCにはプログラムの行を消してしまったり、カンマとピリオドを取り替えたりするこびとさんは住んでいるようなのだが、どうせならファイルを自動的に保存してくれるこびとさんがいれば良いのに（笑）。

って自動保存アドイン入れておけば済む話か。

時間感覚

仕事のプログラムにドはまり。

最初に考えていたプログラムの構造が作っているうちにハードウェア制御部分と整合しなくなってきて、そこをなんとか方向修正して進めてきた結果、ますます整合性が無くなるという完全な泥沼状態。

こうなったら根本的な構造から組み換えるしか無いんだけど、ここまで作り上げてからの変更はあまりに痛い。もっと早めに気付いていれば．．．．

画面関係は完全に別ロジックで分離してあったのが不幸中の幸いで、今日は朝からプログラムを解体してつなげ直すという作業に没頭。ここ数年間で一番じゃないかってくらい頭をフル回転させて、どうにか解体前のプログラムと同じ動作ができる所まで組み直すことができた。

一息ついて、そろそろお昼かなぁと思って時計を見てみたら、お昼どころか午後3時近くになっていたのでマジでびっくり。

楽しい時間は早く過ぎて、辛い時間はゆっくり流れるってよく言われるし、趣味でマイコンのプログラムやってる時なんかは確かに楽しいんだが、脳がオーバーヒートしそうなくらい悩みまくってプログラムの組み直し作業やるのってどう考えても楽しいとは思えないんだけどなぁ。

いや、これはあれか？試験で問題が分からなくて焦っている時は、あっという間に試験時間が過ぎてしまうという奴（笑）。

break文

今日は午後から客先でシステムの調整。

無線通信に使っているチャンネルに干渉する電波源が存在するらしく、ときどき不安定になるのでチャンネルを変更してみたのだが、どのぐらい効果があるのかは本番になってみないと分からない。

このへんは賭だなぁ。

今日は比較的電波状態が安定していて、通信エラーがほとんど発生していない状態だったんだけど、それにしては妙に通信速度が遅くて、リトライしまくっている時と同じくらいのスピードしか出ていない。

変だなぁと思ってプログラムをチェックしてみたら、大間抜けなバグを発見してしまった。

無線通信の処理は全体がループになっていて、エラー発生時は一定回数リトライを繰り返すようになっているんだけど、通信が正常に行われた時にそのループを抜けるためのbreak文が抜けていた。

つまり一回の通信で済むところを必ず複数回通信する無駄な事になっていて、そこにbreak文を追加したら処理速度がいきなり速くなった（笑）。

まさかこんな基本的な部分にバグが潜んでいたとは。

そういえば最初のうちは計算通りの通信速度が出ていた覚えがあるから、何かの修正の時にうっかりその一行を消してしまったのかも。

プログラム中の一行を消してしまったら、コンパイルエラーが出るか実行時に正常動作しなくなるのが普通だけど、ループを脱出するためのbreak文だと無くても見た目は正常に動いてしまうから、今の今まで気付かなかった。

break文が消えたのは、こびとさんの仕業という事にしておこう（笑）。

ダイアログエディタ

現在開発中のシステムは操作画面の数が結構多いんだけど、似たようなパターンの画面が多いから最大公約数的な画面を作っておいて、異なる部分は複数のコントロールを重ねておき、ON/OFFさせることで切り替えようと考えた。

テスト的に作った画面ではうまく行ったので、昨日から本番用の画面を作り始めたのだが、VisualStudioのダイアログエディタは全く同じ場所に複数のコントロールを重ねて配置するような使い方を全く想定してないらしく、最初のうちは良かったけど数が増えるにつれて収拾がつかなくなってきた。

ダイアログエディタ上に配置したコントロールをマウスクリックでしようとすると、重なっている別のコントロールが選択されてしまうから、いちいちTABで順送りする必要があって非常に効率が悪い。

おまけにぴったり重なっているとTAB順を変更する事も困難で、しかたがないからリソーススクリプトをテキストエディタで編集して再読込という、原始的な方法を使う羽目に。

ダイアログエディタにレイヤの概念があれば非常に楽だと思うんだが、Microsoftがそっち方向に開発ツールを強化する気配は無さそうなので、いっそのこと自分で作ってしまうか？

問題は今から作ってたらとっくにシステムの納期が過ぎてしまう事だな（笑）。

デバッグ用

受託開発の仕事って何が来るのか分からないし、会社の方針として来るものは拒まずなので（笑）昨日と今日とではまるっきり毛色の違うプログラムをしている事も珍しくない。

現在開発中の装置は現金の入出を伴うので、紙幣とコインの入出金装置が隣に置かれていて非常に狭苦しい。しかも動作音がかなり大きいので間近に置くとかなりうるさい。

だからといって離れたところに置くと、今度はデバッグするときにいちいちそこまで行かなくてはならないから、しばらくは我慢するしか無いか。密閉型のヘッドホンでも持ってくるかな。

それよりも問題はデバッグの時に多量の現金が必要になることで、会社の金庫から借りたりすると管理が面倒だし紛失すると困るから、自分の財布から出すことになるんだけど、長くやっているとだんだんお金がお金に見えなくなってくる（笑）。これも一種のゲシュタルト崩壊だろうか。

自分のお金なのに扱いが適当になってきて、今日は装置の中にお金を入れたまま帰ってしまったもんだから、帰りにスーパーで財布を開いた時に中身が空っぽでえらく焦ってしまった（笑）。

デバッグ用のお金があれば良いのになぁ、とマジで思ってしまったけど、よく考えたらそれって偽札か（笑）。

Excelリボン

開発したシステムが本番でコケるという失態を晒してしまったので、今日は午後から客先へ行って原因調査。

ありえないデータを端末が読み取ってしまう症状が出ていて、端末側の担当者も頭を捻っていたのだが、現場へ行ってみたらその問題はあっさりと解決。運用のミスで間違ったデータが記録されたカードが使用されていただけだった（笑）。

最重要問題は調査する前からあっさり片づいてしまったが、無線通信の安定度が悪いのはそれとは別の問題だから、現場で調査継続。

調査中に設定ファイルを変更しようとしてExcelを起動したら、インストールされていたのが会社で使っているのよりもかなり新しいExcel 2007で、UIがかなり違うので戸惑ってしまった。

新しいExcelはメニューバーやツールバーが無く、リボンと呼ばれるUIになっていて以前のUIに慣れた人にはかなり不評と聞いてはいたけど、まさかこれほどまでに違う代物だとは思わなかった。

知人の所で以前にPCが壊れて、Office入りの新しいノートPCを買ってきたらExcelがまるっきり違っていて大変だったという話を聞いたけど、こういう事だったのか。納得（笑）。

以前のUIに戻す設定がどっかにあるんじゃないかと思って探してみたが、見あたらなかった。

後から調べてみるとOffice 2007のUIを旧バージョンのスタイルに変更するアドインなんていうのが存在していたので、標準機能ではサポートされていないようだ。何考えてんだかよく分からない事ってMicrosoftには良くあるけど、これは極め付きだなぁ。

Visual Studio 2008にはカスタムリボンを開発する機能が備わっているのだが、もしかして全てのWindowsアプリをこの手のデザインにしてしまうつもりなんだろうか．．．．

本番環境

今日は去年納品したプログラムが実際に使われる日なので、午後から客先で本番に立ち会い。

テスト運用の時に色々と問題が発覚して、修正にかなり時間がかかったプログラムなんだけど、その後の最終テストでは問題なく動いたから本番でも大丈夫．．．．かと思ったら全然大丈夫じゃなかった。

テストの時に比べて無線通信の安定度が異様に悪く、通信エラーが多発してかなりボロボロ。

本番の時は端末のすぐ近くにノートPCが何台も置かれて、その殆どが無線LANで通信しているという状態だったので、極端に不安定になるのはそれが原因のようだ。

無線LANによる障害は当初から考慮してはいたんだけど、一瞬だからそれほど問題にはならないだろうと思っていたのが、まさかすぐ近くに20台以上のノートPCが稼働する環境に置かれるとは思ってもみなかった。

根本的な所から考え直す必要がありそうだ。

とりあえず会社で本番に近い環境を再現する必要があるなぁ。無線LANの入ったノートPCを20台かき集めるのは無理なので、デスクトップPCにUSB無線LANアダプタを10個ぐらい差してみるか？（笑）。

100円サーバ

会社で利用している接続業者が変わって、ホームページ用に提供されていたサーバ容量が一気に拡大したんだけど、誰もメンテナンスする人がいないから宝の持ち腐れ（笑）。

容量が拡大した以外に、今までは予め用意されていたCGIしか使えなかったのが、PHP、Perl、Ruby、Pythonといったスクリプト言語が使えるようになったので、暇を見てちょこちょこと試している。

とりあえずRubyとPythonで簡単なスクリプトが動くことは確認できたけど、サポートページやFAQを読んでもCGIについてはプログラムパスとパーミッションの設定ぐらいしか情報が無くて、あまり積極的に使わせようと言う雰囲気ではない。

FAQにCGIについてはサポートしませんってハッキリ書いてあるし（笑）。

まあサーバ管理者側にとってみたら、ユーザが勝手に動かすCGIなんて厄介の種でしかないし、サポートしてたらきりがないよなぁ。

会社で契約しているサービスはいちばん安い奴なので、RubyやPythonは使えてもMySQLが使えないから遊ぶにはいまいち。会社のレンタルサーバで遊ぶなって？（笑）。

自宅のサーバで遊べば良いんだけど、24時間稼働してる訳じゃないし固定IPでもないから、色々やるとしたら個人でのレンタルサーバ契約か。

Webアプリで遊んでみたい欲求って定期的に発生するんだが、あまり持続しないので継続的な契約をする気にならないのが問題。使いたいときだけ低価格で使えるような料金体系のサーバって無いものかな。

100円で一日だけ使える、ワイコインレンタルサーバとか（笑）。

ArduinoでRTC

パーツ箱を整理していたら、以前に秋月で買ったリアルタイムクロックモジュールが出てきた。

そのうち使ってみるつもりだったんだけど、仕事で同じチップを 使ってしまったので意欲が無くなってそのまま放置していたモノ。仕事でやった事を趣味で繰り返す気にはならないからなぁ。

以前に仕事でAVRを使うのが立ち消えになった事があるのだが、逆に良かったかも知れない（笑）。

全く同じ事を繰り返す気にはならなくても、Arduinoを使ってアクセスしてみるのは目先がちょっと違うので遊べるかなぁと思い直し、ブレッドボードで接続してみた。

I2CインタフェースなのでArduinoとの接続は2線だけ。VccとGNDを含めても4本ですむ。

RTCモジュール上にはプルアップ抵抗が乗っていて、パターンをハンダでショートすればプルアップが有効になるんだけど、他で使うときの事を考えて抵抗は外付け。

ArduinoにはI2C通信をサポートするWireが公式ライブラリとして含まれているから、それを使えば簡単にアクセスできるだろうとは思ったけど、実際にやってみたら思った以上に簡単で、ブレッドボードで配線してスケッチ（Arduinoのプログラム）が動くまで10分程度しかかからなかった。

まあ厳密にはエラー処理なんかを考える必要があるんだろうけど、その手の用途は最初から考えずに、とにかく目の前にあるものを短時間で動かすというArduinoの設計思想は良いよね。お気楽極楽プログラミング（笑）。

ソースファイルはこんな感じ

#include <Wire.h>

int RTC = 0xA2 >> 1;

void setup()
{
  Wire.begin();
  Serial.begin(9600);
}

void loop()
{
  if(Serial.available() > 0)
  {
    byte recv = Serial.read();
    byte param[20];
    int count = 0;
    switch(recv)
    {
      case 'R':
        ReadRTC();
        break;
      case 'W':
        while(count < 14)
        {
          if(Serial.available() > 0)
            param[count++] = Serial.read() & 0x0F;
        }
        WriteRTC(param);
        break;
      default:
        break;
    }
  }
}

void ReadRTC()
{
  Wire.beginTransmission(RTC);
  Wire.send(0x02);
  Wire.endTransmission();
  Wire.requestFrom(RTC, 7);
  byte rbuf[7];
  for(int i = 0; i < 7; i++)
  {
    if(Wire.available())
    {
      rbuf[i] = Wire.receive();
    }
  }
  Serial.print((rbuf[6] & 0x3F) + 2000);
  Serial.print("/");
  Out(rbuf[5] & 0x1F);
  Serial.print("/");
  Out(rbuf[3] & 0x3F);
  Serial.print(" ");
  Out(rbuf[2] & 0x3F);
  Serial.print(":");
  Out(rbuf[1] & 0x7F);
  Serial.print(":");
  Out(rbuf[0] & 0x7F);
  Serial.println("");
}

void Out(byte d)
{
  if(d < 16)
    Serial.print("0");
  Serial.print(d, HEX);
}  

void WriteRTC(byte *param)
{
  byte sbuf[7];
  sbuf[6] = param[2] << 4 | param[3];
  sbuf[5] = param[4] << 4 | param[5] | 0x80;
  sbuf[4] = 0;
  sbuf[3] = param[6] << 4 | param[7];
  sbuf[2] = param[8] << 4 | param[9];
  sbuf[1] = param[10] << 4 | param[11];
  sbuf[0] = param[12] << 4 | param[13];
  Wire.beginTransmission(RTC);
  Wire.send(0x02);
  Wire.send(sbuf, 7);
  Wire.endTransmission();
}

コンパイルしたスケッチをArduinoに転送して、シリアルモニタから'R'を入力するとRTCから読み出し、'W20081125123456"と入力するとRTCに日時を設定できる。

あまりにも簡単に動いてしまったので、思ったほど遊べなかった（笑）。RTCをそのまま接続しただけだと電源切ったときに設定が消えてしまうので、電気二重層コンデンサつないでバックアップできるようにしてみようかな。

ArduinoのIDEが起動時に妙に時間がかかって、Toolメニューを選択した時もしばらく固まっていたから、何故だろうと思ったらXPortの仮想シリアルドライバが入っていたせいだった。

ドライバだけ入っていてデバイスが接続されていないと、ポートチェックのタイムアウトに時間がかかって固まったようになるらしい。ドライバを無効にしておけば問題なし。

Setup Project

今日からの三連休、子供はまたキャンプに行くので朝に新宿駅まで送っていく。日帰りじゃないので今日のお弁当はサンドイッチにした。中身はチーズハンバーグと紅玉ジャム。

ちょっと仕事が残っていたから、その足で会社へ。

先週作成したプログラムのインストーラに、客先から送られてきた使用許諾契約.rtfとREADME.txtを組み込むだけの簡単なお仕事だったのだが、意外な所でハマってしまった。

いつもはInstall Shieldを使ってインストーラを作成するんだけど、今回はVisualStudioのSetup作成機能を使うことになったのがそもそもの原因で、もちろんこれでもちゃんとインストーラは作成できるのだが、専用ツールと比べると機能は低いし使い勝手も悪い。

でも使用許諾契約のrtfファイルを表示させる機能はあるから、そこまでは簡単にできる。問題はインストール完了後にREADME.txtを表示させる方法。

カスタム動作でVBScriptを実行させる事が可能なので、それを使ってファイルを開けばOKだろうと考えてやってみると、確かにメモ帳でREADME.txtを開く事はできた。

でもその時にNortonが思いっきり警告を出しやがるのだ。

この警告を無視しないとファイルを開くことができない。

これをどうにかできないかと思って午前中いっぱいあれこれやってみたのだが、結果は惨敗。VBScriptを使う限りはどうにもならないようだ。

お昼には家に帰ると言って出てきたので、残念ながら今日は途中で切り上げ。Setup作成機能のカスタム動作ではVBScript以外にもexeやdllを起動させることができるから、今度はそっちで試してみよう。

深夜販売

一気に寒くなって朝から冷え冷え。冬の天気だなぁこれは。

まだ体調が完全には回復していないので、この冷え込みはちょっとキビシイ。机の下に入れてあるセラミックヒーターで暖を取りながら仕事する。

天井にエアコンが付いていると上半身は温まるけど、事務机の下には暖気が届かなくて冷えるんだよねぇ。なにか根本的な改善が必要な気がするぞ。

会社が床暖房になれば解決する問題なのだが、さすがに無理か。USBあったかスリッパが売れるわけだ（笑）。

昨日大学へ行って収集してきたデータを元に日中はプログラムの手直し。無線モジュールの設定を変えて状況はだいぶ改善されたけど、ワーストケースを考慮して最悪の場合でもパフォーマンスが落ちないように工夫する。

こういう時って無駄に思えるようなコードでもとにかく実装してみると、その過程でバッサリ簡略化できる方法を思いついたりするんだけど、これを頭の中で考えるだけだとダメ。

どっちも自分の頭の中から出ているモノなのに、手を動かしてコードを書かないと絶対に糸口が見つからない。手を動かす事で脳の中が最適化されるんだろうか。

SFに思考制御ってネタが良く出てきて、現実にも研究が進んでるみたいだけど、頭で考えるだけで文章を作成できる時代になったとしても、プログラマーは相変わらずキーボードを叩き続けてるんじゃないかなぁ（笑）。

今日は一日中気温が低くて、夕方になって日が沈むと更に冷え込んできた。

帰りに幡ヶ谷のライフへ買い物に行くと、明日がボージョレヌーヴォーの解禁日で深夜0時に販売を開始するという告知があったけど、この寒いのに深夜にお店まで行ってボージョレ買ってくる気力は無かった。

この季節はやっぱりワインより熱燗だよねぇ（笑）。

千葉半立

先日納品したシステムの改修作業で、午後から某大学へ。

開発期間がかなり厳しくて、納品後に改修作業が発生することは予想の範囲内ではあったんだけど、端末台数が一定数を超えると通信エラーのリカバリ処理が連続して全体のパフォーマンスが極端に低下するというのは予想外だった。

会社でテストした時は端末を50台しか並べることができず、その時は問題無かったんだけどねぇ。やっぱり無理しても200台並べてテストすべきだったか。

物理的に不可能ではなかったけど、コンセントが足りなかったのが敗因（笑）。

とりあえずボトルネックが何処にあるのかを調べるためのコードをプログラムに仕込み、実際のシステムで半日ほど走らせてデータを収集してみると、電波強度に関係なく一定の割合で通信エラーが発生する。

どうも同じ2.4GHz帯で干渉する電波源があるようで、装置で使用している無線モジュールには自動リトライ機能があるんだけど、その回数内では回復しない事があるらしい。

試しにリトライ回数を4回から8回に増やしてみたら、通信エラーの発生がピタリと止まった。

2.4GHz帯のスペクトラムアナライザでも持ち込まないと詳しいことは分からないが、恐らく干渉する電波の長さが40msecより長く続く場合があるのだろう。

リトライ回数を増やすとその分パフォーマンスは落ちるけど、通信断が発生するとアプリケーション側でのリカバリ処理に余分に時間がかかるので、通信モジュール側でエラーを吸収するほうが全体的には効率が良くなるはず。

納品前に気付くべきだったなぁ．．．．

まあこの通信モジュール使ったのは今回が初めてなので、まだノウハウが蓄積されてなかったからしょうがない。次回はそのへんを考慮しよう。

片づけて大学の外に出ると、まだ5時台なのにもうすっかり真っ暗。

前に行ったときに見つけて買った千葉八街産の半立落花生が美味しかったので、帰りに2袋買っていく。完熟堆肥有機農法って書いてあったけど、完熟堆肥ってどんな代物なんだろう。

あとからネットで調べてみたら

「素材の有機物がよく分解・発酵した堆肥のこと」

と書いてあった。ってそれじゃ何の参考にもならんなぁ（笑）。

無限ループ

スケジュール的にかなり厳しいモノがあって、休日出勤しまくりだった今回のプロジェクトも昨日でなんとか形になったので、今日はだいぶ気分的に楽になった。

長年この仕事をやってると開発に要する期間は割と正確に予測できるから、厳しくてもどうにかなるとは思っていたけどね。

開発中は予期しないバグで時間を取られる事が多いんだけど、バグがどこで発生するのかは予期できなくても、プロジェクトの規模からそれがどのぐらいの割合で発生するのかについては、経験的に予測できる。

それがまた悔しいぐらいに的中するし（笑）。

たまにはバグ無しで一発で完璧に動作しても良いと思うんだが、そうなったら逆に不安になってしまうだろうなぁ（笑）。

今日は最後の仕上げでプログラムにアイコンを付けたり、デバッグ用に仕込んだルーチンを削除したりといった作業をしていたんだけど、最後にインストーラを作るのでDebugビルドからReleaseビルドに切り替えてコンパイルしたら、プログラムが途中で固まってしまった。

この期に及んで致命的なバグか！！と焦ってしまったが、メッセージ出力を埋め込んでどこで固まってるのかチェックすると、プログラムの一部で無限ループが発生してしまう箇所があった。

while(1)
{
    色々な処理
    if(flag == TRUE)
        break;
}

こんな感じのプログラムで、中でチェックしているフラグは他のスレッドでON/OFFされるから、他のスレッドに制御が渡るようにSleep文を入れておかなければならないのに、それが抜けていたのだ。

Debugビルドの時はこれでも固まらずに動いていたから、抜けに気付かなかった。これ以外にもDebugとReleaseではメモリの初期化とかが違ったりするので、Debugビルドで動いたからって安心してはいけませんな。

修正してちゃんと動くようになったので、それからインストーラを作り始める。

インストーラが出来上がったのが定時の30分前で、今日は定時で帰ろうと固く誓っていたからどうにか間に合ったなぁと思っていたら、明日はマニュアルも一緒に納品するという話が。げげっ、それ聞いてないぞ。

納入期限は11/7だから、マニュアルはそれまでに書けば良いと思っていたのに。

慌ててWordを起動してプログラムの画面キャプチャを貼り付け、説明を書きなぐって30分でマニュアルも完成させた。やればできるもんだなぁ（笑）。

印刷サービス

三連休の最終日もやっぱり休日出勤。

おかげで「連休も今日で終わりかぁ」と虚しい気分にならなくてすむ（笑）。

スケジュールに無理がある仕事でもこうやって休日出勤や残業、家に持ち帰っての作業でなんとか辻褄を合わせてしまうと、そのスケジュールでもOKという事になってしまうからホントはあまりよろしくないのだが、このご時世では仕事があるだけマシという話もあるし。

ああ、納期や予算を気にせずに好きな開発だけやっていて良いのなら、どれだけ幸せなことか（笑）。

でもきっと制約がないとやる気も起こらないんだろうなぁ。

まあそれはともかく。

三連休潰した甲斐あってプログラムのほうはどうにか終わりが見えてきて、残るはデータの印刷のみ。

MFCベースで作っているんだけど、メイン画面はCFormViewから派生してるのでMFCの印刷サービスは利用できない。

なのでCEditから派生した追加Viewに印刷サービス関係の関数をまるごと持ってきて、そこから印刷するようにしたのだが、コンパイルして実行すると実行時エラーが出てしまう。

デバッガで調べるとリソースの読み込みでエラーになっていたので、ぐぐってみるとMFCの印刷サービスを利用するには"afxprint.rc"リソースを追加する必要がある事が分かった。

最初から印刷サービスを組み込んだスケルトンプロジェクトを作り、リソースファイルを比較して同じになるように修正すると、今度はちゃんと印刷できる。

MFC使うと便利だけど、標準で提供されている以外のことをやろうとするととたんにハマるのは困ったもんだなぁ。

これでプログラムはとりあえず完成。納期二日前でどうにか間に合った。

思ったよりは早めに片づいたので、帰りは新宿経由。

ブックファーストの大きな店舗が西新宿のモード学園コクーンタワーの中にOpenするんだけど、残念ながらOpenは明日なので新宿ルミネ２の中にあるブックファーストに寄り、ようやく「さくらの境(4)」を購入。最後の一冊だった。

まさか「とらのあな」にすら無いとは思わなかったよ。

返金

午前中は子供の合気道の送り迎えと、部屋の掃除機がけ。

そしてお昼からまた休日出勤。世間一般では今日から三連休だけど、ついに11月に突入して来週の5日には納品だから、もはや猶予がない。

プログラムの中核部分はほぼ完成して、あと残ってる大きな処理は画面表示のみ。

画面表示は客先に見せると必ず変更を喰らうから、最初からそれを見越して凝ったのは作らないつもりなんだけど、どう変更されても良いような構造にするとそれはそれで手間がかかる。

そこが完成すれば残りは印刷やデータのファイル保存と言った補助的な機能だから、2日ぐらいあればどうにかなる分量なのだが、切羽詰まってる時に限って予期しないバグが出ることはほぼ確実（笑）。

なので最低でも納品前に1日は予備日を取っておきたい。

そうなると三連休が潰れることはほぼ確実だけど、まあしかたがないか。もともとスケジュール的に無理がありまくりの仕事だから、そのへんは折り込み済み。

終わったら一週間ぐらい休んでやる（笑）。

とか考えながら会社でひとり黙々とコーディングして、一段落ついたところで先日自宅の留守電に入っていたメッセージを思い出した。

ちょっと前にPASMOのバス運賃二重引き落としが発覚して話題になったけど、どうやら自分がそれに該当していたらしく、コールセンターまで連絡して欲しいという内容だったので、一息入れるついでに電話してみた。

7月にバスに乗ったときに100円多く引き落とされていたようで、係の人から馬鹿丁寧にお詫びを述べられたあと、現金書留で返金しますと言われた。

それだったらPASMOに100円分チャージしてくれたほうが良いのに、少額のチャージはできないような仕様になっているんだろうか？バス料金の引き落としはオンラインじゃなくて、バスが車庫に入ってから一日分のデータをサーバに送るような仕組みになっていたはずだから、その時に100円分を調整するのも不可能ではないと思うんだが。

まあその為にシステムを調整する費用を考えると、現金書留で送ったほうが安上がりという事なのかも。

PASMOのシステムはどこが組んだのかは知らないけど、デバッグ用にそのへんの調整ができる裏コマンドが仕込んである気がするなぁ。でもそれって存在しない事になっている機能だから、使うわけにはいかないか（笑）。

例外処理

そして今日も休日出勤。今月はこれで5回目だ。

作成中のプログラムはデバイスとの通信部分がほぼ完成したんだけど、画面関係がまだなのでこれからそっちを作らなくてはいけない。

制御系のアプリケーションを作っているといつも感じることなのだが、デバイス制御部分が出来上がってPCから完全にコントロールできる所まで作り込みが進むと、もう95%ぐらいは仕事が終わったような気分になってしまう。

でも実際には残り5%に同じくらいの時間がかかったりする（笑）。

デバイス制御って面倒は面倒なんだけど、データシート通りの動きしかしないからうまく動かない場合は99%こっちが何か間違えていて、ちゃんと動くようになれば鉄壁に動作する。

でも相手が人間の場合はそうはいかない。人間にはデータシートが無いし（笑）。

いくらなんでもこんなアホな操作はしないだろう。と思うようなことでも必ずそれをやってしまう奴がいる。それはもう太陽が東の空から昇ってくるのと同じくらい確実（笑）。

DOSプログラムの時代だったらコンソールから行える操作は限られているから、可能性を潰すのはそれほど難しくなかったのだが、Windowsアプリになるとユーザが行える操作が膨大に増えてしまう。

そうなるとその組み合わせで発生する例外的な事象にも何らかの対応を行う必要が出てくるわけで、そこに時間と手間がかかってしまうのだ。しかもそれって例外処理だから、普通は表面に出てこない。完全に裏方仕事。

ユーザが絶対に操作ミスを行わずに、マニュアル通りの使い方しかしないんだったら、プログラムサイズは恐らく半分以下になるはずだ（笑）。

以前から思ってるけどOSってのはそのへんをなんとかしてくれるべきモノであって、ユーザの利便性はその次に来るのが正しい思うんだけどな。その意味では現行のOSはどれもこれもみんなダメOSだ。

それが可能になるにはHAL9000ぐらいのシステムが必要になると思うけど、それはそれでまた困った事が起きそうだしなぁ（笑）。

ハンダ付けハイ

昨日休日出勤した甲斐があって、仕事のプログラムはだいぶ形になってきたけど、スケジュール的にはまだまだ厳しいものがある。

なので今日はちょっと早めに家を出たのに、バスがなかなか来なくて結局いつもとあまり変わらない出勤時間になってしまった。むぅ。

しかも今日は朝から一気に冷え込んで、フリースを一枚羽織って出てきたんだけど、小雨の降る中バス停で長いこと待っているのはかなり辛かった。そのせいか会社に着いてから妙に寒気がして、ちょっと危険な感じに。

おまけに先週治療を受けた歯茎が痛み始めるし。

歯医者で痛み止めは出してもらったんだけど、昨日までは平気だったので持ってこなかった。

そんなわけでコンディションはかなり低下。

でも不思議とプログラムに集中している時は体調の悪さもさほど気にならなかったりする。基本的に集中力が少ないので、なけなしの集中力を使ってしまうと他の所に気が回らないのだな、きっと（笑）。

これが更に進むと、いわゆる「プログラマーズ・ハイ」の状態に突入する。もう完全に周囲とは隔絶された世界で、モニタ画面が視界一杯に広がる視野狭窄も発生。そこからもう一歩進むと、今度は自分が今書いているコード行の周辺しか見えなくなってくる（笑）。

飛躍的にプログラミング効率は上がるんだけど、そのあとの反動が大きいのでプログラマー業界では最後の武器とされているのだが、その割には頻繁に使用されていたり（笑）。

今日もその一歩手前まで行ったもんだから、帰ってから異様に眠くなって食後にしばらくソファーの上で寝入ってしまった。おかげで溜まった録画の消化や、ブログの更新もできずじまい。

Arduinoを使った工作でハンダ付けもしようと思っていたのに。

ふと思ったけど、電子工作をやっている時もプログラマーズ・ハイに類した状態になる事はあるんだろうか？ハンダ付けに集中していると、その部分だけが拡大して見えるようになったら、拡大鏡いらずで便利かも（笑）。

Game of Life

秋の夜長はマイコン遊び、って事で最近は夜中にハンダ付けしたりプログラミングしたり色々とやっている。

ちょっと前に組み立てたAtmega644ボードは20MHzの水晶発振器を付けてあるんだけど、買ってきた状態のAVRは内蔵のRC発振で動くようになっているので、クロックスピード1MHzでしか動かない（内蔵RC発振は8MHzで、デフォルトはそれの1/8）。

ヒューズビットを書き換えてクロック源を内蔵RC発振から外部クリスタルに切り替えれば良いんだけど、これが何度やっても緊張する。クロック源の切り替えを何かミスすると、その瞬間にヒューズビットの書き換えを行う事もできなくなって、どうにもならない状態になってしまう可能性があるからだ。

クロック源に関するヒューズビットは内蔵と外部の切り替えだけじゃなくて、外部の場合は水晶発振器なのかそれ以外なのか、水晶発振器の場合は更にフルスイングするのかしないのか、リセット後の待ち時間は何クロックかといった細かい設定項目があるから、AVRを使い始めた頃はここでずいぶん悩んでしまった。

まあでも今までに失敗した事はないし、失敗してもリカバリできる環境はあるんだが、それでもやっぱり緊張してしまう。

無事に20MHzの水晶発振器に切り替わって、UARTも115.2kで通信できるようなったから、シリアル通信のテストプログラムとしてライフゲームを作ってみた。

TeraTermにVT100のエスケープシーケンスを使ってリアルタイムにライフゲームを表示する仕組み。

AVR Libcにはfdevopen()という関数があって、これを使うと標準出力と自前の1文字出力ルーチンを結びつけてくれる。

たとえばシリアルポートに1文字出力するuart_putch(char ch)という関数を作ったとすると、fdevopen(uart_putch, NULL)と指定すれば標準出力がその関数を使って1文字出力を行うようになる。

あとは普通のprintf文なんかを使えばシリアルポートへ出力されるようになるから、非常に便利。

その代わりメモリを大食いするので、容量の少ないAVRではキビシイものがあるんだけど、Atmega644ならフラッシュ64KbyteにSRAM4Kbyteだから割と気軽に使える。

次は何を作ってみようかな。やっぱりお約束でスタートレック？（笑）。

Arduino熱

昨日図書館で借りてきた「時の風に吹かれて」を鞄に入れて、出勤時にバスの中で読んでいたら話の内容に覚えが．．．．デジャビュ？（笑）。

なわけはなくて、以前に読んだ事があるのをすっかり忘れていて、また借りてしまっただけの話。

まあでも半分ぐらいは忘れていたから、ちゃんと楽しめた。記憶力がアレなのもこんな時には役に立つ（笑）。そういえば岡崎二郎さんの「アフター0（ゼロ）」にそんな感じの話があったな。あれは良かった。

「宇宙家族ノベヤマ」の2巻はいつ出るんだろう．．．．

まあそれはともかく。

このブログの1日あたりのアクセス数はだいたい280～380ぐらいで安定して、土日と平日で100ぐらいアクセス数が違う。平日の方が多いので職場からアクセスする人が圧倒的に多い訳だ（笑）。

ところが今日は夜にアクセス解析ページを見てみると、いつもより妙にアクセス数が多い。

いしかわきょーすけさんの日記からリンクされたのが原因で、それだけで通常アクセスの15%増しなんだからやっぱり凄い。いしかわさんの趣味のマイコン業界に与える影響の大きさがそこからもうかがえる。

そんないしかわさんがArduinoに手を出したようなので、これは嫌でも期待せざるを得ない。

とか言いつつ自分自身のArduino熱はちょっと醒めつつあったり．．．．（笑）。

何か目的があってArduinoを使ってみた訳じゃないからねぇ。最近またちまちまとAVRで遊んでるけど、そっちはAVR-GCCでやってるし。やっぱりこっちのほうが手に馴染む。

でもそのうちまたArduinoに戻るような気はしている。AVR-GCCで制御したデバイスを、Arduinoでも使えるようにするのは面白そうな気がするからだ。ゼロから試行錯誤するときはGCCでガリガリ組んで、理解できたらArduinoで使えるようにするっていうパターン。

秋月で安く売っていて、先日また買ってきたAtmega644をベースにしたArduino互換ボード「Sanguino」がちょっと気になってるから、次に使うとしたらそれかな。

最適化

一昨日作ったAVRのキャラクタ液晶表示プログラムから、液晶表示部分だけを分離してヘッダファイルを付けて後から再利用できるよう手直ししてみた。

ついでにプログラムメモリの固定文字列を表示できる関数なんかも追加。AVR GCCで普通に文字定数を確保するとSRAMに取られて、貴重なメモリ領域を消費してしまうからこれは必須。

作り直したプログラムをコンパイルしてAVRに転送すると、処理自体は何も変わっていないハズなのに、動作がおかしくなってしまった。表示される文字の位置がズレたり、液晶の初期化が行われなかったりする。ありゃ？

元々のプログラムはコンパイラの最適化オプションをOFFにしていて、今日はコードサイズの最適化を指定した事を思い出し、OFFに戻してみると今度はちゃんと動く。むぅ。

AVR LibcのDelay関数を使っていて、最適化無しだとその関数でWarningが出てしまうから有りに指定したのに、それだとダメってのはどーゆー事？

試しに最適化無しと有りでそれぞれリストを出力して見比べてみようとしたら、最適化無しのリストファイルが妙にでかい事に気が付いた。最適化有りの10倍ぐらいある。

中を見てみると一目瞭然、_delay_us関数の引数がdouble型になっていて、浮動小数点演算ルーチンがリストの最後にくっついていた。_delay_usや_delay_msの引数は定数にしないと浮動小数点演算になるってのはどこかで読んだから、ちゃんと定数にしてあったのだが、最適化無しだとダメらしい。

なるほど、Warningが出るのはそれでか。

液晶が正常に表示されなくなる理由も、ちょっと考えたら分かった。手抜きして液晶のBusyフラグをチェックせずに、一定時間待ってから次のデータを送るようにしていたんだけど、その待ち時間が足りなかったらしい。

最適化無しでコンパイルするとDelay関数が浮動小数点演算になって、指定したよりも長く時間がかかってしまうので、それでも動いたわけだ。

最適化有りの時は正しい待ち時間になるから、液晶がまだBusy状態の時に次のデータが送り込まれる事になって、正しく表示されなかったのか。

だとしたら解決策は簡単で、液晶モジュールにコマンドやデータを送る関数の最後に、ちょっと長めのDelayループを付け加えてやったら一発で直った。最適化レベルを変えても今度は問題無し。

やっぱり手抜きせずにちゃんとBusyフラグはチェックすべきだったか。W/Rの信号線はGNDにつないであるから、それをポートの空きにつなぎ変えてBusyフラグをチェックするバージョンも作ってみよう。

SC1602BS

昨日秋葉原でグルーガン（ホットボンド）を買ってきたので、共立エレショップのATmega168汎用基板キット用に作ったブレッドケーブルをこれで補強。一緒に買ってきたちょっと大きめのブレッドボードに差し替える。

前のブレッドボードだとUSBシリアルモジュールを乗せると空きスペースがほとんど無くなって、ブレッドボードを使う意味が無くなってしまうけど、これなら大丈夫。

秋月で14ピンの短いフラットケーブルが売られていて、これが16文字x2行の液晶キャラクタ表示器「SC1602BS」に丁度良かったので買ってきたから、それもつないでみた。

こんな状態（笑）。

この液晶表示器はマイコン工作で良く使われている奴で、AVRでの使用例も多いんだけど、あえてデータシートだけを見てプログラムを作ってみた。

データ転送は4bitモードを使って、Busyフラグは見ない事にしたから必要な線は6本だけ。初期化でちょっと躓いたけど、これはAVRのピン番号を間違えたからで、液晶の制御自体は非常に簡単にできた。

液晶に文字列を表示させるのも、アドレスが1行目と2行目で連続してない事だけを注意すれば思ったよりも簡単だったが、固定文字列を表示させるだけではあまり面白くない。

パーツ箱にボリューム（可変抵抗器）があったので、それをAtmega168のA/Dコンバータにつなぎ、読み取った値を液晶表示器に表示させるようにしてみた。

AVRのA/Dコンバータは使い方が簡単で、基準電圧を何にするのかと、変換を自動でやるかどうかを設定したら、あとは変換完了のフラグが立つまで待っていれば良い。

ちゃんとボリュームの位置によって0～1023（10bit）の値が液晶に表示されて、そう動くように作ったんだから当たり前なんだけど、入力から出力まで完全に自分の作ったプログラムで動くのはやっぱり楽しい。

SC1602BSはかなり前に秋月で買ってきて、パーツ箱で死蔵してたんだけどこれでやっと使う事ができた。

まだグラフィック液晶が転がってるので、次はそれだな。一昨日距離センサも買ってきちゃったし、秋の夜長はそれで費やす事になりそうだ（笑）。

Atmega644P

秋月で以前に買ったAVRマイコンチップAtmega644Pが手つかずのまま放置されていて、何かに使おうとは思うんだけど何に使ったら良いのかさっぱり思いつかない。

このままだとまたパーツ箱の肥やしになってしまう運命なので、とりあえずこれを使った汎用のマイコンボードを考えてみた。基板を起こすつもりは無いんだけど、回路図から簡単にパターンも引いてみる。

基板作らないのにパターン引くのはムダと言われそうだが、ユニバーサル基板で半田付けして作るときの目安になるし、パターン引く事自体が楽しいから良いのだ（笑）。

このパターンを元に半田付けして作成。所要時間約30分。

LEDの位置が違ったり増えてたりしてるけど、細かい事は気にしない（笑）。

ISPピンの位置をICソケットから1ランドしか離さなかったので、ISPコネクタの出っ張りが邪魔して差し込めないという予想外の問題が。やっぱり実際に作ってみないと分からないもんだなぁ。

しかたがないのでISPのピンは微妙に外側に曲げた（笑）。基板パターンはそれを反映してICソケット位置を少しずらしてある。

それ以外には特に問題無く、AVR-GCCでコンパイルしたLEDチカチカのテストプログラムもちゃんと動作した。LEDを2個に増やしたのは、チカチカが1個だとなんか寂しいからという理由（笑）。

秋月のUSBシリアル変換モジュールFT232RLをシリアルインタフェースとUSBからの電源供給に使っているので、この手の基板を作るときは半田付け箇所が少なくて済む。これが232Cレベル変換ICだったら、半田付けの手間が増えるし電源回路も別に必要になってしまう。

そのかわりUSB電源なのであんまり出力は取れないけどね。まあマイコンのテスト用途ならこれで十分。

Atmega644Pは64KByteのフラッシュと、4KByteのSRAM、豊富なI/Oを持ったワンチップマイコンで、このぐらいメモリがあればC言語での開発も余裕。

LEDチカチカをタイマ割り込みにしたり、PWMに変えたりして遊んでいたら、色々とアイデアが湧いてきた。チップだけ眺めていた時には何も思いつかなかったのに、やっぱり動くモノが目の前にあると違うな。

でもプログラマは現物が目の前に無くても作れないとダメなんだけどね（笑）。

怪奇現象

VisualStudio 2005でのデバッグ中に、特定のソースファイルだけデバッガのブレークポイントが効かなくなる現象が発生。

バイナリとソースファイルが食い違っているのでデバッグできないと言われるのだが、そのソースファイルからビルドしてるんだから食い違ってるハズがない。ソースのパスを確認しても間違いなし。

検索すると

visual studio 2005 が不具合を起こした : vb.net, プロジェクト家計簿

のように全く同じ症状に遭遇している人が何人もいた。

「元のバージョンと完全に一致するソースファイルを必要とする」のオプションを外してしまえば、この症状が出てもブレークポイントが効くようになるのだが、本当にソースが食い違っている時にもチェックされなくなるので危険が大きい。

実はこの現象が発生する前に、当該するソースファイルを読み込んだときに「改行コードが一致していません」という警告が出て、一致させるように指定したんだけど、後から考えてみるとどうもそれが怪しい気がする。

試しにファイル保存時の改行設定をCR+LFからLFに変えて保存してみると、なんとそれだけでこの現象が消えてしまうではないか。でも改行コードを戻すとまた発生する。なんだこりゃ。

更に文字コードをシフトJISから他の文字コードに変えた場合も、現象が発生しなくなる事が分かった。

どうもこれってVisualStudio 2005のエディタのバグな気がする。おそらく何らかの区切り（内部バッファ容量？）位置に特定の漢字コード＋改行コードが来た場合だけ、そのバグに引っかかるのではないだろうか？

対処法は分かったから次に同じ現象が出ても大丈夫だけど、なんとなく気持ち悪い。VisualStudio 2008では直ってるのかなぁ？

2.4GHz無線モジュール

Interface誌のColdFire付録基板は、以前に会社で開発した基板の残りパーツで動かせそうなんだけど、次の仕事で使う予定の2.4GHz帯無線モジュールのスターターキットが届いてしまったので、遊んでいる暇が無くなった。

モノはNECのTY24FM-E2024。2.4GHz帯の無線モジュールと言えば最近はZigBee規格が有名で、このモジュールにもZigBeeスタックが乗っているバージョンがあるけど、他社の製品と通信する必要が全く無いから今回は独自プロトコルの乗っているモジュールを使うことになった。

スターターキットを開けると切手大の無線モジュールがコロンと出てきて、このサイズでアンテナまで乗って、インテリジェントな無線通信ができるというのは改めて驚いてしまう。

このモジュール単体ではPCに接続できないから、RS232Cへのレベル変換基板もスターターキットには一緒に入ってくるんだけど、電源が何故か乾電池（笑）。省電力がウリのモジュールだから、それをアピールしようという事なんだろうか。

うっかり電池ボックスのスイッチ切り忘れて、翌朝焦るという未来が今から目に浮かぶ（笑）。

とりあえずスターターキットを2台組み立てて、1対1での通信をさせてみた。

まだざっとしか使ってないんだけど、モジュールのAPIは非常に簡潔で組込用としては使い易いと感じた。この手のモジュールってインテリジェント具合が肝要で、低レベル過ぎると使い難いのは当然なんだけど、インテリジェント過ぎても実は使い難かったりする。

細かい事はモジュール側で全部やってくれて、でもこちらの要求には柔軟に対応できるような作りってのは結構難しいのだ。

このモジュールはそのへんのバランスがうまく取れてると思う。ZigBeeを必要としない組み込み無線用途には結構良いんじゃないかな。値段もかなり安いから、秋葉原で個人が簡単に買えるようになると、色々と面白い使い方が出てくるかも。

今のところはまだ応用事例が少なくて、メーカーから出ている資料だけだと悩んでしまう部分もあったりするから、早く広まって参考資料が増えてくれないかというのが正直なところ（笑）。

でも広まる頃には開発終わってるんだよなぁ。

再会

毎年この時期になると固定資産税と都市計画税の支払いでちょっと憂鬱になってしまう。分割して払えば一回の金額はそれほどじゃないけど、一年間心の片隅に税金の支払いが引っかかっているのも嫌なので一括で払うようにしているのだが、今ならハイビジョン大型液晶テレビが買える金額が一気に消えて無くなると、やっぱりブルーな気分になる。

税金の支払いはネットからでも行えるけど、ネット振込金額の上限設定を変える必要があるし、昼休みはなるべく歩く事にしているから、高円寺駅前の銀行まで払いに行く事にした。

店員に税金支払いの窓口を教えてもらって、そこへ向かうとなにやら見覚えのある装置が．．．

ってこれうちの会社で作った奴じゃん（笑）。

ハード設計は他の人がやったけど、内蔵されているマイコンのファームは自分が担当した奴だ。EEPROMの空き容量が少なくてデータが入りきれず、圧縮ロジックを組み込んだりして結構苦労したから、その分愛着があったりする。

組み込み系の開発は実際にそれが稼働している所を目にする事はあんまり無くて、某所の風力発電装置の表示板みたいに展示目的の装置は例外だけど、工場で使われるような装置は納品してしまったらそれっきり。

それがこんな近所で再会したもんだから、ちょっと驚いてしまった。立派に働いているようで何より。お父さんは嬉しいぞ（笑）。

このページは xfy Blog Editor を利用して作成されました。

非標準GUI

受託開発の仕事を長い事やっていて、相手にした客先は数え切れないほどなんだけど、開発に当たってきちっとした仕様書を出してくる所はホントに少ない。

仕様書が出てきても理解するのに苦労するような代物が多くて、冗談でなくプログラマーに必要な最大の資質は、てきとーな仕様から客先の意図を推察して正しい仕様に変換する能力ではないかと思う。

要求仕様と設計仕様の区別がついてない客先も多いしねぇ。まあそれも含めて仕事だと言われればそうなんだけど、何を要求しているのかという根本的なレベルですらあやふやな場合も多いので、その時は聞き取り調査から始めないといけない。

最近はそこまで酷いのは少なくなってきたけど、ある程度慣れてくると今度は妙に独創的な仕様を出してくる傾向があって、それはそれで困ったモノだったりする。

先日客先から出てきた仕様書に、どう考えてもWindowsの標準的なGUIから大きく外れるような画面仕様が記載されていて、思わず頭を抱えてしまった。

そりゃまあどんなGUIでも自力で作れば実現可能なんだけど、その仕様は独創的すぎてどう考えても使いやすいとは思えない。でもそこで「できません」と言うのも悔しいから、半日ぐらいかけて無理矢理実装してしまった（笑）。

ここで意地になる所がまだ修行が足りないよなぁ。

CDialog に CScrollView の派生クラスを貼るのがうまく行かなくて悩んでしまったが、いろいろと試してみて CFrameWnd を作ってその中でビューを生成させればうまく行く事が分かった。 CFrameWnd が生成したビューは CFrameWnd->GetTopWindow() で取得すれば良い。

でもドキュメントが無いのにビューだけ存在している状態はなんか気持ち悪くて、無理矢理実現したGUIもやっぱり使い勝手が悪い。なので客先に「工数が5倍ぐらいかかります」とメールしたらあっさり折れた（笑）。

試作したプログラムは出番が無くなったが、これはこれでうまく使うと面白い事ができそうなので、何かの時に応用してみよう。

このページは xfy Blog Editor を利用して作成されました。

High-performance

このところWindowsアプリばっかり作っていたけど、次の仕事は久しぶりにマイコンを使った組み込み系の開発。

使うのは例によってルネサスのH8で、個人的に使ってるAVRは相変わらず仕事では使う機会が訪れない。以前にちょっと使えそうな話があったんだけど、値段の関係でダメだった。ルネサス強し。

開発用PCに入っているH8の開発環境はかなり古いモノだったので、ルネサスのサイトから最新の開発パッケージをダウンロードしてきた。

統合開発環境はHEWという名称で、以前は「Hitach Embedded Workshop」の頭文字だったんだけど、三菱の半導体部門と統合して日立の名前は無くなっているから、今は「High-performance Embedded Workshop」の頭文字という事になっている。それだったら名称はHPEWなのでは？

ってどー発音するんだ（笑）。

古いバージョンはエディタが使いにくくて、ホイールのスクロールに対応してなかったり色々と不満があったので外部エディタを使っていたけど、さすがに新しいのは対応してるし、色々と便利な機能も付いているようだ。

特にスタック解析ツールのCall Walkerは、Windowsアプリと違ってメモリ制限の多いマイコン開発では役に立ちそう。でもそのツールに頼るような状況ってかなりドツボに填った時だろうから、なるべくなら使う機会が訪れない事を祈りたい（笑）。

このページは xfy Blog Editor を利用して作成されました。

EZL-80C

ちょっと前から特殊用途の印刷プログラムを開発してるんだけど、印刷まわりは今まで開発してきたプログラムではあまりメインではなく、適当にお茶を濁してきたので経験値が明らかに不足している。

おまけに今回はフォントを拡大したり回転したりといった処理も組み込む必要があって、そっちもあんまり得意じゃないから二重に苦難。

なので小さいテストプログラムをいくつも書いて、検証しながら設計していたりする。泥縄ってゆーな（笑）。

そのへんの作業も割と楽しいんだけど、ネットで調べながらやってるとつい横道に逸れてしまいがち。Googleが無かったら調べるのも一苦労というか、もはや無い状態が想像できないくらい依存してしまっているけど、検索結果からあさっての方向へ行ってしまう事が多々ある。

Googleは諸刃の剣だな（笑）。

何を調べていたのかは忘れてしまったが、今日はいしかわさんの陰気な男でいいですか？でアルファプロジェクトのEZL-80Cを知って、そこから違う方向へ転がってしまい、仕事に戻ってくるまでにだいぶ時間がかかってしまった（笑）。

仕事で良く使うXPortには無線版のWiPortが存在するけど、値段的にはこっちのほうが安いから、無線で何か作る時には考慮してみよう。

同じパターンでUSB無線LANアダプタを挿して使えるシリアル－無線LANコンバータってのがあっても良さそうな気がするんだけど、寡聞にしてまだ見た事がない。CFに比べてUSBは制御が面倒になるから、理由は分かるけどね。

でも最近はUSBホストチップも色々と出ているみたいだし、知らないだけでどこかに存在してそうな気はするな。

調べ始めるとますます仕事に復帰できなくなるから、今はやらないよ（笑）。

このページは xfy Blog Editor を利用して作成されました。

Dropbox

Gmailのアカウントに「Dropbox Private Beta Invitation」というメールが届いていて、一瞬spamかと思ってしまったけど、以前に登録したオンラインストレージサービス「Dropbox」のプライベートベータ開始の通知だった。

登録したのは1年近く前だから、もうすっかり忘却の彼方だったよ（笑）。

先週マイクロソフトのオンラインストレージ「DkyDrive」を試してみて、OSのファイルシステムと統合されていればもっと使いやすいのにと思ったんだけど、Dropboxはまさにその思った通りのサービス。なんてジャストなタイミングだ。

オンラインストレージをWebDAV経由でドライブとして使うのは以前からやっていて、Dropboxもそれと同じような感じなんだろうと最初は思っていたのだが、専用クライアントをインストールして使ってみるとそれよりも遙かに進歩していた。

プログラマーを長年やってると性格がヒネてくるから（笑）他人が構築したシステムを素直に誉めるなんて事は滅多にやらないのだが、このサービスはちょっと凄い。諸手をあげて絶賛してしまおう。

専用クライアントをインストールして認証を行うと以降はタスクバーに常駐して、My Documentsの下にMy Dropboxというフォルダができる。このフォルダに対してファイルをコピーするとオンラインストレージに転送されるんだけど、ローカルに保存されてからバックグラウンドで同期が行われるため、普通のフォルダと全く同じに扱う事ができる。

つまりオンラインストレージの存在を全く意識せずに、単にフォルダに対してファイルをコピーしたり更新したり、削除したりできるわけだ。しかもファイル操作はローカルに対してだからタイムラグが無い。

この使い勝手だけでも十分に評価できるんだけど、凄いのはそれだけでは無い。

別のPCに同じようにクライアントをインストールして認証を行うと、そのPCのMy Dropboxとオンラインストレージが自動的に同期されるのだ。会社のPCでMy Dropboxにファイルをコピーしておき、帰宅してから自宅のPCを立ち上げるとその変更が自動的に反映される。

もちろん逆に自宅のPCでMy Dropbox内のファイルを更新しておけば、翌日出社した時にはその変更がちゃんと反映されている。

ネットワークを経由するので即座に反映されるわけでは無いけど、出社してPCを起動してブラウザ立ち上げたりメールチェックを行ったりしている間にバックグラウンドで同期を取ってくれるから、さほど問題にはならない。

それよりも複数のPCで時間と場所を超越した共有フォルダが使える事のほうが、遙かにメリットが大きいだろう。

たとえば会社でExcelを使っていて、作業途中でそのファイルをMy Dropboxに保存しておけば、自宅PCのMy Dropboxにもそのファイルが自動的に出現するのだ。そのファイルを直接開けば会社で行っていた作業の続きが即座にできてしまう。USBメモリを使ってのファイルの持ち運びなんか、この便利さを体験したら馬鹿らしくてやっていられない（笑）。

My Dropbox内のフォルダやファイルには同期中・同期済みを示すマークが付くのも分かりやすい。フォルダを開いて見ているとバックグラウンドで徐々に同期が行われていく様子が分かる。

これだけでも恐ろしく便利なサービスなんだけど、更に便利な事にDropboxにはリビジョン管理機能があって、ファイルの更新時に自動的に履歴が取られるのだ。これはもうプログラマにとっては泣くほど便利。

会社のPCにはリビジョン管理ツールをインストールしてあるけど、会社と自宅をまたがって古いバージョンを取得したりはできないしね。会社で更新したファイルが自宅に反映されるのみならず、更新前の古いバージョンまで取得できるなんて夢のような話だ（笑）。

しかもMy Dropbox内には他のDropboxユーザ間でファイルを共有する共有フォルダも作成できる。以前にサイズの大きなファイルをメールに添付して送ろうとしたら、メールサーバに拒否されてしまったけど、そんな場合にもこれは便利に使えそうだ。

客先がDropboxを使ってないと意味がないけどね（笑）。

これはマジにOSに統合されるべき機能だと思うな。Windows Vistaの次期バージョンの話も最近ちらほらと目にするけど、それに標準で搭載して欲しい。有料でも使いたい人は多いはず。

このページは xfy Blog Editor を利用して作成されました。

ISP実験

フィジカルコンピューティング用のボード「Arduino」はATmegaのブートローダと自己書き換え機能を使って、専用のライタを使わずにシリアルポートからプログラムを転送する事ができるのだが、公開されている回路図とファームを使って自作する場合は、どうしてもファームを書き込む時にライタが必要になる。

以前に共立エレショップのATmega168基板に秋月のFT232RLモジュールをくっつけてArduinoとして動かしてみたんだけど、FT232RLモジュールにはRS232Cの制御線を4ビットのデジタルI/Oとして使う事ができる。

AVRのISP書き込みに必要なのはMISO/MOSI/CLK/RESETの4本の信号線だから、これを使ってAVRにISP書き込みが行えるのではないだろうか？と考えた。それが可能ならライタが無くてもArduinoを作る事が可能になる。

RS232Cの信号線を使うCOMポート接続のAVRライタと考え方は同じで、車輪の再発明という気もするけど、まあそこはそれ。誰かが作ったのをそのまま使うのと、ゼロから自分で作ってみるのとでは経験値の上がり方が違うと思うし。

ということでまずはFT232RLモジュールの制御線設定を変更。FTDIのサイトからMProg 3.0aをダウンロードしてインストールし、FT232RLモジュールを接続してTool->Read and Phaseで現在の設定値を読み込む。I/O ControlsのCB0～CB3をI/O Modeに変更して保存し、Device->Programで書き込めばOK。

I/OとATmega168のピンは以下のように接続

CB0 → MOSI(17)
CB1 → MISO(18)
CB2 → CLK(19)
CB3 → RESET(1)

FT232RLモジュールのGNDとVccもATmega168のGNDとVccに接続する。ISP書き込みにUSBの電源を使うのはあまりお薦めできないし、ショートした時にPCが死ぬ可能性もあるからよゐこは真似しないこと（笑）。

ついでにMOSI端子にLEDもぶら下げておく。新品のATmega168は内蔵RC発振に設定されているから、これだけでISP動作できるはずだ。

さて、これであとはFT232RLのI/OをFT_SetBitModeを使ってON/OFFし、ISP書き込みコマンドをAVRに送出してやれば良い。ちなみにこのAPIを使うためにはVirtual COM Portドライバではなく、D2XXドライバがインストールされている必要がある。

VisualStudio 2005でテスト用のプログラムをさくっと作って、とりあえずデバイスIDの読み出しを行ってみた。

SEND : AC 53 00 00　　ISPモードに移行
RECV : AC D3 53 00　　応答
SEND : 30 FF 00 FF　　指標バイト00読み出し
RECV : 00 30 FF 1E　　応答
SEND : 30 FF 01 FF　　指標バイト01読み出し
RECV : FF 30 FF 94　　応答
SEND : 30 FF 02 FF　　指標バイト02読み出し
RECV : FF 30 FF 06　　応答

デバイスIDは応答の太字部分で、並べると1E 94 06となり、ATmega168のデータシートに書かれているデバイスIDと一致している。

ちゃんとデバイスと通信できているという事なので、あとはフラッシュメモリの消去とプログラムの転送、ロックビットの書き換えなんかをISPの手順に従って送信してやれば、Arduinoのファームウェアを真っさらなAVRに書き込むことができるはず。

とりあえず今日はここまで。可能なことが分かってしまうとモチベーションが一気に下がるので、続きをやるかどうかはまだ未定（笑）。

このページは xfy Blog Editor を利用して作成されました。

DirectShowへの道【圧縮編】その２

USBカメラを使ってキャプチャした動画を、圧縮してファイルに保存するクラスを先週作ったので、そのクラスを使用したアプリケーションを納品前にテスト用のPCにインストールして試してみたところ、実行時にエラーになってしまった。

最初はDirectShowのランタイムや.NET Frameworkの最新版が入っていないからだろうと軽く考えていたのだが、そのへんをインストールして試してみても結果は同じ。おやぁ？

でも開発環境の入っている他のPCでは何の問題も無く動いてしまう。

デバッグする為にはテスト用のPCにも開発環境を入れる必要があるが、そうすると動くようになってしまう可能性が高い。でもそれでは何の解決にもならないし、動作環境としてVisualStudio 2005のインストールが必須なんて言ったら殴られる（笑）。

そこでアプリケーションがフィルタグラフを構築した時に、その情報をファイルに出力する関数をアプリケーションに追加してみた。

HRESULT CCapture::SaveGraphFile(IGraphBuilder *pGraph, WCHAR *wszPath)
{
    const WCHAR wszStreamName[] = L"ActiveMovieGraph";
    HRESULT hr;

    IStorage *pStorage = NULL;
    hr = StgCreateDocfile(
        wszPath,
        STGM_CREATE | STGM_TRANSACTED | STGM_READWRITE | STGM_SHARE_EXCLUSIVE,
        0, &pStorage);
    if(FAILED(hr))
    {
        return hr;
    }

    IStream *pStream;
    hr = pStorage->CreateStream(
        wszStreamName,
        STGM_WRITE | STGM_CREATE | STGM_SHARE_EXCLUSIVE,
        0, 0, &pStream);
    if (FAILED(hr))
    {
        pStorage->Release();    
        return hr;
    }

    IPersistStream *pPersist = NULL;
    pGraph->QueryInterface(IID_IPersistStream, reinterpret_cast<void**>(&pPersist));
    hr = pPersist->Save(pStream, TRUE);
    pStream->Release();
    pPersist->Release();
    if (SUCCEEDED(hr))
    {
        hr = pStorage->Commit(STGC_DEFAULT);
    }
    pStorage->Release();
    return hr;
}

これでGraphEditorで読み込める形式のフィルタグラフ定義ファイルができあがる。

これをエラーの発生するPC上のGraphEditorで読み込ませてみると、フィルタがつながらない状態でバラバラのままで読み込まれてしまった。開発環境の入っているPCではつながるはずのフィルタが、そうでないPCではやはりちゃんとつながってくれない。

バラバラに読み込まれたフィルタを改めて手動でつないでやると、ちょっと意外な結果に。

ビデオキャプチャデバイスのプレビュー出力からレンダラへつなげようとしたら、その中間に自動的にColor Space Converterフィルタが挿入されたのだ。その状態で最後までフィルタをつないでやると、GraphEditor上ではちゃんとキャプチャして圧縮もできるようになる。

今度はキャプチャクラスでも同じようにColor Space Converterをグラフに追加して、こんなふうに変えてみた。

旧
// プレビューピン接続
hResult = m_pBuilder->RenderStream(&PIN_CATEGORY_PREVIEW,
   &MEDIATYPE_Video, m_pSrc, NULL, m_pVideoRenderer);

新
// プレビューピン接続
hResult = m_pBuilder->RenderStream(&PIN_CATEGORY_PREVIEW,
   &MEDIATYPE_Video, m_pSrc, m_pColour, m_pVideoRenderer);

RenderStreamでフィルタをつなぐときに、以前は中間フィルタを通さずにレンダラへつなげていたのを、Color Space Converterフィルタを通すように変えてみたところ、テスト用のPCでもきちんと動作するようになった。

動くようになったのは良いんだけど、実行時にエラーが発生していたのはキャプチャーピンの接続なのに、プレビューピンの接続側にフィルタを追加すると動くって、どうも納得がいかない。

それ以前に開発環境が入っているPCでは全く問題無かったのに、入ってないPCではフィルタを追加しないとダメってどういう事？

何が悪かったのかは今持って分からずじまい。DirectShow関係はやっぱり鬼門だという事だけはハッキリした（笑）。今は過渡期でちぐはぐになっている感もあるから、あと数年もすれば一本化されてもっと楽に使えるようになってるんだろうけどね。というかそうなってくれないと困る。

更にカオスになっている可能性も否定できませんが（笑）。

このページは xfy Blog Editor を利用して作成されました。

HyperTerminal

Windows Vistaの「び」の字も無かった時分に開発したソフトが、Vistaで誤動作するという連絡が来た。

そんなもん検証も何にもやってないし、当然ながら動作保証もしてないわけなんだが、それでも対応はしなくちゃならないのが辛いところ。プログラムにも品質保証期限を付けさせて欲しいぞ（笑）。

連絡が来たのは昨日なんだけど、検証用のVistaマシンを久しぶりに起動して、ついでにSP1を適用しようとしたらいつまで経っても終わらなかったので、昨日はそのまま放置して帰ってしまった。

VistaのSP1は色々と改良が加わっていて、だいぶ軽くなっていると聞いたけど、ほとんど使って無かったからどこら辺が変わったのか良く分からない（笑）。Extended FATでファイルサイズの最大値が16エクサバイトになったらしいが、だったら素直にNTFSを使えば良いのでは？

まあそれはともかく、Vistaでプログラムを動かした時の挙動を確認するために、まずはシリアルポートからの出力をクロスケーブルで戻して、出力されているコマンド列を見ようとしたんだけど、スタートメニューを開いてもHyperTerminalが見あたらない。

あれっ？と思ってネットで調べてみたら、なんとVistaにはHyperTerminalが含まれていないという衝撃の事実が。えー、それはかなり困るぞ。

開発時はVistaでも問題なく動くTeraTermを使えば済むんだけど、客先に納品した装置で設定をRS-232Cで行うような場合に、シリアルで通信する手段が標準で用意されていないと何もできなくなってしまう。

客先によってはフリーウェアのインストールを禁じている所もあるしね。なによりも納品するドキュメントに「スタートメニュー -> アクセサリ -> 通信にあるハイパーターミナルを起動して下さい」と書けなくなってしまうではないか。なんで削るかなぁ。

ハイパーターミナルについてを読むと、PC間の通信にはリモートシェルまたはTelnetを使えと書かれていて、シリアルデバイスの制御にはインターネットからダウンロード可能なバージョンのハイパーターミナルを取得可能と書かれているけど、それが何処からダウンロードできるのかは一切書かれてないし。むぅ。

相変わらずMicrosoftの考えることは良く分からない。

で、肝心のVistaで誤動作する件は通信データにゴミが混じっていたせいだと判明。でもXPでは大丈夫でVistaではダメな理由が良く分からない、どうもAPIの挙動が微妙に違うっぽい感じなのだが、もうちょっと詳しく調べてみる必要がありそうだ。

なんてことをやっていたおかげで、各サイトのエイプリルフールネタはあんまり楽しめなかったよ（笑）。

このページは xfy Blog Editor を利用して作成されました。

XPortクライアント

シリアルとネットワークの変換器XPortは、デバイスサーバと呼ばれているように通常はサーバとして動作する。

つまりネットワーク上で常に接続されるのを待っていて、クライアントから接続されてから動作を開始するのだが、それとは逆にクライアントモードで動作させる事もできる。

その場合はシリアル側からコマンドを出してサーバに接続に行くんだけど、実際にどのように行うのかについては、仕事で使わなかったので詳しくは調べなかった。

最近暇を見てちょこちょこと遊んでいるArduinoで、植木鉢の水が少なくなるとtwitterにメッセージが飛ぶBotanicalls Twitterという面白いモノを作った人がいて、これにXPortが使われている。

XPortからtwitterのサーバに接続するんだから、クライアントモードで動作している事は間違いないので、ちょっと興味が出てきた。Botanicalls Twitterはソースが丸ごと公開されているから、それを読めばやり方は分かるハズだが、自分で調べないと面白くない。

以前に秋月のUSBシリアル変換モジュールを使って作成した玄箱Pro用のシリアルコンソール用アダプタを引っ張り出して、そこに新たにXPort接続用のコネクタを増設、XPortと接続して通信させてみた。

XPortは3.3V動作で、USBシリアル変換モジュールの出力は5Vだけど、XPort-03R以降は入力端子に5V信号を突っ込んでも大丈夫なのでそのまま直結。古いXPortでこれをやると一発で壊れるようだ。

手元の資料によるとXPortから外部サーバへ接続するには

C192.168.1.1/80

のように先頭にCコマンドを置いて、IPアドレスとポートを指定すれば良いらしい。でも同じようにコマンドを送っても何の反応も無い。

ちょっと悩んでしまったが、何の事はないXPortのモード設定を変えるのを忘れていただけだった（笑）。XPortのDeviceInstallerからWebManagerを起動して、Connection SettingsのActive Connectionを変えないとクライアント接続ができないのだ。

クライアント接続にはシリアル側から任意のデータが送られてきた時と、DTR信号がONになった時、特定のスタートキャラクタが送られてきた時、そして手動接続の四つのモードがある。そのうち手動接続を除く三つは予め設定されているサーバにしか接続できないので、マイコンから制御する時は手動接続モードにしておく必要がある。

この設定を保存して適用したあと、Cコマンドを送ると指定したIPへ接続を行う事ができる。

接続先がWebサーバなら、接続が成功したあとシリアル側からGETコマンドを送れば、指定したアドレスのhtmlファイルがテキストで送り返されてくるので、あとはそれをマイコン側で解釈してやればいい。

気合いと根性さえあれば、マイコンに接続したLCDでWebをブラウズする事も可能になるはず。

twitterにログインしてメッセージをPOSTするためには、そこから認証を行わなければならないので、まだもう少し処理が必要だ。それができるようになると、物理的な事象をtwitterにPOSTすることが可能になるから、色々と面白い使い方ができそうな気がする。

植木鉢に対抗して金魚鉢とかはどうだろうか？（笑）。

このページは xfy Blog Editor を利用して作成されました。

DirectShowへの道【圧縮編】

以前に作成したUSBカメラからキャプチャして動画ファイルに出力するクラスは、手抜きしてまるっきり圧縮をかけていなかったから、長時間動かすと出力ファイルがとんでもない大きさになってしまう。

客先からは何も指示されていなかったので、とりあえずそのまま出してみたら案の定指摘されてしまった（笑）。

現状のクラスはVideo CaptureとVideo Rendererの間に独自フィルタを挟んで右から左に（絵では左から右になってるけど）ストリームを流すだけの単純な構造になっている。

このストリームの途中に圧縮フィルタを挟み込めば、何も考えずに圧縮を行ってくれるはずなので、GrephEditツールを使ってとりあえずフィルタを並べてみた。このツールは必要な中間フィルタを自動的に挿入してくれるから、同じようにプログラムで接続すれば動くようになるはず。

GraphEditでフィルタを接続すると、独自フィルタと圧縮フィルタの間にColor Space Converteが挿入された。

独自フィルタの出力ピンはMEDIASUBTYPE_RGB32で作成したから、圧縮フィルタの入力ピンと接続するためには色変換が必要になるらしい。

これをプログラムで行うには、ICaptureGraphBuilder2インタフェースのRenderStreamメソッドを使って順番に並べてやればいい。RenderStreamで接続できるのは先頭と中間と終端の3つのフィルタのみだけど、終端フィルタを先頭にして再度RenderStreamを呼び出せばチェインさせることができる。

で、最初に作ったのがこれ

hResult = m_pBuilder->RenderStream(&PIN_CATEGORY_CAPTURE,
    &MEDIATYPE_Video, m_pSrc, m_pMyFilter, m_pColour);
if(FAILED(hResult))
    throw ERR_RENDER;
hResult = m_pBuilder->RenderStream(NULL,
    &MEDIATYPE_Video, m_pColour, m_pCompressor, m_pRenderer);
if(FAILED(hResult))
    throw ERR_RENDER;

これでGraphEditと同じように接続されるはずなのだが、実行すると何故か二番目のRenderStreamでエラーになってしまう。

この順番でも唯一Microsoft RLE圧縮フィルタだけは接続できるんだけど、出力された動画を見ると色数が極端に落ちて、もの凄く汚い。これで納品したら客先から文句が来るのは確実（笑）。

フィルタの順番を入れ替えたり、中間フィルタを更に増やしたりと試行錯誤して、ようやくエラーのでない接続が分かった。

Color Space Converteと独自フィルタの順番を入れ替えると、なんの問題もなく接続できる。GraphEditで自動接続させた時と順番が違うのは何故なんだろう？

hResult = m_pBuilder->RenderStream(&PIN_CATEGORY_CAPTURE,
    &MEDIATYPE_Video, m_pSrc, m_pColour, m_pMyFilter);
if(FAILED(hResult))
    throw ERR_RENDER;
hResult = m_pBuilder->RenderStream(NULL,
    &MEDIATYPE_Video, m_pMyFilter, m_pCompressor, m_pRenderer);
if(FAILED(hResult))
    throw ERR_RENDER;

プログラムはこうなった。

開発機では問題無く動作して出力ファイルも1/10以下になった。ところがこれを他のPCで動かすと画面が異様に暗くキャプチャされてしまう。圧縮フィルタにはIntel Indeo 5.10を使ってるんだけど、何かのプロパティを明示的に設定しないとダメなのかも知れない。

とりあえず圧縮フィルタを特に問題がなかったWindows Video 1に入れ替えて誤魔化したけど、このへんはいずれちゃんと使いこなせるようにしたい所。COMの使い方についてはだいぶ慣れてきたから、もう一歩かな。

この歳になっても、勉強しなくちゃならない事はまだまだ多いなぁ。プログラマ35歳定年なんて、どこの世界の話なんだ？（笑）。

このページは xfy Blog Editor を利用して作成されました。

英語版インストーラ

VisualStudio 2005で開発中のプログラムがほぼ完成して、インストーラでレジストリの削除もできたから、あとは納品用のファイルを作るだけ。

プログラム本体は日本語版と英語版があって、コンパイル時のスイッチで両方のバイナリが生成できるようにしたんだけど、セットアッププロジェクトは共通化できなかったから、別個に作る必要がある。

ところが、日本語XP上でインストーラを作成すると、ロケールを英語に設定して作成していても英語版XP上では文字化けしてしまう事が発覚。しかたがないので動作チェック用の英語版XPマシンにもVisual Studioを入れようとしたら、HDDの空き容量不足で入らなかった（笑）。

動作チェックにしか使わないつもりだったから、余っていた6GのHDDを入れていたので、残り容量が2Gしか無かったのだ。

どうしようもないので急遽別のHDDを発掘したけど、動作確認用PCはスリムデスクトップでHDDが1台しか内蔵できない。むぅ。

で、結局HDDを交換してから英語版XPのインストールを始める羽目に。

VisualStudio 2005の英語版もインストールして、ようやく英語版のインストーラを作成する事ができた。MSDNには英語版のOSや開発ツールが山ほど入っていて、こんなもんいつ使うんだろうと思っていたけど、意外と出番は早かったな（笑）。

このページは xfy Blog Editor を利用して作成されました。

レジストリ削除

開発したソフトのインストーラは今までInstallShieldを使って作成していたけど、VisualStudio 2005には標準でインストーラの作成機能が付いてるので、試しにそれを使って作ってみる事にした。

ソリューションにウィザードでセットアッププロジェクトを追加して、あとはほぼデフォルトのままであっさりとインストーラは作成できたのだが、客先に送ったらアンインストール時にプログラムが自動的に作成するレジストリも削除して欲しいという要望が来た。

レジストリが残っていても害は無いので、別に消す必要は無いと思うんだけど、ご要望とあればしかたがない。お客様は神様ですから（笑）。

セットアッププロジェクトにはカスタム動作を追加できるので、レジストリを削除するVBScriptを作ってアンインストール時に実行すれば良いだろう、と単純に考えてしまったのだが、それが大間違い。

もう既におわかりの事と思うが、インストーラに含まれているVBScriptをアンインストール後になんか実行できるわけがない（笑）。もちろんセットアッププロジェクトのプロパティで、PermanentをTrueに設定すれば削除されずに残るのだが、そうすると今度はスクリプトファイルが最後に残ってしまう。

PCの再起動時に削除されるように細工するのは可能だけど、どう考えても方向性が間違ってる気がするので、マイクロソフトの「300 秒でズバリ !!」&「10 行でズバリ !!」 シリーズの中にあった「10 行でズバリ !! セットアップ プログラムの作成」を真面目に読んでみる。

我ながら泥縄だなぁ（笑）。

で、セットアッププロジェクトのレジストリ設定の所に DeleteAtUnistall というプロパティがあることを発見。プログラムの実行中に作成されるのと同じレジストリをここで登録しておいて、そのプロパティをTrueにするだけであっさりとアンインストール時に削除された。これだけで良かったのかぁ。

わざわざスクリプト組んだりして、えらく遠回りしてしまった。ハマってからでないと真剣に調べないのは悪い癖だな。

まあしょっちゅうハマってるから、結果的には良く調べている事になるか（笑）。

このページは xfy Blog Editor を利用して作成されました。

多言語対応

仕事で作成中の制御系プログラムは、ターゲットとなる装置が海外へも輸出されるので、日本語版と英語版を作る必要がある。

こういう時ってバージョン管理ツールを使ってプロジェクトを分岐させるのが本当なんだけど、以前にちょっと厄介な状態に陥った事があったから、表記を変える程度ならプロジェクトを分岐させずに済ませたい。

プログラム中のメッセージボックスなんかは#ifdefで切り替えて、ダイアログは日本語版と英語版の両方をプロジェクトに持たせてコンパイル時に切り替える事ができれば、プロジェクト自体は一本で済むなぁと思ってやってみると、メッセージボックスの切り替えはできるんだけどダイアログはダメ。

ダイアログクラスのヘッダにリソースIDが定義されているから、そこを書き換えるだけで済むと思ったんだけど、以下のように書き換えてコンパイルすると「コードの生成に失敗しました」と表示されてしまう。

// ダイアログ データ
#ifndef _LANG_JP
 enum { IDD = IDD_DLG_PREF_E }; // 英語ダイアログ
#else
 enum { IDD = IDD_DLG_PREF_J }; // 日本語ダイアログ
#endif

でもその状態でリビルドすると今度はちゃんとコードが生成される。おそらくどこかにクラスとダイアログを結びつける情報が入っていて、ダイアログクラスの定義だけを書き換えるとインクリメンタルコンパイルでは不整合が発生するのだな。ふむ。

その情報がどこにあるのか気になったので、あちこち探してようやく発見。クラスビューでダイアログクラスを展開すると出てくる_unnamed_xxxxクリックすると、下のペーンにIDDという項目が表示される。

そこをクリックするとプロパティビューに色々と表示されて

その中のInitExpressionにダイアログのリソースIDが定義されていた。こんな所に隠れていたのか。それでヘッダファイルの定義だけ#ifdefで書き換えるとダメなのだな。

ちなみにこのプロパティをマニュアルで書き換えると、驚いたことにヘッダファイルの定義も一緒に書き換わって不整合が起きないようになっていた。ううむ、マイクロソフト製品って相変わらず凄いんだかバカなんだか良く分からないぞ（笑）。

このページは xfy Blog Editor を利用して作成されました。

Cプログラムの中身がわかる本

AVR-GCCでプログラムを始めた当初は、C言語からどのようにアセンブラに変換されるのかを、コンパイラの出力を読んで確認するのを良くやっていた。

プログラムが思った通りに動かない時は結構有効で、AVRアセンブラはもともと高級言語との親和性が高いから、コンパイラの出力もかなり読みやすい。AVRアセンブラのテクニックを発見できたりするオマケも（笑）。

何かで検索して行き当たったブログの「なつたん」で「Cプログラムの中身がわかる本」を知ったんだけど、これが同じようなことをx86アーキテクチャでやっているらしいので、ちょっと興味が出てきた。

可愛い表紙でいかにも初心者向けな感じなのに、そんなマニアックな本だったとは。

この本を紹介していたブログでも

「表紙は可愛い犬ですが、中身は狼なので注意が必要」

と書かれてるし（笑）。うかつに手を出すと噛みつかれるわけですな。

とりあえずどこかで内容をチェックしてこよう。地元の書店では見かけなかったけど、中野のあおい書店にならあるかな？

渋谷の公園通りの会社で仕事していた時は、ブックファーストが近かったから便利だったんだけどね。でもあの巨大書店も今はビルごと無くなってしまったらしい。諸行無常。

渋谷の旭屋書店にもずいぶんとお世話になったんだけど、だいぶ前に撤退して今はそこがブックファーストになっているらしい。コンピュータ雑誌のバックナンバーがそろっていた大盛堂も旭屋書店と同じくらいの時期に閉店しているから、昼休みによく行っていた青山ブックセンター、ブックファースト、大盛堂、旭屋書店はすべて無くなってしまった事になる。

十年一昔と言うけど、まだ五年しか経ってないのになぁ。しみじみ。

このページは xfy Blog Editor を利用して作成されました。

文字エンコード

客先に送ったメールが文字化けして、何書いてあるのか分かりませんという連絡が来た。

添付されていたテキストを見てみると、半角とひらがなとカタカナは問題無いんだけど、何故か漢字だけが文字化けして全部アスタリスクに変わっている。まるで伏せ字だらけの怪しいテキストのようだ（笑）。

今までこんな奇妙な文字化けに遭遇した事が無かったので、原因を調べてみると客先から送られたメールに返信した時だけこの症状が出ている。でも必ず文字化けが起きる訳ではなく、ほとんどの場合は返信しても問題がない。

更に詳しく調べてみると、メールの文字エンコードがUTF-8とISO-2022-JPの二種類混在していて、UTF-8で送られたメールに対して返信すると必ず文字化けすることが分かった。

UTF-8のメールでも返信時に文字エンコードをISO-2022-JPに変えてから送れば、文字化けせずにちゃんと届く事も分かったけど、文字コードを変えて返信しないとダメなのはどう考えてもおかしい。

そもそもひらがなとカタカナは問題無くて、漢字だけ化けるのが納得できない。全角文字が全部ダメっていうのならまだ分かるんだけど、UTF-8って漢字とひらがな・カタカナの扱いに何か違いがあるんだろうか？

返信する時は必ずISO-2022-JPに固定する事で対処はできるのだが、うっかりしてると忘れそうだし、なんだか気持ちが悪い。

これに限らず文字エンコードがらみの問題って根が深くてイヤな感じがする。この手の仕事が回って来ない事を、切に願いたい（笑）。

このページは xfy Blog Editor を利用して作成されました。

スピンボタン

ある装置をGPIB経由で制御するアプリケーションをVC++で書いていて、制御そのものはそれほど難しく無いんだけど、送信するパラメータがやたらと多いのでその為の画面を作るのがかなり面倒。

まあだいたい制御系のアプリって、実際の制御部分よりもユーザインタフェース部分を作るのに手間がかかるのが普通なんだけどね。装置は決められたプロトコルでしか動作しないけど、人間は想定外の使い方をするし。

プログラムのユーザインタフェースがコマンドラインだけだったら、どんなにか開発が簡単だろう（笑）。

と思ってしまいたくなるほど今作っているのは面倒で、ダイアログ上にエディットボックスだけで80個もある。もちろんそれ以外のコントロールもてんこ盛り。

数は多くても処理はほとんど共通だから、ON_CONTROL_RANGE マクロでハンドラを一本化してやれば効率よく作れるだろうと思ってやってみたんだけど、エディットボックスについては確かにそれで共通化できたのだが、スピンボタンで躓いてしまった。

CSpinButtonCtrl のクリック時に UDN_DELTAPOS メッセージが来るのだが、このメッセージを ON_CONTROL_RANGE で定義してもハンドラへ飛んでいかないのだ。どうもスピンボタンはエディットボックスやボタンとは扱いが違うらしい。

しかたがないのでスピンボタンの処理だけはハンドラ定義を80個並べる羽目に。飛び先のハンドラは共通にできるから、結果的には同じ事なんだけど、エディットボックスの場合は ON_CONTROL_RANGE 使って定義が1行で済んでいるのに、スピンボタンだけ80行ってのはバランスが．．．．

VC++のプログラミングでこの手の困ったことを調べたい時は、Belution.comというサイトが非常に役に立ったのだが、いつのまにか接続できなくなってそれっきり。もう半年近くになる。

閉鎖なら残念だけどしかたがないが、何のアナウンスも無しに接続できない状態が続いていると、いつまでも気になってしまう。まあそうやって消えていったサイトは多いんだろうけどね。

はっ！もしやメンテナンスに異常に時間がかかっているだけとか？（笑）。

このページは xfy Blog Editor を利用して作成されました。

MS Shell Dlg

VisualStudio 2005での開発もだいぶ慣れてきて、いちいち何やるにも待たされるのはまだイライラさせられてしまうが、開発には支障なく使いこなせるようになった。

待たされるのはCPU速度とメモリの関係もあるから、開発用PCをアップグレードすれば解消するはず。もう最低でもCore2Duoプロセッサとメモリ2GByteは必須だなぁ。思えば遠くへ来たもんだ（笑）。

VC++でプロジェクトにダイアログを追加すると、デフォルトではフォントがMS Shell Dlgという見慣れないフォントに設定されるんだけど、このフォントがらみで少々悩んでしまった。

このフォントってコントロールパネルでインストールされているフォントの一覧を出しても、その中には存在しないのだ。

Windowsのフォントには論理フォントと物理フォントがあって、論理フォントはレジストリで物理フォントにマッピングされるから、フォント一覧の中に無くても不思議ではなくて、レジストリの [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\FontSubstitutes]を見ると以下のように定義されている。

このフォントは各言語の標準ダイアログフォントにマッピングされるから、日本語版Windowsと英語版Windowsで同じプログラムを動かした場合でも、文字化けせずに表示されるようになる。漢字を使ったらダメだけどね（笑）。

それは非常にありがたい事なのだが、ひとつ問題が。

ダイアログのプロパティでフォント設定を一度変えてしまうと、元に戻せなくなってしまうのだ。存在していないフォントなのでフォント選択ダイアログには出てこないし、直接フォント名を指定する事もできない。

さすがにそんなバカな事は無いと思うので、何らかの方法はあると思うんだけど、見つけ出す事ができなくて結局リソースファイルを直接編集して戻してしまった。そして未だに不明なままだったりする。

まあリソース編集で戻せるんだから良いと言えば良いんだけど、ちょっと気持ち悪い。誰か方法を知りませんか？

追記：

コメントで戻す方法を教えて頂いた。ダイアログプロパティの中にあるUse System FontをTrueに設定すると、FontがMS Shell Dlgに戻る。

まさかプロパティとして存在するとは思ってなかったので、他の所をず～っと探し回ってしまった。まさに灯台もと暗し（笑）。

このページは xfy Blog Editor を利用して作成されました。

XPスタイル

開発中のプログラムで画面の一部にオーナードローボタンを使う必要があって、ちょっと特殊な事をやっているので苦労したんだけど、どうにか仕様書通りの画面を作る事ができた。

仕様書の画面はWindows XPのクラシックスタイルで描かれていたから、オーナードローボタンの外観もそれに合わせて作成したのだが、出来上がってからふとデスクトップテーマをXPスタイル（Luna）に切り替えたらどうなるだろう？と思って試してみると．．．．

オーナードローしたボタン以外のコントロールが、全部XPスタイルに変わってしまうではないか。

機能的には問題無いけど、同じウィンドウの中でクラシックスタイルとXPスタイルのコントロールが混在しているのは、非常に見た目が悪い。

でも以前に同じVS 2005のVC++で開発したプログラムの中には、デスクトップテーマを変えてもコントロールのスタイルが変わらないモノがある。はて？この違いは何だろう？

検索するとプログラムをXPスタイルに対応させたい場合については見つかるのだが、逆に対応させたくない場合については見つからない。マニフェストが関係している事までは分かったので、コントロールとマニフェストについて更に調べて、やっと解答に行き当たった。

VC++のアプリケーションウィザードでプロジェクトを生成する時に「コモン コントロール マニフェスト」がチェックされていると、自動的にXPスタイル対応になってしまうらしい。

対応になっていなかったプログラムはもともとVS 6.0で作成したプロジェクトだったから、それをVS 2005でコンパイルした場合は非対応のままという事のようだ。

こーゆー余計な機能をデフォルトでONにするのは止めて欲しいぞ。マイクロソフト自身は余計な機能じゃなくて、重要な機能だと思ってるのかも知れないけど（笑）。

このページは xfy Blog Editor を利用して作成されました。

DirectShowへの道【ストリーム制御編】

USBカメラから取り込んだ動画を加工して録画するプログラムを以前に作って、その為にDirectShowの独自フィルタを作成した話を「DirectShowへの道 【独自フィルタ編】」に書いたんだけど、今度はそのプログラムで録画中に一時停止したいという要望が出てきた。

作成したプログラムでも録画の停止は可能なのだが、その度に個別のAVIファイルが作成されるから、確かに使い方によっては問題がある。数秒毎に停止するような使い方で丸一日動かすと、一万本ぐらいの動画ファイルができてしまうし（笑）。

DirectShowのIMediaControl インターフェイスにはRun、Pause、Stopといったメソッドがあって、これを使う事によってフィルタグラフを通るデータの流れが制御できるらしいので、早速実装してみると確かにプレビュー画面は停止する。

簡単じゃん。と思ったら大間違いで、出力されたAVIファイルを再生してみると、Pauseメソッドで停止している間は静止画が延々と録画されてしまっている（笑）。DirectShowでファイルを再生する時はこのメソッドで問題無いけど、録画する時はそれだけではダメなようだ。

ダメな事は分かっても、どうすれば良いのかが分からなくてずいぶん悩んでしまったが、あれこれ調べてICaptureGraphBuilder2 インターフェイスのストリームの開始タイムと終了タイムを設定するControlStreamメソッドを使えば良いことがようやく分かった。

キャプチャ開始前に使うメソッドだと思いこんでいて、キャプチャ中にも使える事に気付かなかったのが敗因。

一時停止する時は開始タイムをNULLにして、終了タイムをゼロにする。再開する時は開始タイムをゼロにして、終了タイムをMAXLONGLOGに設定すれば良い。って分かり難いにもほどがあるぞそれは（笑）。

実際のコードはこんな感じ（一部省略）

int Run(void)
{
    REFERENCE_TIME pstart = 0;
    REFERENCE_TIME pstop = MAXLONGLONG;
    hResult = m_pBuilder->ControlStream(&PIN_CATEGORY_CAPTURE, &MEDIATYPE_Video, NULL,
        &pstart, &pstop, 0, 0);
    if(FAILED(hResult))
        エラー処理
    hResult = m_pMediaControl->Run();
    if(FAILED(hResult))
        エラー処理
    return ERR_NONE;
}

int Pause(void)
{
    REFERENCE_TIME pstart = NULL;
    REFERENCE_TIME pstop = 0;
    hResult = m_pBuilder->ControlStream(&PIN_CATEGORY_CAPTURE, &MEDIATYPE_Video, NULL,
        &pstart, &pstop, 0, 0);
    if(FAILED(hResult))
        エラー処理
    hResult = m_pMediaControl->Pause();
    if(FAILED(hResult))
        エラー処理
    return ERR_NONE;
}

これで録画中に一時停止・再開ができるようになった。

このページは xfy Blog Editor を利用して作成されました。

いまひとたびのJava

XPortを使った装置の開発で、PC側の制御プログラムはVC++で作る事が多いんだけど、今回はそれに加えてJavaでも作ってみる事にした。

XPortは簡易的なWebサーバとフラッシュメモリを内蔵しているから、Javaで作ったプログラムをフラッシュメモリに書き込んでおくと、ブラウザでアクセスするだけでプログラムを実行する事ができる。つまりPC側に制御プログラムを置く必要が無くなるのだ。

装置を制御するためのプログラムをその装置自身が内蔵しているのは、オブジェクト指向的でちょっと面白い。

Javaは以前に某自動車メーカーの仕事でかなり凝ったシステムを組んだ事があるのだが、あれからもう5年近く経ってるからきれいさっぱり忘却の彼方（笑）。どうも自分はどんな開発言語でも急速に習得できる代わりに、使わなくなった時の忘却速度も速いらしい。

学生時代の一夜漬け勉強にそのへんの根元があるような気が（笑）。

とりあえず以前にも使った事がある稀杜の「CPad for Java2 SDK」を起動して、簡単なプログラムを打ちこんだり昔のプロジェクトを引っ張り出して眺めたりしていたんだけど、なんかJavaって簡単で良いなぁと思ってしまった。

以前に使った時はそう思わなかったのだが、あれから今日までの間に色々と経験を積んで、もっと使い難い言語や開発環境で七転八倒する事が多かったからなぁ。あのへんに比べると妙にスッキリした言語に思えてしまう。

プログラム言語の善し悪しなんて、その時々の立ち位置でがらっと変わってしまうものなのだな。ってそれは何でもそうか（笑）。

このページは xfy Blog Editor を利用して作成されました。

双眼その３

PCにUSBカメラを二台接続すると「USBコントローラの帯域幅の超過」のエラーが出て一台しか動かない問題の検証用に、USBインタフェースカードを買ってきてPCに増設することを考えていたんだけど、結局土日には買いに行けずじまい。

USBカメラはPCの前面にあるUSBポートへ挿していて、今日出社した時にふと思いついてそのうちの片方を背面のUSBポートへ移動してみると、何故かドライバのインストールが自動的に始まった。

しかも今度は帯域超過のエラーが出ない。

ををっ？と思ってGraphEditでそれぞれのUSBカメラからキャプチャするグラフを書き、実行してみるとちゃんとウィンドウが二つ開いてプレビューが開始されるではないか。なんだ、これで良かったのか。

USBインタフェースカード買う前に気付いて良かった（笑）。と安心したのもつかの間。GraphEditの実行を停止させたらその瞬間にPCがブルースクリーンで落ちてしまった。ありゃりゃ。

もともとPlayStation2用の周辺機器であるEyeToyを無理矢理PCで使ってるから、何が起こっても不思議では無いんだけど、OSごと落ちるのは困るなぁ。

ネットで調べてみると4台まで同時接続可能と明記しているUSBカメラがあるから、それを使えば問題無いんだろうけど、キャプチャソースがデバイス固定になってしまうのはできれば避けたい。

故障した時すぐに代替え品が入手できないと困るし、そういったデバイスに限ってすぐ生産中止になったり、メーカーが潰れたりする。

まあ予備として予め100台ぐらい買い込んでおけば、たぶん大丈夫だろうけどね（笑）。

このページは xfy Blog Editor を利用して作成されました。

双眼その２

昼休みにブックオフまで行ったので、中古ゲームの棚をチェックするとPS2のEyeToy対応ゲームで、カメラ同梱の奴を発見。

値段を見てみたら750円だった。安っ（笑）。

ゲームは不要なのでその場でカメラだけ取り出して、残りは「処分して下さい」と言って置いていこうかと思ったけど、それもアレなのでとりあえず会社に持って帰る。ヤフオクに1円で出せば売れるかも知れないし（笑）。

たぶんダメだとは思ったが、試しに以前に買ったEyeToyカメラと一緒にPCに挿してみると、やっぱり「USBコントローラの帯域幅の超過」というエラーが出てしまう。週末に新宿か秋葉原へ行けたら、安いUSBインタフェースカードを買って試してみるしか無いな。

銀塩カメラで胴体にレンズが二個並んでいて、ステレオ写真が撮れるカメラがあるけど、USBカメラで双眼ってのは存在してないんだろうか？それだったらPCからは一個のデバイスとして認識されるから、問題無いはずなんだけど。

いよいよダメだったらネットワークカメラを二台並べて使う手かなぁ。でもその場合はDirectShowとは無関係な世界になってしまうから、あれだけ苦労して作った独自フィルタが無駄になってしまう。

おまけにネットワークカメラのキャプチャ手段って標準化されてないので、使うカメラ合わせてプログラムを作らなきゃならないし。そんなんで悩むとまた白髪が増えてしまいそうだ（笑）。

このページは xfy Blog Editor を利用して作成されました。

双眼

USBカメラでキャプチャした画像をリアルタイムに加工して、動画としてファイルに保存するプログラムを以前に作って、その時はDirectShowとの格闘で白髪になりそうなくらい苦労したんだけど、今度はそのシステムでカメラを増設できないかという打診が来た。えー（笑）。

USBカメラを2台使って撮影したいらしいんだが、まさか立体画像でも撮るつもりなんだろうか？

Windowsで複数のキャプチャデバイス同時使用ってのはサポートされないんじゃなかったっけ？と思って調べてみると、ドライバが対応していれば可能という情報があった。と言う事は違うドライバを使うUSBカメラなら同時に使えるのだろうか？

モノは試しで使ってなかった古いUSBカメラを引っ張り出して挿してみると、「USBコントローラの帯域幅の超過」というエラーメッセージが出てしまう。当然キャプチャはできない。う～ん。

ドライバの対応うんぬん以前に、これではどうしようも無い。

USBコントローラの帯域幅の超過って事は、PCIスロットに別のUSBインタフェースボードを挿して、そこにUSBカメラをつなげばどうにかなるんだろうか？今なら1000円ぐらいで買えるはずだから、1枚買って試してみるしかないな。

同一のUSBカメラを2台挿した場合にどうなるかも試してみなくてはいけないから、いま使ってるEyeToyカメラと同じモノを中古ゲーム屋で探してこよう。

そのままではPCで使えないんだけど、ドライバに小細工すると使えるようになるので、お手軽に試すには丁度良い。今なら値段も安いし。

それに会社の近所にPCショップは無くても、中古ゲーム屋はいっぱいあるからね（笑）。

このページは xfy Blog Editor を利用して作成されました。

Vistaにはまだ早い

以前に開発したシリアル通信で装置から計測データを取り込むプログラムが、特定のUSBシリアル変換器をVistaで使った時だけ正常に動作しないという、非常に嫌なトラブルが発生。

デバッグのため客先からそのUSBシリアル変換器は借りてきたんだけど、会社のテスト用Vista PCには開発環境が入っていないので、デバッグする為にはVisual Studio 2005をインストールする必要がある。

と言うことでMSDNのDVDをドライブに入れたのだが、いつまで待ってもインストールが開始されなくて、おかしいなぁと思ったらそのPCのドライブはCD-ROMだった（笑）。最近のPCはDVDドライブ搭載が普通だけど、テスト用のVista PCはもともとサーバ用に調達した奴だったからなぁ。

結局Visual Studioのインストールは他のPCのDVDドライブを共有して実行。インストール中にセキュリティ上の問題があるので、Updateパッチを実行しろと言われたが無視してデバッグを開始したら、ブレークポイントでVisual Studioそのものの実行まで停止しやがる。セキュリティ上の問題かそれ？

Updateパッチを実行したら安定したけど、それだけで二時間近くかかってしまった。インストールよりもUpdateパッチのほうが時間がかかるって、なんか間違ってる気がするなぁ（笑）。

デバッグを開始するまでにえらく時間がかかったけど、デバッグを始めると問題点はあっさりと特定できた。同じUSBシリアル変換器なのに、XPとVistaではドライバの挙動が違っていて、プログラムがその差違を吸収できていなかったのが原因。

他のメーカー製のUSBシリアル変換器をVistaで使った時は、考えていた通りの動作をしていたので気付かなかった。というかドライバってのは機種毎の差違をそこで吸収して、アプリケーション側からは画一化して扱えるようにするためのモノじゃないのか？そうじゃないと困ると思うんだが。

これに限らずどうもVista用のドライバってまだ不完全なモノが多い気がする。作りがまるっきり違ってしまったから、ノウハウがまだ蓄積されて無いんだろうな。

まあ不完全でもドライバが提供されていればまだマシで、未だに現役で使っているWindows2000時代の周辺機器も多いんだけど、それらに対してはドライバがほとんど提供されていないし。かと言ってOSに合わせて周辺機器を買い換えるわけにはいかないからなぁ。

やっぱりまだVistaに移行するには早いようだ。

UIがかなり違うのは慣れの問題で、デスクトップテーマをクラシック表示に切り替えればだいぶ馴染みやすくなるから、ハードウェアに対する扱いも古いドライバが完全動作するクラシックモードが存在していれば良かったのに（笑）。

このページは xfy Blog Editor を利用して作成されました。

TinyBASIC

正月中にAVRマイコンで何か作ってみようかと思い立ち、簡単なインタプリタはどうだろうかと思ってネットで色々と調べていたら、Motorola MC68000版Tiny BASICのソースコードに行き当たった。

モトローラ純正の評価ボードMEX68KECB用でDr. Dobb's Journalの1985年2月号に掲載されたものらしい。評価ボードはお目にかかった事がないけど、Dr. Dobb's Journalの記事はなんとなく覚えがある。

もちろんソースコードはアセンブラで書かれているのだが、23年ぶりに再読したコードは思いの外読みやすかった。MC68000のニモニックなんかすっかり忘れていたけど、MOVE、SUB、ROL、BSR、BSLのような間違えようのない省略形が使われている事もあって、すぐに思い出す事ができた。

昔読んだ時の事はもう覚えてないけど、たぶん今のほうが容易に内容を理解できたと思う。20数年分のプログラマとしての経験を経て、やっとそのレベルに追いついたという事か（笑）。

それにしてもこのソースは楽しい。プログラムを読むというよりは、何かの読み物を読んでいるような感じもする。Linuxのカーネル読書会って参加した事無いけど、こんな感じなのかな。

ケータイにソースコードを転送して、暇な時にいつでも読めるようにしておこう（笑）。

このページは xfy Blog Editor を利用して作成されました。

立ち会い検査

年内は一応28日の金曜日までは出社日だけど、今週は月曜日が休みで今日は火曜日だから、気分的にはもう終わったような感じ。

なのに、今日は客先で立ち会い検査の予定が．．．．うちの会社は今週から休みですって言っておけば良かった（笑）。

立ち会い検査ってこっちは何も手出しできなくて、客先が製品を動かして問題が無いかチェックするので、精神的にはあまり良くない。もちろんバグが無いようにプログラムは作ってるんだけど、プログラムが100%完璧という証明はできないしね。

それにプログラムを作った本人が操作すると出ないのに、他の人が操作すると不具合が出易い傾向があるし（笑）。作った本人は内部処理が分かってるから、それに沿った操作をするのに対して、知らない人は想定外の操作をするからねぇ。

その場合でも正常動作するように作るのが本当なんだけど、すべての可能性を網羅してそれに対処するプログラムなんか作れないから、どうやったって不安は残る。

と言うことで戦々恐々だったのだが、どうにか致命的な問題は出ずに終了。場所が秋葉原の近くだったので、寄り道してから帰ろうと目論んでいたのに、別な製品の出荷を今日中に行うという連絡が入ってしまった。むぅ。

しかたがないので会社にとんぼ返り。

秋葉原へは昨日行ったばかりだけど、家に帰ってから「あれも買っておけば良かった」と思うことが多いので、寄って行きたかったんだけどなぁ。

まあ今日秋葉原に寄れて、昨日買い漏らしたモノを首尾良く買えたとしても、やっぱり家に帰った時には同じ事を思ってしまいそうだが（笑）。

このページは xfy Blog Editor を利用して作成されました。

律儀なフォント

以前に作ったプログラムが日付入力で不正な処理になるという報告が来たので、調べてみると2038年以降の日付を入力した時に確かにそうなる。

そんな先まで使われる事は無いと思うけど、間違って入力される可能性はあるからその時に落ちてしまうのはマズい。

日付入力コンポーネントの内部でCTimeオブジェクトに日時を代入した瞬間に落ちているので、MFCの問題なのは明らかなんだけど修正のしようが無い。VS2005のMFCでは問題無い事が分かっているから、プロジェクトをVS2005に移して再コンパイルする事にした。

例によって変数スコープの違いによるエラーや、古い形式で定義されている関数の警告が山ほど出てきたけど、エラー以外はとりあえず無視。再コンパイルしたプログラムでは2038年以降の日付を入れても問題無く動く。

ところが、画面に描画されているフォントのサイズが微妙におかしい。VS6.0でコンパイルした時よりも文字間隔が開いて、文字列全体の横幅が長くなってしまっている。ウィンドウからはみ出している文字列もあるから、このままではリリースできない。。

該当する部分のソースを見ると、CFontクラスのCreatePointFontメソッドを使って80ポイントのフォントを作っている。試しにそこを72ポイントに変更すると、文字列幅が以前と1ドットの狂いもなく同じになった。

以前のMFCでは指定されたポイントと同じフォントが存在しない場合に、いちばん近いサイズのフォントを代替えとして使っていたが、新しいMFCでは代替えフォントを使うところまでは同じで、更に文字間隔を調整して律儀に指定されたサイズに近いフォントを作ろうとするらしい。

確かにそっちのほうが正確なんだけど、プログラム中でフォントを使う時にそのポイントが存在するかなんて気にした事がないから、VS2005で再コンパイルした時に同じ問題にぶち当たるプログラムがボロボロ出てきそうだ。

まあでも今回の日付の問題みたいなのが無ければ、古いプロジェクトを新しい環境で再コンパイルする必要は無いだろうから、それほど気にしなくても良いかな。そういう事にしておこう（笑）。

このページは xfy Blog Editor を利用して作成されました。

DirectShowへの道 【独自フィルタ編】

ちょっと前からUSBカメラを使って録画するプログラムに取り組んでいて、キャプチャしてAVIファイルで保存するだけなら楽勝だろうと思っていたんだけど、実際にはそれほど楽な道では無かった。

いやキャプチャして録画ってだけなら確かに楽勝で、あっと言う間にできたんだけど、客先からの要求はキャプチャした動画に対して処理を行ってから保存というモノだったので、そうなると一気に敷居が高くなってしまうのだ。

キャプチャも保存もDirectShowが別スレッドで勝手にやってくれるから、何の処理も行わないならそれで終わりなのだが、単体で完結しているので独自処理を挟もうとすると逆に難しい。

資料をあちこち読みあさって、なるべく手抜．．．．簡潔な手段を探してみたけど、結局フィルタを自分で作るのが一番の近道だという事が分かった。う～ん、迂回しようと思っていたイバラの道が、実は一番楽な道だったという事か。

覚悟を決めて独自フィルタ作成について調べてみると、ゼロから構築するのは確かに面倒だけど、提供されているサンプルフィルタを元にして必要な部分だけコードを書けば良いらしい。

具体的にはCTransformFilterクラスを継承して、Transformメソッドをオーバーライドする。フィルタに入力されたストリームはTransformメソッドに渡されるので、そこで独自処理を加えてフィルから出力すれば良い。

Transformメソッドに渡されるのはIMediaSample型のポインタ二つで、最初が入力、次が出力。IMediaSampleオブジェクトにはフレームバッファのポインタを取得するGetPointerというメソッドがあるから、これでめでたくUSBカメラからキャプチャした画像の生データにアクセスする事ができる。

なんて遠い道なんだ（笑）。

でもまだ終わりじゃなくて、バッファのポインタを得る事ができてもそれが指すのは単なるバイト配列だから、加工するためにはGDIオブジェクトとして取り扱えるようにしなくてはならない。

幸いな事にWin32 APIにはCreateDIBSectionという関数が存在していて、バイト配列からDIBSection形式の特殊なDIBを作成してくれる。DIBSectionに対しては通常のビットマップと同じようにTextOutやBitBltといったGDI関数で描画する事ができるので、これでようやくすべての準備が整うわけだ。

あとは普通に画像を加工して、最後に出力へコピーしてやればいい。

実際のコードはこんな感じ

HRESULT CTestFilter::Transform(IMediaSample *pIn,IMediaSample *pOut) {
    LPDWORD pSrc;
    LPDWORD pDst;
    CheckPointer(pIn,E_POINTER);
    CheckPointer(pOut,E_POINTER);
    // フレームのポインタを取得
    pIn->GetPointer((BYTE**)&pSrc);
    pOut->GetPointer((BYTE**)&pDst);
    // 画像サイズを取得
    AM_MEDIA_TYPE *pType = &m_pInput->CurrentMediaType();
    VIDEOINFOHEADER *pvi = (VIDEOINFOHEADER *)pType->pbFormat;
    ASSERT(pvi);
    const long acSize = pIn->GetActualDataLength();
    int h = pvi->bmiHeader.biHeight;
    int w = pvi->bmiHeader.biWidth;
    // DIBSectionを作成
    BITMAPINFO biBMP;
    ZeroMemory(&biBMP, sizeof(biBMP));
    biBMP.bmiHeader.biSize = sizeof(BITMAPINFOHEADER);
    biBMP.bmiHeader.biBitCount = 32;
    biBMP.bmiHeader.biPlanes = 1;
    biBMP.bmiHeader.biWidth = w;
    biBMP.bmiHeader.biHeight = h;
    void* pRGB;
    HBITMAP hBMP = CreateDIBSection(NULL, &biBMP, DIB_RGB_COLORS, &pRGB, NULL, NULL);
    if(hBMP == NULL)
       return NULL;
    // 画像をコピー
    CopyMemory(pRGB, pSrc, acSize);
    // DCを取得
    HDC hDC = CreateCompatibleDC(0);
    // DCにDIBSectionを割り当てる
    HBITMAP hOldBMP = (HBITMAP)SelectObject(hDC, hBMP);
    // 描画処理
    // ここに処理を記述する
    // 描画したBITMAPを出力にコピー
    CopyMemory(pDst, pRGB, acSize);
    // 解放
    SelectObject(hDC, hOldBMP);
    DeleteDC(hDC);
    DeleteObject(hBMP);
    pOut->SetActualDataLength(acSize);
    pOut->SetSyncPoint(TRUE);
    return S_OK;
}

できあがったフィルタをGraphEditorでつないでテストしてみると、ちゃんと加工した画像が出力された。これで山は一つ越えたかな。一つ越えても次の山がそびえ立ってる気がするけど（笑）。

今度はこのフィルタをプログラムから使えるようにしなくてはならない。色々と調べたおかげでDirectShowの構造はだいぶ分かってきたから、この先はそれほど苦労せずに作れる．．．．と良いなぁ（笑）。

このページは xfy Blog Editor を利用して作成されました。

日本語化

制御・計測系のアプリってターゲットとなる機器毎の一品モノみたいな感じで作る事が多く、ターゲットも同時進行で開発中だったりするので明確な仕様ってのがなかなか出てこない。

通信仕様なんかはさすがに明確になってないと作れないので先に出してもらうんだけど、ユーザインタフェースなんかは考えてくれないから、聞き取りした内容をもとに自分で設計する事になる。

特に悩むのがボタンやメニューなんかの文字列で、一応それっぽい感じの英単語を付けて作るんだけど、先日納品したプログラムは今まで何も言って来なかったのに、この期に及んで画面の表記を全部日本語にしろと言ってきやがった。

どんな名前にすれば良いかというリストは出てきたけど、単純に置換するとボタンやダイアログの幅と合わなくなるので、全部調整し直し。むきゅー。

それだけならまだ良かったのだが、そのプログラムは既にドキュメント作成まで完了していて、画面のスクリーンショットを大量に貼り付けてあるのだ。日本語表記に変わってしまったらそれも全部作り直しじゃん。ドキュメント中の文字列なら置換すれば済むけど、ビットマップ画像中の文字列までは置換してくれないしなぁ。

まあドキュメントは客先の要望で納品より先に作ったんだから、その後から変更出して食い違いが出てもこっちの責任ではない。誰が日本語化しろって言い出したのか知らないけど、ドキュメントはその人に責任持って修正してもらいましょう（笑）。

このページは xfy Blog Editor を利用して作成されました。

AVR-GCCメモ

仕事でAVRマイコン使う話は、仕切値が他のマイコンチップよりも割高という事で立ち消えになりそうな雲行き。以前からAtmel社は日本市場へ積極的に売り込もうという意欲が感じられなかったんだけど、今でもそうなのか。

まあでも日本語サイトが存在するだけ以前よりはマシか。たとえ翻訳がアレだとしても（笑）。せっかくいいCPU作ってるんだから、もう少し意欲的に売り込んでも良いんじゃないのかなぁ。トラ技にCPU基板付けさせるとか。

それはさておき。

久しぶりにAVRの開発について調べていたら、すっかり時代に取り残されている事に気付いてしまったので、仕事で使うかどうかは別として自宅PCに開発環境を構築しておくことにした。

AVRはアセンブラでもプログラムし易いマイコンで、以前はかなり複雑な事もアセンブラでガリガリ書いていたんだけど、もうそんな根性はないしマイコンの性能も上がっているから、ソフトウェアでビデオ信号発生させたりしなければC言語でも十分。

ということでまずはAVR StudioとAVR-GCC(WinAVR)の最新版をダウンロード。AVR Studioの最新版は4.13 (build 528)で、以前は何も無しにダウンロードできたのに今は登録が必要になっている。開発ツールのダウンロードぐらいは自由にやらせて欲しいなぁ。

AVR Studioを先に入れてしまうとWinAVRが認識されなくなる事があると聞いたので、最初にWinAVRをインストールしてからAVR Studioを入れた。手順はほとんどデフォルトのままで問題なし。

昔の記憶を頼りに適当なデバイスを選んでテストプログラムを打ち込み、コンパイルさせるとこんなエラーメッセージが出てくる

Include <avr/io.h> instead of this file.

言われたとおり<avr/io.h>をインクルードして再度コンパイルすると、今度はこんなエラーメッセージ。

Attempt to include more than one <avr/ioXXX.h> file.

何が問題なのか良く分からなかったので、インクルードした<avr/io.h>と<avr/iotn26.h>を両方開いて中身を読んでみたら理解できた。デバイス個別のヘッダファイルはインクルードする必要が無かったのか。って良く見てみたら最初のエラーメッセージにちゃんとそう書いてあるじゃないか（笑）。

コンパイル時にターゲットデバイスが名が定義されるから、<avr/io.h>の中でそれをチェックして適切なヘッダファイルが自動的にインクルードされるようになっているのだ。なるほどね。

あとI/Oポートへのアクセスが以前はinb()/outb()という関数形式だったのが、ポート名に対する代入形式に変わっていたので少し戸惑ったけど、そっちのほうが分かりやすいからすぐに慣れるだろう。

使い込むとまた色々と悩むことが出てきそうだが、それはその都度blogに書いてメモとして残しておくつもり。最近とみに記憶力がアレなので、メモを残しておかないと何度でも同じ所で躓いてしまうからなぁ（笑）。

このページは xfy Blog Editor を利用して作成されました。

Windows SDK

仕事で構築するシステムにUSBカメラで状態監視する機能が必要となったが、USBカメラからキャプチャするクラスはだいぶ前に作ってあったから楽勝。

と思って昔のソースを引っ張り出してみると、DirectShow関係のライブラリが見つからなくてビルドできない。そういえばこれを作ったのはマザーボードが突然死した以前のPCだった、と思い出してDirectShow SDKを探すと、以前はDirectX SDKに含まれていたのがいつのまにかPlathome SDKに含まれるようになっている。

で、Plathome SDKをダウンロードしてインストールしてから、再度試してみると今度はVisual Studioのバージョンが古くてビルドできなかった。むぅ。

という所で放置していたんだけど、その後開発環境をVisual Studio 6.0からVisual Studio 2005にアップグレードしたので、三度目の正直で今度こそ大丈夫だろうと思ったらまたもやNG。

以前にインストールしたPlathome SDKはVisual Studio 2003でビルドすることを前提に作られていたのだ。開発環境はVisual Studio 2005になっているから、今度はコンパイラの方が新しくて適合しない。うがー。

このへんで既に何言ってるのか分からなくなってる人多数だと思うが（笑）まだ続きがあって、じゃあ対応するSDKは何処にあるんだ？と探してみると、Plathome SDKはVista対応になってWindows SDKに変わっている事が分かった。

なんでこうもコロコロ名称が変わるんだ？

．．．．Microsoftのデベロッパ部門担当者の首を絞めたくなってきたが、気持ちは分かって貰えるだろうか？（笑）。

し・か・も。Windows SDKは事もあろうに容量が1.4GByteもありやがる。Vista対応の.NET Framework SDKとか色々入ってるから巨大になるのは分かるんだが、こっちが欲しいのはDirectShow SDKの最新版なのだ。頼むから個別にダウンロードできるようにしてくれよー。

更に追い打ちで、ダウンロードしたファイルはISOのイメージファイルだし。DVDに焼くか仮想ドライブにマウントしないとインストールすらできない。どこまで開発者の手を煩わせれば気が済むのだ。

で、結局今日はDVDを焼いただけで時間切れ。

そして帰りのバスの中で、先日MicrosoftからMSDNの追加分のDVDが届いて、忙しかったから開封せずに放置していたことを思い出す。ああっ！！（笑）。

このページは xfy Blog Editor を利用して作成されました。

Only One

客先に納品したプログラムに後から修正要望が出てくるのはいつものことで、本当だったら納品後の追加修正は別料金の作業になるんだけど、簡単に直せるレベルの修正だったらそのままやってしまう事が多い。

今日客先から来た修正依頼のメールには、珍しいことに修正点だけではなくて具体的なプログラム例まで添えられていて、このように修正したらどうですかという提案が含まれたものだった。

そこまで考えて貰えるのは非常に有り難い事なのだが、問題がひとつ。

その修正案はVisualBasicで書かれていたんだけど、私が作って納品したプログラムはVisual C++で開発したものなのだ（笑）。これでいったいどーしろと。

作成したプログラムって自分ではかなり高度なプログラム技術を使ったつもりなんだけど、VBで開発したと思われていたとは．．．．かなりショック。動的にウィンドウの分割を切り替えたりってVBでは難しいと思うんだけどなぁ。

というかどうもその客先の担当者って、世の中に存在するWindowsプログラムがすべてVBで書かれていると思っているフシが．．．．まさかとは思うんだけど、ホントにそうだったら怖いので確認できません（笑）。

まあでも多かれ少なかれ、どの客先も似たような傾向はあるんだけどね。自分の知っている範囲でしか物事を見ようとしない。

そう言っている自分も、組込みマイコンからWindows・Linuxアプリ、Webアプリケーションまで手広くやっているつもりだけど、それでも全方向ってわけじゃないから当然死角はあって、その範囲でしか物事は見えてないんだろうけどね。

死角があっても多方向から見ることで無くすことはできるはずだから、それを忘れないようにしようと思う。その為に仕事中にWebであるこち見て回る事も必要なんですよ。決して遊んでいるわけではありません（笑）。

このページは xfy Blog Editor を利用して作成されました。

趣味と仕事

組込み系の仕事では使用するマイコンも客先指定の事が多く、そういう時に限ってどう考えてもオーバースペックな仕様書を突きつけられて頭を抱えたりするんだけど、次の仕事はマイコンの選定からこっちに任されたので、趣味に走ってAtmel社のATmegaシリーズを候補に揚げてみた。

個人的な趣味で使ってるのはATtiny止まりで、ATmegaはそのうち手を出してみようと思いつつ今に至っているから良い機会だし、最新の開発ツールを会社で買って貰えるのではないかという目論見もあったり（笑）。

でも今までは客先から押しつけられたマイコンでの開発だったから、それを理由にぶつくさ文句を言うこともできたが、自分で選んだマイコンだとそれが言えなくなってしまうなぁ（笑）。それでドツボに填っても自業自得になってしまう。ストレス溜まりそうだ。

趣味の開発だったら途中で放り投げても誰からも文句言われないが、仕事で始めるとそうもいかないしね。趣味を仕事にするなとも言われるしなぁ。

でも考えてみたら自分の仕事って、趣味が仕事になるパターンの連続だったりする。学生時代に趣味でプログラミングやっていたのが仕事になって、趣味でマイコン電子工作を始めるようになったら次に入社したのが組込み開発系の会社だし（笑）。

とゆーことはtwitterやtumblrを趣味だと言っていればそのうち．．．．（笑）。

このページは xfy Blog Editor を利用して作成されました。

併用

開発用に客先から借りたノートPCにVisual Studio 2005を入れて使っていて、最初は違和感バリバリだったけどだいぶ慣れたから、そろそろ本格的に移行するかなぁと思っていた矢先に、そのノートPCを返却せよという指令が。

もともと単発の開発用に借りていた奴だからしかたないんだけど、これで否応なしに移行せざるを得なくなった。

でも昔のプロジェクトも忘れた頃に修正依頼が来るから、Visual Studio 6.0の開発環境も残しておきたい。

両方入れても大丈夫とは聞いていたけど、何が起こるか分からないので最初に全プロジェクトをファイルサーバに待避してからインストールを実行。仕事で使うのは主にVC++なんだけど、暇な時にいじってみたいのでC#も一緒に入れる。あと念のためVBも（笑）。

最近はあまり無くなったけど、たまにVB指定で来る事があるからね。

で、なんでVBじゃないとダメなんですか？って聞くと

「社内にVBしか分かる奴がいないから」

という答えが平気で返ってくるし。それってつまりは後から追加変更する時に金出すのが嫌だから、社内でやらせるって事？

まあそれでも構わないんだけど、だったらプログラム内容に関する質問メールを投げてこないで欲しいなぁ（笑）。社内で何とかして下さい。

まあそれはともかく。VS2005のインストールが終わった後にVS6.0でコンパイルしてみると、今までと変わらなく使えたからとりあえずは大丈夫なようだ。しばらくはこれで併用してみよう。

でもちょっとだけ気に入らない点があって、ファイルの関連づけが変わったせいで、古いプロジェクトをダブルクリックするとVS2005が起動してしまうのだ。ファイルの中身を調べて自動的にどっちを起動するか判断するぐらいの芸は無いんだろうか（笑）。

あ、自分で自動振り分けするプログラム作って、プロジェクトファイルに関連づけすれば良いのか。いま気付いた（笑）。

このページは xfy Blog Editor を利用して作成されました。

誤配送

先週作ったプログラムの動作確認のため、午後から客先が来社する予定になったので、応接スペースにノートPCを移動してデモ環境を整えて待ち構えていた。

客先の担当者は時間通りにやってきたのだが、肝心のPCに接続するデバイスを持たずに手ぶらでやってきている。それではデモできませんと言ったら、デバイスは昨日宅配便でこちら宛に送ったはずと言われて、伝票番号から追跡すると何故かうちの会社とは全然違う千葉県の配送センターへ行っている事が判明。

どうやら何かの手違いで一緒に集荷された千葉県行きの荷物とごっちゃになってしまったらしい。そんな事もあるのか、珍しいなぁ。

年間に何百回も宅配便で荷物を出したり、受け取ったりしているけどそんな事が起こったのは初めてだ。もちろん宅配業者はすぐにこちらへ届けますと言っていたけど、いつになるのか分からないのでデモは明日に延期。

荷物が届いたのは客先が帰ってから一時間ぐらい後で、とりあえずデバイスを箱から出してプログラムの動作チェックをしてみると．．．．いきなり致命的なバグが発覚。うひー、これをデモしてたらちょっとヤバかった。

もちろん急いで修正して、何も見なかった事にしたのは言うまでもない（笑）。

まさか宅配業者の誤配送に助けられる事になろうとは、世の中何が幸いするか分からないものだなぁ。こういうのも運の強さと言うのだろうか？

このページは xfy Blog Editor を利用して作成されました。

FDTIプログラミング

今日は妻が仕事に出たので、子供と一緒にお留守番。

天気が良かったら代々木公園で開催されている「第３回代々木クラフトフェア」へ行ってみようかと思っていたけど、台風20号が関東に急速接近しつつあって、時間が経つにつれて風雨がどんどん酷くなってくる。

午後にはとてもじゃないけど出かけられるような状態ではなくなってしまった。代々木公園の会場はどんなありさまになっている事やら。

そんなわけで夕方に妻が帰ってくるまでは子供と一緒にピタゴラスイッチを見たり、お菓子を食べたりして過ごした。今日のピタゴラスイッチにはどこかで見たような商店街が出ていたけど、あれは笹塚の十号通り商店街じゃないかな。

夜は先週秋月で買ってきたUSBシリアルモジュールを使って、ちょっとプログラミングして遊ぶ。

仮想COMポートドライバを使ってシリアルポートとして使う分には何も考えずにそのまま使えるけど、FTDI社からこのモジュールに乗っているチップ（FT232RL）を直接叩くためのライブラリやAPIの資料が提供されているので、プログラマとしてはそれを試さない訳にはいかない。

FT232RLには5本のI/Oピンがあって、デフォルトでは送受信インジケータLEDを付けたりするための端子なんだけど、EEPROMを書き換えると汎用のI/Oピンとして使える。小手調べとしてそのへんをプログラムから操作してみる事にした。

EEPROMを書き換えるにはFTDI社のサイトからMProgというツールをダウンロードして行うんだけど、ちょっと癖のあるツールでいちいちテンプレートを保存しないと書き込みモードに戻れないことに気が付かず、戸惑ってしまった。

それと5本あるI/Oピンのうち、何故か一本だけ汎用I/Oポートとして切り替える事ができなくて、そこでもだいぶ悩んでしまったのだが、データシートを読むとそれで正解らしい。秋月の資料には「5本のデジタルI/O付き」と書かれているけど、あれはちょっと不正確だな。実際に使えるのは4本だけのようだ。

プログラムからそのI/Oポートを操作するのは思ったよりも簡単で、最初にデバイスリストを取得してデバイスを開き、あとはAPIのFT_SetBitModeとFT_GetBitModeを使えば読み書きができる。Windowsプログラマならものの数分で作れるレベル。

VC++でダイアログベースのアプリをちゃちゃっと作り、ブレッドボードにモジュールを差してLEDのOn/Offをできるようにしてみたのが上の写真。4ビットのうち2ビットだけLEDをつないである。

950円で買えるモジュールでいとも簡単に4ビットのデジタルI/O制御ができるので、ちょっとしたオモチャには良いんじゃないかな。4ビットだけってのはショボいと思うかも知れないけど、USBシリアル変換としての機能は当然そのまま使えるから、オマケとして考えればずいぶん役立つオマケじゃないかと思う。

もっとビット数が欲しいんなら秋月でUSBパラレル変換モジュールを買えば良いだけの話だし。

あとはこれを何に使うかだけど、2ビットだけで制御できるカメラモジュールTrevaなら簡単に動かせそう。もうその手の電子工作ネタは旬が過ぎまくってるけどね（笑）。

このページは xfy Blog Editor を利用して作成されました。

Chumby

ネットの新しモノ好き達のアンテナに最近よく引っかかっているChumbyなるデバイスが自分も気になってきたので、とりあえずアカウントを作ってみた。

実物を持ってないと登録しても意味がないかと思ったけど、アカウントを作っておけばブラウザ上で動くvirtual chumbyをカスタマイズして使う事ができる。

最初に聞いた時は中身がLinuxでネットにつながって、カスタマイズできる目覚まし時計という話だったので何なのかさっぱり分からなかったのだが、virtual chumbyを使ってみてピンときた、Blogのサイドバーなんかで動くwidgetsを単体で動かすためのガジェットなのだな。

Blogの設定画面でwidgetを表示する位置を指定できるけど、それが拡張されてPCのモニタ画面を飛び出す事が可能になったと考えれば分かりやすいかも。なるほど、これは面白い。面白すぎる。

既に用意されているwidgetだけでも山ほどあるし、Flashベースのwidgetを作成できる人なら自分で好きなように作れるわけか。それって無限の可能性があるって事じゃん。新しモノ好き達のアンテナに引っかかるわけだわ。

まあ冷静に考えれば今のケータイでも同じような事はできるんだけど、家の中でPCの置かれていない場所に据え置くデバイスという位置づけだから、ケータイとは競合しない。どっちかというと競合するのはTVやサイドボードの上に置かれている時計やカレンダーや写真立て、あるいはベッドのヘッドボードに置く目覚まし時計だ。

あ、それで「カスタマイズできる目覚まし時計」という話だったのか。なるほど納得（笑）。

なんかもの凄く欲しくなってきたぞ、日本から注文できるのかな？

このページは xfy Blog Editor を利用して作成されました。

ドキュメント納品

プログラムのソースコードからドキュメントを自動生成するツールはいくつかあるが、自分はだいぶ前からDoxygenを使っている。

ドキュメントを生成させる為にはルールに従ったコメントを付ける必要があって、それを覚えるのが最初はちょっと手間だけど、それほど特殊なルールではないから覚えるのは簡単。

しかもそれらしい図が付いた大量のドキュメントが自動的に生成されるので、納品物件の水増しにも重宝する（笑）。前にも書いた気がするけど、CD-Rにファイルを焼いて納品する時ってファイルを全部入れても大概はスカスカだから、自動生成させたファイルを山ほど入れると気分的にはちょっと違う。

それでも1/4ぐらいしか埋まらないんだけどねぇ。

で、ちょっと前に最終版の実行ファイルだけ渡してそれっきりになっていた客先から、今日になって急にドキュメントを納品して欲しいという連絡が来た。

じゃあ例によってDoxygenで生成して、htmlファイルをメールで送信すれば良いか。と思ったら「紙で出してください」ってなんですと～（笑）。今時それは無いでしょ。

よく聞いてみると印刷は向こうでやるからPDFで出してくださいという事だったので、プリントして宅配便で送るような事態からは逃れられたが、DoxygenでPDFを出力する使い方はしたことがない。

色々と調べてみると、TeXで出力してLeTeXでコンパイルして、ごにょごにょやればPDFを作ることが可能なのは分かったけど、それだけのためにWindowsにLaTeX環境をインストールするのはちょっとアレな気がする。

だったらrtf形式で出力して、MS-Wordで読み込んでAcrobatのPDFプリンタへ印刷すればどうだろうか？と思いついて早速やってみると、ちゃんとPDFファイルができた。

ところが出来上がったPDFファイルを開いてチェックすると、リンクの画像が抜け落ちて[×]印になってしまっている。あれれ？

これはMS-Wordのオプションで「印刷前にフィールドを更新する」と「印刷前にリンクを更新する」をオンにすることで解決。ファイルを単に読み込んだ状態でPDFプリンタへ印刷すると、リンクオブジェクトが読み込まれないまま印刷されてしまうらしい。それも妙な話だなぁ。

まあとにかくこれでPDFドキュメントはできたので、客先にメールで送って一件落着。ちなみにそのドキュメント、600ページもあるんだけど本当に紙で印刷する気なんだろうか？（笑）。

このページは xfy Blog Editor を利用して作成されました。

Vista検証その２

WindowsXPで開発したプログラムのVistaでの動作検証をやっていて、昨日はビットマップの色で引っかかったんだけど、今日はiniファイルの読み書きで不可解な現象に遭遇。

プログラムに何らかの設定値が存在する場合、レジストリに保存するのが普通なんだけど、昔ながらのiniファイルに読み書きする場合も結構多い。何故かというと、客先からプログラムをフォルダごと他のPCにコピーして、設定済みの状態で使いたいと言われる事が多いからだ。

作ってるのが一般的なアプリじゃなくて工場とかで使う計測・制御プログラムが主だから、設定済状態での稼働ってのは割と要望があるんだけど、レジストリを使っているとそれができない。

Vistaではセキュリティが強化されて、iniファイルへの読み書きも制限されると聞いていたから、その手のプログラムは警告が出まくるんじゃないかと思っていたのだが、実際にやってみると何の問題もなく動く。

ところが、設定値を保存したiniファイルを開いてみると、そこには何も書き込まれていないのだ。にもかかわらずプログラムを起動すると、保存した設定値が間違いなく読み込まれている。ミステリィ（笑）。

結論から言うと、これはVistaで新たに導入されたUAC（User Account Control）の仕業だった。VistaにはVirtual Storeという機能が追加されて、UACが有効になっている時に権限のないプログラムがProgram Files以下のフォルダに書き込みを行うと、UACが裏で小細工をするらしい。

表にするとこうだ

	READ	WRITE
複製無し	元のファイルから読み出す	元のファイルを複製して、それに書き込む
複製あり	複製から読み出す	複製に書き込む

これによって以前のプログラムとの互換性を保ちつつ、セキュリティを高めるという事らしいけど、大きなお世話もここに極まれりって感じだな（笑）。UACが無効の時は以前と変わらない動きをするから、設定によって同じプログラムが違う動きをするって事で、プログラマにとっては全くありがたくない機能だ。

しかも、複製が格納されるフォルダは

\Users\[ユーザー名]\AppData\Local\VirtualStore\Program Files\

の下になるから、ユーザ毎に異なる設定ファイルができてしまう。それはそれで便利なこともあるだろうけど、元々のプログラムがそれを意図していない場合でも、強制的にそうなってしまうのは問題なのでは？

色々と話は聞いていたけど、VistaがダメOSだってのはこれで確信（笑）。仕事でも個人でもできれば使いたくないが、うっかり普及しちゃうと開発の仕事では使わざるを得ないんだよなぁ．．．．

普及する前に次のまっとうなOSが出る事を祈ろう（笑）。

このページは xfy Blog Editor を利用して作成されました。

Vista検証

だいぶ前から取りかかっている計測・制御系のプログラム開発がそろそろ終わりそうなので、懸案事項だったVistaでの動作検証を行ってみる事にした。

今まではVistaマシンが無くてできなかったんだけど、激安販売されていた時に買ったDELLのサーバにいつのまにかMSDNのVistaが入っていたから、これ幸いと借用。

インストールされていたのはVistaの最上位版に当たるUltimateなのだが、サーバ用のPCだけあってグラフィック能力が貧弱でAeroが使えなかったのは泣いた。しかもPCI-Expressスロットが微妙な仕様になっていて、そのままではビデオカードが差せないときている。

かなり強引な改造を施せば外部ビデオカードも使えるんだけど、さすがに会社のPCにそんな無茶はできない（笑）。

なのでAeroでの動作検証は諦めて、スタンダード画面での動作だけを確かめて見る事にした。動作検証の意味がない気がするが、どうせ客先にもVistaマシンは今のところ1台も無いわけだから、何か問題があってもしばらくは気付かれないハズ（笑）。

ファイルサーバにフォルダを作って動作検証するプログラムを放り込み、Vista側からそれを起動してみると、基本的な動作は問題無いようなのだが、表示されるビットマップが何故か正しい色で表示されない。

TreeViewやListViewにビットマップアイコンを付けてるんだけど、XPで実行させた時と明らかに色が違う。よく見てみると黒色が表示されずに、背景が透過しているように見える。

使っているのはWindwosの基本とも言える16色ビットマップで、もちろんGIFやPNGじゃないから透過色なんてのは存在しないハズ。でも実際には確かに黒で描画した部分が抜けてしまっている。はて？これはいったい？

Vistaではビットマップの扱いが変わってしまったのだろうか？と思ってネットで調べてみたが、該当しそうな情報は見つからなかった。ベータ2でOutlookのアイコンがおかしくなるという話はあったけど、もちろんベータじゃないし。

色々と試してみると、この現象はVistaの画面が16ビットカラーの時だけ発生する事が分かった。24ビットカラーや32ビットカラーでは発生しない。

ビットマップの作成は

 m_ListImg.Create(IDB_TREE_IMG, 15, 0, ILC_COLOR4);

とやっていて、16色ビットマップは4ビットカラーだからILC_COLOR4の指定で間違いないけど、試しにこれを8ビットカラー(256色)に変えて試してみると．．．．

 m_ListImg.Create(IDB_TREE_IMG, 15, 0, ILC_COLOR8);

今度は画面が16ビットカラーの時でもちゃんと表示されるではないか。

ううむ、ますます納得いかないなぁ。最初はVistaのビデオドライバが関係しているのだろうと思っていたのだが、リモートデスクトップでも全く同じように黒抜けが発生するし。何が原因なのかさっぱり分からなくなってしまった。

ILC_COLOR8で指定すれば問題無い事は分かったから、とりあえずそれで良い事にしてしまおう。悩むのは時間ができてからだ（笑）。

このページは xfy Blog Editor を利用して作成されました。

変数スコープ

今ごろと言うかようやくと言うか、Windowsの開発環境をVisual Studio 6.0からVisual Studio 2005ベースに移行すべく、先週から本格的に使い始めているんだけど、思っていたよりは早めに慣れた気がする。

画面がごちゃごちゃした印象なのは相変わらずで、もう少しシンプルにまとめられないものだろうかと相変わらず思うのだが、何がどこにあるのか一度把握できてしまえばとりあえずは大丈夫。

散らかった部屋でもモノがある場所を覚えてしまえば、整理整頓された部屋と変わらずに使えるってのと一緒だな（笑）。

プロパティウィンドウは「自動的に隠す」機能が付いたから、普段使わないウィンドウは全部隠すように設定。もちろんアニメーション機能はOFF。マイクロソフトはウィンドウがアニメーションしながら表示されて、喜ぶプログラマがいると本気で思ってるんだろうか？

まあ悪いところばかりではなくて、エディタ画面がタブ切り替え方式になったのは嬉しい点だ。以前のようにダイアログエディタが独立したモードではなく、タブ毎に切り替わるようになったのも使い勝手の面では良い。

一番引っかかったのは変数スコープの扱いが変わってしまった事で、今まではfor文の括弧の中で宣言した変数はfor文を抜けても有効だったのが、Visual Studio 2005では無効になってしまう。

これは結構影響が大きくて、for文の終値をループを抜けてから使うようなプログラムを組んでいるとのきなみアウト。でもこれはVisual Studio 6.0の仕様が変なのであって、標準C++ではこの動作の方が正しい。

プロジェクト毎のプロパティに「for ループ スコープの強制準拠」というオプションがあるので、これを「いいえ」にすれば以前のバージョンと同じ動作になるんだけど、この言い方ってまるで

「標準C++の動作は間違ってるけど、強制的にその仕様に従う」

と言っているように思えてしまうのは私だけだろうか？（笑）。

「非標準for ループ スコープ」というオプションで、それを「はい」にした時だけ以前のコンパイラと互換になるほうが正しいと思うんだけどなぁ。さすがは天下のマイクロソフトだ（笑）。

このページは xfy Blog Editor を利用して作成されました。

無線と有線

開発用に借用したノートPCのWindows XPをSP2にアップデートしたら、CPUの使用率が100%に張り付いたまま何もできなくなってしまったので、結局諦めて会社のLet'snoteにVisual Studio 2005をインストールして使う事になった。

こっちは最初からSP2が入っているから、何の問題も無くインストールできる。

長い事Visual Studio 6.0ばっかり使っていたから、Visual Studio 2005を使うと最初は違和感バリバリ。情報量過多というか、画面構成がごちゃごちゃしすぎ。DOS/V版のTurboPascalはシンプルで良かったなぁ（笑）。

でもプロパティウィンドウを自動的に隠すようにしたり、使わないツールバーを外したりと細かく設定を変えたらだいぶスッキリした。初期画面が必要最低限の画面構成になっていればいちいち設定を変えなくて済むのに、ほとんどのアプリって逆で初期画面はありったけの情報を見せようとする傾向があるよね。

それが親切だと思ってるんだろうけど、なんか違う気がするなぁ。初期画面に表示されないと存在すら気付いてもらえない機能が出てくるから、プログラマの気持ちとしては非常に良く分かるのだが。

まあそれはともかく。

ノートPCをそのまま開発に使うと置き場所に困るし、画面もXGAでは狭すぎるからメインPCからXPのリモートデスクトップで使う事にしたんだけど、どうも無線LANの感度が低くて反応が良くない。

それもそのはずでいつのまにか無線LANのアクセスポイント周辺に荷物が山積みされてるし（笑）。しかも中身は全部金属部品だから、感度が悪くなるのも当然。しかたがないのでLANケーブル引っ張ってきて有線でつなぐようにした。

ところが、無線LANから有線LANに切り替えると何故かワークグループに入れない。正確に言うとワークグループは表示されるのだが、そこには自分しか表示されなくて、他のPCが出てこないのだ。

でも無線LANに戻すと同じワークグループのPCがちゃんと表示される。もちろん無線LANと有線LANのネットワーク設定を見比べても違いは無いし、他のPCに対するpingも問題なく届く。

違いがあるとしたら無線と有線でMACアドレスが異なるぐらいだけど、それがワークグループへの参加に影響するとは思えない。可能性があるとすればブラウザマスタが保持している情報が何か食い違っている事ぐらい。

そもそもブラウザマスタってMACアドレスを保持してるんだっけ？

そのへんの情報を手軽に表示できるツールが無いかと思って探してみると、「DomainView--」という非常に良くできたツールがあった。ネットワークに接続されているPCのIP、MACアドレス、ブラウザマスタ情報なんかがリストで表示される。

結構古くからあるツールらしいけど、今まで存在を知らなかった。これは定番ツールとして覚えておこう。

でもこれを使っても、有線LANの時にコンピュータ名がワークグループのリストに現れてこないのは同じで、結局原因は掴めなかった。なんかものすごく単純な原因のような気がするんだが．．．．

このページは xfy Blog Editor を利用して作成されました。

Update地獄

客先から開発用に借用したノートPCに、開発環境としてVisual Studio 2005をインストールしようと思ったら、XPがSP1の状態だったのでインストールの最初ではじかれてしまった。

じゃあ先にXPをSP2にアップデートすればOK、と気楽に考えて昨日の午後にその作業を始めたのだが、それがUpdate地獄の始まりだったとはその時は知る由もなかった。

マイクロソフトのサイトからSP2のアップデートパッチをダウンロードして、インストールするまでは良かったんだけど、インストール終了後からPCの動作が妙に重たくなって、再度試してみたVisual Studio 2005のインストールも.NET Frameworkのステップからいつまで経っても先へ進まない。

タスクマネージャのCPU使用率は100%のままで下がらないし。

しかたがないのでインストールを中断して、Windows Updateを開始してみたのだが、これも最初の段階から先へ進まず、昨日はそのまま放置して帰ってしまった。

その後何時間か経ってUpdateは完了したらしいが、それでも激重なのは変わらず。いろいろと調べてみるとOffice2003がインストールされている環境にSP2のアップデートを適用すると発生する問題らしい。でもサイトに書かれている対処法を全て試しても症状が改善されない。

改善されるどころか更に悪化して、エクスプローラでフォルダを開こうとしただけでもアプリケーションが応答無しと表示されてしまう始末。でもハングアップしている訳ではなくて、3分ぐらい経つとちゃんとフォルダが開く。

Pentiumの100MHzぐらいでXPを動かしたら、ちょうどこんな感じなのではなかろうか（笑）。

昨日の午後から今日の午前中までの時間を費やしてもダメで、結局あきらめて会社のノートPCを使って開発することになってしまった。そっちは最初からXPのSP2なので問題は無いハズ。

最初からそっちでやっていれば、今頃は半分ぐらいプログラムが完成していてもおかしく無かったんだよなぁ。セットアップでハマって時間を無駄にするってのは良くある事だけど、これだけ長いことかかって結局ダメだったのは初めてだ。徒労という言葉を久しぶりに実感してしまったよ。

ダメダメな状態になったノートPCは借用品だから、開発が終わったら客先に返さないといけないのだが、さすがにこまま返却したら文句言われるだろうなぁ（笑）。

このページは xfy Blog Editor を利用して作成されました。

DirectShow

客先からPCを使った監視システムの引き合いが来て、基本的にはPCに接続したUSBカメラでキャプチャした画像をファイルに落とすだけだから、それほど難しい仕事ではない。

USBカメラからのキャプチャは以前にDirectShowをいじった時に、簡単にキャプチャできるようにラップするクラスも作ってあるので、それを引っ張り出して簡単なテストプログラムを作ってみようとしたら、SDKがインストールされていなかった。

会社で使っているPCは以前にマザーが突然死して、新しいPCに交換したんだけどDirectShowを使って色々やっていたのは古いPCのほうだったから、SDKが入っていないのは当然。

調べてみると今のDirectShow SDKはDirectX SDKには含まれず、Plathome SDKに含まれるようになったらしい。以前に使った時にDirectXに含まれるのは微妙に違う気がすると思っていたから、これは納得。

ところが、Plathome SDKをインストールしてキャプチャプログラムをコンパイルしてみると、インクルードファイル不足でエラーになってしまう。そしてそのファイルはDirectX SDKに含まれているのだった（笑）。

結局両方インストールしないとダメじゃん。

相変わらずMicrosoftの考える事って良く分からない事が多いなぁ。特に開発環境まわりって、あまりにも複雑かつ多種多様になってしまったから、内部の人間でも全てを把握している人って少ないんじゃないだろうか。

そういえば会社に鎮座しているMSDNにも、何に使うのかさっぱり見当の付かないDVDが何枚か入っていたような．．．．（笑）。

このページは xfy Blog Editor を利用して作成されました。

漢字コードの消失

一昨日書いたKURO-BOX/PROの環境構築の続き。

Windowsプログラマがなるべく違和感なくLinuxの開発を行えるようにと考えて、フリーのツールや自作スクリプトを組み合わせて作った開発環境を、KURO-BOX/PROでも動くように設定したのが前の話。

もともとはVine Linux用だったんだけど、Debianでもほとんど問題なくコンパイルや実行、Makefileの自動生成ができるようになった。

JmEditor2の強力なマクロ機能のおかげで、カーソル位置の単語をmanで調べるのもリモートで可能になっているのだが、よく見てみるとその出力結果がおかしい。リモートログインした状態でmanを実行すると

printf(1)                                                            printf(1) 名前        printf - データを整形して表示する 書式        printf format [argument...]        printf [--help] [--version] 説明        printf  は文字列 format を表示する。その際 `%' は書式指定子として、また        `\' はエスケープ文字として解釈される。解釈のしかたは C の printf(3)  関        数 と同じである。引き数 format は与えられた argument すべてをコンバート        するのに必要な回数分再利用される。

と出力されて何の問題も無いのだが、これをリモート開発環境から行うと

printf(1)                                                            printf(1)        printf -        printf format [argument...]        printf [--help] [--version]        printf   format  `%'        `\'  C  printf(3)          format  argument

こんな事になってしまう。日本語部分がすべて消えて無くなっているのだ。

最初はLocaleの問題かと思って、インストールし直したり環境変数の設定を変えてみたりと色々やってみたのだが、どうやっても結果は同じ。これにはかなり悩んでしまった。

manをリモート実行するシェルスクリプトは、最初に環境変数の設定を行ってから

man $1 | col -b | nkf -s

を実行しているだけで、特に変な事はやっていない。manの出力をcolに喰わせてバックスペース文字を取り除いてから、nkfでシフトJISコードに変換しているだけ。manをプレーンテキスト化するのにcolを使うのは定番だし、Vine Linuxでは問題なく動いていたので、まさかここに落とし穴があるとは気づかなかった。

そう、Debianのcolは漢字コードを全部削ってしまうという落とし穴が（爆）。

気づいた時は唖然としてしまったぞ。

改めてネットで探してみると、Debianのcolをマルチバイト対応にしたwcolというツールがあって、その説明にはしっかりと

「Debian GNU/Linux etch では日本語のマニュアルページに対して man hoge | col -bfx などとすると日本語が出力されません」

と書かれてるし、むぅ。

そのツールをインストールしてcolの代わりに使うと、今度はちゃんと日本語が出力されるんだけど、フォントがボールドになっている見出し部分だけは文字化けしてしまう。その部分の制御コードは取り除いてくれないようだ。

まあ見出し部分が文字化けしてもプログラム中に関数の書式を調べたいという目的には影響がないから、とりあえずこれでOKという事にしておこう。あとは暇な時に自分でフィルタするツールを作って、置き換えすれば良し。

このページは xfy Blog Editor を利用して作成されました。

環境構築

あんまり長い事放置してるとやる気が無くなってしまうので、KURO-BOX/PROのDebian化と開発環境の構築を一気にやってみた。

と言ってもエレキジャックのKURO-BOX/PRO特設ページに書かれている内容をほぼそのまま行っただけで、特に難しい事は何もやっていない。Debian化に必要なファイルも特設ページからダウンロードしたものをありがたく使わせて頂いた。

何をやったのか忘れてしまいそうなので、以下にメモ。

• Debian化
• Debian 化する(実行編)を参照
• アップデート
• apt-get update
• apt-get upgrade
• sambaのインストール
• apt-get install samba
• adduserでsamba用のユーザ(develop)を作成
• smbpasswd -a develop
• /etc/init.d/samba restart
• 開発環境のインストール
• apt-get install gcc make libc-dev libc6-dev
• apt-get install g++
• apt-get install tmake
• apt-get install nkf
• apt-get install manpages manpages-dev manpages-ja
• apt-get install jless
• localeの設定
• apt-get install locales
• dpkg-reconfigure locales
• 文字コードはja_JP.EUC-JPとja_JP.UTF-8を選択
• /home/developの.bashrcに以下の2行を追加
• export LC_ALL=ja_JP.EUC-JP
• export PAGER=jless

g++とtmakeとnkfのインストールはエレキジャックの記事には無いけど、以前に作ったXPからリモートでコンパイルする環境で必要。

リモートコンパイルはsshクライアントPuTTYの作者が作ったPlinkを利用させていただいている。Plinkはssh経由でリモート先のプログラムを実行できるプログラムで、それを使ってリモート先に置いたコンパイル用のシェルスクリプトを叩く仕組み。

XP側はマクロ実行機能を持つテキストエディタJmEditor2を使って、マクロからPlinkを実行している。図にするとこんな感じ。

なんでこんな面倒な事をやっているかと言うと、LinuxのコンパイルもVisualStudioと同じような感じでエディタからキー一発で実行できるようにしたかったから。

マクロをかなり趣味に走って作ったので、コンパイル結果のエラー行をダブルクリックするとその行へ飛べるとか、カーソル位置の単語をmanで調べる機能なんかも付け加えてある。もちろんショートカットはF1キーだ（笑）。

いかにVisualStudioに毒されてるかって話だけど、それは言わない約束（笑）。この環境を構築するためにエディタのJavaScript互換マクロと、bashのシェルスクリプトの作り方も覚える事ができたし、それだけでもずいぶん面白かった。

まったくもってプログラマは業が深いよなぁ（笑）。

このページは xfy Blog Editor を利用して作成されました。

BusyBox

KURO-BOX/PROのシリアルコンソールが正常に動かなかった件は、以前のエントリに書いたようにコネクタの半田付け不良が原因で、半田付けし直したら何の問題もなく使えるようになった。

バッファローダイレクトで特価販売されていた奴だったので、動かなかった時はハードウェアの不良を疑ってしまったよ。疑ってスミマセン。

これで心おきなくDebian化が進められるんだけど、せっかくなのでその前にデフォルト状態でどんな構成になっているのかを色々と調べてみた。

Webの情報でKURO-BOX/PROはBusyBoxを使用していると書かれていて、それが実際は何なのかピンと来なかったのだが、/binディレクトリでls -lをやってみたら一目瞭然。

bin # ls -l lrwxrwxrwx    1 root     root            7 Apr 10 22:45 addgroup -> busybox lrwxrwxrwx    1 root     root            7 Apr 10 22:45 adduser -> busybox lrwxrwxrwx    1 root     root            7 Apr 10 22:45 ash -> busybox -rwxrwxrwx    1 root     root       619848 Dec 21  2006 bash lrwxrwxrwx    1 root     root            4 Apr 10 22:45 bash2 -> bash lrwxrwxrwx    1 root     root            7 Apr 10 22:45 bbconfig -> busybox -rwxr-xr-x    1 root     root       797180 Apr  6 22:45 busybox lrwxrwxrwx    1 root     root            7 Apr 10 22:45 cat -> busybox lrwxrwxrwx    1 root     root            7 Apr 10 22:45 chattr -> busybox lrwxrwxrwx    1 root     root            7 Apr 10 22:45 chgrp -> busybox lrwxrwxrwx    1 root     root            7 Apr 10 22:45 chmod -> busybox lrwxrwxrwx    1 root     root            7 Apr 10 22:45 chown -> busybox lrwxrwxrwx    1 root     root            7 Apr 10 22:45 cp -> busybox lrwxrwxrwx    1 root     root            7 Apr 10 22:45 cpio -> busybox lrwxrwxrwx    1 root     root            7 Apr 10 22:45 date -> busybox lrwxrwxrwx    1 root     root            7 Apr 10 22:45 dd -> busybox lrwxrwxrwx    1 root     root            7 Apr 10 22:45 delgroup -> busybox

ほとんどのコマンドがBusyBoxへのリンクになっていた。なるほど、そういう事か。

つまりlsもmkdirもmountも実行されるのは同じBusyBoxで、BusyBoxはarg[0]をみて自分がどのコマンドとして実行されたのかを調べて、そのコマンドに応じた処理を行う訳だ。

C言語でプログラムしていた時に、arg[0]に格納される実行ファイル名って意味が無いよなぁと思っていたんだけど、これなら十分に意味がある（笑）。

リソースに余裕のあるシステムならBusyBoxを使う必要は無いけど、複数のコマンドやツールを一つにまとめる事でサイズを大幅に削減できるから、制約の多い組み込みシステムでは確かに便利だろう。

うまいこと考えるもんだなぁ。感心してしまった。

あとからWebで調べてみると「BusyBoxを使って組み込みLinuxシステムを単純化する」というIBMの記事があった。これは良くまとまっていて分かりやすい。最初にこの記事を読んでおけば、すぐにピンと来たのにな（笑）。

このページは xfy Blog Editor を利用して作成されました。

不正な処理

VC++で既存のプロジェクトから新しいプロジェクトを作ろうとして、VSSとの絡みで半日分の作業をパアにした話を以前のエントリに書いた。

その時に作ったプロジェクトが昨日の帰り間際に不可解なエラーを出したので、ちょっと気になって午後から会社に出ることにした。午前中は子供を合気道教室へ連れて行って、そのあと地域無料開放のプールへ一緒に行ったから疲れていたのだが、月曜日になってから致命的なバグだということが発覚したりすると、時間的にかなりキビシイので。

特定のダイアログを開こうとすると不正な処理になるという症状で、デバッグモードでトレースすると最初の初期化段階でエラーが発生している。更に細かくトレースするとダイアログ上の特定のコントロール変数に対して、UpdateDataで初期値を設定しようとした瞬間に不正な処理になる。

今までそんな部分でエラーになったことは無いので、変だなぁと思いながらもコントロール変数の定義をチェックしてみたが、特に問題は無い。じゃあコントロールのほうか？と思ってダイアログエディタで開くと．．．．あれ？コントロールが無くなってる！！！！！（爆）。

コントロール変数はちゃんと定義されているけど、それと関係づけられているコントロールがリソースファイルから消えてしまっていた。不正な処理になるわけだ．．．．

どうやらVSSとの絡みでプロジェクトがごちゃごちゃになった時に、リソースファイルだけリビジョンの古いファイルが上書きされてしまったらしい。コントロール変数の定義とリソースファイルの定義に食い違いが生じて、実体の無いコントロールにアクセスしようとしていた訳だ。

しかも元になったプロジェクトのリソースファイルまでリビジョンが古くなっている。というかオリジナルが古いリビジョンで上書きされてしまった事に気づかないで、そこから新しいプロジェクトを作ってしまったのだな。

バックアップからリソースファイルを取り出して入れ替えて、変更点だけ手作業で書き戻して一件落着。直すのは簡単だったけど、なぜこんな事になったのかは謎のまま。意図的に戻さない限りVSSが古いリビジョンのファイルで上書きする事は無いんだけどなぁ？

なにはともあれ休日出勤した甲斐はあった。週明けからこんな訳の分からないバグで悩みたくないし。これで明日は気持ちよく休める（笑）。

このページは xfy Blog Editor を利用して作成されました。

BASIC魂

未だに仕事で使う機会は無いんだけど、Parallax社のBASIC Stampシリーズは以前から気になっていて、やはりそれは自分のプログラマとしての根っこの部分に「BASIC」という言語が深く関わっているからだろうと思う。

かつて「マイコン少年」と呼ばれていて、今でも現役でプログラマやってる人なら分かって貰えるんじゃないかな。私よりも下の世代のプログラマの根っこには、何があるのだろう？

まあそれはともかく、久しぶりにそのParallax社のサイトを見に行ったら、知らない間にUSBスティックタイプの製品「BS1USB」が出ていて、かなり心が動いてしまった。

なんかこのタイプの開発用マイコンボードって好きなんだよなぁ。仕事で使ってる開発ボードがシリアル通信やデバッガや電源のケーブルでぐちゃぐちゃになってるから、その反動かも知れない（笑）。

この製品は非常にシンプルな形状だけど、透明チューブでコネクタ部分の補強が行われているから、乱暴に扱わなければコネクタ部分がへし折れる事も無い．．．．かな？（笑）。透明チューブは素手で抜き差しする場合の基板保護も兼ねていて、それはなかなか良いアイデアじゃないかと思う。

まだ国内では扱っている代理店は無いみたいだけど、値段次第では使ってみたいと思う人が多いのではないだろうか？ツクモロボット王国でBASIC Stamp 2は取り扱っているから、こっちも取り扱ってくれる事を期待しよう。

メーカーの製品ページからダウンロードできるPDFファイルの最後にBASICのサンプルプログラムが載ってるんだけど

Main:   DEBUG CLS, "Hello World!", CR   END

やっぱり最初はHello Worldなんだねぇ。でも最後にGOTO 10が無いのはちょっと寂しいかな（笑）。

そういえばWikipediaにHello worldの項目があるんだけど、かなり無茶苦茶な例が載っていて笑ってしまった。HQ9+という言語はHコマンド一文字で"Hello, world!"を出力するので、サンプルコードは'H'一文字だけだし（笑）。

OoK!やWhitespaceといった可読性を極端に低くする事を目的とした書かれた言語で、Hello Worldを出力するサンプルを掲載するのって何の意味があるのかちょっと疑問。まあ読むのが困難だという事を示すサンプルにはなっているか（笑）。

このページは xfy Blog Editor を利用して作成されました。

not Safe

VC++にはプロジェクト名を変更する機能が無いので、以前に作ったプロジェクトをベースにして新しいプロジェクトを作成する時は、ソースファイルとプロジェクトファイルをGrepして置換という原始的な手段で行っている。

プロジェクト名に「if」とか「switch」等の名前を使ってるとその手は使えないんだけど、予約語は本能的に避けるようになってるから大丈夫（笑）。

普段ならそれで問題無いのだが、今回はオリジナルのプロジェクトがVSS(Visual Source Safe)を使ってリビジョン管理をしていたので、かなり厄介な事になってしまった。

VC++のプロジェクトファイルにはVSSへの参照設定も含まれていて、プロジェクトを複製するとその設定もそのまま引き継いでしまうのだ。つまりどうなるかと言うと、新しいプロジェクトなのにVSSのデータベースはオリジナルのプロジェクトを指しているから、オリジナルが上書きされてしまうのである。

これは非常にマズイ。

最初はVSSの参照設定が引き継がれている事に気付かなくて、どうも動きが変だなぁと思ってネットで検索してみたら「Visual Studio 6 のワークスペース・プロジェクトから VSS の参照設定を削除する方法」という情報が見つかって、ようやく何がおかしいのかが分かった。

確かにそこに書かれている通り、プロジェクトファイル内にしっかりとVSSへの参照設定が記述されている。

ところが、それを削除してプロジェクトを読み直しても、やっぱり参照先が変わっていない。しかもそこでプロジェクトを保存すると、削除したはずの記述がゾンビのように蘇っているのだ。

どうやらVC++が自動的に作成するファイルの何処かに設定が保存されていて、プロジェクトを読み込んだ時にVSSの参照設定が無くなっていると、そっちから設定を復活させてしまうらしい。なんという大きなお世話（笑）。

そこで今度は.dsw .dspファイル内のVSS参照設定を削除してから、.ncb .opt .clw .apsの各ファイルも削除。プロジェクトを読み直すと、今度はソース管理のメニューで「ソース管理へ追加」の項目だけが有効な状態になった。

その状態でソース管理への追加を選択すると、新規プロジェクトの登録ダイアログが現れて、ようやく思った通りの状態にすることができた。

と、これで一件落着なのだが。VSSへの登録が終わった時点でソースファイルを開いてみたら、それまでに修正した内容がきれいさっぱりと消えてしまっている。どうやら間違ったデータベースへリンクされていた時に、うっかりファイルの書き戻しを実行してしまったらしい。

おかげで半日分の作業がパアに．．．．

こんな事にならないようにVSSを使っていたハズなのに、逆にその為にファイルをロストしてしまうとは。無理な使い方をしたのが悪いのは分かっているんだけど、久しぶりに徒労感を味わってしまったよ。とほほ。

同じ轍を踏まないために、正しい手順をメモしておこう

1. 元になるプロジェクトをフォルダごと複製
2. 複製したプロジェクト内のプロジェクトファイルとソースファイルをGrepして、プロジェクト名を置換
3. .cssファイルを全て削除
4. .dsw .dspファイル内のVSS参照設定を削除
5. .ncb .opt .clw .apsの各ファイルを削除
6. プロジェクトを読み込んでClassWizardでクラス情報ファイルを再作成
7. ソース管理に追加

これで大丈夫なハズ。

このページは xfy Blog Editor を利用して作成されました。

InstallShield

以前に作成したアプリケーションの英語版を作って欲しいという仕事をちょっと前にやって、作って納品したからその仕事は終わったんだけど、今度はそれ用にインストーラも作ってくれないかという依頼が来た。

日本語版のインストーラ作成はInstallShieldを使っていて、これは英語版OS(Windows XP)にも対応していた覚えがあったので簡単に作れるだろうと思って引き受けたのだが、結構ハマってしまった。

InstallShield日本語版が英語版OSでも動作すると思ったのがそもそもの間違いで、英語版のPCにセットアップCDを突っ込んでインストールしようとしたら、インストーラの画面が文字化けの嵐。

そこでようやく英語版OS対応というのは意味が違う事に気が付いた。って遅すぎ（笑）。実際には日本語版OS上で英語版のインストーラが作成できるという意味だったのだ。すっかり勘違いしていたよ。

日本語版OSのほうでInstallShieldを起動して、プロジェクト設定で英語を選択したらちゃんと英語版のインストーラが作成できた。案ずるより産むが易し。

でもスタートメニューの設定部分で、選択した言語に関わらず「アンインストール」という思いっきりカタカナなメニューが挿入されるのはいかがなものかと（笑）。そこはちゃんと言語に従ったデフォルトメッセージを入れて欲しかったなぁ。

会社で使ってるのはちょっと古いバージョンだから、最新版だともう少し賢くなっていたりするんだろうか。

このページは xfy Blog Editor を利用して作成されました。

犯人捜し

だいぶ前に開発した装置の制御用ソフトが、あるタイミングで誤動作すると言う報告がきた。

他の仕事で手が離せないし、装置の現物がないのでデバッグできませんよと言って逃げていたんだけど、出社したらいきなり机の前に装置が運び込まれてるし（笑）。しかたがないので記憶を掘り起こしてデバッグしてみたが、どこにも異常なところは見あたらなかった。

どう考えても装置のCPUがデータ送信をサボっているとしか思えないので、ファーム屋のほうに調べて貰うと、ファーム側ではちゃんと送信しているという答えが返ってきた。

確かに実績のあるロジックを使っているから間違いようが無いんだけど、そうすると装置側は正しくデータを送信しているのに、PC側へデータが伝わってこないという妙な事になってしまう。データパケットの消失。ミステリ小説の人体消失よりも、こっちのほうがよっぽど不可解だ（笑）。

装置とPC間はUSBシリアル変換チップ経由で通信を行っているので、残る可能性はUSBシリアル変換チップの不具合しか考えられない。でも使っているのはFTDI社のチップで、実績ありまくりだからいまさら不具合というのも考えにくい。

少なくとも私の作った部分に責任がない事は確実なので、下駄を預けて他の仕事をやっていたらしばらくして犯人が判明。原因はソフトでもファームでもなく、ハードウェアの設計そのものにあった。

特定のタイミングである操作をすると装置内部で盛大にノイズが発生するんだけど、どうもそれが回り込んでUSBシリアル変換チップをダウンさせてしまうらしい。ダウンしたチップはしばらくすると復旧するが、当然その間に送信されたデータは消えて無くなってしまう。

装置のCPU側はデータを送ったつもりでも、PC側には届いてないから動作がおかしくなるのは当然。ノイズが回り込まないように対策を行ったら、ピタリと誤動作が止まった。やれやれ。

この手のバグってホントに分かりづらいな、ハード設計とファームウェアとPCアプリの何処に問題があるのかなんて、一人じゃとても突き止められない。今回は全部社内でやった奴だから良かったけど、これが全部別々の会社で手がけた奴だったらどうなっていた事か。

原因を突き止めるまで半年ぐらいかかっていたな、きっと（笑）。

このページは xfy Blog Editor を利用して作成されました。

極小サーバ

単体でサーバとして動作する組み込み向けの小型モジュールは、なにも考えなくても基板上に載せるだけで装置をネットワーク対応にできてしまうので、色々なところで使われている。

LANTRONIX社のXPortがその代表的な製品で、シリアル－Ethernet変換を単体で行ってくれるから、ワンチップマイコンを使った製品とは非常に相性が良い。実際に今取りかかっている仕事がまさにそれだし、以前に自社で設計した基板にも後付でXPortが載せられるようにパターンが引いてあったりする。

客先からネットワーク対応にできないか？と言われた時に「こんなこともあろうかと」と言っておもむろにXPortを載せるわけだ（笑）。

最近は似たような製品が他にも色々と出てきて、北海道のサイレントシステムが開発した「超小型ワンチップサーバー OS-1」なんかはちょっと面白そうだなぁと思っている。余談だけどその会社の代表取締役は私が高校生の時にお世話になった人で、いま自分がそっち方面の仕事をやっているのは間違いなくその人から多大な影響を受けたせいだ。

それが良かったのか悪かったのか、今となっては分からないけどね（笑）。

もうひとつ気になっている製品があって、最近始めたTumblrでFriends登録している人のページで知ったpicotuxがそれ。開発元はドイツの会社で、見た目はXPortにソックリなんだけど、ARMプロセッサを内蔵してなんとこのサイズでLinuxが動いてしまうのだ。

製品名がpico+tuxってのはあまりにもそのまんまだなぁ（笑）。ええっと、tuxってのはLinuxのマスコットになってるペンギンの事ね。

Linuxと言ってもuClinuxだけど、Linuxで開発した経験があればさほど苦労せずに独自アプリケーションをこの小さなモジュールで動かせるメリットは大きいハズ。

まあXPortでもJavaでそれっぽい事ができるのだが、あれはコンパイルしたオブジェクトがXPortのフラッシュメモリ上に置かれているだけで、実行しているのはクライアント側のJavaVMだからずいぶんと違う。

XPortの方式もサーバ側に負担をかけないという点では、非常に賢いやり方だと思うけどね。

ちょっと前にuClinuxを使う仕事の話が来て、本を読んで勉強していたんだけど結局話が止まったまま先へ進んでないのだが、本格的にやる事になったらこれを使ってみるのも面白いかも知れないな。

でも今のところ日本国内には代理店が無い様子。仕事で使う場合は代理店経由じゃないと色々と面倒な事になるので、早いところどこかが扱って欲しいぞ。若松さんとかツクモロボコン王国さん、取り扱ってみません？（笑）。

このページは xfy Blog Editor を利用して作成されました。

PDF化

休刊してしまった「LinuxWorld」と「JavaWorld」の全記事をPDFで収録したメモリアルDVDブックが昨日発売になったようだ。昼休みに新高円寺の書店へ行っていれば並んでいたんだろうけど、雨で外に出る気が無くなって「日清焼そばU.F.O. スパイシーカレー焼そば」で済ませてしまったから気が付かなかった（笑）。

この手の本って値段が高いのが普通なんだけど、この本はLinuxWorldが2,310円、JavaWorldが1,980円と非常に良心的。何処とは言わないけど1年分の記事を収録したCD-ROM版を13,650円で売っている出版社にはぜひとも見習って欲しいところだ（笑）。

まあ良心的というなら最終号に過去の主要記事を収録したCD-ROMを付けた「LinuxJapan」のほうが上だけどね。しかも著者は自分のPDF記事を自由に配布して良い事になっていたのだ。太っ腹だよねぇ。

休刊してしまった雑誌の全記事PDFがこのぐらいの値段で手に入るんだったら、他にも欲しいのはいっぱいあるぞ。「C MAGAZINE」「DDJ日本語版」「Inside Windows」「プログラマーズページ」が本棚のかなりのスペースを占めているので、これがPDF化されたら喜んで買ってしまうな。

会社にScanSnapがあるんだから、少しずつ持って行って自力でPDF化すれば良いだけなんだけどね。終わるまで5年ぐらいかかりそうだが（笑）。

このページは xfy Blog Editor を利用して作成されました。

ハードとソフト

ただのにっきの6/19の日記コメント欄で、FOSS界ではハードタブ派は迫害を受けるような存在だという事を知ってショックを受ける（笑）。

えぇぇぇぇぇぇぇ、って感じですよホントに。

ってプログラマじゃないと何の事か分からないと思うけど、要するに字下げにTABを使うかスペースを使うかという話で、TABを使うと字下げ幅は各自の環境に依存するけど、スペースを使えば必ず見た目が同じになる。

前者をハードタブ、後者をソフトタブと呼んで、なぜそう呼ぶかというのも歴史的経緯があったりするのだがそれはまあ置いておくとして、どっちが良いかというのは結局の所コードは読むモノなのか読ませるモノなのかという所に収束するんだと思う。

コードを読む時に自分の読みやすいように幅が変えられるほうが良いというのがハードタブ派で、コードを読んで貰う時に自分の書いたとおりに読んで欲しいというのがソフトタブ派。つまり根本的に立場が異なるので、どっちが良いとか論ずるのは無意味だし、それで迫害されるってのも酷い話だ。

まあ迫害ってのは冗談だと思う（思いたい）けどね。

そういえば昔は先頭部分にコメントで「TAB = 4」とか書いてあるコードを良く見かけたんだけど、最近そういう文化は無くなったという事なのかな。まあ書いてあっても無視する奴は無視して自分の好きなタブ幅にしちゃうんだろうけど（笑）。

このページは xfy Blog Editor を利用して作成されました。

doubleとfloat

C言語で実数（浮動小数点）を格納する変数にはdouble型とfloat型の二種類があって、double型のほうが精度が高いし、コンパイラがそっちに最適化されて速度も速いから通常ならfloat型は使わないのだが、組み込みの場合はちょっと事情が違う。

ワンチップマイコン用のコンパイラでもdouble型は扱えるけど、double型は8byte長の変数なのでSRAM領域が小さいマイコンだと如実に響いてくる。PCならメモリがギガとかメガ単位なので8byteぐらいは何でもないが、マイコンはキロバイトだからマジに死活問題。

double型の演算を行う場合にリンクされるライブラリもサイズが大きくなるから、ROM(Flash-RAM)領域も圧迫されてしまう。

という理由でワンチップマイコンを使用した装置でfloat型の変数を使ったんだけど、おかげで大バグを作ってしまった。float型は精度が低いから、小数部の桁数が多くなると値が一致しなくなるのは分かっていたんだが、思っていたよりも有効桁数が小さかったのが敗因。ちゃんと調べてから使わないとダメだなぁ。

なにがどうダメだったのかというと

float a;  float b;  long c;  a = 16.15;  b = 1.80;  a += b;  c = (long)(a * 100);

上記プログラムを実行した場合、変数aには16.15 + 1.80で当然17.95が入るんだけど、それを100倍してlong型の変数cに格納すると、結果は1794になってしまう。つまり17.95 x 100 = 1794というおかしな結果になる。

float a;  long c;  a = 17.95;  c = (long)(a * 100);

ところがこれを上記のように変えると、今度は変数cに正しく1795が格納される。

つまり16.15 + 1.80を計算した結果の17.95と、定数を代入した結果の17.95では見た目が同じでも内部的には異なっていて、前者は誤差が含まれているために100倍すると誤差が拡大されて値の違いが生じてしまうのだ。

c = (long)(a * 100 + 0.001);

上記のように有効桁以下の補正値を加算すれば正しい値になるんだけど、数値がマイナスの時はそれを考慮する必要があるので処理が繁雑になってしまうし、あまり美しくない。

結局float型を使うのはやめにして、全てlong型の固定小数点演算に書き直してしまった。えらく手間はかかったが、これなら誤差が出ないし浮動小数点演算のライブラリをリンクする必要もないから、プロフラムサイズも小さくなる。

あとは仕様追加で三角関数の演算なんかが出てこない事を祈るのみ（笑）。

このページは xfy Blog Editor を利用して作成されました。

XPort

ギリギリっぽかった仕事がどうにか一段落したので、わざわざ秋葉原まで行って買ってきたのに、組み立てたあと放置していたXPort03Rベースキットを引っ張り出してみた。

組み立てた時にシリアルポートをリダイレクトしてネットワーク経由で使うドライバは確認済みなんだけど、JavaアプレットでWebブラウザからXPortの機能を使うのは試していなかったから、そっちをやってみようと思った次第。

客先から装置の設定をWebブラウザ経由でやりたいという案件が出てきたので、それの検証作業も兼ねてという事で。決して遊びではないですヨ（笑）。

Javaでプログラミングするのも久しぶりで、以前にPCがクラッシュした時に開発環境がまるごと無くなってしまったから、改めてsunのサイトからJDKをダウンロード。JDKのバージョンって外部バージョン番号と内部バージョン番号の二種類が存在しているから、ちょっと分かりにくいな。

まあVC++だって「Visual C++ 2005」が内部的には「VC++ 8.0」だったりするので、それと同じと言えば同じか。

JDKをインストールして試しに適当なプログラムをコンパイルしてみると、以前は問題なかったプログラムが何故かNoClassDefFoundエラーで実行できなくなっている。変だなぁと思って調べてみたら、設定した覚えのない環境変数CLASSPATHが設定されているではないか。

どうやらQuickTimeをインストールすると、インストーラが勝手にCLASSPATHを設定してしまうらしい。しかもカレントディレクトリを含まないダメダメな設定だし。

CLASSPATHが設定されていなければデフォルトでカレントディレクトリを参照するから問題ないんだけど、設定されているとそこしか参照しなくなってしまうので、中途半端に設定されてしまうと非常に困った事になってしまう。

appleともあろうものが、いったい何やってんのかねぇ。自分の所のアプリだけが動けばそれで良いのかい。実は何かの嫌がらせか？（笑）。

CLASSPATHを修正してプログラムが実行できるようになったので、XPortに転送して内蔵Webサーバからの実行も確認。これでWebブラウザからXPortのシリアルポートを操作できるようになったから、あとは適当にそれっぽい画面を作ってやればOK。

このページは xfy Blog Editor を利用して作成されました。

英語リソース

MFCベースで作成したプログラムを英語版にする作業はほぼ終わって、ソース中に含まれるメッセージやメニュー及びダイアログのキャプション変更、それに伴うサイズの微調整なんかもすべて完了。

コンパイルしたものを英語版のWindows XPで動かしても、問題無く動作する。

ところが、コンパイルオプションを変えてデバッグ版からリリース版にすると、フレームワークが出力するダイアログのメッセージが文字化けしてしまう。フレームワークが勝手に出しているメッセージだから、どこを修正すれば良いのか初めは分からなくて悩んでしまった。

デバッグ版とリリース版で何が違うのかを調べてみると、リリース版はライブラリをスタティックリンクするように設定してあったので、共有DLLを使用するように変更して再コンパイルすると今度は正常になる。

ということはリンクされるライブラリが間違っているわけで、そのセンで色々と調べてみるとリソースファイル内にLANGUAGEやcode_pageを指定している箇所があった。VC++の日本語版と英語版で空のプロジェクトを作ってリソースファイルを比較して、異なっている部分を元のプロジェクトへ反映させてから再コンパイルすると、今度はリリース版でもメッセージが化けなくなった。一件落着。

プロジェクトの英語化って、とにかくメッセージを全部書き換えてフォント設定なんかも変えればOKだろうと簡単に考えていたんだけど、やっぱり落とし穴があったか。

ところでリソースファイルを比較する時に、Windiffに編集機能の付いたツールがあったら便利だろうと思って探してみると、テキスト比較ができるフリーのエディタ「UnEditor」が見つかった。実際にダウンロードして試してみたんだけど、これは結構便利。

Grepして置換する機能も付いてるし、英語版を作る時に最初からこのツールの存在を知っていれば、もう少し楽に作業ができたのにな。事前調査が足りなかったか。

このページは xfy Blog Editor を利用して作成されました。

リモートデスクトップ

以前にPCから特定の装置を制御するプログラムを作ったんだけど、その装置が海外向けに売られることになったので、制御プログラムも英語版を作ることになった。

日本語版のWindowsで日本語版のVC++を動かした場合でも原理的には英語版のプログラムが作れるはずなのだが、面倒な事態が発生することは100%確実（笑）。なので素直に空きPCに英語版の開発環境を構築したんだけど、他の仕事も平行してやっているからキーボードとマウスを二組並べて操作していると途中で混乱してしまう。

WindowsXPにはリモートデスクトップ機能があるので、試しにそれを使ってやってみたら、思ったよりも良い感じで使えた。多少もたつく感じがあったり、画面の再描画がおかしくなる事もあるんだけど、ストレスが溜まるほどではない。

以前にリモートデスクトップ使って遠隔操作したときはずいぶんとイライラさせられたけど、あの時は公衆回線経由だったから無理もないか。なんせリモートPCは地球の裏側に置かれていたからなぁ（笑）。

その時は必要が無かったので気付かなかったけど、リモート操作している時ってメニューからシャットダウンや再起動ができないので、ちょっと困ってしまった。ログアウトしかできない。

Ctrl+Alt+Delでやろうとしたら当たり前だけどローカルPCのほうにシャットダウンダイアログが出るし（笑）。

調べてみたらリモートPCのシャットダウンはCtrl+Alt+DelではなくてCtrl+Alt+Endらしい。確かにこれだとリモートPCのほうにダイアログが出てくるから、ちゃんとシャットダウンさせることができた。覚えておこう。

このページは xfy Blog Editor を利用して作成されました。

USBスティックタイプ

フリースケール社の開発キットUSBSPYDER08がツクモロボコン王国でキャンペーン販売されていて、秋葉原へ行った時についでに買おうと思っていたんだけど、実際に買いに行った時には既に売り切れ。

この手の開発キットってとにかく広く使ってもらうのが目的だから、売り切れになっても近いうちにまたキャンペーンやるだろうと思っていたんだけど、思った通りまたキャンペーン価格での販売在庫が追加されたようだ。今度は買えるかな？

USBスティックタイプだから他にはケーブルすら不要で、PCのUSBポートに直接挿すだけで開発できてしまうお手軽さは、開発時に机の上がすぐカオス状態になってしまう人には最適（笑）。

だからという訳でも無いと思うけど、最近はこのスタイルの開発ツールが各社から色々と出ていて、ざっと見ただけでもTIのeZ430-F2013、NECのV850が載ったTB0304、78K0S/KA1+が載ったUSBスティックタイプ基板が付録の書籍「はじめての78Kマイコン」というのもある。

今日STマイクロエレクトロニクスから発表されたSTR9-comStickは、ARM966Eコア･ベース32bitマイコンが搭載されたUSBスティックタイプの開発キットで、大容量のFlashとSRAMを内蔵し、イーサネット機能まで搭載しているのに小売価格が$49と格安。

ネットワークにぶら下げるタイプのガジェットを作るには最適なんじゃないかな。

なんかみんなお手頃価格なので、つい買い集めたくなってしまって困るぞ（笑）。そのうちUSBハブにぎっしり各社の開発キットが挿してあるという異様な状態になりそう。

上面にUSBコネクタのあるUSBハブ内蔵キーボードがあれば使うのに便利だと思うんだけど、存在してないんだろうか？テンキー部分の上ぐらいにコネクタがあると良いのに。

このページは xfy Blog Editor を利用して作成されました。

英語版XP

以前に作成した制御ソフトウェアの英語バージョンを作る仕事が来たので、嫌になるほど大量にあるMSDNのCDから英語版のXPとVisualStudioを発掘、作業用のPCにインストールして開発環境を整えた。

XPの英語版をインストールしたのは初めてだけど、手順は日本語版と同一だから特に問題はない。XPのインストール自体は何度やったか分からないぐらいで、もう目をつぶってもできそうなくらいだし（笑）。

インストール完了してちょっと使ってみると、日本語版と比べて英語版は妙にスッキリした感じになっていて、こんなに印象が違うとは意外。同じ画面解像度でもずいぶんと広く感じる。

エクスプローラのメニューが英語表記になってるだけでも違うから、日本語版XPでシステムメニューだけ英語に切り替える事ができれば良いんだけど、それって可能なんだろうか？

英語版のXPで日本語を使う方法は検索するといっぱい出てくるんだけど、その逆で日本語版XPを英語版XPっぽく使う方法というのは見つからなかった。そんなひねくれた事をやろうと思うのは私だけなのか？（笑）。

このページは xfy Blog Editor を利用して作成されました。

Bugtter

Blogで「Twitterを医療や福祉に活用出来るんじゃないか」という話を読んでなるほどなぁと思った。幸いにして今まで入院というものを経験した事は無いのだが（子供の時に事故で指を潰して手術入院した事はある）もし長期入院する事になったら病室にノートPC持ち込んでTwitterやっている事は確実だろう（笑）。

PCの持ち込みが禁止されていなければの話だけどね。

現時点でのTwitterはユーザ数が急増しすぎたせいか反応がかなり鈍くなって、頻繁に猫メンテの画像を見るようになったから、このままだと面白い使い方を思いついても応用できないまま終わってしまうかも知れない。既に複数のTwitter類似サービスが立ち上がっているので、徐々に分散していくのだろうか。

まあそれはそれとして。

Twitterを使い始めた初期の頃から「プログラマー専用Twitter」というのがあれば面白いかなぁと考えていたりする。もっと厳密に言うと「デバッグしているプログラマ専用Twitter」（笑）。

ソフトハウスでプログラマーが机を並べて仕事している時に、各人がなにかブツブツ呟きながらデバッグやコーディングしている姿ってのが、なんとなくTwitter的じゃないかと思ったからだ。そこ、不気味ってゆーな（笑）。

問題点を他人に説明することで解決の糸口が見えるというのはプログラマなら誰でも経験している事だと思うし、結構有効じゃないかと思うんだがどうだろうか？

でも実際に立ち上げたら、90%ぐらいアニメの話題で埋まったりという可能性も（笑）。

このページは xfy Blog Editor を利用して作成されました。

保温

ワンチップマイコンの開発に使っているデバッガがちょっと古めで、OSがWindows98でしか動かないのに加えてインタフェースがPCカードなもんだから、それ専用に古いノートPCを引っ張り出して使っているんだけど、これを使っていると左手が熱くなってくる。

何故かというとノートPCの置き場がキーボードの左側にしか確保できなくて、しかもノートPCの廃熱口が右側に開いているから、温風が左手に直接吹き付けてくるのだ。

冬場でも手にじっとりと汗をかいてしまうぐらい熱いので、お茶を入れたマグカップを廃熱口のすぐ横に置いて温風を遮るようにしてみたら、お茶がなかなか冷めないという副次的効果が（笑）。

以前にUSBでマグカップを保温するプレートを見た時は、こんなもん誰が使うんだと馬鹿にしていたのだが、気が付くとやっていることはあまり変わらなかった（笑）。

まあでもあっちはわざわざUSBから電力取って熱を作り出しているのに対して、こっちは廃熱利用だから言ってみればゴミ焼却炉の熱でお風呂を沸かすようなものなので、ちょっとはマシか？（笑）。

このページは xfy Blog Editor を利用して作成されました。

シリアルEEPROM

昨日の話の続き。

データを圧縮してシリアルEEPROMに読み書きするテストプログラムはどうにか正常に動くようになったので、今日の午前中はそれをメインプログラムに反映する作業を行った。

おおまかに修正した所で試しに動かしてみると、書き込んだデータの照合時にエラーになってしまう。チェックサムの生成で何かミスったか？と思ってソースを念入りに調べてみても、おかしな所は見あたらない。

変だなぁと思ってシリアルEEPROMの中身をダンプしてみたら、書き込んだはずのデータが途中で途切れていて、切れた残りは違うアドレスに書き込まれているという怪現象が。

シリアルEEPROMに書き込むルーチンは以前から使っていたもので、今までは問題無く動いていたから他の部分に原因があるのだろうと思って夕方まで必死にデバッグしてみたのだが、どこをどう変えても現象は同じ。こうなると書き込みルーチンに問題があるとしか思えない。

で、そのライブラリを作成した人に尋ねてみたら、シリアルEEPROM書き込みルーチンは開始アドレスが16byte境界にアライメントされていないと駄目という驚愕の事実が。まじですかそれ。

どうやらシリアルEEPROMの仕様上の制限で、連続書き込み時のアドレスオートインクリメントは16byte境界までしか有効ではないらしい。つまり10byte目から8byteのデータを書き込もうとすると、6byte目を書き込んだあとアドレスの下位4bitがゼロに戻ってしまうので、意図したのとは違うアドレスに書き込まれてしまうのだ。

それでデータが途中で切れて飛んでいるように見えたのか。納得。

実績のあるライブラリだからって、盲目的に信用してはいかんという事だな。まあ想定外の使い方をするほうが悪いと言われればそうなんだけどねぇ。でも動いてるライブラリを使う時に、わざわざハードウェアの仕様書をチェックして制限事項を確認するなんて事は、普通しないと思うぞ。

このページは xfy Blog Editor を利用して作成されました。

圧縮

ワンチップマイコンを使って開発した装置に機能追加を行うことになって、データ量がかなり増大するので計算し直してみたら、データ保持用のシリアルEEPROMに入りきらないことが判明。

基板に載っているのは1024ByteのEEPROMなのに、データ量は単純計算で1500byteぐらいになってしまうから、そのままでは絶対に入らない。

装置で取り扱う数値データは-99999～99999の範囲で、short型では入りきらないから32bit長のlong型にしてるんだけど、実際には18bitで足りるので14bit余る。18bitを上位2bitと下位16bitに分割してパッキングすれば余剰ビットが出ずに済むだろうと思って計算してみると、950byte程度で収まることが分かった。

これならギリギリでどうにかなる。

符号付き数値をビットフィールドに分割したり結合したりする処理はミスを犯しやすいので、VC++で検証用のプログラムを作って充分テストしてからマイコン側のプログラムを作るという、自分にしては珍しく慎重な作業を行ったのだが、それでもハマった（笑）。

ビットフィールドは処理系によって互換性が無いというのを忘れていて、VC++とマイコンのC言語ではビットの詰め方が逆だったから、数値がぐちゃぐちゃに。

まあ並び順を変えただけでちゃんと動くようになったから、ハマり度としては軽微な部類だな。この程度は日常茶飯事だし（笑）。

このページは xfy Blog Editor を利用して作成されました。

コード解析

通信プロトコロルに関する仕様が不明な装置があって、唯一あるのはその装置とPCを接続して制御するためのプログラムソースだけなので、ソースを読んで通信プロトコルの仕様を逆に起こすという仕事が回ってきた。

他人の書いたソースコードの解析なんて、プログラマなら絶対に敬遠したい仕事の一つだと思うんだけど、それがCやJavaじゃなくてVisual Basicで書かれているとなればなおさらだ。

まあVBのプログラムでもちゃんと作ってあればなんとかなるんだけど、送られてきたプロジェクトファイルを開いて思わず絶句してしまった。禁じ手のオンパレードだよ、おい。

ひとつのプロシージャが異様に長くて4ページぐらいあるし、その中でループが何重にもなっていて、おまけにループの中でGoto文が使われている。しかも状態遷移はグローバル変数でスイッチするようになっていて、そのグローバル変数は別なモジュールで非同期にON/OFFされているから、プログラムの動きが全く読めない。

もうそのままゴミ箱へぶちこんで見なかったことにしてしまおうかと思ったよ。マジで（笑）。

さすがにそうもいかないので、結局装置をPCにつないでプログラムを動かして、デバッガで止めたりステップ実行させたりしながらプロトコルを抽出するという原始的な手段でどうにか間に合わせた。

VBのソースコードを変換してDoxygenに喰わせるためのVBDoxygenというアドインも試してみたんだけど、うまく動かなくて時間も無かったので止めてしまった。どっちみち動いても元のソースにDoxygen形式でコメントが付いてないと、あまり意味がないしね。

時間ができたらあとでもう一度やってみよう。

このページは xfy Blog Editor を利用して作成されました。

ウオッチドッグ

以前に開発した表示装置のバージョンアップで、表示するデータの種類が一気に20種類近く増える事になった。

種類が増えてもプログラム自体はそれほど変わらないから、楽勝だろうと思っていたのに予想に反して大ハマリ。プログラム修正してマイコンのフラッシュメモリに書き込み、起動させると初期化中に何故かリセットがかかって、それをエンドレスに繰り返してしまっている。リセット地獄。

データ量が増えたからどっかでメモリを食いつぶして暴走しているのだろうと思って、昨日休日出勤してああだこうだやっていたのだが、原因が全く掴めなかった。

今日出社してマイコンに詳しい人に聞いてみると「ウォッチドッグでリセットがかかっているのでは？」という答えだったので、試しにウォッチドッグを止めてみたらビンゴ！！リセット地獄がピタリと止まった。

プログラムの初期化処理でシリアルEEPROMからデータを読み込んでいるんだけど、データ数が一気に増大したので読み込みに時間がかかるようになり、ウォッチドッグタイマのリセットが間に合わなくなっていたのが原因だった。

シリアルEEPROMの読み出しがこんなにも遅かったとは。

プログラム中では1mSec周期のタスクでウォッチドッグタイマをリセットしているから時間のかかる処理があっても問題無いんだけど、初期化処理はタスクが起動する前だからなぁ。そこで時間がかかってしまうのは致命的。

とりあえず読み書き中はウォッチドッグを停止するようにして逃げたが、あまり良い手では無いのであとからきちんと直すことにしよう。

このページは xfy Blog Editor を利用して作成されました。

スケール感

今やっている仕事と、その前にやった仕事はどちらも7セグLEDを使ったデータ表示装置の開発で、見た目は似たような感じなのだが中身はまるっきり違う。

前回使ったのはモバイルCeleronが乗ったワンボードPCで、OSはLinux。メモリも256MByte乗っているのに対して、今回使っているのはH8マイコンを搭載した自社製基板で、メモリも4KByteしかない。

一応自社製のマルチタクスモニタが走って、C言語で開発しているから感覚的にはあまり変わらないんだけど、うっかりするとリソースの差を忘れてハマる事になる。

というか今日実際にハマった（笑）。

プログラムを組んでいるうちに今まで動いていた部分が動かなくなって、原因が分からないので追加した部分を逆にコメントアウトしていったら、グローバル変数でバッファを定義した所でダメになっている事が分かった。MAPファイルを見てみるとその変数を追加した事で後ろに定義した変数がメモリ領域を越えていたので、それでは動くはずがない。

4KByteのうちスタックとマルチタスクモニタで2KByte使っているのに、更に1KByteのバッファなんか確保したら溢れるのが当たり前なのだが、前の仕事がLinuxベースでメモリ容量なんかほとんど気にしてなかったから、その感覚でうっかりやってしまった。

なかなかこの感覚って切り替わらないんだよね。これだけ長い事多種多様な開発やってるんだから、ターゲットに応じた適切なスケール感に瞬時に切り替わる能力を会得していても良いはずなのに、逆に切り替わりにくくなっている気が．．．．

年とって頭が固くなるってのは、もしかしてこういう事を指すのか？（笑）。

このページは xfy Blog Editor を利用して作成されました。

5x7ドットフォント

以前に開発した7セグLED表示装置に、5x7ドットマトリクスLEDを追加して文字表示も行えるバージョンを作ることになったので、5x7ドットフォントのパターンをネットで探してみた。

できればC言語のソースコードになっていてフリーの奴が良かったのだが、「5x7 Font」で検索してもなかなか見つからない。Google LabsにGoogle Code Searchがあったことを思いだし、そっちで検索してみると今度は一発で出てきた。

C言語の配列形式で定義されているから好都合だったのだが、ライセンスがGPLになっているので、これを使ってしまうと製品のソースコードをGPLにしなくてはならないから、ちょっとマズイ。

目先を変えて「Dot Matrox Font」でぐぐってみると、フリーのTrueTypeフォントで使えそうなのがいくつか見つかったので、それを使ってパターンを生成してしまうことにした。

手作業でデータを起こすのはあまりにもかったるいから、フォントを表示させてドットの有無をスキャンしてデータ化するプログラムをVisual-C++で作成。出力されたデータ配列を表示器のプログラムに組み込んで、どうにかテキスト表示もできるようになった。

データ生成プログラムを作る時間と、手作業でデータを起こす時間とどっちが短かったかは微妙なところ（笑）。でもまぁプログラム化しておけばまた使う機会があるかも知れないし。

元になったフォントには￡とユーロ記号が無かったので、そこだけは手作業で作成したのが、それをどのコードに割り当てるかでちょっと悩んでしまった。割り当ててしまうと本来そこにあった文字は使えなくなってしまうからね。

結局ポンドは「|(縦線)」、ユーロは「^(カレット)」に割り当てる事に落ち着いた。なのでその二文字を含む文字列を表示すると変な事になるのだが、そこはもう「仕様です」という事で押し切ってしまおう（笑）。

このページは xfy Blog Editor を利用して作成されました。